[Top][All Lists]

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

bug#55025: Automake should allow one to enable POSIX make behavior

From: Mike Frysinger
Subject: bug#55025: Automake should allow one to enable POSIX make behavior
Date: Sat, 14 Jan 2023 02:07:07 -0500

On 14 Jan 2023 01:30, Nick Bowler wrote:
> On 2023-01-13, Mike Frysinger <vapier@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)

Attachment: signature.asc
Description: PGP signature

reply via email to

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