[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9587: Automake claims $(*F), $(<D), etc. are non-POSIX.
From: |
Stefano Lattarini |
Subject: |
bug#9587: Automake claims $(*F), $(<D), etc. are non-POSIX. |
Date: |
Wed, 19 Oct 2011 11:05:22 +0200 |
User-agent: |
KMail/1.13.7 (Linux/2.6.30-2-686; KDE/4.6.5; i686; ; ) |
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
- bug#9587: Automake claims $(*F), $(<D), etc. are non-POSIX.,
Stefano Lattarini <=