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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 55025 in the body.
You can then email your comments to 55025 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: bug-automake <at> gnu.org
Subject: Automake should allow one to enable POSIX make behavior
Date: Tue, 19 Apr 2022 17:33:48 +0200

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
says about the target rules:

  .POSIX
    The application shall ensure that this special target is specified
    without prerequisites or commands. If it appears as the first
    non-comment line in the makefile, /make/ shall process the makefile
    as specified by this section; otherwise, the behavior of /make/ is
    unspecified.

But even though one may add a .POSIX target as the first non-comment
line in one's Makefile.am file, Automake will add various non-comment
lines before this target in the generated Makefile. I received a
remark about that for GNU MPFR. Though GNU make does not require
this target to be the first non-comment line, this may matter with
other make implementations.

This could be done either by detecting a .POSIX target in Makefile.am
or with some AM_* macro in the configure.ac file.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

From: Mike Frysinger <vapier <at> gentoo.org>
To: Vincent Lefevre <vincent <at> vinc17.net>, bug-automake <at> gnu.org
Subject: Re: bug#55025: Automake should allow one to enable POSIX make behavior
Date: Fri, 13 Jan 2023 01:19:39 -0500

[Message part 1 (text/plain, inline)]

On 19 Apr 2022 17:33, Vincent Lefevre wrote:
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
> says about the target rules:
> 
>   .POSIX
>     The application shall ensure that this special target is specified
>     without prerequisites or commands. If it appears as the first
>     non-comment line in the makefile, /make/ shall process the makefile
>     as specified by this section; otherwise, the behavior of /make/ is
>     unspecified.
> 
> But even though one may add a .POSIX target as the first non-comment
> line in one's Makefile.am file, Automake will add various non-comment
> lines before this target in the generated Makefile. I received a
> remark about that for GNU MPFR. Though GNU make does not require
> this target to be the first non-comment line, this may matter with
> other make implementations.
> 
> This could be done either by detecting a .POSIX target in Makefile.am
> or with some AM_* macro in the configure.ac file.

any reason we don't just define it ourselves unconditionally ?  seems
like the whole point of Automake is for devs to not worry about these
kind of nitty details.
-mike

--- a/lib/am/header-vars.am
+++ b/lib/am/header-vars.am
@@ -14,6 +14,8 @@
 ## You should have received a copy of the GNU General Public License
 ## along with this program.  If not, see <https://www.gnu.org/licenses/>.
 
+.POSIX:
+
 VPATH = @srcdir@
 
 @SET_MAKE@

[signature.asc (application/pgp-signature, inline)]

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Mike Frysinger <vapier <at> gentoo.org>
Cc: bug-automake <at> gnu.org
Subject: Re: bug#55025: Automake should allow one to enable POSIX make behavior
Date: Fri, 13 Jan 2023 11:21:55 +0100

On 2023-01-13 01:19:39 -0500, Mike Frysinger wrote:
> any reason we don't just define it ourselves unconditionally ?  seems
> like the whole point of Automake is for devs to not worry about these
> kind of nitty details.

Probably. Note, however, that .POSIX affects GNU "make" on a few
points (the default is obviously not portable, but some developers
might require GNU "make", though probably for other reasons):

   If the '.POSIX' special target is defined then backslash/newline
handling is modified slightly to conform to POSIX.2: first, whitespace
preceding a backslash is not removed and second, consecutive
backslash/newlines are not condensed.

     In particular, if this target is mentioned then recipes will be
     invoked as if the shell had been passed the '-e' flag: the first
     failing command in a recipe will cause the recipe to fail
     immediately.

'warning: ignoring prerequisites on suffix rule definition'
     According to POSIX, a suffix rule cannot contain prerequisites.  If
     a rule that could be a suffix rule has prerequisites it is
     interpreted as a simple explicit rule, with an odd target name.
     This requirement is obeyed when POSIX-conforming mode is enabled
     (the '.POSIX' target is defined).  In versions of GNU 'make' prior
     to 4.3, no warning was emitted and a suffix rule was created,
     however all prerequisites were ignored and were not part of the
     suffix rule.  Starting with GNU 'make' 4.3 the behavior is the
     same, and in addition this warning is generated.  In a future
     version the POSIX-conforming behavior will be the only behavior: no
     rule with a prerequisite can be suffix rule and this warning will
     be removed.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

From: Karl Berry <karl <at> freefriends.org>
To: vincent <at> vinc17.net
Cc: 55025 <at> debbugs.gnu.org, vapier <at> gentoo.org
Subject: Re: bug#55025: Automake should allow one to enable POSIX make behavior
Date: Fri, 13 Jan 2023 16:01:03 -0700

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.

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

