From: Stefano Lattarini Date: Wed, 18 Jul 2012 18:26:41 +0000 (+0200) Subject: [ng] vars: names for internal make variables: 'am.foo' and 'am.foo.bar-baz' X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=1266796e90fcd67cca308e1fb3295a16c3c3e06d;p=thirdparty%2Fautomake.git [ng] vars: names for internal make variables: 'am.foo' and 'am.foo.bar-baz' 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. Signed-off-by: Stefano Lattarini --- diff --git a/HACKING b/HACKING index c15718f55..03b9dd528 100644 --- a/HACKING +++ 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, + except in those situation where that would cause spurious + conflicts with mainline Automake. ================================================================ = Editing '.am' files