Re: [jamboost] [BB2] Modifiers, some progress towards version support...

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
> is
>>> one borrowed from V1 in which there are modifiers to mutate the
> generation
>>> of targets, files, etc.
>>>
>>> I thought I'd post some of the code I have so far, to get some feedback
> and
>>> to request help. I'm currently stuck because of a current limitation of
> BB2.
>>> 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,
> which
>>> causes an error...
>>>
>>>
> /home/grafik/CVSROOTs/Boost/boost/tools/build/examples-v2/../new/generators.jam:811:
>>> 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
>>other use-cases?
>
> 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
things.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com