FESCo Proposal for blocking older version of autoconf & automake
Toshio Kuratomi
a.badger at gmail.com
Tue May 6 16:04:59 UTC 2008
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
More information about the fedora-devel-list
mailing list