GNU bug report logs - #55025
Automake should allow one to enable POSIX make behavior

Previous Next

Full log

Message #24 received at 55025 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: Mike Frysinger <vapier <at> gentoo.org>
Cc: 55025 <at> debbugs.gnu.org, vincent <at> vinc17.net,
 Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#55025: Automake should allow one to enable POSIX make behavior
Date: Sat, 14 Jan 2023 01:30:24 -0500

On 2023-01-13, Mike Frysinger <vapier <at> gentoo.org> wrote:
> On 13 Jan 2023 16:01, Karl Berry wrote:
>> I am doubtful about blithely defining .POSIX unconditionally. I feel
>> sure that will break existing Makefiles. I don't think we should do that.
>>
>> Detecting .POSIX in an existing Makefile.am and moving it to the front
>> sounds desirable, since that is clearly what the developer intended.
>>
>> Another (not mutually exclusive) possibility is to add an Automake
>> option (say, "make-posix") that outputs the .POSIX line. --thanks, karl.
>
> i'd be amenable to a `no-make-posix` option, but imo forcing people to
> opt-in to the right behavior is the wrong mental model.

Does adding .POSIX: to a Makefile actually solve any real-world
portability problem with Automake generated makefiles, or is all of
this just hypothetical?

Because we shouldn't go changing default behaviour to solve imaginary
problems ...

> i'm also a bit skeptical of the idea that we're breaking makefiles.

... and adding this to a Makefile really does change the behaviour
significantly on at least one popular make implementation (GNU make).

I imagine a lot of people who are unfamiliar with traditional UNIX
implementations would be very surprised to see gmake suddenly start
running their rules using /bin/sh -e, which is probably the most
obvious effect that the .POSIX special target has on this particular
implementation.

And it doesn't even seem to work to get GNU make to follow the POSIX
behaviour, as POSIX says -e is NOT used whenever errors are being
suppressed (that is, when running commands that start with a -, or
if the .IGNORE: special target is present in the makefile, or if
make is run with the -i option).  GNU make appears to just always
run the shell with -e if you include the .POSIX special target.

Even then, portable makefiles can't rely on the shell being run
with -e even normally, as NetBSD make does not do this.

I tried several other implementations and they follow the POSIX
behaviour by default, adding -e only when errors are not suppressed.

> if an implementation is POSIX compliant, then it already behaves as
> POSIX defines make.  as it stands now, we, and our users, are
> generating files that target an undefined standard that no one agrees
> on, cannot be tested or asserted, and maybe they happen to work on the
> developer's desktop, but not on random users of their own.  by
> defining .POSIX, we turn the state from "usually works, but sometimes
> fails" to "either works or fails, but it's the same everywhere".

Unfortunately, reality is messy.  GNU's behaviour means that adding
.POSIX: actually means that with this specific behaviour (whether or
not the shell is run with "-e"), you now have to consider three
possibilities instead of just two.

Consider these two Makefiles, identical except for the presence of
the .POSIX special target:

  % cat >noposix.mk <<'EOF'
  craziness:
	@-false; echo hello
	@false; echo hello
EOF

  % cat >posix.mk <<'EOF'
  .POSIX:
  craziness:
	@-false; echo hello
	@false; echo hello
EOF

GNU:

  % gmake -f noposix.mk
  hello
  hello

  % gmake -f posix.mk
  gmake: [posix.mk:3: craziness] Error 1 (ignored)
  gmake: *** [posix.mk:4: craziness] Error 1

NetBSD:

  % make -f noposix.mk
  hello
  hello

  % make -f posix.mk
  hello
  hello

HP-UX 11:

  (this is the actual POSIX-specified behaviour which I also observed on
  multiple other systems):

  % make -f noposix.mk
  hello
  *** Error exit code 1

  Stop.

  % make -f posix.mk
  hello
  *** Error exit code 1

Cheers,
  Nick

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.