Feature Validation Problem

"Bojan Resnik" <resnikbgmail.com> 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.


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On Wednesday 24 May 2006 18:51, David Abrahams wrote:
> "Bojan Resnik" <resnikbgmail.com> 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.

This was just implemented and checked in.

- Volodya

-- 
Vladimir Prus
http://vladimir_pru
s.blogspot.com
Boost.Build V2: http://boost.org/boost-
build2
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build