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

Subject: Re: [boost] Interface for configuring third-party dependencies
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2010-10-07 22:13:38

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 ;

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?

>> 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.

> 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).

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail