Re: [Boost-build] Interface for configuration framework

Subject: Re: [Boost-build] Interface for configuration framework
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2010-03-17 11:25:12

AMDG

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

I'd like to be able to use any rule for checking, so it would
be nice if there were a generic way to attach this extra
information to any target.  For example:

exe long_double_check : has_long_double.cpp : <config-name>"long double" ;

or

exe long_double_check : has_long_double.cpp ;
config-check long_double_check : "long double" ;

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

Can you use the project id instead of <component>?
Also, would it be reasonable to ask that the messages
printed be unique.  I don't really want to see 8 copies
of every message when I build all variants.

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

What does check-module do?  I'm guessing that it
checks for a BBv2 module?

In Christ,
Steven Watanabe