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

Previous Next

Package: automake;

Reported by: Nick Bowler <nbowler <at> elliptictech.com>

Date: Fri, 23 Sep 2011 19:03:02 UTC

Severity: minor

Tags: confirmed, help, pending

Full log


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




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

Previous Next


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