Re: [PATCH] Add --jobserver/jobserver option for GCC -flto=jobserver

Nick Bowler <[email protected]>
Newsgroups gmane.comp.sysutils.automake.patches
Message-ID <CADyTPEye-bKJCCu8DdUCvEeGt026mkK-VpSyoP62HgCod+3R5g@mail.gmail.com>
On 2020-10-28, Zack Weinberg <[email protected]> wrote:
> On Wed, Oct 28, 2020 at 2:16 PM Nick Bowler <[email protected]> wrote:
>> On 2020-10-28, H.J. Lu <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.