Re: [boost] Use of third-party libraries

Subject: Re: [boost] Use of third-party libraries
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-07-25 04:07:33

On July 25, 2014 2:53:34 AM EDT, Michael Shepanski <mps_at_[hidden]> wrote:
>On 24/07/2014 7:56 PM, Roland Bock wrote:
>> On 2014-07-24 04:35, Michael Shepanski wrote:
>>> - 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.
>> Sounds good to me except for the last item.
>>
>> Assuming there is no backend for the database I am interested in, I
>> might want to have quince core in order to develop that backend. I
>> therefore think that quince core should always be built.

+1

>In that case, sooner or later you're going to have to tweak quince's
>jam file, to make the building of your backend contingent on the presence
>of some third-party library (fron MySQL or Oracle or whatever).

If the backend is never contributed to Boost, but only used for in-house development, there's no need to modify a jamfile. Other build systems can be used for such backends.

>Now the item you object to has the effect of forcing you to do this 
>sooner rather than later. I would argue that that's no real hardship, 
>and I was all ready to say it's outweighed by Rob Stewart's statement 
>that "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."

I hadn't considered the use case Roland mentioned when I wrote that.

>However:
>
>I'm coming around to Karsten Ahnert's idea that I should ship sqlite.
>(I wouldn't call it a "default backend", as Karsten does, because 
>application code still has to make a choice -- but that's just a
>quibble.).

You can do that but as yet another backend.

>In this way I meet your wishes *and* Rob's *and* Karsten's. Win win
>win.

Mine and Roland's should be merged.

>All that remains is this point from Karsten:
>
>> Of course the licence of sqlite must then be compatible with the
>boost license.
>
>Sqlite is totally unrestricted (http://www.sqlite.org/copyright.html). 
>So would my distribution of it have to carry a boost licence? And if
>so, will there be complaints that I'm restricting something that should 
>be unrestricted?

IANAL, but I don't see any problem including sqlite as is.

___
Rob

(Sent from my portable computation engine)