Subject: Re: [Boost-build] [Boost][build] Bjam ordering source $(>) list
From: K. Noel Belcourt (kbelco_at_[hidden])
Date: 2009-06-26 16:02:57
On Jun 26, 2009, at 3:53 AM, Juergen Hunold wrote:
> On Friday 26 June 2009 01:13:26 K. Noel Belcourt wrote:
>> I guess what I'm wondering is why are all the exe (and dependent)
>> sources (object and libraries) lumped into $(>)? Perhaps the follow-
>> on question is: given that the objects and libraries in the exe rule
>> sources are all in $(>), can we apply a stable sort to $(>) so that
>> the objects precede the libraries while retaining the original
>> relative ordering. This will help us on systems where we don't have
>> a multi-pass linker nor options like start / end group.
>> Does that make any sense?
> At least for me, yes.
> I've encountered a similar problem while implementing response file
> for gcc on windows. I ended up extrating the libs from $(>) and
> passing them
> to the build rule. Unfortunately, I have historical circular
> I attach the relevant part of my gcc.jam patch for completeness.
> I would like to know more about building the sources of $(>), too.
Thanks for the push, I dug in a bit more to see how sources $(>) are
populated for the link action.
In builtin.jam, linking-generator.generated-targets() is the place to
alter what ends up in $(>), and in what order. For my problem, I
separated the OBJ sources from all other sources so I could place the
OBJ before STATIC_LIB, etc... The fix turned out to work beautifully
as you can see here.
My Fortran executable link action was being passed two libraries
before it sees the object containing the main, leading to my link
object(file-target)@15922 object(file-target)@16343 object(file-
target)@23952 object(file-target)@2015 object(file-target)@2286 object
The actual OBJ file that I need to appear first in $(>) is actually
the third entity in the list ( object(file-target)@23952 ). With
the attached patch, the OBJ is now the first source in $(>), as you
can see here.
object(file-target)@23952 object(file-target)@15922 object(file-
target)@16343 object(file-target)@2015 object(file-target)@2286 object
This patch moves all objects before non-objects and retains their
respective relative ordering, so as not to break the dependency
Anyone think this is this worth committing to Boost.Build?
I appreciate your insight Jurgen!
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