Re: [Boost-build] Specifying several property sets on the command line

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:
> 
> 	link=static/include=/usr/foo/bar
> 
> 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:
> 
> 	link=static/include="/usr/foo/bar"/something=whatever
> 
> 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,

        location=/tmp/foo

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,
for example

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

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:

   feature=value1

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:

   feature=value1,..,valueN

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?

- Volodya