On 9 April 2013 11:46, Vadim Zeitlin <vz-s...@zeitlins.org> wrote:
> On Tue, 9 Apr 2013 03:08:26 +0100 Mateusz Loskot <mate...@loskot.net> wrote:
>
> ML> > ML> 3) Add /soci/soci folder for all public headers
> ML> > ML> Installation by copying: cp -a soci/soci /usr/include
> ML> > ML> will effectively deploy headers buried in /usr/include/soci
> ML> >
> ML> > If we do keep src subdirectory it would really make sense to have the
> ML> > includes in include/soci.
> ML>
> ML> Intentionally or not, you seem to suggest the GNU-style layout, aren't
> you?
>
> I didn't know it was called like this but yes, I like separating (public)
> headers from the implementation files.
I have proposed such separation.
> ML> On the other side, less directory levels makes it easier (quicker) to
> navigate
> ML> and easier to search, shorter paths to type, either in console or
> ML> browsers like NERDTree, or less clicks in IDE.
> ML> So, here my laziness kicks in :)
>
> I don't know about the IDE but having foo.h and foo.cpp in different
> directories often results in *less* key strokes when typing the path to
> them than having them in the same one because you can TAB-complete without
> ambiguity.
I'm not suggesting to keep public .h and .cpp together as we do know.
On the contrary, I'm suggesting separation.
> ML> I find the flattened Boost layout without /include directory a bit
> friendlier,
> ML> as /include would only store soci folder, it feels somewhat artificial.
> ML> There are more sub-folders in /src, just like Boost's /libs,
> ML> but libs is of no meaning for us.
>
> Well, boost layout is really idiosyncratic to boost, I've never seen
> another project that used it and am willing to bet that those that do have
> copied it from boost. I have no idea why did they do it like this but most
> C and C++ projects have either a single directory (which is fine until you
> start having too many files and I think SOCI does fall in this case) or
> include and src subdirectories.
I sense misunderstanding.
We both support separation of public headers form .cpp and internal
(not installed)
headers. We only differ in how to layout the headers.
- you propose GNU-style
{root}/include/soci
{root}/include/soci/soci.h
{root}/src/core
{root}/src/backends
{root}/src/backends/empty
- I propose one level less for headers
{root}/soci
{root}/soci/soci.h
{root}/src/core
{root}/src/backends
{root}/src/backends/empty
The latter is exactly what Boost does, it just renames src to libs:
{root}/boost
{root}/boost/version.hpp
{root}/libs/a
{root}/libs/b
The only known and well-established layout I know is the GNU coding style
which is bound to GNU Autotools. But, it does not mean this is the
only valid one.
IMHO, Boost or any other simple and clear layout is not worse than GNU's.
I admit, I personally stay away of any GNU conventions.
I used to have long running romance with GNU Autotools.
> ML> > But, and sorry for the lack of enthusiasm, it's a bit hard to
> ML> > be excited about all these more or less trivial changes which
> nevertheless
> ML> > risk taking quite some time. Perhaps we could leave the introduction of
> ML> > namespaces until some unspecified later time? :-) Also, notice that
> adding
> ML> > namespaces is backwards incompatible too, e.g. soci::odbc_soci_error I
> ML> > currently use would need to be replaced with soci::odbc::error... Which,
> ML> > BTW, doesn't make much sense considering that we have soci::soci_error
> ML> > instead of just soci::error...
> ML>
> ML> In fact, whatever we discuss and decide as planned has unspecified time,
>
> My joke clearly fell flat but IME of project management postponing
> something without specifying a deadline is just another word for not doing
> it at all.
Apparently, I wasn't clear enough.
There is a common set of goals, but I have my own schedule, you have yours.
I can't and even don't want to set any deadlines on anyone, apart from myself.
It's more sensible to specify what we want to do, divide into feasible tasks
and iterate with small steps, instead of making evil estimation
(http://pragprog.com/magazines/2013-02/estimation-is-evil)
> ML> Back to namespaces,
> ML> I assumed we can forget about compatibilities for SOCI 4 and
> ML> let to carry away ourselves a bit ;-)
> ML> Thus, I thought it may be a good idea to structure SOCI into
> ML> namespaces was perspective some larger number of new types and definitions
> ML> getting into the codebase. IMHO, namespaces increase quality, make
> interfaces
> ML> discoverable and make most aspects of working with code easier on both
> ends,
> ML> developer's and user's.
>
> I am somewhat sceptical about these claims. Clearly, namespaces are nice,
> but I hardly see them as revolutionary, they're not very different from the
> prefixes that all (good) C libraries have been using since 40 years or so.
First, I don't claim they are revolutionary.
They are as better as the old bad C prefixes are worse.
I have worked with projects using
class CustomRdbmsMySqlDataStorePropertyDictionary : public
RdbmsMySqlDataStorePropertyDictionaryBase {};
long enough to build wall around my brain fat enough to hold most
potential anti-namespace attacks :)
> So while namespaces are clearly more elegant and more C++ way of doing
> things, I just don't see what do we gain in practice.
The only reason against proper use of namespaces that I can
take is to keep backward compatibility.
I understand we decide to keep such compatibility, then I'm not
pushing the namespaces idea.
> ML> p.s. One thing, traditionally, SOCI never promised ABI compatibility
> ML> between releases and I personally won't make such promises either.
>
> Yes, I agree here, I don't think SOCI is at the stage where this is really
> important and keeping ABI requires a serious effort. The only thing we need
> to do at this point is to ensure that different versions of SOCI use
> different versions in the SO names of the shared libraries under Unix. I
> don't know if Cmakefiles already take care of this or not.
The build config is set with SOVERSION [1], but similarly to Maciej,
I personally don't attach any great importantce to that.
Historically, SOCI never promised any care about SONAME/SOVERSION,
it was only an added value. If anyone cares, I will welcome
contribution of relevant maintenance.
[1]
https://github.com/SOCI/soci/blob/febbe7cc3684e5051096b7185692084abadc9375/src/cmake/SociVersion.cmake#L22
[2] http://sourceforge.net/mailarchive/message.php?msg_id=26166209
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
