[Boost-build] Interface for configuration framework

Subject: [Boost-build] Interface for configuration framework
From: Vladimir Prus (ghost_at_[hidden])
Date: 2010-03-17 05:03:13

Folks,

now that we've more or less decided how named parameters should look, then
next question is how the interface for configuration framework should work.
To remind, the goal is to perform various checks of environment, and
decide what should be built and how based on that -- and, importantly,
have a simple and consistent interface for that.

Here's how a zeroeth approximation look like:

        exe long_double_check : has_long_long.cpp ;

        lib boost_math_tr1l : ...sources... :
           [ check-target-builds long_double_check : : <build>no ] ;

The 'check-target-builds' thing takes three parameters -- target id,
"true-properties" and "false-properties". When boost_math_tr1l metarget
is generated, the long_double_check will be also generated and immediately
built. If the built is successfull, then 'true-properties' will be added
to build properties for boost_math_tr1l -- and 'false-properties' will
be added otherwise. So, the above code has the effect of skipping
boost_math_tr1l is the long_double_check target fails to build.

For avoidance of doubt -- this actually already works now. Contrary
to what I have though before, it's not even a big change.

This example illustates something that I think is an important point --
separation between actual checks, and logic that alters build of
other targets. Here, "long_double_check" is the actual check.
On the other hand, use of "check-target-builds" allows to adjust
any metatarget depending on the outcome of the test -- and the
test does not have to be repeated.

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

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?

Thanks,

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