the script am-wrapper.pl acts basically as documented in the comments at the beginning of the script, the problem is that one of these behaviors is counter-intuitive. If a package has a configure.ac file rather than a configure.in file, and an acinclude.m4 rather than aclocal.m4 then any directives as to the version of automake in either of those files will be ignored and automake 1.5 will be used. The autoconf documentation implies that configure.ac is the preferred version and so the test for the AC_PREREQ macro should be in that file. This seems to stem from the 1.5 version of this script which decided that if configure.ac existed then the most current version of automake should be used. As the script was updated, this test was left, causing autoconf 1.5 to be preferred. It is important to note that the first time this script is run is when aclocal is run, thus it may be possible for acinclude.m4 to be processed using version 1.5, and then a version of autoconf to be used on configure.ac to get version 1.6 to be used on makefile.am Reproducible: Always Steps to Reproduce: 1.write a package that requires automake version 1.6 2.use configure.ac for autoconf 3.run autoreconf without aclocal.h or configure already being present Actual Results: errors like: automake-1.5: configure.ac: `AM_INIT_AUTOMAKE' must be used Expected Results: compilation without errors There is a simple work-around, namely set the environment variable "WANT_AUTOMAKE=1.6". Once the package compiles once, files such as aclocal.m4 or configure will give the versions of their creators and compiling will proceed without the environment variable.
It has to do with kde ... Can the KDE guys tell us if the kde system still need 1.5 automake version?
The more recent versions of kde (3.1 and 3.2) work fine with automake 1.7 (and prefer it I do believe). Portage still includes 3.0 for posterity, which I *believe* works okay with 1.6, but I don't know for sure. There are still (kde) applications in portage, though, that demand the older automake. Is the thought here to remove this support?
this applies to automake-1.8.5-r1 ? or automake-1.8.3 ?
re-open if 1.8.5-r1 doesnt address this issue (i'm not sure how to test if it's been fixed ...
