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
