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

[Stefano Lattarini]

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