From: Mike Frysinger <vapier <at> gentoo.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: 55025 <at> debbugs.gnu.org, vincent <at> vinc17.net
Subject: Re: bug#55025: Automake should allow one to enable POSIX make behavior
Date: Fri, 13 Jan 2023 23:59:12 -0500

[Message part 1 (text/plain, inline)]

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.

i'm also a bit skeptical of the idea that we're breaking makefiles.  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".

i grok that not everyone is POSIX-compliant, and we sometimes try to add
support for such systems where reasonable, but that's a case-by-case, and
we can't keep bending over backwards to support decades old dead software
that no one uses.
-mike

[signature.asc (application/pgp-signature, inline)]

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

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

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: Re: 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)]

Message #30 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 03:30:02 -0500

On 14/01/2023, Mike Frysinger <vapier <at> gentoo.org> wrote:
[...]
>> 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.

But as I demonstrated, adding .POSIX doesn't actually make GNU make
work the same as these "POSIX-by-default" implementations.  It just
gives it a different, GNU-specific behaviour, since GNU make apparently
enables -e regardless of whether or not errors are suppressed.

Does changing the behaviour in this way really improve anything for a
maintainer that is only testing with GNU make?

Without putting .POSIX in the Makefile, GNU is at least consistent with
NetBSD here (which never uses -e) and probably also other modern BSD
derivatives, as I think many have these days adopted NetBSD make.

Cheers,
  Nick

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

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

Mike, if you want to make an option that lets people have .POSIX if they
want it (and/or recognize .POSIX in the Makefile.am), fine. Please don't
foist it on the rest of us. As Nick has shown, I feel pretty sure the
change would break a lot of existing projects, which IMHO is something
to avoid at all costs. The benefit here does not seem nearly worth
it to me. --thanks, karl.

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

From: Karl Berry <karl <at> freefriends.org>
To: vapier <at> gentoo.org
Cc: nbowler <at> draconx.ca, 55025 <at> debbugs.gnu.org, vincent <at> vinc17.net
Subject: Re: bug#55025: Automake should allow one to enable POSIX make behavior
Date: Sat, 14 Jan 2023 15:12:00 -0700

P.S. I note that GNU make just made an alpha release. If anyone wants to
report the purported .POSIX bug, might be a good time.

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Nick Bowler <nbowler <at> draconx.ca>
Cc: 55025 <at> debbugs.gnu.org, Mike Frysinger <vapier <at> gentoo.org>,
 Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#55025: Automake should allow one to enable POSIX make behavior
Date: Sun, 15 Jan 2023 01:55:51 +0100

On 2023-01-14 01:30:24 -0500, Nick Bowler wrote:
> Does adding .POSIX: to a Makefile actually solve any real-world
> portability problem with Automake generated makefiles, or is all of
> this just hypothetical?

For MPFR, when I initially added it, this was just in case.

The real issue at that time was that I was using $< in a case
where it was unspecified by POSIX, and this was failing on FreeBSD.
Unfortunately there doesn't seem to be a way to get a failure
on non-portable features (which would ease maintenance). Though
I test the tarball on various systems before a release candidate,
this is not the case of the development branch (and the Makefiles
would typically be more affected than the C code, on which various
portability checks are done under Linux).

Well, I use autoreconf with --warnings=all,error (passed to automake),
but I didn't get any portability error.

Later I noted:

# The ".POSIX" line is needed in particular for GNU "make", so that
# recipes are invoked as if the shell had been passed the -e flag.

as this is really what we want, both for consistency with other
"make" implementations and to be able to detect errors.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Karl Berry <karl <at> freefriends.org>
Cc: nbowler <at> draconx.ca, 55025 <at> debbugs.gnu.org, vapier <at> gentoo.org
Subject: Re: bug#55025: Automake should allow one to enable POSIX make behavior
Date: Sun, 15 Jan 2023 03:01:48 +0100

On 2023-01-14 15:12:00 -0700, Karl Berry wrote:
> P.S. I note that GNU make just made an alpha release. If anyone
> wants to report the purported .POSIX bug, might be a good time.

I've just reported it:

  https://savannah.gnu.org/bugs/index.php?63667

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: 55025 <at> debbugs.gnu.org
Subject: Re: bug#55025: Automake should allow one to enable POSIX make behavior
Date: Mon, 2 Oct 2023 16:23:55 +0200

On 2023-01-14 01:30:24 -0500, Nick Bowler wrote:
> 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
[...]
> 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

