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