Hello Bruno,
* Bruno Haible wrote on Tue, Sep 01, 2009 at 10:37:49AM CEST:
> I can see that in rare, rare cases, since MKDIR_P is a command, people
> may want to use different versions of it. But for things like @LIBINTL@
> and @LIBSOCKET@, it is still better to write them as @LIBINTL@, not
> $(LIBINTL),
> because if the corresponding autoconf macro was not run, it makes the error
> appear on all platforms. Otherwise it's too easy to write a Makefile.am
> that builds fine on glibc systems but not on Solaris or MacOS X.
It is certainly true that the package author as well as the gnulib macro
author can more easily detect this sort of thing with @libi...@.
However, for the smart end-user running configure, it is easier to
override an empty $(LIBINTL), but requires editing makefiles or even
configure scripts or their inputs to override @libi...@.
You are arguing for the developer case, which is fine per se, of course,
but you are trading it for better end-user experience. Once we accept
that most of our macros are going to have bugs, or not do the right
thing on some platform we may not be aware of, it isn't so clear anymore
what is better.
Can't we improve the situation by looking for a solution to your
maintainability issue that does not affect the end-user negatively?
For example, writing $(MKDIR_P) is not a big problem as an uninitialized
MKDIR_P variable will show up easily. GNU make has
--warn-undefined-variables but there are too many of them in typical
automake-generated makefiles to be terribly useful. Some of them we
could fix in Automake, but others (like DESTDIR, V) are left undefined
by intention, so that their override works across recursive make
portably; maybe it would be a start to write an exclude list for this,
though, so one could find outliers.
We could probably let config.status warn if its output contained lines
matching @[a-zA-Z_]\{1,\}@ (sed BRE notation), maybe given some
configure option or macro to enable or disable this. But this wouldn't
solve this particular problem: you need to find instances of $(variable)
that aren't initialized.
Cheers,
Ralf
