Jim Meyering wrote: > Bruno Haible wrote: >> Simon Josefsson wrote: >>> > So the use of @...@ is not only appropriate here, it is even mandatory. >>> >>> So possibly the maint.mk check should be relaxed to permit constructs >>> matching FOO = ... @FOO@ then? >> >> Yes, this is what I meant. >> >>> Then I think the current behaviour of maint.mk shoudld stay, unless >>> anyone else finds other corner cases -- this warning resulted a change >>> to use a more modern style in one of my projects. >> >> It is also commonplace to use Makefile.am to tweak a definition found >> by Autoconf. For example, I have >> >> MAKEINFO = env LANG= LC_MESSAGES= LC_ALL= LANGUAGE= @MAKEINFO@ >> >> in several projects, otherwise makeinfo will put German or French navigation >> helps into an otherwise English documentation. > > Thanks to both of you, here are some improvements. > In addition, I've extended it to also check *.mk files, > so it may expose new uses of @VAR@ in some projects. > > Subject: [PATCH] maint.mk: makefile_at_at_check extend and clean up
FYI, when pushing that, I accidentally pushed this commit, too: "use _GL_ATTRIBUTE_CONST and _GL_ATTRIBUTE_PURE" http://git.sv.gnu.org/cgit/gnulib.git/commit/?id=349d7fe0e307d59d Obviously, without even a ChangeLog entry, it was not ready. It seems wrong to have to define these __attribute__ _GL_ATTRIBUTE_PURE _GL_ATTRIBUTE_CONST in every compilation unit that uses these attributes. What do you think about putting those definitions in gnulib-common.m4 like we do for _GL_UNUSED? Why am I doing this? I've started using some new gcc-4.6 options, by adding these lines to coreutils' configure.ac: + gl_WARN_ADD([-Wsuggest-attribute=const]) + gl_WARN_ADD([-Wsuggest-attribute=pure]) + gl_WARN_ADD([-Wsuggest-attribute=noreturn]) I've already adjusted all of coreutils, but wanted to fix gnulib first, because fixes there might induce additional changes in coreutils.