Re: [Boost-build] [bbv2][serialization] Feature Validation Problem

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2006-05-24 11:07:37

David Abrahams wrote:
> "Bojan Resnik" <resnikb_at_[hidden]> writes:
> 
> >> Concerting <stdlib>, one possible approach is to go to property.jam, rule
> >> expand-subfeatures-in-condition, and adjust the hardcoded list of non-checked
> >> features.
> >>
> >> The thing is, I believe that hardcoded lists like this should have at most two
> >> elements, and adding <stdlib> will make it three-element list, so maybe we
> >> need to start looking for a general solution.
> >>
> >> - Volodya
> >
> >   How about disabling validation in conditions altogether? Validation
> > is a problem espesially for dynamically extended features. For
> > example, I have a feature that detects all installed versions of a
> > tool on the client machine, and extends the feature <tversion> with
> > the detected versions. Some projects might require conditions such as
> > <tversion>2.0:<define>T_2, which produce validation errors when run on
> > machines that do not have tool version 2.0 installed. Instead, it
> > should simply evaluate to 'false', when <tversion> is not 2.0.
> 
> That sounds right to me.

Seconded.

It would also be useful for the <os> feature, allowing:

   lib foo : foo.cpp : <os>LINUX ;
   lib foo : bar.cpp : <os>CYGWIN ;

without any special machinery.

However, are there any situations where validating features is useful?

What about:

   bjam gcc-4.1

when your user-config.jam just defines gcc-4.0?

How about this as well:

   flags compile <optimization>yes : -opt ;

It may be useful to make condition validation errors into warnings
that are off by default (enabled by --validate-conditions, or something)
to pick up errors like the above, but not to stop the build.

- Reece
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/