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
>>> 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?
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk