Re: [Boost-build] Interface for configuration framework

Subject: Re: [Boost-build] Interface for configuration framework
From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2010-03-19 03:51:47

Vladimir Prus wrote:
> On Thursday 18 March 2010 12:28:23 Johan Nilsson wrote:
>
>> Vladimir Prus wrote:

[snip]

>>> This example illustates something that I think is an important point
>>>
>>> However, this interface does not make it easy to emit sensible
>>> messages.
>>> It would like to see this when building:
>>>
>>> Performing configuration checks
>>>
>>>         - long double       : no
>>>
>>>    Component summary
>>>
>>>          - math             : building
>>>                               long long libraries skipped
>>>
>>>
>>> And for that to work, we need to specify more detail, e.g:
>>>
>>> check-exe long_double_check "long double" : has_long_long.cpp ;
>>>
>>> lib boost_math_tr1l : ...sources... :
>>>    [ check-target-builds long_double_check :
>>>          : <build>no <message>"long long libraries skipped"
>>> <component>math ] ;
>>>
>>> Does this seem passable? I think that adding 'human name' to
>>> long_double_check target is not an issue, but the
>>> check-target-builds interface makes me nervous.
>>
>> It doesn't look very obvious and is more verbose than desired, IMHO.
>> Just to make things worse I started playing around a bit with a more
>> "familiar" interface (probably a couple of syntax errors around
>> here):
>>
>> ---
>>
>> probe-target long_double_check
>>     : sources
>>       has_long_long.cpp
>>
>>     # We should really have something called "attributes" or
>>     "properties" - # labelling the below properties "requirements"
>> doesn't feel quite right ...
>>
>>     : requirements
>>     <type>exe
>>     <displayname>"long double"
>>     ;
>>
>> lib boost_math_tr1l
>>      : ...sources...
>>      : requirements
>>
>> <target-builds>long_double_check/<component>math/<message-fail>"long
>> long libraries skipped"
>>     ;
>
> I am not sure what I think about this approach. It introduces yet
> another
> mini-language, which is probably hard to extend should we need so,
> while
> a function can get a new parameter relatively painlessy

I don't think it's a "mini-language" - the example just uses property paths?
It's admittedly ugly though.

>> ---
>> or:
>> ---
>>
>> [snip definition of long_double_check]
>>
>> alias long_double_check_for_math
>>     : long_double_check
>>     : requirements
>>     <component>math
>>     <message-fail>"long long libraries skipped" ;
>>
>> lib boost_math_tr1l
>>      : ...sources...
>>      : requirements
>>     <target-builds>long_double_check_for_math
>>     ;
>
> This means you need quite considerable code for each component/target
> that is checking for a given property.

Well, assuming math sets the component as you mentioned as a possible
solution:

lib boost_math_tr1l
     : ...sources...
     : requirements
    <target-builds>long_double_check/<message-fail>"long long libraries
skipped"
    ;

I don't feel having to define the "check-target" for boost_math_tr1l
out-of-line being a big nuisance. A bit more typing, but could lead
to more readable code IMVHO.

>
>> which might enable conditional stuff such as:
>> ---
>>
>> alias long_double_check_for_math :
>>     long_double_check
>>     : requirements
>>     <component>math
>>     <message-fail>"using emulated long long libraries"
>>     <message-ok>"using native long long libraries"
>>     ;
>>
>> lib boost_math_tr1l
>>      : ...sources...
>>      : requirements
>>
>>
>>
>> <target-builds>long_double_check_for_math:<library>native_long_double
>> <target-builds-not>long_double_check_for_math:<library>emulated_long_double
>> ;
>
> Well, this is already possible in my proposal, with:
>
> [ check-target-builds long_double_check : <library>native_long_double
> : <library>emulated_long_double ]

That looks nice (for the simpler case).

>
>> (yes, there are details to be fleshed out)
>>
>>> I guess that <component> can be a requirements in Boost.Math
>>> Jamfile, so that
>>> it's not repeated for every target that might need configure checks,
>>> leading to:
>>>
>>> lib boost_math_tr1l : ...sources... :
>>>    [ check-target-builds long_double_check :
>>>          : <build>no <message>"long long libraries skipped" ] ;
>>>
>>> Also, it might be good to provide a less generic mechanism for
>>> skipping a
>>> target, for example:
>>>
>>> lib boost_math_tr1l : ...sources... :
>>>    [ demand-target-builds long_double_check : "long long libraries
>>> are skipped" ] ;
>>>
>>> How does that look? Again, it assumes <component>math is in
>>> Boost.Math requirements.
>>
>> The latter, simple, case looks ok. I agree with Spencer's comment
>> about
>> using "require" instead of "demand", though.
>
> I'm a bit concerned about using 'require' naming for anything that is
> part
> of "requirements" -- sounds like double "require" qualifier.

Yeah. That's why I originally suggested changing "require-target-builds" to
... " : requirements [ target-builds ..."

I'm also not sure about "requirements ... demands ..." not being kind of a
semantic duplicate.

>
>>> Another question is about naming. I assume the most common checks
>>> will be 'does this target builds' and 'is 3rd party library XXX
>>> available'. And there are two variants for each check -- one were
>>> you can specify true-properties and false-properties, and one that
>>> just skips a target. So far, I propose this naming:
>>>
>>> check-target-builds <target> : <true-properties> :
>>>    <false-properties> ; demand-target-builds <target> : message ;
>>>
>>>    check-module <module-name> : <true-properties> :
>>> <false-properties> ; demand-module <module-name> : message ;
>>>
>>> Does this naming sufficiently reflects the differences in semantics?
>>
>> As above - "require" fits better that "demand". Also, just to add
>> some alternatives:
>>
>> check-target-builds => target-builds
>> check-module => module-exists
>
> This looses the semantic bit of "we're checking". "target-builds"
> sounds like
> a statement.

No, "build-target" would look like a statement :)

> Hmm, I wonder whether "if-builds" is a better name, for
> it
> more directly reflects what is happening.

Perhaps. This looks rather nice for the simpler cases:

lib foo
    : foo.cpp
    : requirements
    [ if-builds has_native_bar : <library>native-bar : <library>own-bar ]
    # or perhaps "if-else-builds" or "if-builds-else" to be even
    # more explicit
    ;

lib foo
    : foo.cpp
    : requirements
    [ if-not-builds has_native_bar : <build>no <message>"needs native bar
library" ]
    ;

(as a sidenote here, I believe that it should be possible to express a build
failure in these requirements, e.g. "<build>fail")

Perhaps even the usage of "builds" is to restricted as we can use all sorts
of targets here, such as test targets which report success according to
actually running specific tests - what about
"if-succeeds"/"if-fails"/"if-succeeds-else", e.g.:

lib foo
    : foo.cpp
    : requirements
    [ if-succeeds find_library <name>pthread : <searched-lib>pthread :
<build>no <message>"can't find pthreads library" ]
    # Note usage of "named argument" to find_library as first implied by
Steven in this thread
    ;

(To go even further: what about lambda-style "if_", "if!_" (or "unless_")?
But that would probably be taking things a bit too far :)

I was then thinking about the more complex cases then, where you might have
to pass specific requirements to the "check" target. An example:

lib foo :
    : foo.cpp
    : requirements
    [ if-builds has_native_bar
        : <library>native-bar
        : <library>own-bar
        : requirements <link>static <toolset>gcc
<runtime-link>static:<define>RTLSTATIC ]
    ;

A bit chatty perhaps, but not that bad actually. Also I guess that one could
potentially do it the same way I suggested when using e.g. <target-builds>
property above:

lib has_native_bar
    : has_native_bar.cpp
    ;

alias has_native_bar_for_foo
    : has_native_bar
    : requirements
    <link>static
    <toolset>gcc
    <runtime-link>static:<define>RTLSTATIC
    ;

lib foo :
    : foo.cpp
    : requirements
    [ if-builds has_native_bar_for_foo : <library>native-bar :
<library>own-bar ]
    ;

Would this be possible?

Regards / Johan