From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-05-17 03:53:00
On Sunday 06 April 2008 22:18:43 Vladimir Prus wrote:
> Boost.Build allows one to build several variants in one go, and
> there are two ways to specify those variants on the command line:
> 1. Implicit. If you specify, say
> link=static link=shared <other properties>
> then two builds will be done:
> link=static <other properties>
> link=shared <other properties>
> 2. Explicit. You can specify:
> link=static/whatever=foo link=shared/something=bar
> The second method is well, more explicit, but it has the problem with
> the following:
> Of course, we can use greedy parsing for include to make this work, but
> then 'include' must be at the end, and there's no way to specify more
> than one path feature. We could try to use other separators, but given
> that free features can contain anything, that's not very nice. Maybe,
> we can require quoting, like this:
> Any other ideas? Maybe, a completely different syntax? Say
> bjam link=static include=/usr/foo/bar -- link=shared something=whatever?
> This last syntax in theory makes it possible to build different targets with
> different properties, though I'm not sure I want to support it.
> Or maybe we should just disallow this fancy syntax, and use only implicit way
> to build several variants?
We discussed this with Jurko on IRC. To rehash:
1. There's the issue that, for example,
does not work, as we think there are three features been specified, "location=" and "tmp"
and "foo", and of course, none of those is a valid feature, nor meant to be.
2. Implementing greedy parsing for values of free features might work, but then only
a single free feature can be used in "/"-separated bit.
3. The current semantics of "/" separated features is building isolated property sets,
bjam g=v a=b/c=d a=x/c=y
will build everythin in just two variants
g=v a=b c=d
g=v a=x c=y
whereas without "/", we'd build 4 variants. This behaviour is not very common.
4. Using quoting for values is tricky given the number of various shells that do
So, the conclusion is to break current "/" syntax and make the new syntax be:
bjam [options] [targets] [properties] ( "--" [targets] [properties] ) *
Here, the "--" token separates independent groups of targets and properties.
Inside a given group of targets/properties, properties are specified as:
No "/" is allowed. Just as now, it's OK to specify several targets, or several values
for a given feature, inside one group. The shortcut of:
will still work. The only behaviour that will not be possible in the new scheme is
specifying features that will apply everywhere. That is, my original example of
bjam g=v a=b/c=d a=x/c=y
would have to be written as:
bjam g=v a=b c=d -- g=v a=x c=y
with "g=v" duplicate. This does not seem like a very bad thing to me, given that
building several groups of features appears to be rare thing.
Any objections before I go an implement/document this?
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk