Re: FESCo Proposal for blocking older version of autoconf & automake

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux