bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some "fun" last weekend


From: Dmitry Goncharov
Subject: Re: Some "fun" last weekend
Date: Wed, 20 Jul 2022 20:33:58 -0400

On Wed, Jul 20, 2022 at 9:33 AM Paul Smith <psmith@gnu.org> wrote:
> There are so many ways this can bite people.  The last thing
> GNU make needs IMO is more obscure subtleties.  For example if someone
> writes this:
>
>   NRMAKE = $(MAKE)
>
>   recurse:
>           MAKEFLAGS=$(MAKEFLAGS) $(NRMAKE)
>
> it will break.

Maybe this behavior is useful. When jobserver-auth in MAKEFLAGS
bothers the user a regular advice is to reset MAKEFLAGS or filter out
jobserver-auth. This new behavior does just that. Even though, i
agree, it is very surprising.


> Just to be clear when you say "all the disadvantages of named pipes"
> are you referring to the ones I mentioned in my email, or are there
> other disadvantages that should be considered as well that I didn't
> mention?

The ones that you mentioned.

>  Are you suggesting that we create
> our own implementation of sem_* that works this way?

That and eventfd was an answer to your question "how do we add a
semaphore to select?".
i am not suggesting any of that in make. i actually like the current design.

if we take a step back, what is the problem? The problem is the
presence of jobserver-auth in MAKEFLAGS in the non recursive case.
You already implemented a solution which sets jobserver-auth=-2,-2.
Another option is to remove jobserver-auth from MAKEFLAGS. This would
rob make of a chance to notify the user that the program cannot
participate in the job server protocol, the file descriptors cannot be
opened. That may be better than the subtlety that you described above.
On the other hand, if we were to rewrite the current impl with e.g.
named pipes, the problem of jobserver-auth in MAKEFLAGS would stay,
would it not?


regards, Dmitry



reply via email to

[Prev in Thread] Current Thread [Next in Thread]