2010/12/24 Mateusz Loskot <[email protected]>
> There is a problem which I described as comment to the pull request:
> https://github.com/denisarnaud/soci/pull/1
>
I've updated the 'buried_headers' branch with the (small) directory
structure change: https://github.com/denisarnaud/soci/pull/2
It fixes the compilation issue (there is still another compilation issue,
but apparently not related to whether headers are buried or not).
As for the general discussion, usually, developers include external headers
by prefixing those headers with the name of the corresponding project. For
instance, when referring to MySQL headers, we write:
#include <mysql/mysql.h>
That way, there is no ambiguity: we are referring to the "mysql.h" header of
the MySQL project, not to any such header from any other project such as
SOCI.
That may be obvious when talking about mysq.h, but it is much more ambiguous
when referring to headers such as 'common.h' or 'session.h'...
That way of referring to external headers (by prefixing them with the
project name) allows the compiler to find those headers from standard
installation directories. For instance, MySQL headers are to be found in
/usr/include/mysql. Thus, there is no need for additional compilation flag
to be set when compiling such a program (since '-I/usr/include' is added by
default by numerous C++ compilers).
SOCI headers are installed in /usr/include/soci. That's perfect. So, if we
do not want to play too much with macros in the code, and make any
difference when building SOCI itself compared to when building another
project using SOCI, having the source (or, at least, the headers) in a
sub-directory named 'soci' seems reasonable... and is pretty standard as
well.
In short, I just speak about adding one directory level within the src
directory. For instance, the backends directory would be in '<top
dir>/src/soci/backends'. That is, indeed, the structure you will find in the
'buried_headers' branch (
https://github.com/denisarnaud/soci/tree/buried_headers).
Just my $0.02
Denis
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
