[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Add --jobserver/jobserver option for GCC -flto=jobserver
From: |
Nick Bowler |
Subject: |
Re: [PATCH] Add --jobserver/jobserver option for GCC -flto=jobserver |
Date: |
Wed, 28 Oct 2020 14:40:04 -0400 |
On 2020-10-28, Zack Weinberg <zackw@panix.com> wrote:
> On Wed, Oct 28, 2020 at 2:16 PM Nick Bowler <nbowler@draconx.ca> wrote:
>> On 2020-10-28, H.J. Lu <hjl.tools@gmail.com> wrote:
>> > GCC introduced some time ago option -flto=jobserver in order to use the
>> > GNU Make jobserver when parallelising LTO builds. It is actually a
>> > similar "recursive make". When doing a recursive make, you need to
>> > place a '+' character at the beginning of the recipe line in order to
>> > let GNU Make pass the jobserver file descriptors to the child
>> > processes.
>> >
>> > Add the --jobserver option to add a '+' character to the recipe line in
>> > program.am and ltlibrary.am.
> ...
>> Surely this needs to be a configure-time option, perhaps combined
>> with some sort of configure test, since otherwise users won't get
>> this choice, right? As an automake option the choice made by whomever
>> prepares the distribution will get baked into distributed Makefile.in
>> files...
>
> I was going to say something very similar: there shouldn't be an
> option at all. The decision of whether or not to put + at the
> beginning of the recipe line should be made _when make is run_, based
> on whether -flto=jobserver actually appears in $(LDFLAGS) or wherever.
Since this check cannot be done inside a rule, testing LDFLAGS at make
time is probably impractical to do portably.
However I think I misunderstood the impact of this option on first
reading.
I am not aware of any portability concerns with including "+" in
commands, if this is literally the only difference it should be OK
to just always include it (after ensuring that "make -n" is respected
portably in the command).
Cheers,
Nick