Boost logo

Boost-Build :

Subject: Re: [Boost-build] Named metatarget parameters
From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2010-03-01 03:11:14

Vladimir Prus wrote:
> I am thinking of introducing named parameters to metatarget rules
> along the lines of the following:
> lib program_options
> : parsers.cpp
> [ requirements <link>static ]
> [ usage-requirements <define>BOOST_ALL_NO_LIB=1 ]
> [ default-build <variant>release ]
> [ description "Does something about dashes on command line" ]
> [ license "BSL 1.0" ]
> ;
> I expect the current syntax to remain available forever, but make this
> new one the officially documented. You might note the example uses
> some attributes ('description', 'license') that are not even
> available now,
> and in fact adding a pile of optional attributes is the primary goal
> here.
> Internally, this will be implemented by introducing special classes
> that are returned by rules like 'requirements' and specially processed
> when encountered in the list of sources.
> Before I go and implement this, would anybody be willing to critizie
> my experiments in DSL design?

First: I see where this's coming from, it took me quite some time learning
the order and arity of the "standard" metatarget parameters and I guess I'm
not the only one. So I guess it's a problem that needs some attention. This
is no "criticism", but some comments and perhaps some feed for thought:

- Cross-post to the developer's list to get the attention of a wider

- The above example looks a lot "messier" than current usage due to the
angle brackets. It looks less declarative and perhaps a bit more imperative;
IMHO one of Boost.Jam / Boost.Builds greater strengths is the declarative
nature of (most parts) of the jamfiles. As an example try to take a look at
SCons build files which also tend to suffer from the imperative vs
declarative problem, IMVHO.

- The "project" rule already makes use of named parameters but in another
fashion, using the first value of each parameter to "dispatch" and collect
the remaining values for the parameter. This would look cleaner (avoiding
the square brackets), and it could be possible to allow a mixture between
positional and named attributes (similar to what Boost.Parameter does):

lib program_options
    : parsers.cpp # By position
    : requirements <link>static
    : usage-requirements <define>BOOST_ALL_NO_LIB=1
    : default-build <variant>release
    : description "Does something about dashes on command line"
    : license "BSL 1.0"

- Downside with the above approach is that it's potentially hard to visually
"parse" which one of the values are parameter names and which one's are not.
I however do not think that this should be a problem in practice - the
project rule has always been easier to use. Another possibility would be to
add the convention of recognizing a tag at the end of parameters to
distinguish them as parameter names, a couple of ideas:

    : requirements: <foo>bar <bar>foo
    : requirements= <foo>bar <bar>foo
    : requirements=> <foo>bar <bar>foo
    : requirements-> <foo>bar <bar>foo

- I guess you are, at least not very explicitly, mentioning one of the
reasons for going the route of passing by named parameter _objects_ though;
you would like to be able to pass an arbitrary numbers of
attributes/parameters, which is not possible with bjam. Right? With the
above approach it would be possible to use a syntax like this:

lib program_options
    : # sources
      parsers.cpp # By position
    : # named properties
      requirements: <link>static
      usage-requirements: <define>BOOST_ALL_NO_LIB=1
      default-build: <variant>release
      description: "Does something about dashes on command line"
      license: "BSL 1.0"
      version: <major>1 <minor>0 <build>4321

Just my 0.05EUR.

Regards / Johan

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at