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

From: Rene Rivera (grafik666_at_[hidden])
Date: 2003-02-25 11:05:28

[2003-02-25] Vladimir Prus wrote:

>Ee... the 'name-modifier' generator has '<name-modify>yes' as requirements,
it
>should be preferred to generic linker. There are three problems:
>
>1. The <name-modify> is not optional, so the default value is added to
build 
>request. Later <name-modify>yes is added too, so there are two different
>values. Not sure this is the real problem yet.

I see you fixed that. I coun't immediate see how to fix this, so thanks :-)

>2. The generator matching works in this way. All generators are asked for 
>their rank w.r.t specific properties. If generator returns nothing, it
can't 
>work. Otherwise it returns a number: the larger the number, the more 
>specific the generator is. Requirements are used to check if generator
>can work. To boost specificity, optional properties are used: now the match
>rank is equal to the number of optional properties which are present in
build 
>properties. 

So the "optional-properties" rule is the one that makes the modifier more
specific now? I'll read up on those rules then.

>3. When cloning the target, you don't clone the action. The problem is that 
>action has a back pointer to all it's targets, so cloning just target does 
>not work. Your comment which reads:
>
> # Need a MUTCH better way to clone a target...
> # ...Or a way to mutate an existing target safely.
>
>Is *extremely* right!

Ah totally unaware that the action was part of it also :-(

>After addressing those problem I get the following:
>
>MkDir1 bin
>MkDir1 bin/gcc
>MkDir1 bin/gcc/debug
>MkDir1 bin/gcc/debug/main-target-hello
>gcc.compile bin/gcc/debug/main-target-hello/hello.o
>gcc.link bin/gcc/debug/main-target-hello/hello.1.0
>
>Which looks sane. I attach the diff to your version as well as new version
of
>modifiers.jam. Now the issues are:

Than you :-] It works as I hoped! ... I wasn't totally sure the right thing
would come out of the target.

>1. Cloning of targets should become separate rule, unless we want bugs all 
>over the place (current stage.jam uses the same).

Definitely... but what about the other choice I mention in my comment? Can a
target, as returned by the "run" rule be safely modified without cloning it?
In the name-modifier case I could not because there is no way (that I know)
of changing the name of the target.

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq