Re: [Boost-build] CVS: boost/tools/build/v2/build generators.jam, 1.100, 1.101 targets.jam, 1.197, 1.198

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-09-21 10:09:16

Hm, almost missed your reply :-(

Vladimir Prus wrote:
> On Monday 07 August 2006 10:00, Rene Rivera wrote:
> 
>>> Hmm, I start to think what you did could be done simpler. You can modify
>>> gcc linking generators, so that for runtime-link=static it returns
>>> nothing. Then, you can modify typed-targets so that when generators
>>> return nothing, warning is emitted instead of error (probably, just for
>>> Boost). Then, you won't need new generators method, as well as some of
>>> the changes you made.
>>>
>>> This approach would simplify the code; though I still don't agree with
>>> target skipping approach.
>> Hm, I wonder if an easier solution is to have the gcc toolset add a
>> "<build>no" to the properties. Is that possible? It would seem to solve
>> all the problems of skipping targets and dependents.
> 
> I'm not sure what you mean. We can add
> 
>     <toolset>gcc,<link>shared,<runtime-link>static:<build>no
> 
> to top-level requirements, so that if such combination won't be ever built.

Well kindof, what I meant is can we make the toolset itself add that to 
targets. There seem to be a variety of time when the toolset itself 
needs to impose such constraints on what gets built. I did this in BBv1 
with the toolset::requirements rule. And I thought that was the overall 
intent of the custom gcc generator. So the overall question:

How do we impose build requirements from a toolset?

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo