@FOO@ vs. $(FOO) (was: Re: filenamecat-tests)

[Bruno Haible]

Jim Meyering wrote:
> BTW, does anyone know why all modules that add LIBINTL add
> it with the anachronistic @LIBINTL@, rather than $(LIBINTL)?
> Similarly, there are many uses of @EXEEXT@ that should be $(EXEEXT)
> these days.

Why "anachronistic"? Why "should"? Automake allows to write it both ways.
What's the pro and contra of each?

Pro $(FOOBAR):

  - It allows the user to override a variable. For example, after
      include Makefile.gnulib
    one can add
      AM_CPPFLAGS += -lcrypt

Pro @FOOBAR@:

  - It detects typos: When you write @LIB_INTL@ instead of @LIBINTL@
    you will get a link error on every platform. Whereas when you write
    $(LIB_INTL) instead of $(LIBINTL), you get link errors only on particular
    platforms. And automake does not warn.

  - It tells the maintainer immediately: "Look for the definition in
    config.status, and at the m4/* macros." With $(FOOBAR) the developer
    must first make sure that the definition is not mangled by automake
    "magic".

> Here's the full list:
> 
>      33 @EXEEXT@
>      22 @LIBINTL@
>       6 @MKDIR_P@
>       5 @LIBICONV@
>       2 @TRUNC_LIBM@
>       2 @TRUNCF_LIBM@
>       2 @LIBMULTITHREAD@
>       2 @INTL_MACOSX_LIBS@
>       2 @FLOORF_LIBM@
>       2 @CEILF_LIBM@
>       1 @TRUNCL_LIBM@
>       1 @TEST_TSEARCH_LIBM@
>       1 @ISNANL_LIBM@
>       1 @FREXP_LIBM@
>       1 @FLOORL_LIBM@
>       1 @CEILL_LIBM@
> 
> Barring objections

I object. I don't see why overriding these macros in the Makefile.am would
be useful - if they are incorrectly defined, it's better fixed in the m4
macros. So for me, the arguments pro @FOO@ win 2:1.

Bruno