Re: [Boost-build] Interface for configuration framework

Subject: Re: [Boost-build] Interface for configuration framework
From: Spencer E. Olson (olsonse_at_[hidden])
Date: 2010-03-17 13:10:29

My two cents for now:  

1.  change 'demand-module' to 'require-module' following the macro names in 
Boost.Test.

2.  Being able to use all targets as checks would be better and attaching 
additional 'configuration properties' via the new 'named parameters' 
interface is fine (as Steve suggested):
exe long_double_check : has_long_double.cpp : <config-name>"long double" ;
By being able to use any target, then we can use some 'run' targets for 
configuration as well.

Spencer

On Wednesday 17 March 2010 09:25, Steven Watanabe wrote:
> 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
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost-build