From: David Abrahams (dave_at_[hidden])
Date: 2003-03-05 15:53:13
Rene Rivera <grafik666_at_[hidden]> writes:
> [2003-02-26] David Abrahams wrote:
>>Rene Rivera <grafik666_at_[hidden]> writes:
>>> I made some time to work on the modifier ideas I had. The basic approach
>>> one borrowed from V1 in which there are modifiers to mutate the
>>> of targets, files, etc.
>>> I thought I'd post some of the code I have so far, to get some feedback
>>> to request help. I'm currently stuck because of a current limitation of
>>> The way the current code works it wraps some basic target types (EXE only
>>> for now) with a generic generator that mutates the target. Unfortunately
>>> this produces multiple possible transformations for a single target,
>>> causes an error...
>>> in select-dependency-graph from module generators
>>> error: 2 possible generations for Can't handle this now.
>>> Attached is the code in question. Uncompress while at the BOOST_ROOT.
>>Somehow I missed the original discussion of this functionality. Is
>>the point to be able to define features which change the build
>>properties of the target? Or is it to change other aspects of the
>>target, like the target filename, which have not been, up till now,
>>features in the Boost.Build sense?
> Either, the point is to be able to define changes to targets orthagonally to
> toolsets. I don't want to write how to name files with a version number for
> every toolset, as is the case in V1.
> Oh, and there wasn't much original discussion :-)
>>The only example I saw was the version modifier; do you have any
> On other I can immediately think of is to more cleanly, from a user UI
> perspective, support adding features like Python module support. That is,
> instead of having the $(PYTHON_*) vars like in V1, or the extra target for
> module, you can instead have a <python-module> feature with a modifier that
> inserts all the needed includes, changes the extension, etc. without having
> to touch the toolsets themselves.
How is this different from what we do for STLPort support?
If we really do need modifiers, can toolsets just be a special case
of modifiers? It seems like there are too many ways of doing similar
-- Dave Abrahams Boost Consulting www.boost-consulting.com
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