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

Previous Next

Full log

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/)

Previous Next

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