Re: [jamboost] Stages and multiple names

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-07-24 08:59:10

Hi Pedro,

Pedro Ferreira wrote:

> I've attached a new version: I am now restoring the original name after
> constructing the targets. Hope this is ok.

Yep, that's ok. 

> > One question though. If I have
> >
> > exe a : a.cpp :
> > <variant>debug:<tag>_d
> > <variant>release:<tag>_r
> > <link>shared:<tag>_d
> > ;
> >
> > what names will be created when I run "bjam debug link=static" and "bjam
> > profile"? Won't it be the same name?
>
> Yes, they will. But if you define something like:
>
> ...
> <variant>debug:<tag>_d
> <variant>release:<tag>_r
> <variant>profile:<tag>_p
> <link>shared:<tag>s
> ...
>
> you'll get different names for each (debug release profile) * (static
> shared) combination: a_d, a_ds, a_r, a_rs, a_p, a_ps.

So, in theory it's possible to confuse different targets, but probably it's 
not a problem in practice, especially as V1 seem to have the same behaviour. 

> > "Methods for declaring expectation" item to table of content and read the
> > second paragraph. The main idea is that you specify Windows suffixes and
>
> test
>
> > system adjusts them as needed.
>
> Thanks. I always try to avoid getting RTMs but I deserved this one ;-)

:-)

> Please let me know if this implementation is correct or if I should change
> anything.

I've comitted your patch. Thanks!

I have some considerations on topic:

1. The copyright on tag.py is not correct. Would you mind if I replace my name 
with yours?

2. Currently, "tag" does not work on "stage" rule. But maybe it's not that 
important.

3. There are other ways how 'tag' could have been implemented. One approach 
would be to use a special generator which is used when there's 'tag' 
property. In fact Rene has written some classes to support such a approach.

I've decided to apply your patch as it is, since
- it your patch works on any main target, while if using other approach, it 
would work only for targets which use generators. 
(Dave, if you recall, we once discussed the idea to eliminate all classes 
derived from basic-target,
to make all generators classes concrete, and introducing some new entity to 
handle "smarts" in build process. This sounds like additional motivation. We 
could have a "Builder" which is selected when there's "tag" property).

- it's simple and has a test, so even if we decide to move "tag-name" rule 
somewhere else, we can easily do so.

Thanks again,
Volodya