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
