FESCo Proposal for blocking older version of autoconf & automake

[Toshio Kuratomi]

Jeroen van Meeuwen wrote:
> Toshio Kuratomi wrote:
>> Jeroen van Meeuwen wrote:
>>> One could imagine a policy in which new packages using these tools 
>>> would not be accepted per-se, while the tools would still be 
>>> available, packaged, for those other packages and developers that 
>>> need it.
>>>
>>> Does such, or something similar, make sense?
>>>
>> No.
>>
>> The packager should not have to use the autotools normally.  So during 
>> package review, what version of autotools is necessary might not come 
>> up.  Only when a problem is discovered that requires changing the 
>> configure.in/ac or Makefile.am will the version of autotools start 
>> mattering to the packager.
>>
> 
> While the "problem" may not be apparent at first, one can tell from any 
> configure.in/ac or Makefile.am whether it needs one of the older autofoo 
> tools though, right? If so, I can only conclude the reviewer would be 
> able to raise this (but, possibly, not block approval?). If not so, 
> forget what I said -I'm no guru in autofoo ;-)
> 
Not really.  You an tell which version of autoconf was used to create 
the configure script and which version of automake was used to create 
the Makefile.in's just by looking at the comments at the top of the 
generated files.  For instance, from configure::

   # Generated by GNU Autoconf 2.61 for giflib 4.1.6.

and from Makefile.in::

   # Makefile.in generated by automake 1.10 from Makefile.am.

However, this only tells you which versions of autoconf and automake 
were used to create these files.  It doesn't tell you which versions 
could possibly have been used.  Despite incompatibilities, some packages 
will generate correct Makefiles whether you use automake-1.4 or 
automake-1.9.

Of course, if you know which constructs cause problems between versions 
of autoconf/automake you can look at the source of the configure.ac and 
Makefile.ams to determine which require older versions... but that's the 
same as requiring all reviewers to know which constructs in C are no 
longer supported by gcc-4.3... with one major difference:  we compile 
the packages with gcc so many of the problematic constructs are caught 
by the compiler.  By and large we do not "compile" the configure.ac and 
Makefile.am's with autoconf and automake so we don't catch these 
problems via the toolchain.

> BTW... Given your statement:
> 
>  > The packager should not have to use the autotools normally.
> 
> I "never" *cough* the two packages that I'm upstream for *cough* ship 
> any autofoo output files, only autofoo input files; it's excluded from 
> the source tree and excluded in tarballs... Should I reconsider this? Is 
> it gonna give trouble at some point?
> 
Yes!  It's quite common to exclude from the source tree (in the VCS). 
This is the theory that only source files go in the VCS and they are 
regenerated from there.  This is fine.

However, autotools were designed to not be needed by the users of a 
package.  You, the upstream developer use autotools to create a 
configure script (and Makefile.ins) that gets included in your release 
tarball.  The user (or distro packager in the majority of cases these 
days) runs the configure script (which is a bourne script) to configure 
the program for their system and generate proper Makefiles.  This way, 
if you've written your configure.ac and Makefile.ams correctly the 
user's don't need to have the autotools installed on their system at all.

If you're using automake to create your tarballs, there's a great make 
target: make dist (also make distcheck which will also run any unittests 
you have configured) that can help you create tarballs that have 
configure and Makefile.in created and ready for your user's to consume.

-Toshio