automake-ng
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]