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