GNU bug report logs - #9587
Automake claims $(*F), $(<D), etc. are non-POSIX.

Previous Next

To reply to this bug, email your comments to 9587 AT debbugs.gnu.org.

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

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

From: Nick Bowler <nbowler <at> elliptictech.com>
To: bug-automake <at> gnu.org
Subject: Automake claims $(*F), $(<D), etc. are non-POSIX.
Date: Fri, 23 Sep 2011 15:02:08 -0400

Hello,

When running automake without "foreign" in configure.ac it claims that
variables such as $(*F), $(<D), etc. are non-POSIX, with an error of the
form:

  Makefile.am:2: *F: non-POSIX variable name

The complaints *do* occur with automake --foreign; you have to actually
put foreign in configure.ac (or in AUTOMAKE_OPTIONS) to make them go
away.  Regardless, automake does not complain about $(@F) or $(@D).
However, $(*F) and friends are most certainly POSIX variable names.
Quoting IEEE Std 1003.1-2004:

> The five internal macros are [... $@, $%, $?, $<, $* ...].
>
> Each of the internal macros has an alternative form.  When an
> uppercase 'D' or 'F' is appended to any of the macros, the meaning
> shall be changed to the directory part for 'D' and filename part for
> 'F'. The directory part is the path prefix of the file without a
> trailing slash; for the current directory, the directory part is '.'.
> When the $? macro contains more than one prerequisite filename, the
> $(?D) and $(?F) (or ${?D} and ${?F}) macros expand to a list of
> directory name parts and filename parts respectively.

These variables are supported by (at least) bmake, pmake, dmake and GNU
make.  I can reproduce this with the following example:

% cat >Makefile.am <<'EOF'
.foo.bar:
	echo "$(@F) $(%F) $(?F) $(<F) $(*F) $(@D) $(%D) $(?D) $(<D) $(*D)" > $@
EOF

% cat >configure.ac <<'EOF'
AC_INIT([test], [1.0])

AM_INIT_AUTOMAKE([-Wall])

AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF

  % aclocal
  % automake --add-missing --foreign
  configure.ac:3: installing `./install-sh'
  configure.ac:3: installing `./missing'
  Makefile.am:2: %F: non-POSIX variable name
  Makefile.am:2: ?F: non-POSIX variable name
  Makefile.am:2: <F: non-POSIX variable name
  Makefile.am:2: *F: non-POSIX variable name
  Makefile.am:2: %D: non-POSIX variable name
  Makefile.am:2: ?D: non-POSIX variable name
  Makefile.am:2: <D: non-POSIX variable name
  Makefile.am:2: *D: non-POSIX variable name

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

From: Nick Bowler <nbowler <at> elliptictech.com>
To: 9587 <at> debbugs.gnu.org
Subject: Re: Automake claims $(*F), $(<D), etc. are non-POSIX.
Date: Fri, 23 Sep 2011 15:47:13 -0400

On 2011-09-23 15:02 -0400, Nick Bowler wrote:
> These variables are supported by (at least) bmake, pmake, dmake and GNU
> make.  I can reproduce this with the following example:

I spoke a bit too soon here.  Neither bmake nor pmake seem too support
$(?F) or $(?D) (both expand to be empty in both inference and target
rules).  And dmake seems to differ slightly from POSIX wrt the "D"
variants.  Quoting IEEE Std 1003.1-2004 again:

> The directory part is the path prefix of the file without a
> trailing slash; for the current directory, the directory part is '.'.

For all the "D" variants, dmake puts a trailing slash contrary to the
above, and for the current directory expands to the empty string instead
of "." as required.

-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: bug-automake <at> gnu.org
Cc: Nick Bowler <nbowler <at> elliptictech.com>, 9587 <at> debbugs.gnu.org
Subject: Re: bug#9587: Automake claims $(*F), $(<D), etc. are non-POSIX.
Date: Wed, 19 Oct 2011 11:05:22 +0200

severity 9587 minor
thanks

Hi Nick, sorry for the delay.

On Friday 23 September 2011, Nick Bowler wrote:
> On 2011-09-23 15:02 -0400, Nick Bowler wrote:
> > These variables are supported by (at least) bmake, pmake, dmake and GNU
> > make.  I can reproduce this with the following example:
> 
> I spoke a bit too soon here.  Neither bmake nor pmake seem too support
> $(?F) or $(?D) (both expand to be empty in both inference and target
> rules).  And dmake seems to differ slightly from POSIX wrt the "D"
> variants.  Quoting IEEE Std 1003.1-2004 again:
> 
> > The directory part is the path prefix of the file without a
> > trailing slash; for the current directory, the directory part is '.'.
> 
> For all the "D" variants, dmake puts a trailing slash contrary to the
> above, and for the current directory expands to the empty string instead
> of "." as required.
>
Given this, and the fact that no-one has complained about this automake
limitation so far, I'm oriented at simply leave the situation as is.

