On Tue, 9 Apr 2013 14:35:43 +0100 Mateusz Loskot <mate...@loskot.net> wrote:
ML> > I didn't know it was called like this but yes, I like separating (public)
ML> > headers from the implementation files.
ML>
ML> I have proposed such separation.
Yes, sorry, I didn't imply that you didn't. BTW, a question: where should
we put private headers, i.e. those that don't need to be installed? I
believe it's better to have them in a different directory or at least a
specially named subdirectory, what do you think?
ML> We both support separation of public headers form .cpp and internal
ML> (not installed) headers. We only differ in how to layout the headers. -
ML> you propose GNU-style
ML>
ML> {root}/include/soci
ML> {root}/include/soci/soci.h
ML> {root}/src/core
ML> {root}/src/backends
ML> {root}/src/backends/empty
Yes. The advantages of this that I see are that we keep the source files
where they are (so no changes to [c]makefiles or any custom projects or
whatever people might be using to build SOCI) and that, IME, this layout is
much more common.
ML> - I propose one level less for headers
ML>
ML> {root}/soci
ML> {root}/soci/soci.h
ML> {root}/src/core
ML> {root}/src/backends
ML> {root}/src/backends/empty
ML>
ML> The latter is exactly what Boost does, it just renames src to libs:
Yes. But who else does it like this? I honestly can't think of any
examples right now. So IMHO it has a disadvantage of being surprising
because it's relatively unusual. And the only advantage listed so far was
that it avoided having an almost empty "include" directory with just "soci"
directory. To which I can give 2 contradictory counterarguments:
1. Having almost empty directories is not a problem. In fact, completing
include/soci/soci.h takes exactly the same number of key strokes as
soci/soci.h because you can press TAB immediately after "i" in the
former case while you need to enter "so" to avoid ambiguity with "src"
in the latter ;-)
2. We can avoid keeping it empty by putting our private headers there. Or
maybe have include/private subdirectory to make it even more explicit.
In fact I rather like this convention, what do you think?
And what other advantages does this approach have?
ML> The only known and well-established layout I know is the GNU coding style
ML> which is bound to GNU Autotools.
FWIW I'm pretty sure this was a de facto standard for Windows program
sources organization for a very long time so I don't think it's specific to
autotools.
ML> > ML> p.s. One thing, traditionally, SOCI never promised ABI compatibility
ML> > ML> between releases and I personally won't make such promises either.
ML> >
ML> > Yes, I agree here, I don't think SOCI is at the stage where this is
really
ML> > important and keeping ABI requires a serious effort. The only thing we
need
ML> > to do at this point is to ensure that different versions of SOCI use
ML> > different versions in the SO names of the shared libraries under Unix. I
ML> > don't know if Cmakefiles already take care of this or not.
ML>
ML> The build config is set with SOVERSION [1], but similarly to Maciej,
ML> I personally don't attach any great importantce to that.
ML> Historically, SOCI never promised any care about SONAME/SOVERSION,
ML> it was only an added value. If anyone cares, I will welcome
ML> contribution of relevant maintenance.
Unfortunately I just can't force myself to dive into this CMake stuff so I
won't be contributing to this part but from a cursory look it does seem
like it should ensure that ABI-incompatible versions of the library have
different SO versions which is the thing that really counts.
Regards,
VZ
pgp72GO2MoaNu.pgp
Description: PGP signature
------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________ soci-devel mailing list soci-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/soci-devel
