Re: [Boost-build] Named metatarget parameters

Subject: Re: [Boost-build] Named metatarget parameters
From: Vladimir Prus (ghost_at_[hidden])
Date: 2010-03-06 04:26:00

On Monday 01 March 2010 11:11:14 Johan Nilsson wrote:

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

Good idea. Will do so.

> - 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"
>     ;

I was thinking about this, including interaction with the 'project' rule,
and don't know the best solution :-(.
The above looks great, but there's the motivating example that prompted
this email, and it is this:

 lib boost_math_long
     : parsers.cpp # By position
     : [ requirements <link>static ]
     : [ require-target-builds has_long_long : "skipping boost.math long long" ]
     ;

This 'require-target-builds' thing is supposed to 

- try building has_long_long target in the same Jamfile 
- if it fails to build, skip boost_math_long, outputting the specified
  message

It seems that for this case, we cannot avoid brackets -- since otherwise the syntax
becomes completely ambiguous. Does mixing styles, as follows:

 lib boost_math_long
     : parsers.cpp # By position
     : requirements <link>static
     : [ require-target-builds has_long_long : "skipping boost.math long long" ]
     ;

Seem reasonable?

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

Good point.

> 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
>     ;

Will dropping ":" make syntax too confusing?

Thanks,

--
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build: http://boost.org/boost-build2