Same behavior on AIX, i.e. the .POSIX special target is useless for
*this* example. However, if it is not the first non-comment line, I
get a warning:

  warning: .POSIX directive is not first non-comment line.

(found during my test of GNU MPFR on cfarm119.cfarm.net).

Note that its "make" man page says:

  .POSIX
      Causes the make command to use a different default rules file. The
      file, /usr/ccs/lib/posix.mk, provides the default rules as
      specified in the POSIX standard.

but I don't know whether this changes the behavior with Automake.

If /usr/ccs/lib/posix.mk is included when the .POSIX directive is read,
the fact that it is not the first non-comment line might cause issues.
For instance, this file (re)defines some variables:

MAKE=make
AR=ar
ARFLAGS=-rv
YACC=yacc
YFLAGS=
LEX=lex
LFLAGS=
LDFLAGS=
CC=c89
CFLAGS=-O
FC=fort77
FFLAGS=-O 1
GET=get
GFLAGS=

So this is expected to be found early in the makefile.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

From: Karl Berry <karl <at> freefriends.org>
To: vincent <at> vinc17.net
Cc: 55025 <at> debbugs.gnu.org
Subject: Re: bug#55025: Automake should allow one to enable POSIX make behavior
Date: Mon, 2 Oct 2023 15:17:13 -0600

Sorry, I don't understand what you want Automake to do.

Right now, as far as I can tell, Automake does nothing with .POSIX. It's
not mentioned in the manual nor, as far as I can grep, the code. Maybe
that's the issue, and you want a leading .POSIX in your Makefile.am to
be specially copied at the beginning of the output Makefile.in?
(Or an option, or something.)

But ... have you tried to run a Makefile originating from Automake with
.POSIX in effect?  I feel doubtful that it will work, although I don't
know it for a fact.  -k

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Karl Berry <karl <at> freefriends.org>
Cc: 55025 <at> debbugs.gnu.org
Subject: Re: bug#55025: Automake should allow one to enable POSIX make behavior
Date: Tue, 3 Oct 2023 01:19:16 +0200

On 2023-10-02 15:17:13 -0600, Karl Berry wrote:
> Sorry, I don't understand what you want Automake to do.
> 
> Right now, as far as I can tell, Automake does nothing with .POSIX. It's
> not mentioned in the manual nor, as far as I can grep, the code. Maybe
> that's the issue, and you want a leading .POSIX in your Makefile.am to
> be specially copied at the beginning of the output Makefile.in?
> (Or an option, or something.)

Yes, Automake should either detect a ".POSIX:" in the Makefile.am
file (at least if it is the first non-comment line) and place it at
the beginning of Makefile.in, or provide an option to be used with
AM_INIT_AUTOMAKE (or AUTOMAKE_OPTIONS) in order to have a ".POSIX:"
at the beginning of Makefile.in.

> But ... have you tried to run a Makefile originating from Automake with
> .POSIX in effect?  I feel doubtful that it will work, although I don't
> know it for a fact.  -k

The Makefile.am files of GNU MPFR have a ".POSIX:" target as the
first non-comment line: the shell for recipes is expected to be
run with the -e flag. So, the ".POSIX:" is necessary for GNU Make
in order to detect errors[*] (fortunately, GNU Make does not seem
to care about its position in Makefile).

[*] It is not needed for a successful build, but its absence might
yield successful builds that are actually broken.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

From: Karl Berry <karl <at> freefriends.org>
To: vincent <at> vinc17.net
Cc: 55025 <at> debbugs.gnu.org
Subject: Re: bug#55025: Automake should allow one to enable POSIX make behavior
Date: Tue, 3 Oct 2023 15:08:42 -0600

    Yes, Automake should either detect a ".POSIX:" in the Makefile.am
    file (at least if it is the first non-comment line) and place it at
    the beginning of Makefile.in, or provide an option to be used with
    AM_INIT_AUTOMAKE (or AUTOMAKE_OPTIONS) in order to have a ".POSIX:"
    at the beginning of Makefile.in.

Ok. I welcome patches for either or both. It's not something I'll be
implementing myself any time soon (regrettably).

    The Makefile.am files of GNU MPFR have a ".POSIX:" target 

Glad to know it works in practice for you. I'm just surprised that
nothing in Automake's make output breaks under POSIX. --thanks, karl.

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Karl Berry <karl <at> freefriends.org>
Cc: 55025 <at> debbugs.gnu.org
Subject: Re: bug#55025: Automake should allow one to enable POSIX make behavior
Date: Wed, 4 Oct 2023 17:57:46 +0200

