[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Automake-NG] [PATCH] vars: names for internal make variables: 'am.f
From: |
Jim Meyering |
Subject: |
Re: [Automake-NG] [PATCH] vars: names for internal make variables: 'am.foo' and 'am.foo.bar-baz' |
Date: |
Fri, 20 Jul 2012 13:11:44 +0200 |
Stefano Lattarini wrote:
> That is the new preferred naming scheme: 'am.foo' where we would
> have previously used something like 'am__foo', and 'am.foo.bar-baz'
> where we would have previously used something like 'am__foo_bar_baz'
> or 'am__foo__bar_baz'.
>
> We should start using the new naming to do so in future commits. But
> we should also avid a sweeping rename for now, to minimize conflicts
> with the mainline Automake codebases, which (for portability reason)
> must still limit itself to the use of the 'am__' prefix.
>
> * HACKING: Adjust. Also, remove now-irrelevant advice about the
> problem of an old vendor make (NEWS-OS 4.2R) with variables whose
> name start with an underscore.
Sounds good. A typo below:
...
> +++ b/HACKING
> @@ -41,16 +41,17 @@
> ================================================================
> = Naming
>
> -* We've adopted the convention that internal AC_SUBSTs should be
> - named with a leading 'am__', and internally generated targets
> - should be named with a leading 'am--'. This convention, although
> - in place from at least February 2001, isn't yet universally used.
> - But all new code should use it.
> -
> - We used to use '_am_' as the prefix for an internal AC_SUBST.
> - However, it turns out that NEWS-OS 4.2R complains if a Makefile
> - variable begins with the underscore character. Yay for them.
> - I changed the target naming convention just to be safe.
> +* Internal make variables and functions should be named following patterns
> + like 'am.tty-colors' or 'am.dist.files'.
> +
> +* Internal AC_SUBSTs should be named with a leading 'am__'.
> +
> +* Private make targets should be named with a leading 'am--'.
> +
> +* WARNING! This convention, introduced recently (since July 2012),
> + isn't yet universally used. But all new code should use it,
> + expect in those situation where that would cause spurious
s/expect/except/
> + conflicts with mainline Automake.
>
> ================================================================
> = Editing '.am' files