Sure. But it is also relevant if one developer adds a macro which is
only available in some recent version of automake, say. Another
developer might not yet have that automake version.
It doesn't really seem any worse than _any_ potential tool
incompatibility problem -- compiler version, library version, etc --
though...
Usually those issues aren't such a huge deal, because most project try
to be relatively portable, and when version dependencies do crop up,
they can be dealt with relatively well using simple checks in the
configure script.
Isn't that what people usually do about autoconf versions too (declare a
minimum version in configure.ac)?
Yes. You can even declare a maximum (or exact) version, too, if that is
what you need. We did that in GCC, see the _GCC_AUTOCONF_VERSION_CHECK
macro in http://gcc.gnu.org/viewcvs/trunk/config/override.m4?view=markup
and with Automake, it should work at least to test $am__api_version at
configure time. I guess we should make it possible to test easily at
m4 run time too ...
Fine, but do you expect every developer to be able to write good m4
macros? Or search the Internet for macros that could be relevant for
ones own project?
I know projects where people (mis-)use autotools even if their project
is not fitting in a standard C project, just to gain a bit more
portability and achieve standard makefile targets where otherwise most
developers would program in a project specific langauge.
Is there actually a good reason, why the autotools are distributed as
separate packages (autoconf, automake, libtool, m4)? (Maybe even
pkg-config, but I still don't yet know exactly whether it is good for me.)
Nowadays, it's certainly not a question of diskstorage anymore and it
would probably ease autotools acceptance if there were just one software
to install. (Just a suggestion.)
(and I guess this is worth another FAQ entry ...)
Definitely.
Ralf