On 2023-10-03 15:08:42 -0600, Karl Berry wrote:
>     Yes, Automake should either detect a ".POSIX:" in the Makefile.am
>     file (at least if it is the first non-comment line) and place it at
>     the beginning of Makefile.in, or provide an option to be used with
>     AM_INIT_AUTOMAKE (or AUTOMAKE_OPTIONS) in order to have a ".POSIX:"
>     at the beginning of Makefile.in.
> 
> Ok. I welcome patches for either or both. It's not something I'll be
> implementing myself any time soon (regrettably).

I think that a "posix" option is cleaner and simpler to implement.
I have some idea of a patch. I'll try to look at it more closely
late tonight.

>     The Makefile.am files of GNU MPFR have a ".POSIX:" target 
> 
> Glad to know it works in practice for you. I'm just surprised that
> nothing in Automake's make output breaks under POSIX. --thanks, karl.

On platforms with a POSIX "make", the generated makefile needs to
work as expected. This limits the risk of breakage when using a
".POSIX:" target.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Karl Berry <karl <at> freefriends.org>
Cc: 55025 <at> debbugs.gnu.org
Subject: [PATCH] New "posix" automake option.
Date: Thu, 5 Oct 2023 02:30:37 +0200

This patch is from https://bugs.gnu.org/55025.

* lib/Automake/Options.pm: declare "posix" option.
* bin/automake.in: if the "posix" option is present, add
a .POSIX special target as the first non-comment line in
the Makefile.in files.
* NEWS: mention this.
* doc/automake.texi: likewise.
---
 NEWS                    | 2 ++
 bin/automake.in         | 7 +++++++
 doc/automake.texi       | 6 ++++++
 lib/Automake/Options.pm | 1 +
 4 files changed, 16 insertions(+)

diff --git a/NEWS b/NEWS
index ced0fd640..821ae0cf1 100644
--- a/NEWS
+++ b/NEWS
@@ -30,6 +30,8 @@ New in 1.17:
     as given in the Makefile.am will be used.  If @setfilename is present,
     it should be the basename of the Texinfo file, extended with .info.
 
+  - New option "posix" to generate a .POSIX special target.
+
 * Bugs fixed
 
   - Generated file timestamp checks now handle filesystems with sub-second
diff --git a/bin/automake.in b/bin/automake.in
index 369a47fa2..edc0488b8 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -8126,6 +8126,13 @@ sub generate_makefile
   my $output =
     "$output_vars$output_all$output_header$output_rules$output_trailer";
 
+  # The .POSIX special target must be the first non-comment line;
+  # otherwise, the behavior of "make" is unspecified by POSIX.
+  if (option 'posix')
+    {
+      $output =~ s/^((#.*)?\n)*\K/.POSIX:\n\n/;
+    }
+
   # Decide whether we must update the output file or not.
   # We have to update in the following situations.
   #  * $force_generation is set.
diff --git a/doc/automake.texi b/doc/automake.texi
index d14b769fd..97e3e3475 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -10679,6 +10679,12 @@ are ordinarily automatically provided by Automake.
 Don't require @file{texinfo.tex}, even if there are texinfo files in
 this directory.
 
+@item @option{posix}
+@cindex Option, @option{posix}
+@opindex posix
+Generate a @code{.POSIX} special target as the first non-comment line in
+the @file{Makefile.in} files.
+
 @item @option{serial-tests}
 @cindex Option, @option{serial-tests}
 @opindex serial-tests
diff --git a/lib/Automake/Options.pm b/lib/Automake/Options.pm
index 69fc2ecb5..22d527fac 100644
--- a/lib/Automake/Options.pm
+++ b/lib/Automake/Options.pm
@@ -290,6 +290,7 @@ sub _is_valid_easy_option ($)
     no-installman
     no-texinfo.tex
     nostdinc
+    posix
     readme-alpha
     serial-tests
     parallel-tests
-- 
2.42.0

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

From: Karl Berry <karl <at> freefriends.org>
To: vincent <at> vinc17.net
Cc: 55025 <at> debbugs.gnu.org
Subject: Re: [PATCH] New "posix" automake option.
Date: Thu, 5 Oct 2023 15:18:40 -0600

    This patch is from https://bugs.gnu.org/55025.

Thanks Vincent!

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

From: Karl Berry <karl <at> freefriends.org>
To: vincent <at> vinc17.net
Cc: 55025 <at> debbugs.gnu.org
Subject: Re: [PATCH] New "posix" automake option.
Date: Fri, 6 Oct 2023 16:40:32 -0600

I installed your patch (and added a tiny test case). Thanks Vincent!
Closing this bug (finally ...). -k

Previous Next

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