Boost logo

Boost-Build :

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ć


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