Boost logo

Boost-Build :

From: Pedro Ferreira (pedro.ferreira_at_[hidden])
Date: 2003-07-24 09:23:51


Hi Volodya,

> > 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.

I didn't want to add a policy but just a means to do it.

> > Please let me know if this implementation is correct or if I should
change
> > anything.
>
> I've comitted your patch. Thanks!

Great, 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?

Please do it.

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

Agreed.

> 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.

Please feel free to add or remove it whenever you want.

Thanks again,

Pedro

 


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