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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
