« Return to Thread: [Boost][build] Bjam ordering source $(>) list
Re: [Boost][build] Bjam ordering source $(>) list
by K. Noel Belcourt
::
Rate this Message:
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
builtin.jam.diff (682 bytes) « Return to Thread: [Boost][build] Bjam ordering source $(>) list
| Free embeddable forum powered by Nabble | Forum Help |
