Re: [Boost-build] Interface for configuration framework

Subject: Re: [Boost-build] Interface for configuration framework
From: Vladimir Prus (ghost_at_[hidden])
Date: 2010-03-19 02:44:56

On Wednesday 17 March 2010 18:25:12 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" ;

I agree that we should be able to use any metatarget for checking.

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

That's good idea. On the other hand, I need to check that relative project
ids work as expected now. I.e:, if you use:

        project math ;

I should make sure that /boost/math//whatever still works.

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

Of course. It's actually done right now (in SVN), by keying all checks
on <toolchain>. I think the final solution would have to key on
toolchain + version + target-os + target-arch.

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

Oh, apparently the name is bad. The idea it to check for third-party libraries --
like zlib. I was imagine that we'd have 'zlib.jam' and it would have 'get' function
that will return targets and usage requirements necessary to use zlib, with a
twist

- If there's explicit 'using zlib' somewhere already, just return whatever is
specified there
- If no explit 'using zlib' is given, attempt to find zlib in system directories,
and return that.

Is there some other name that will better reflect this behaviour? I was thinking
about 'check-library' -- but then, on the backend of this system I envision
separate 'ac.check-library' and 'ac.check-header' functions -- that check for
just library file and header file, respectively, while 'check-library' checks
for both, or more than one of each. On the other hand, backend functions
can be called 'ac.check-library-file' and 'ac.check-header-file' respectively,
removing the confusion.

Thanks,

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