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

Previous Next

Package: automake;

Reported by: Vincent Lefevre <vincent <at> vinc17.net>

Date: Tue, 19 Apr 2022 15:35:02 UTC

Severity: wishlist

Tags: confirmed

Done: Karl Berry <karl <at> freefriends.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Mike Frysinger <vapier <at> gentoo.org>
To: Nick Bowler <nbowler <at> draconx.ca>
Cc: 55025 <at> debbugs.gnu.org, vincent <at> vinc17.net, Karl Berry <karl <at> freefriends.org>
Subject: bug#55025: Automake should allow one to enable POSIX make behavior
Date: Sat, 14 Jan 2023 02:07:07 -0500
[Message part 1 (text/plain, inline)]
On 14 Jan 2023 01:30, Nick Bowler wrote:
> 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.

if this is the case, then it sounds like a bug.  at a glance, i don't see a
report in the upstream tracker, so can you throw one up there if you have a
test case that shows the problem ?

> 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.

this is exactly my point.  if i'm developing a project with automake and i'm
using gnu make, i can easily produce bad code that is not portable.  but the
insidious part is that it doesn't fail for me, it fails for my users who are
not using gnu make, but using a POSIX-compliant implementation that respects
the `set -e` behavior.

the reason i use automake in my projects in the first place is to produce a
build env that is reasonably portable, and if i have to write custom hooks,
to help steer me away from non-POSIX (i.e. things likely to not be portable)
constructs.
-mike
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 1 year and 287 days ago.

Previous Next


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