Bruno Haible <[EMAIL PROTECTED]> wrote: > 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.
I prefer $(FOOBAR) for its readability, but the ability to detect invalid typos early is worth keeping the uglier syntax. In that vein, you may want to change your modules: modules/csharpexec:DEFS += -DEXEEXT=\"$(EXEEXT)\" modules/javaexec:DEFS += -DEXEEXT=\"$(EXEEXT)\" modules/relocatable-prog:DEFS += -DEXEEXT=\"$(EXEEXT)\"
