Subproperty valiidity

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Subproperty valiidity

Boost - Build mailing list
In the Boost Build manual it states in section 5.8.2:

"Subproperty validity may be restricted so that certain values are valid
only in the presence of certain other subproperties. For example, it is
possible to specify that the <gcc-target>mingw property is only valid in
the presence of <gcc-version>2.95.2."

However it does not explain how to specify, or enforce, such subproperty
validity. How can this be done in Boost Build ?

As a practical example if I have:

feature.subfeature toolset gcc : std : c03 c11 c14 c17 : optional
composite propagated ;

feature.compose <toolset-gcc:std>c03 : <cxxflags>-std=c++03 ;
feature.compose <toolset-gcc:std>c11 : <cxxflags>-std=c++11 ;
feature.compose <toolset-gcc:std>c14 : <cxxflags>-std=c++14 ;
feature.compose <toolset-gcc:std>c17 : <cxxflags>-std=c++1z ;

I might want to allow:

b2 toolset=gcc-8.3-c17

but I might not want to allow:

b2 toolset=gcc-4.8-c17

Is there a way of enforcing this by some jam code in my user-configf.jam
file ?


_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Subproperty valiidity

Boost - Build mailing list
AMDG

On 7/27/19 7:18 AM, Edward Diener via Boost-build wrote:

> In the Boost Build manual it states in section 5.8.2:
>
> "Subproperty validity may be restricted so that certain values are valid
> only in the presence of certain other subproperties. For example, it is
> possible to specify that the <gcc-target>mingw property is only valid in
> the presence of <gcc-version>2.95.2."
>
> However it does not explain how to specify, or enforce, such subproperty
> validity. How can this be done in Boost Build ?
>
> As a practical example if I have:
>
> feature.subfeature toolset gcc : std : c03 c11 c14 c17 : optional
> composite propagated ;
>

If it works, which I'm somewhat doubtful about, as I was
unaware this this was possible, the syntax would be:

feature.subfeature toolset gcc-8.3 : ... ;

> feature.compose <toolset-gcc:std>c03 : <cxxflags>-std=c++03 ;
> feature.compose <toolset-gcc:std>c11 : <cxxflags>-std=c++11 ;
> feature.compose <toolset-gcc:std>c14 : <cxxflags>-std=c++14 ;
> feature.compose <toolset-gcc:std>c17 : <cxxflags>-std=c++1z ;
>
> I might want to allow:
>
> b2 toolset=gcc-8.3-c17
>
> but I might not want to allow:
>
> b2 toolset=gcc-4.8-c17
>
> Is there a way of enforcing this by some jam code in my user-configf.jam
> file ?
>

In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Subproperty valiidity

Boost - Build mailing list
On 7/27/2019 10:05 AM, Steven Watanabe via Boost-build wrote:

> AMDG
>
> On 7/27/19 7:18 AM, Edward Diener via Boost-build wrote:
>> In the Boost Build manual it states in section 5.8.2:
>>
>> "Subproperty validity may be restricted so that certain values are valid
>> only in the presence of certain other subproperties. For example, it is
>> possible to specify that the <gcc-target>mingw property is only valid in
>> the presence of <gcc-version>2.95.2."
>>
>> However it does not explain how to specify, or enforce, such subproperty
>> validity. How can this be done in Boost Build ?
>>
>> As a practical example if I have:
>>
>> feature.subfeature toolset gcc : std : c03 c11 c14 c17 : optional
>> composite propagated ;
>>
>
> If it works, which I'm somewhat doubtful about, as I was
> unaware this this was possible, the syntax would be:
>
> feature.subfeature toolset gcc-8.3 : ... ;

I can do:

feature.subfeature toolset gcc-8.3 : ... ;

feature.compose <toolset-gcc-8.3:std>c03 : <cxxflags>-std=c++03 ;
feature.compose <toolset-gcc-8.3:std>c11 : <cxxflags>-std=c++11 ;
feature.compose <toolset-gcc-8.3:std>c14 : <cxxflags>-std=c++14 ;
feature.compose <toolset-gcc-8.3:std>c17 : <cxxflags>-std=c++1z ;

and Boost Build does not complain of any error, but when I now invoke:

b2 toolset=gcc-8.3-c17 ...

the gcc.init rule eventually gets called with 'version' equal to
'8.3-c17' and all other values as empty, even though there is no toolset
definition which says:

using gcc : 8.3-c17 : etc ;

Of course this happens after the gcc-init rule is called for valid gcc
toolsets, but still handling an imaginary toolset is not what any init
rule should have to do.

BTW your debugger is superb ! Can I suggest, while I have your
attention, a 'break' command which just lists the breakpoints which have
been set ?

>
>> feature.compose <toolset-gcc:std>c03 : <cxxflags>-std=c++03 ;
>> feature.compose <toolset-gcc:std>c11 : <cxxflags>-std=c++11 ;
>> feature.compose <toolset-gcc:std>c14 : <cxxflags>-std=c++14 ;
>> feature.compose <toolset-gcc:std>c17 : <cxxflags>-std=c++1z ;
>>
>> I might want to allow:
>>
>> b2 toolset=gcc-8.3-c17
>>
>> but I might not want to allow:
>>
>> b2 toolset=gcc-4.8-c17
>>
>> Is there a way of enforcing this by some jam code in my user-configf.jam
>> file ?

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