Re: [Boost-build] Named metatarget parameters

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 
audience(!)

- 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