Boost logo

Boost-Build :

Subject: Re: [Boost-build] [Boost][build] Bjam ordering source $(>) list
From: K. Noel Belcourt (kbelco_at_[hidden])
Date: 2009-06-26 16:02:57

Hi Jurgen,

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
> support
> for gcc on windows. I ended up extrating the libs from $(>) and
> passing them
> to the build rule. Unfortunately, I have historical circular
> dependencies.
> 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
(file-target)@8052 object(file-target)@8568

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
(file-target)@8052 object(file-target)@8568

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!

-- Noel

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at