Re: [Boost-build] creating a second linker target, map output from the linker

Subject: Re: [Boost-build] creating a second linker target, map output from the linker
From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2012-09-02 02:43:26

   Hi.

> I'd like to output a map file from the gcc linker to the bin directory.
> I can easily output a map file to the source directory like this:
>
>     exe demo
>        : # sources
>          ...
>        : # requirements
>          <linkflags>"-Xlinker -Map=demo.map"
>        ;
>
>
> But how can I compute the bin output directory when adding the linkflag?

   This can not be done at that location since when your exe target gets 
defined you do not know its complete property set, and its target 
location is calculated only after all of its properties have been collected.

   I believe the /correct/ way to do this would be to define a new 
incidental mapfile feature, and teach the gcc toolset to produce the map 
file in its generators the same way msvc toolset does it for PDBs. 
However, if you just want to hack through this /one special occasion/, 
something like this might do the trick:

> import targets ;
> import property-set ;
> import path ;
>
> exe x : x.cpp : <conditional>@x-rule ;
>
> rule x-rule ( properties * )
> {
>     local t = [ targets.current ] ;
>     local p = [ $(t).project ] ;
>     local ps = [ property-set.create $(properties) ] ;
>     local path = [ path.join [ $(p).build-dir ] [ $(ps).as-path ] demo.map ] ;
>     path = [ path.native $(path) ] ;
>      return <linkflags>"-Xlinker -Map=$(path)" ;
> }

   This is a quick quick-fix attempt, and I have not played around with 
it for more than 5 minutes so there might be a better way to do this. 
Hopefully someone else can suggest one if this is so...

   Here, your property gets defined using an indirect conditional rule. 
Such rules get called only later, as a final step in determining a 
target's final property set. We then manually reconstruct the target 
path there.

   Note that the target file name is hardcoded. You could reconstruct 
that as well from the target but not in a real generic way since you 
would need the exact virtual-target created by this target for that and 
I do not think they have been constructed yet at this time.

   Note also that this code may get called multiple times for a single 
target so be careful about any side-effects like changing global 
variables and such. This is just a side-effect of how 
indirect-properties are calculated (to cover the case when one such 
property affects other such properties).

   Hope this helps.

   Best regards,
     Jurko Gospodnetić