Re: [Boost-build] Checking for property values...

Subject: Re: [Boost-build] Checking for property values...
From: Brian Ravnsgaard Riis (brian_at_[hidden])
Date: 2009-01-05 13:41:55

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steven Watanabe wrote:
> AMDG
> 
> Brian Ravnsgaard Riis wrote:
>> Given
>>
>>     if [ property.select <some_feature> : $(properties) ] in
>>         value1 value2 value3 and_so_on
>>     {
>>         ...
>>     }
>>
>> The ... part gets evaluated if <some_feature> has a value in the list,
>> but also, it seems, if <some_feature> is not present in properties at
>> all. Is this intentional? I need the branch to execute only if
>> <some_feature> is present *and* is one of value1 value2 etc.
>>   
> 
> This is an artifact of the way "in" works:
> 
>> From 
> http://www.boost.org/doc/tools/jam/jam/language.html#jam.language.flow_of_control
> 
> 
> |/a/ in /b/|
> 
>    true if all elements of /a/ can be found in /b/, or if /a/ has no
>    elements

Ah, I missed that. So it *is* intentional.

> The easiest way around this is to create a named variable:
> 
> local values = [ property.select ... ] ;
> if $(values)-is-defined && $(values) in value1 value2 ... {
> }

I tried with a double-lookup, and that worked, but a named variable is
probably better. However...

It turns out that the underlying problem is not that an empty property
is caught by "in", but that the property is empty at all.

<some_feature> above is actually two features, and the jamfile is called
wxwidgets.jam, Rene's stab at a wx-extension for Boost.Build.

In rule setup_h there is a clause:

        if [ property.select <architecture> : $(properties) ] in
            sparc power mips1 mips2 ...
        {
            define-1 += WORDS_BIGENDIAN ;
        }

I discovered this issue, because "#define WORDS_BIGENDIAN 1" appeared at
the top of the generated "wx/setup.h" header, but I'm on an AMD
processor, which is certainly not big-endian, and not in the list. But
<architecture> is not in $(properties), so that explains that.

Further up in the same rule there is a switch clause on

        [ property.select <target-os> : $(properties) ]

Same thing again. <target-os> is not in $(properties). Actually
inserting a "ECHO $(properties) ;" reveals that only the wx-extension
properties are in $(properties). Assuming the extension file worked for
Rene, at some point $(properties) must have also contained properties
for <target-os>, <architecture> and likely <toolset>, <variant> and all
the rest. Where did they go? And how do I get them back? :-S

 /Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJYlRzk1tAOprY6QERAqghAKDQe+bX5NGCpPeLA2rKc3HtqMOsygCfbnlN
cRILJla21tmL1iMWfDNsJPE=
=Hk//
-----END PGP SIGNATURE-----