Still, if someone else do care, and write a proper patch to improve the
situation, I'd be happy to consider it.  A "proper" patch should do the
following:

  - Add a test, say "spy-internal-macros.test", which ensures that all
    the POSIX internal macros Automake does not warn about are supported
    by the make implementation that is being used in the tests.

  - For POSIX-mandated internal macros that are not portable in practice,
    Automake should give an error stating "non-portable internal macros"
    (or something like that), rather than "non-POSIX variable name".

Regards,
   Stefano

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

From: Nick Bowler <nbowler <at> elliptictech.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: bug-automake <at> gnu.org, 9587 <at> debbugs.gnu.org
Subject: Re: bug#9587: Automake claims $(*F), $(<D), etc. are non-POSIX.
Date: Wed, 19 Oct 2011 11:18:04 -0400

On 2011-10-19 11:05 +0200, Stefano Lattarini wrote:
> On Friday 23 September 2011, Nick Bowler wrote:
> > Neither bmake nor pmake seem too support $(?F) or $(?D) (both expand
> > to be empty in both inference and target rules).  And dmake seems to
> > differ slightly from POSIX wrt the "D" variants.  Quoting IEEE Std
> > 1003.1-2004 again:
> >
> > > The directory part is the path prefix of the file without a
> > > trailing slash; for the current directory, the directory part is '.'.
> >
> > For all the "D" variants, dmake puts a trailing slash contrary to the
> > above, and for the current directory expands to the empty string instead
> > of "." as required.
>
> Given this, and the fact that no-one has complained about this automake
> limitation so far, I'm oriented at simply leave the situation as is.

The only reason I didn't notice this before is I've been unknowingly
running for years without portability warnings enabled.  I didn't
realize (until now) that they get disabled by "foreign" in:

  AM_INIT_AUTOMAKE([-Wall -Werror foreign ...]).

While it's certainly possible to avoid the use of these macros by doing
it in the shell, they're invaluable in non-recursive build systems:
probably about half of the suffix rules that I write contain either
$(@D) or $(*F) (automake only warns about the latter).  Amusingly, of
those two variables in the make implementations that I've tested, only
$(@D) has portability issues (dmake) -- and it's the one that automake
*doesn't* warn about.

The dmake issues noted above are pretty minor: I doubt a trailing slash
in a directory name would affect many rules, though an empty string
instead of "." might.  But since these macros are really only useful
for working with files *not* in the current working directory, this
also seems unlikely to affect many rules (but I guess deserves a note).

But yeah, $(?F) and $(?D) are obviously not portable.  This is
unfortunate, but I haven't actually used these particular macros
before.

Incidentally, automake also produces similar non-POSIX warnings about
$(<), $(*), $(%) and $(?), which are the same as $<, $*, $% and $?,
respectively.  It also warns about things like $(<:.foo=.bar).

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

