Re: [gentoo-dev] Why autoconf in system?
On Monday 12 September 2005 14:26, Frank Schafer wrote: Hi, we meet often the (faulty) notion that autoconf/automake (even a couple of versions on gentoo) is a dependency for packages. This is true only for development of these packages itself. Autoconf/automake provides tools to GENERATE configure scripts. Both are totally unnecessary to build a package or run the programs it provides. I've built a full featured LFS system not long ago without even autoconf/automake installed. I'd suggest to remove the build of autoconf/automake from ``emerge system''. I'd leave all of the autoconf/automake versions in portage tough for the case someone wants to involve in development of some package. One reason is that there are many packages that have faulty/incomplete versions of the scripts, or that have patches applied to the configure script. For those packages automake/autoconf must be installed at make time as automake/autoconf must be ran during the building of those packages. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpxde1ctOUtW.pgp Description: PGP signature
Re: [gentoo-dev] Why autoconf in system?
On Mon, 2005-09-12 at 14:26 +0200, Frank Schafer wrote:
Hi,
we meet often the (faulty) notion that autoconf/automake (even a couple
of versions on gentoo) is a dependency for packages.
This is true only for development of these packages itself.
Autoconf/automake provides tools to GENERATE configure scripts. Both are
totally unnecessary to build a package or run the programs it provides.
I've built a full featured LFS system not long ago without even
autoconf/automake installed.
I'd suggest to remove the build of autoconf/automake from ``emerge
system''. I'd leave all of the autoconf/automake versions in portage
tough for the case someone wants to involve in development of some
package.
While this is true, you missed the fact that many packages from time to
time apply patches that touches configure.{ac,in}, or Makefile.am, or
just do not come tarballed with configure, etc generated, so it is
indeed needed.
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Why autoconf in system?
On Monday 12 September 2005 08:26 am, Frank Schafer wrote: we meet often the (faulty) notion that autoconf/automake (even a couple of versions on gentoo) is a dependency for packages. not quite sure what you mean by 'faulty', autoconf/automake is used heavily throughout portage I'd suggest to remove the build of autoconf/automake from ``emerge system''. I'd leave all of the autoconf/automake versions in portage tough for the case someone wants to involve in development of some package. it wouldnt matter, coreutils for example would still need it which means it would show up in `emerge system` -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Why autoconf in system?
On Monday 12 September 2005 08:48 am, Frank Schafer wrote: On Mon, 2005-09-12 at 08:41 -0400, Mike Frysinger wrote: On Monday 12 September 2005 08:26 am, Frank Schafer wrote: we meet often the (faulty) notion that autoconf/automake (even a couple of versions on gentoo) is a dependency for packages. not quite sure what you mean by 'faulty', autoconf/automake is used heavily throughout portage I'd suggest to remove the build of autoconf/automake from ``emerge system''. I'd leave all of the autoconf/automake versions in portage tough for the case someone wants to involve in development of some package. it wouldnt matter, coreutils for example would still need it which means it would show up in `emerge system` Hi, as I mentioned, I built LFS without this (and I have coreutils on it ;) last i checked, Gentoo != LFS, so i dont really see what your point is we patch source files heavily and regenerate the configure/Makefile.in files in coreutils -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Why autoconf in system?
Hi, as I mentioned, I built LFS without this (and I have coreutils on it ;) Not at all - if we need to modify or create configure files during build as Paul and Martin said ... we need autoconf/automake And furthermore, many programs (or upstream authors if you prefer) are braindead and don't know what some non-x86 arches are without updating the config.sub/config.guess, and re-running autoconf/automake. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Why autoconf in system?
On Monday 12 September 2005 08:58 am, Stephen P. Becker wrote: Hi, as I mentioned, I built LFS without this (and I have coreutils on it ;) Not at all - if we need to modify or create configure files during build as Paul and Martin said ... we need autoconf/automake And furthermore, many programs (or upstream authors if you prefer) are braindead and don't know what some non-x86 arches are without updating the config.sub/config.guess, and re-running autoconf/automake. those two files dont require re-running autoconf/automake it isnt uncommon though to have upstream run autotools in the wrong order and package the result as their release ... then when you run `./configure make`, the build system has mismatched timestamps and thus tries to invoke autotools to fix itself :/ -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Why autoconf in system?
On Mon, 2005-09-12 at 10:38 -0400, Mike Frysinger wrote: On Monday 12 September 2005 08:58 am, Stephen P. Becker wrote: Hi, as I mentioned, I built LFS without this (and I have coreutils on it ;) Not at all - if we need to modify or create configure files during build as Paul and Martin said ... we need autoconf/automake And furthermore, many programs (or upstream authors if you prefer) are braindead and don't know what some non-x86 arches are without updating the config.sub/config.guess, and re-running autoconf/automake. those two files dont require re-running autoconf/automake it isnt uncommon though to have upstream run autotools in the wrong order and package the result as their release ... then when you run `./configure make`, the build system has mismatched timestamps and thus tries to invoke autotools to fix itself :/ Toss in libtool in the mess, and it runs aclocal, autoconf and then automake, and you end up with a mismatched ltmain.sh and whatever macro's of libtool expanded in configure, causing either breakage (random or not), or in our case an error informing about the mismatch :/ -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
