Use of third-party libraries

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Use of third-party libraries

Michael Shepanski-2
On one hand, there's this:

     "A Boost library *should not* use libraries other than Boost or the
C++ Standard Library."
     (http://www.boost.org/development/reuse.html)

On the other hand, sometimes it just seems like common sense. E.g.
Boost.Math uses NTL, MPFR, and others.

Now I'm trying to get quince and its backend libraries
(quince_postgresql, quince_sqlite) into shape for blincubator. The job
of the backends is to liaise between quince and other people's
libraries: libpq and sqlite3. There is no getting around that. So I was
hoping that the prohibition would be waived in this case, as it was in
the case of Boost.Math.

The trouble I have is that quince_postgresql and quince_sqlite are *not*
header-only, and their code that calls libpq and sqlite3 is in .cpp
files. And yet I don't want them to break the boost build for people who
don't need this stuff, and haven't installed either or both of those
third-party libraries.

Any suggestions? Any precedents?

Thanks,
--- Michael


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Andrey Semashev-2
On Wed, Jul 23, 2014 at 3:14 PM, Michael Shepanski <[hidden email]> wrote:

> On one hand, there's this:
>
>     "A Boost library *should not* use libraries other than Boost or the C++
> Standard Library."
>     (http://www.boost.org/development/reuse.html)
>
> On the other hand, sometimes it just seems like common sense. E.g.
> Boost.Math uses NTL, MPFR, and others.
>
> Now I'm trying to get quince and its backend libraries (quince_postgresql,
> quince_sqlite) into shape for blincubator. The job of the backends is to
> liaise between quince and other people's libraries: libpq and sqlite3. There
> is no getting around that. So I was hoping that the prohibition would be
> waived in this case, as it was in the case of Boost.Math.
>
> The trouble I have is that quince_postgresql and quince_sqlite are *not*
> header-only, and their code that calls libpq and sqlite3 is in .cpp files.
> And yet I don't want them to break the boost build for people who don't need
> this stuff, and haven't installed either or both of those third-party
> libraries.
>
> Any suggestions? Any precedents?

The library build scripts should perform auto-detection checks at
build time. I have something like this in Boost.Log, although I test
whether the compiler supports SSE/AVX and whether Message Compiler is
available. But the approach should be similar - you attempt to compile
a test application and set up build macros or select the actual
sources to build from.

You can also take a look at Boost.IOStreams which detect if bzip2 and
zlib are available. Boost.Thread also contains some auto-detection
checks, I think.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Rob Stewart-6
In reply to this post by Michael Shepanski-2
On July 23, 2014 7:14:32 AM EDT, Michael Shepanski <[hidden email]> wrote:

>On one hand, there's this:
>
>   "A Boost library *should not* use libraries other than Boost or the
>C++ Standard Library."
>     (http://www.boost.org/development/reuse.html)
>
>On the other hand, sometimes it just seems like common sense. E.g.
>Boost.Math uses NTL, MPFR, and others.
>
>Now I'm trying to get quince and its backend libraries
>(quince_postgresql, quince_sqlite) into shape for blincubator. The job
>of the backends is to liaise between quince and other people's
>libraries: libpq and sqlite3. There is no getting around that. So I was
>
>hoping that the prohibition would be waived in this case, as it was in
>the case of Boost.Math.

There's no need for a waiver, provided the library builds without the external libraries. If it requires at least one to be useful, then it should not build when none of those libraries is available. Otherwise, your library won't be acceptable.

___
Rob

(Sent from my portable computation engine)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Michael Shepanski-2
In reply to this post by Andrey Semashev-2
On 23/07/2014 9:31 PM, Andrey Semashev wrote:

> The library build scripts should perform auto-detection checks at
> build time. I have something like this in Boost.Log, although I test
> whether the compiler supports SSE/AVX and whether Message Compiler is
> available. But the approach should be similar - you attempt to compile
> a test application and set up build macros or select the actual
> sources to build from.
>
> You can also take a look at Boost.IOStreams which detect if bzip2 and
> zlib are available. Boost.Thread also contains some auto-detection
> checks, I think.

Thanks Andrey.

It seems I'll have to lift my Boost.Build skills quite a bit. Fair enough.

Also I'm thinking that my approach of having separate backend libraries
is not right. The idea had been that a user decides which backend
library to download and build, but that is not going to be happening a
boost context. Everything should be in the "quince" library, every user
downloads it all, and its build script decides which components to build.

Regards,
--- Michael


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Roland Bock-2
On 2014-07-23 14:09, Michael Shepanski wrote:

> On 23/07/2014 9:31 PM, Andrey Semashev wrote:
>> The library build scripts should perform auto-detection checks at
>> build time. I have something like this in Boost.Log, although I test
>> whether the compiler supports SSE/AVX and whether Message Compiler is
>> available. But the approach should be similar - you attempt to compile
>> a test application and set up build macros or select the actual
>> sources to build from.
>>
>> You can also take a look at Boost.IOStreams which detect if bzip2 and
>> zlib are available. Boost.Thread also contains some auto-detection
>> checks, I think.
>
> Thanks Andrey.
>
> It seems I'll have to lift my Boost.Build skills quite a bit. Fair
> enough.
>
> Also I'm thinking that my approach of having separate backend
> libraries is not right. The idea had been that a user decides which
> backend library to download and build, but that is not going to be
> happening a boost context. Everything should be in the "quince"
> library, every user downloads it all, and its build script decides
> which components to build.
Hi Michael,

There's also MySQL and MariaDb and Oracle and TransactSQL and Firebird
and BerceleyDB and I don't know how many else, but a lot. To me it does
not sound like a good idea to have all backends in one giant library.

Just my 2ct.

Regards,

Roland


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Karsten Ahnert-3
In reply to this post by Michael Shepanski-2
On 23.07.2014 13:14, Michael Shepanski wrote:

> On one hand, there's this:
>
>     "A Boost library *should not* use libraries other than Boost or the
> C++ Standard Library."
>     (http://www.boost.org/development/reuse.html)
>
> On the other hand, sometimes it just seems like common sense. E.g.
> Boost.Math uses NTL, MPFR, and others.
>
> Now I'm trying to get quince and its backend libraries
> (quince_postgresql, quince_sqlite) into shape for blincubator. The job
> of the backends is to liaise between quince and other people's
> libraries: libpq and sqlite3. There is no getting around that. So I was
> hoping that the prohibition would be waived in this case, as it was in
> the case of Boost.Math.
>
> The trouble I have is that quince_postgresql and quince_sqlite are *not*
> header-only, and their code that calls libpq and sqlite3 is in .cpp
> files. And yet I don't want them to break the boost build for people who
> don't need this stuff, and haven't installed either or both of those
> third-party libraries.
>
> Any suggestions? Any precedents?

We have in odeint several adapters for several third party libraries.
None of these adapters is build or tested during a normal boost build,
but you can use them manually or test them manually.

I think if you use a similar policy there shouldn't be any problems.
Maybe you can even ship sqlite (I think it is only one source file) and
use sqlite it as a default backend. Of course the licence of sqlite must
then be compatible with the boost license.



>
> Thanks,
> --- Michael
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Michael Shepanski-2
In reply to this post by Roland Bock-2
On 23/07/2014, at 10:54 PM, Roland Bock <[hidden email]> wrote:

> On 2014-07-23 14:09, Michael Shepanski wrote:
>>
>>
>>
>> Also I'm thinking that my approach of having separate backend
>> libraries is not right. The idea had been that a user decides which
>> backend library to download and build, but that is not going to be
>> happening a boost context. Everything should be in the "quince"
>> library, every user downloads it all, and its build script decides
>> which components to build.
> Hi Michael,
>
> There's also MySQL and MariaDb and Oracle and TransactSQL and Firebird
> and BerceleyDB and I don't know how many else, but a lot. To me it does
> not sound like a good idea to have all backends in one giant library.

I don't have any strong opinions about this, and I'm happy to go with the conventional approach -- as soon as I know what that is.

Taking your lead and daring to imagine a future with quince backend code for a great many DBMSes, I ask: what do you propose? Would there be a separate boost/libs/quince_xyz for each DBMS xyz?

Also, what disadvantages do you see in the "one giant library" approach (assuming that its build script chooses which parts to compile, based on the presence of third-party libraries).

Regards,
--- Michael

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Stephen Kelly-2
Michael Shepanski wrote:

> On 23/07/2014, at 10:54 PM, Roland Bock <[hidden email]> wrote:
>
>> On 2014-07-23 14:09, Michael Shepanski wrote:
>>>
>>>
>>>
>>> Also I'm thinking that my approach of having separate backend
>>> libraries is not right. The idea had been that a user decides which
>>> backend library to download and build, but that is not going to be
>>> happening a boost context. Everything should be in the "quince"
>>> library, every user downloads it all, and its build script decides
>>> which components to build.
>> Hi Michael,
>>
>> There's also MySQL and MariaDb and Oracle and TransactSQL and Firebird
>> and BerceleyDB and I don't know how many else, but a lot. To me it does
>> not sound like a good idea to have all backends in one giant library.
>
> I don't have any strong opinions about this, and I'm happy to go with the
> conventional approach -- as soon as I know what that is.

For a data point, the approach in sqlate is to generate strings from the
edsl and delegate the query handling to third party drivers (sqlate doesn't
depend on Qt, but the test does)

 https://github.com/KDAB/sqlate/blob/master/tests/selecttest.cpp

If the interface of your library only creates strings, you can similarly
allow users of it to use the Qt drivers, your drivers from somewhere
separate, something else entirely, or whatever comes out of the ISO DB SG.

Thanks,

Steve.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Andrey Semashev-2
In reply to this post by Michael Shepanski-2
On Wed, Jul 23, 2014 at 5:13 PM, Michael Shepanski <[hidden email]> wrote:

> On 23/07/2014, at 10:54 PM, Roland Bock <[hidden email]> wrote:
>
>> On 2014-07-23 14:09, Michael Shepanski wrote:
>>>
>>>
>>>
>>> Also I'm thinking that my approach of having separate backend
>>> libraries is not right. The idea had been that a user decides which
>>> backend library to download and build, but that is not going to be
>>> happening a boost context. Everything should be in the "quince"
>>> library, every user downloads it all, and its build script decides
>>> which components to build.
>> Hi Michael,
>>
>> There's also MySQL and MariaDb and Oracle and TransactSQL and Firebird
>> and BerceleyDB and I don't know how many else, but a lot. To me it does
>> not sound like a good idea to have all backends in one giant library.
>
> I don't have any strong opinions about this, and I'm happy to go with the conventional approach -- as soon as I know what that is.
>
> Taking your lead and daring to imagine a future with quince backend code for a great many DBMSes, I ask: what do you propose? Would there be a separate boost/libs/quince_xyz for each DBMS xyz?
>
> Also, what disadvantages do you see in the "one giant library" approach (assuming that its build script chooses which parts to compile, based on the presence of third-party libraries).

Monolithic library is not a good solution for distributed binaries.
Once compiled library will require all the DBMSes it was compiled
against and not support any other. E.g. on Linux such library package
will pull all DBMS packages, even though the user might need just one.

I think separate optionally compiled binaries (one backend per binary)
is the preferred solution. That doesn't mean the library source code
and docs must be split, though.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Roland Bock-2
In reply to this post by Michael Shepanski-2
On 2014-07-23 15:13, Michael Shepanski wrote:

> On 23/07/2014, at 10:54 PM, Roland Bock <[hidden email]> wrote:
>
>> On 2014-07-23 14:09, Michael Shepanski wrote:
>>>
>>>
>>> Also I'm thinking that my approach of having separate backend
>>> libraries is not right. The idea had been that a user decides which
>>> backend library to download and build, but that is not going to be
>>> happening a boost context. Everything should be in the "quince"
>>> library, every user downloads it all, and its build script decides
>>> which components to build.
>> Hi Michael,
>>
>> There's also MySQL and MariaDb and Oracle and TransactSQL and Firebird
>> and BerceleyDB and I don't know how many else, but a lot. To me it does
>> not sound like a good idea to have all backends in one giant library.
> I don't have any strong opinions about this, and I'm happy to go with the conventional approach -- as soon as I know what that is.
>
> Taking your lead and daring to imagine a future with quince backend code for a great many DBMSes, I ask: what do you propose? Would there be a separate boost/libs/quince_xyz for each DBMS xyz?
>
> Also, what disadvantages do you see in the "one giant library" approach (assuming that its build script chooses which parts to compile, based on the presence of third-party libraries).

I guess that you would not want to maintain the backends for the umpteen
databases. I don't know what the best approach is. Maybe you provide
backends for the most popular databases and let others provide backends
for the rest? I don't think that there is a precedent for this situation.

Personally, I would prefer the individual repositories. It makes it
easier to distribute the work load and you would not have to decide
which databases to include in the main repositories and which to keep
out. It would therefore also emphasize the vendor neutrality of the main
library.


Regards,

Roland




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Gavin Lambert
In reply to this post by Michael Shepanski-2
On 24/07/2014 01:13, Michael Shepanski wrote:
> Taking your lead and daring to imagine a future with quince backend
> code for a great many DBMSes, I ask: what do you propose? Would there be
> a separate boost/libs/quince_xyz for each DBMS xyz?

I'm not sure exactly how it works but from the modularisation discussion
it's evident that Boost's library structure supports "sub-libraries"
(aka submodules) that exist in the same repository but are built separately.

I suspect what you'll probably want to do would be to create a "core"
submodule that each of the separate backend submodules depend on (each
of those also depending on a single external library as needed), and
then finally a "front-end" top level that doesn't directly depend on
anything but the core, but allows any of the DB-specific backends to be
used with it.

Boost.Numeric seems to be an existing example of a library divided into
submodules.

Boost.Math seems to be an example of a library without submodules that
nevertheless builds multiple output libraries.

I'm not sure which style is "preferred".



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Michael Shepanski-2
In reply to this post by Karsten Ahnert-3
On 23/07/2014 11:11 PM, Karsten Ahnert wrote:
> We have in odeint several adapters for several third party libraries.
> None of these adapters is build or tested during a normal boost build,
> but you can use them manually or test them manually.
>
> I think if you use a similar policy there shouldn't be any problems.
> Maybe you can even ship sqlite (I think it is only one source file) and
> use sqlite it as a default backend. Of course the licence of sqlite must
> then be compatible with the boost license.

Thanks Karsten,

I don't think I could get away with this in my case. The DBMS-specific
code is of a size where it really it should be tested routinely. Also
the idea of a "default backend" doesn't quite fit, since application
programmers need to be aware of which backend they're using, at least at
one point in their code (see
http://quince-lib.com/getting_started/creating_the_database_object.html).

Regards,
--- Michael


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Michael Shepanski-2
In reply to this post by Stephen Kelly-2
On 23/07/2014 11:19 PM, Stephen Kelly wrote:
> For a data point, the approach in sqlate is to generate strings from the
> edsl and delegate the query handling to third party drivers (sqlate doesn't
> depend on Qt, but the test does)
>
>   https://github.com/KDAB/sqlate/blob/master/tests/selecttest.cpp
>
> If the interface of your library only creates strings, you can similarly
> allow users of it to use the Qt drivers, your drivers from somewhere
> separate, something else entirely, or whatever comes out of the ISO DB SG.

Hi Stephen,

Thanks for this but, as with Karsten's suggestion, I don't think I could
get away with it in my case, mainly because of the size of my
DBMS-specific code (quince_sqlite and quince_postgresql), and the size
of the interface between it and the core code (quince). The
DBMS-specific code includes everything about the representation of basic
types, the dialectal differences in SQL, the mechanics of sending
commands "down the wire", interpreting the DBMS's response, and (in the
case of quince_postgresql) buffering output.

Regards,
--- Michael

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Michael Shepanski-2
In reply to this post by Andrey Semashev-2
On 24/07/2014 12:12 AM, Andrey Semashev wrote:
> Monolithic library is not a good solution for distributed binaries.
> Once compiled library will require all the DBMSes it was compiled
> against and not support any other. E.g. on Linux such library package
> will pull all DBMS packages, even though the user might need just one.

Good point.  Okay, so I will avoid monolithic .lib output.  And as you
say, that leaves other questions open:


> I think separate optionally compiled binaries (one backend per binary)
> is the preferred solution. That doesn't mean the library source code
> and docs must be split, though.

Reading this and other responses I realise how many separate questions
are on the table: "Single or multiple output libs?", "Single or multiple
subdirs of boost/libs?", "Single or multiple git repositories?" are all
different questions. But I think we have now answered the first one.

Regards,
--- Michael


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Michael Shepanski-2
In reply to this post by Roland Bock-2
On 24/07/2014 12:28 AM, Roland Bock wrote:
> I guess that you would not want to maintain the backends for the umpteen
> databases.

+1


> I don't know what the best approach is. Maybe you provide
> backends for the most popular databases and let others provide backends
> for the rest?

I'll definitely be doing that, but it leaves open the question of how to
organise it.



> I don't think that there is a precedent for this situation.
>
> Personally, I would prefer the individual repositories. It makes it
> easier to distribute the work load and you would not have to decide
> which databases to include in the main repositories and which to keep
> out. It would therefore also emphasize the vendor neutrality of the main
> library.

I agree that any approach I take should be uniform, i.e. not one
approach for some databases and another approach for others.

I take your point about the benefit of multiple git repositories to aid
distributed development efforts. To be clear: that is separate from the
question "One .lib output or many?", and also separate from the question
"One subdir of boost/libs or many?"

Regards,
--- Michael

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Michael Shepanski-2
In reply to this post by Gavin Lambert
On 24/07/2014 9:23 AM, Gavin Lambert wrote:

> I'm not sure exactly how it works but from the modularisation
> discussion it's evident that Boost's library structure supports
> "sub-libraries" (aka submodules) that exist in the same repository but
> are built separately.
>
> I suspect what you'll probably want to do would be to create a "core"
> submodule that each of the separate backend submodules depend on (each
> of those also depending on a single external library as needed), and
> then finally a "front-end" top level that doesn't directly depend on
> anything but the core, but allows any of the DB-specific backends to
> be used with it.

Currently the "quince" library contains both the "core" and "front-end"
components. I figured that nobody would want one without the other. What
advantage do you see in separating them?


> Boost.Numeric seems to be an existing example of a library divided
> into submodules.
>
> Boost.Math seems to be an example of a library without submodules that
> nevertheless builds multiple output libraries.
>
> I'm not sure which style is "preferred".

Putting together your response and all the other responses, I'm starting
to stabilize on the following set of views:

- I should put just one new directory into boost/libs, i.e.
boost/libs/quince.

- The backend-specific source code should be in subdirs of
boost/libs/quince.

- These subdirs should be separate git modules, in the manner of
boost/libs/numeric/*/ .

- The output should consist of a core quince .lib file, and separate
.lib files for each backend, laid out in the manner of
boost/bin.v2/libs/math/build/*/*/*/*/*.lib.

- boost/libs/quince/Jamfile.v2 should somehow detect which third-party
libraries are present, and build the corresponding backend libraries. If
there are more than zero, it should build the core quince library.

Thanks,
--- Michael


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Michael Shepanski-2
In reply to this post by Andrey Semashev-2
On 23/07/2014 9:31 PM, Andrey Semashev wrote:
> The library build scripts should perform auto-detection checks at
> build time. I have something like this in Boost.Log, although I test
> whether the compiler supports SSE/AVX and whether Message Compiler is
> available. But the approach should be similar - you attempt to compile
> a test application and set up build macros or select the actual
> sources to build from.

So let's say I'm trying to decide whether libpq is installed. Your
suggestion is that I "attempt to compile a test application". So I would
have to tell the compiler the location of libpq's incude directory (and
if I attempt to link then I have to tell the linker the location of the
libpq binary). Now, at the moment, the only way I know these locations
is from the constants "libpq_include_dir" and "libpq_lib_dir", defined
in user-config.jam (see
http://quince-lib.com/preparation/configuring_boost_build.html). So I
might as well test those constants directly, no? Or should I be
determining the "installed" locations of those things by some other means?

> You can also take a look at Boost.IOStreams which detect if bzip2 and
> zlib are available.

Its Jamfile.v2 says:

     # The biggest trick in this Jamfile is to link to zlib and bzip2 when
     # needed. To configure that, a number of variables are used, which must
     # be set by user with 'path-constant' either in Boost's root
Jamfile, or
     # in user-config.jam.


> Boost.Thread also contains some auto-detection checks, I think.

Its Jamfile.v2 says:

     # You need to provide the include path and lib path in the variables
     # PTW32_INCLUDE and PTW32_LIB respectively. You can specify these
     # paths in site-config.jam, user-config.jam or in the environment.

I'm thinking that the only auto-detection I need is inspection of bjam
constants.

--- Michael


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

Andrey Semashev-2
On Thu, Jul 24, 2014 at 11:11 AM, Michael Shepanski <[hidden email]> wrote:

> On 23/07/2014 9:31 PM, Andrey Semashev wrote:
>>
>> The library build scripts should perform auto-detection checks at
>> build time. I have something like this in Boost.Log, although I test
>> whether the compiler supports SSE/AVX and whether Message Compiler is
>> available. But the approach should be similar - you attempt to compile
>> a test application and set up build macros or select the actual
>> sources to build from.
>
>
> So let's say I'm trying to decide whether libpq is installed. Your
> suggestion is that I "attempt to compile a test application". So I would
> have to tell the compiler the location of libpq's incude directory (and if I
> attempt to link then I have to tell the linker the location of the libpq
> binary). Now, at the moment, the only way I know these locations is from the
> constants "libpq_include_dir" and "libpq_lib_dir", defined in
> user-config.jam (see
> http://quince-lib.com/preparation/configuring_boost_build.html). So I might
> as well test those constants directly, no? Or should I be determining the
> "installed" locations of those things by some other means?
>
> I'm thinking that the only auto-detection I need is inspection of bjam
> constants.

Having constants so that the user is able to specify the paths
manually (either in user-config.jam or bjam command line) is required.
However, on Linux (and on other UNIX-like systems as well) there are
standard locations for headers and libs which need not be specified in
the compiler command line. So if libpq is installed but the bjam
constants are not set you might still be able to compile your backend.
In order to check that you'll have to attempt to compile a test
application. Then there is pkgconfig, which can be used to obtain
these paths automatically. It is quite common in Linux and probably
other UNIX-like systems, although I'm not sure. Of course, how far you
are willing to go in inspecting the environment is up to you.

There is another aspect that may require test applications. I don't
know if that's your case but you may have requirements on specific
versions or features of the third party libraries. You can use test
applications to verify that the third party library fulfills your
requirements.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

John Maddock-3
In reply to this post by Michael Shepanski-2
> On 23/07/2014 9:31 PM, Andrey Semashev wrote:
>> The library build scripts should perform auto-detection checks at
>> build time. I have something like this in Boost.Log, although I test
>> whether the compiler supports SSE/AVX and whether Message Compiler is
>> available. But the approach should be similar - you attempt to compile
>> a test application and set up build macros or select the actual
>> sources to build from.
>
> So let's say I'm trying to decide whether libpq is installed. Your
> suggestion is that I "attempt to compile a test application". So I would
> have to tell the compiler the location of libpq's incude directory (and
> if I attempt to link then I have to tell the linker the location of the
> libpq binary). Now, at the moment, the only way I know these locations
> is from the constants "libpq_include_dir" and "libpq_lib_dir", defined
> in user-config.jam (see
> http://quince-lib.com/preparation/configuring_boost_build.html). So I
> might as well test those constants directly, no? Or should I be
> determining the "installed" locations of those things by some other means?

While it can be convenient to have a backdoor that lets the user
explicitly set the path to the lib, on most Unix-like systems those
libraries will be installed in standard location which are searched by
default.  You might want to look at how the multiprecision lib handles
locating gmp, mpfr etc for inspiration.

HTH, John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Use of third-party libraries

John Maddock-3
In reply to this post by Michael Shepanski-2
>> I guess that you would not want to maintain the backends for the umpteen
>> databases.
>
> +1
>
>
>> I don't know what the best approach is. Maybe you provide
>> backends for the most popular databases and let others provide backends
>> for the rest?
>
> I'll definitely be doing that, but it leaves open the question of how to
> organise it.

For me I would have one lib (and repository):

mylib/
   include/
   src/
     backend1/
     backend2/
   build/

But really it's up to you - as long as the structure is clearly
organised and folks can find their way around I don't believe anyone
should beat you up too much about it.  In short use the right
organisation for the job in hand.

HTH, John.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12