Re: [boost] Interface for configuring third-party dependencies

Subject: Re: [boost] Interface for configuring third-party dependencies
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2010-10-20 04:13:36

Rene Rivera wrote:

> On 10/7/2010 2:39 PM, Vladimir Prus wrote:
>> Rene Rivera wrote:
>>
>>> On 10/7/2010 11:20 AM, Vladimir Prus wrote:
>>>> Second, it will  possible to specify external dependencies in user-config.jam,
>>>> or any other configuration file. This approach is slightly more complicated,
>>>> as one has to edit a config file, but retains configuration and permits
>>>> to specify multiple configuration for an external dependency -- which
>>>> is not possible using environment variables. Roughly, the syntax will
>>>> be:
>>>>
>>>> using zlib
>>>>               : condition<target-os>windows
>>>>               : include-path whatever
>>>>               : library-path something-else
>>>>               ;
>>>>
>>>> The 'condition' parameter specifies when this declaration will be picked up.
>>>> Other parameters mirror the environment variables above.
>>>
>>> Since this is the replacement for the external library support extension
>>> I have..
>>
>> Actually, as I've mentioned on IRC, it's not a replacement. Your extensions
>> allow to build external project -- this is mostly an interface how to specify
>> the location of pre-built things.
> 
> The problem I see with that is that those will collide with my
> extensions for building from source. And IIRC there are some Boost libs
> with external dependencies that allow sources already (which builds the
> library). More concretely.. I can't have both this prebuilt declaration,
> and mine for zlib:
> 
> using zlib : 1.2.3 : $(ROOT)/sdk/zlib ;

Well, you can't have exact same declaration, but it's possible to have this:

        using zlib : source $(ROOT)/sdk/zlib ;

Actually, it's probably reasonable to ask whether we want to support building
from source for all external libraries, or for select ones, and if the latter,
how do we decide? Supporting build from source for all libraries might easily
become troublesome -- especially, if those libraries are being actively developed.

> I'm assuming you will have some utilities for specifying things like the
> version number of libraries since it's important some times to build
> code against specific versions. Right?

That's a good question. I did not had it in my original plan. The primary
problem I see is that a project might specify a certain version, while
user-config.jam might not specify any, and:
- requiring that user always specify version, especially for system libraries,
is annoying
- detecting the version automatically might be tricky.

What do you suggest?

>>> I have one question.. Where would support for configuring the
>>> "variation" (i.e. what settings to use when the library/ies are used)
>>> fit in the above? Or is the above only for pre-built libraries?
>>
>> I assume you mean usage requirements of library targets?
> 
> No.
> 
>> At this level,
>> they don't exist -- this interface is meant to specify where to find
>> the library, and the actual implementation (e.g. zlib.jam) is responsible
>> to define appropriate targets (e.g. /zlib//zlib) so that their usage
>> requirements are right. In particular, in about all cases usage requirements
>> should contain<include>whatever property, as otherwise complication
>> again the library will fail.
> 
> Right, which I already do in my extensions utility. Hopefully you will
> also define library specific features to be used as conditions.

Can you clarify this "used as conditions" part?

> 
>> Does this make sense?
> 
> Yes, but it doesn't answer my question entirely ;-) So I would say...
> Please come up with a syntax that allows for both pre-built and
> source-to-build libraries to be supported. In case it's useful my
> extension utilities take the form:
> 
> using /name/ : /version/ : /location/ + : /options/ * ;
> 
> I.e. similar to how we configure toolsets. Where /options/ are in the
> form of arg options (--enable-xyz, --disable-xyz, --with-xyz=val).

Well, my proposed syntax differs from above in that 'version' and 'location'
are not positional parameters, but rather specified by name -- must like
your 'options'.

- Volodya