From: Bogdan <bogdro_rep <at> gmx.us>
To: automake-patches <at> gnu.org, 9587 <at> debbugs.gnu.org
Subject: [bug#9587][PATCH] Automake claims $(*F), $(<D), etc. are non-POSIX.
Date: Thu, 23 Mar 2023 20:57:44 +0100

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

Hello again.

 The attached patch allows the following symbols not to cause 
Automake errors about non-POSIX variables (and updates the test):

 $(@F) $(%F) $(?F) $(<F) $(*F) $(@D) $(%D) $(?D) $(<D) $(*D) $(%) 
$(?) $(<) $(*) $% $? $< $*

 I don't have the POSIX standard and didn't find any references to 
POSIX variables in GNU make's manual, so I assume the quotation in the 
defect report is correct.

 The patch doesn't do anything to check if the variables are 
supported by the end-user's 'make', because it's not the end-user's 
'make' which decides what is portable or not. The message is not 
changed either.

 I don't know if "$(<:.foo=.bar)" should be allowed, but that seems 
to be taken care of in 
lib/Automake/Variable.pm:scan_variable_expansions anyway (resulting in 
just "<" in this example).

 Fixes bug#9587.

-- 
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

[automake-posix-vars-mail.diff (text/x-patch, attachment)]

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

From: Karl Berry <karl <at> freefriends.org>
To: bogdro_rep <at> gmx.us, nbowler <at> draconx.ca, nbowler <at> elliptictech.com
Cc: automake-patches <at> gnu.org, 9587 <at> debbugs.gnu.org
Subject: Re: bug#9587: [PATCH] Automake claims $(*F), $(<D),
 etc. are non-POSIX.
Date: Sat, 1 Jul 2023 09:35:16 -0600

Back on this bug report from Nick in 2011 (thanks/sorry):
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9587

    bd> The attached patch allows the following symbols not to cause 
    Automake errors about non-POSIX variables (and updates the test):

    $(@F) $(%F) $(?F) $(<F) $(*F) $(@D) $(%D) $(?D) $(<D) $(*D) $(%) 
    $(?) $(<) $(*) $% $? $< $*

I installed the patch. Thanks Bogdan.

    I don't have the POSIX standard

It's online nowadays.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
As far as I could see, Nick's report was correct (as expected :).

    because it's not the end-user's 'make' which decides what is
    portable or not.
    
Testing a given make implementation can prove that a variable is
unportable (when it fails). There's never any way to prove that
something is perfectly portable.

Nevertheless, in this case, it seemed to me that it was better to fix
the incorrect warning about non-POSIX variables now than to require
testing for and giving perfect diagnostics for the implementations that
don't correctly support all the POSIX variables. If people use those
implementations, they most likely are not relying on Automake
diagnostics about those variables. Nevertheless, I'm leaving the bug
open for this reason. I also mentioned this suboptimality in the NEWS
item. --thanks, karl.

-----------------------------------------------------------------------------
2023-07-01  Bogdan  <bogdro_rep <at> gmx.us>

automake: do not warn that POSIX variables are non-POSIX.

This change fixes https://bugs.gnu.org/9587.

* lib/Automake/Variable.pm (_VARIABLE_PATTERN_EXTRA_POSIX):
new variable for $(*D) and the like.
(_VARIABLE_PATTERN): use it.
* t/vars3.sh: update test.
* NEWS: mention this.
POSIX spec (currently):
  https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html

diff --git a/NEWS b/NEWS
index b73c92569..61d631ba0 100644
--- a/NEWS
+++ b/NEWS
@@ -37,6 +37,12 @@ New in 1.17:

   - Emacs Lisp compilations respects silent make output.

+  - Automake no longer incorrectly warns that the POSIX make variables
+    $(*D) and the like are non-POSIX. Unfortunately, the make
+    implementations which do not correctly implement all the POSIX
+    variables are not detected, but this seems to have little impact
+    in practice. (bug#9587)
+
   - distcleancheck ignores "silly rename" files (.nfs* .smb* .__afs*)
     that can show up on network file systems.

diff --git a/lib/Automake/Variable.pm b/lib/Automake/Variable.pm
index 2c118314e..8bafc8e3a 100644
--- a/lib/Automake/Variable.pm
+++ b/lib/Automake/Variable.pm
@@ -132,7 +132,9 @@ non-object).
 =cut

 my $_VARIABLE_CHARACTERS = '[.A-Za-z0-9_@]+';
-my $_VARIABLE_PATTERN = '^' . $_VARIABLE_CHARACTERS . "\$";
+my $_VARIABLE_PATTERN_EXTRA_POSIX = '[*?<%][DF]?';
+my $_VARIABLE_PATTERN = '^(' . $_VARIABLE_CHARACTERS
+                             . '|' . $_VARIABLE_PATTERN_EXTRA_POSIX . ")\$";
 my $_VARIABLE_RECURSIVE_PATTERN =
     '^([.A-Za-z0-9_@]|\$[({]' . $_VARIABLE_CHARACTERS . '[})]?)+' . "\$";

diff --git a/t/vars3.sh b/t/vars3.sh
index ae89a6869..cbba47e68 100644
--- a/t/vars3.sh
+++ b/t/vars3.sh
@@ -15,7 +15,8 @@
 # along with this program.  If not, see <https://www.gnu.org/licenses/>.

 # Check that Automake warns about variables containing spaces
-# and other non-POSIX characters.
+# and other non-POSIX characters, but not about real POSIX
+# variables (see bug#9587).

 . test-init.sh

@@ -32,6 +33,10 @@ L08$(o u c h): $(wildcard *.c)
 	echo $${ok-this is}
 L11: $(thisis) $(ok)
 	${here}
+just_a_test:
+	echo "$(@F) $(%F) $(?F) $(<F) $(*F) $(@D) $(%D) $(?D) $(<D) $(*D)" > $@
+	echo "$(%) $(?) $(<) $(*)" > $@
+	echo "$% $? $< $*" > $@
 EOF

 $ACLOCAL
@@ -59,6 +64,20 @@ grep ':8:.*wildcard' stderr
 grep ':9:.*another Error' stderr

 $EGREP 'ok|thisis|here' stderr && exit 1
+grep '@F' stderr && exit 1
+grep '%F' stderr && exit 1
+grep '?F' stderr && exit 1
+grep '<F' stderr && exit 1
+grep '*F' stderr && exit 1
+grep '@D' stderr && exit 1
+grep '%D' stderr && exit 1
+grep '?D' stderr && exit 1
+grep '<D' stderr && exit 1
+grep '*D' stderr && exit 1
+grep ': %: ' stderr && exit 1
+grep ': ?: ' stderr && exit 1
+grep ': <: ' stderr && exit 1
+grep ': *: ' stderr && exit 1

 # None of these errors be diagnosed with '-Wno-portability'.
 $AUTOMAKE -Wno-portability

compile finished at Sat Jul  1 08:32:40 2023

Previous Next

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