Arkadiusz Miskiewicz <[EMAIL PROTECTED]> writes:
> Usually generic system macros are placed in /usr/share/aclocal directory
> (and for example there is libtool.m4 from my libtool) and when you call
> aclocal macros used in configre.in are searched in /usr/share/aclocal
> and in acinclude.m4, acsite.m4... Now if you provide some wget specific
> macros you should place them in acinclude.m4 since aclocal.m4 is
> overwritten at aclocal call.
aclocal is part of Automake. wget doesn't use Automake. Don't use
Automake with packages that don't use it.
> The same thing with autoheader. When you change configre.in (for example
> add AC_CHECK_FUNCS(xyz) then autoheader call will place proper #undef
> HAVE_XYZ in config.h.in... But if you use some local definitions you
> must place #undef LOCAL_SOMETHING in accinclude.h to get it properly
> placed in config.h.in at autoheader call...
Manually maintaining config.h.in is how many packages have used autoconf
for years. It works fine.
I'd recommend switching to the three-argument form of AC_DEFINE when
people have the chance, as autoconf 2.50 strongly recommends it and it
generally works better and more reliably (and keeps all the information
related to a macro together with that macro, which is nice from a code
reuse perspective). But editing config.h.in isn't particularly hard.
(I *don't* recommend switching to acconfig.h; going all the way to using
the three-argument form of AC_DEFINE is better.)
Automake, on the other hand, I've never particularly liked and I think
frequently just makes everything more complicated, not simpler. If I were
starting a project from scratch, it would be worth considering, but for an
already-established project that has portable Makefiles already, I'm not
sure it's worth it.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
