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
> 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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk