> Once upon a time that was done through CVS, but CVS is no longer up to
> the job, and now every project is using a different distributed version
> control system. But, sooner or later, one of the competing projects
> will win out and "hopefully we'll have clarity again." Autotools and
> pkgconfig can also go a long way toward creating consistency between
He is right for cvs.
IMO obviously he isn't right for autotools.
Since some time a lot of projects are switching away from it, mainly to
CMake (and Scons).
Autotools (beside from being really hard to learn for developers) have
one real problem: they require a shell. Free software is becoming more
and more portable, also to Windows. Typical Windows users/developers
don't have a UNIX shell, so autotools don't work there (yes, there is
cygwin and different levels of mingw with shell, but IMO these are all
work-arounds). Look e.g. at Python, it has an autotools based build
system and additionally to that it has MSVC project files. I don't know
how e.g. Mozilla or Gimp or OpenOffice handle this, but having to
maintain multiple independent buildsystems in parallel is obviously no
And, honestly, pkgconfig has a big design flaw. It stores information
about how a library is to be used. But it stores it in a format which can
be used just for one purpose: executing it and feeding the results
directly as arguments into gcc. If the information would be available in
some structured way, it could be actually processed and also used for
other things (e.g. linking a library with pkgconfig information with
MSVC, or getting the include dirs and definitions for use in an IDE so it
can do proper autocompletion).