Re: debbugs, and a FAQ, for Autotools

[Ralf Hemmecke]

> > > 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