Re: [Boost-build] Named metatarget parameters

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

Vladimir Prus wrote:
> 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" ]
>>>   ;
>>>

[snip]

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

Why not:

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

(Assuming that target-builds is a 'requirement', which it at least looks 
like).

[snip]

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

In the above example, how would you then differ between the property name 
and values? I kind of like it as is, even though it would in practice mean 
that we're overloading the ":" symbol. However, there's still the problem 
with calling rules "inline":

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
    require-target-builds: has_long_long : "skipping ..."
;

The above would be no good as "skipping..." would be passed as an argunent 
to the lib rule instead of require-target-builds (and it doesn't look good 
either). This would of course be possible:

lib program_options
    : # sources
    parsers.cpp # By position
    : # named properties
    requirements:
    <link>static
    [ require-target-builds has_long_long : "skipping ..." ]
    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
;

... but looks even messier. Perhaps the first one (i.e. example after the 
"Why not:" above) would be a reasonable candidate?

/ Johan