[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
@FOO@ vs. $(FOO) (was: Re: filenamecat-tests)
From: |
Bruno Haible |
Subject: |
@FOO@ vs. $(FOO) (was: Re: filenamecat-tests) |
Date: |
Fri, 19 Oct 2007 00:07:29 +0200 |
User-agent: |
KMail/1.5.4 |
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