Re: [Boost-build] [Boost][build] Bjam ordering source $(>) list

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  
errors.

STATIC_LIB
STATIC_LIB
OBJ
STATIC_LIB
STATIC_LIB
STATIC_LIB
STATIC_LIB

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  
ordering.

Anyone think this is this worth committing to Boost.Build?

I appreciate your insight Jurgen!

-- Noel