From: Pedro Ferreira (pedro.ferreira_at_[hidden])
Date: 2003-07-22 05:57:30
I finally had some time to implement <tag>. Comments and/or suggestions are
I've attached two diffs and one simple test.
- Added a free feature 'tag'.
- Added a 'tag-name' rule to 'basic-target', which tags a name according to
- basic-target's generate rule calls 'tag-name' before calling construct.
BTW, I'm not sure what's the best way to handle dll and exe suffixes across
different platforms in the tests. Any suggestion or pointer to an example?
----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>
Sent: Wednesday, July 09, 2003 9:56 AM
Subject: Re: [jamboost] Stages and multiple names
> [2003-07-08] Vladimir Prus wrote:
> >Hello Pedro,
> >> If not, and if you think it is worth it, I am avalable to try and
> >> it.
> >Thanks a lot for your attitude! If you're willing to implement <tag>
> >most welcome. Of course, I'll be glad to help.
> >I've actually almost forgotten the details about <tag> feature and I
> >V1 it works not only in stage targets, but also in regular targets (like
> Yes, it works on any main target.
> >So I guess it's better to start by asking Rene how it works in V1 and
> making a
> >short description of proposed V2 semantic, so that everybody could be
> >what's going to be implemented. What do you think?
> >Rene, I'm specifically interested why we need tag in regular targets
> >stage targets.
> Answering that last one first... It's needed in regular targets because
> is the way, in V1, that it stages linked targets (DLLs, EXEs) directly to
> the stage dir. Doing the link step again but with the staged name is
> required because various platforms use the name for linking and loading.
> The basic mechanism is to map feature names that appear in the target to
> strings which get inserted between the basename and extension of the final
> target name. For example <tag><debug>_debug, checks if the "debug" is in
> subvariant spec of the target and appends "_debug" to the name. Or to put
> in one sentence. It maps the features in the target subvariant to suffix
> strings on the target file name.
> It's very simple code, as much is in V1, the naming is done in
> boost-base.jam/rename-target rule. Surprisingly it's documented ;-)
> For V2 we already have the linking directly to the stage (if I remember
> correctly). So it's only the naming that's needed, and the interface to
> The naming part I intended to use the modifier concept. -- The current
> modifiers implementation is a placeholder ;-) -- But basically if we can
> integrate some sort of target modifier (name/propeties/sources/etc) into
> target building. We can then write the <tag> support in terms of it.
> Hmm, I just realized I'm rambling... it's late, and I need sleep... ask
> questions if the above doesn't make much sense.
> -- grafik - Don't Assume Anything
> -- rrivera (at) acm.org - grafik (at) redshift-software.com
> -- 102708583 (at) icq
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
------=_NextPart_000_022E_01C35048.6DAAE6D0 Content-Type: application/octet-stream;
[Attachment content not displayed.] ------=_NextPart_000_022E_01C35048.6DAAE6D0 Content-Type: application/octet-stream;
[Attachment content not displayed.] ------=_NextPart_000_022E_01C35048.6DAAE6D0 Content-Type: text/plain;
# Copyright (C) Vladimir Prus 2003. Permission to copy, use, modify, sell =
# distribute this software is granted provided this copyright notice appea=
# all copies. This software is provided "as is" without express or implied
# warranty, and with no claim as to its suitability for any purpose.
from BoostBuild import Tester, List
t =3D Tester()
exe a : a.cpp : <tag>x ;
lib b : a.cpp : <tag>y ;
stage c : a ;
file_list =3D List("bin/$toolset/debug/main-target-ax/ax") + List("bin/$too=
lset/debug/main-target-by/by.so") + List("c/ax")
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