On 9 April 2013 23:13, Vadim Zeitlin <vz-s...@zeitlins.org> wrote:
> 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.
No worries.
> 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?
What about keeping them next to related .cpp files?
I assume private headers are never included directly from the public
ones that user #include <soci/...h>
> 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?
Nah, argument of "unpopularity" never makes a good reason to me and
I have learned my own lessons that proved it :-)
(http://www.davemacleod.com/shop/9outof10climbers.html)
...if Steve Jobs had followed what was common... ;-)
Anyway, I sense compromise is close, let's not lose heart
> 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 ;-)
My motivation is as simple as that: one less unnecessary level
makes the layout simpler and simpler is just better.
No need to split hair and discuss details of personal workflows
(I started that I admit, but it's weak argument).
> 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?
My idea of {root}/soci or {root}/include/soci is to reserve it for public
headers only. Isn't it that GNU conventions suggest it too, by the way [1]
First, AFAIK, {root}/include is commonly dedicated to keep almost the same
content as that installed into {prefix}/include.
Second, I consider private headers having the same role as .cpp files:
"Files that are used in constructing the library, but are not
installed" [1], so I
keeping them next to public headers might be confusing.
[1] http://gcc.gnu.org/onlinedocs/libstdc++/manual/source_organization.html
On the other hand, such headers may be shared by multiple library
modules (i.e. core and backends), then common location makes sense.
It also might be easier to keep definitions of public and private interfaces
together, grepping and browsing for types in single space (no need to
filter .h only),
newcomers may find it easier to learn what are public and what private parts.
It's the kind of modularisation I like myself too.
Shall we compromise on this then?
{root}/include/soci
{root}/include/private
{root}/src
{root}/src/core
{root}/src/backends
{root}/tests
{root}/docs/
...
And I still can cp -a {root}/include/soci /my/prefix/include to
install SOCI headers :)
> 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.
Sure, good and best practices are transitive :)
> 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
Sure, it's on me, no problem.
> 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.
Sounds good.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
------------------------------------------------------------------------------
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
