Bug 61591 - Use autoconf-2.53 when running autoconf
Use autoconf-2.53 when running autoconf
Status: CLOSED RAWHIDE
Product: Red Hat Public Beta
Classification: Retired
Component: automake15 (Show other bugs)
skipjack-beta1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
:
: 62232 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-21 17:18 EST by Enrico Scholz
Modified: 2008-05-01 11:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-04-03 10:48:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
missing patch to search for versioned autoconf and automake programs (1.96 KB, patch)
2002-04-03 03:16 EST, Jens Petersen
no flags Details | Diff

  None (edit)
Description Enrico Scholz 2002-03-21 17:18:10 EST
m4/init.m4 contains

| AC_DEFUN([AM_INIT_AUTOMAKE],
| ...
| AM_MISSING_PROG(AUTOCONF, autoconf)
| AM_MISSING_PROG(AUTOMAKE, automake-${am__api_version})
| AM_MISSING_PROG(AUTOHEADER, autoheader)
| ...

Therefore, when running 'make' on a modified configure.ac, 'autoconf' (version
2.13) will be called. Because it makes not very much sense to run a modern
automake with an antiquated autoconf, this will be probably wrong.

I suggest to replace the lines above with

| AC_DEFUN([AM_INIT_AUTOMAKE],
| ...
| AM_MISSING_PROG(AUTOCONF, autoconf-2.53)
| AM_MISSING_PROG(AUTOMAKE, automake-${am__api_version})
| AM_MISSING_PROG(AUTOHEADER, autoheader-2.53)
| ...

Because automake15 is used only rarely in Skipjack, it won't break something.



Example demonstrating the issue:

$ cat <<EOF >configure.ac
AC_INIT(x,1,y)
AM_INIT_AUTOMAKE

AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF

$ touch Makefile.am

$ aclocal-1.6

$ automake-1.6 --foreign -a

$ autoconf-2.53 

$ ./configure

$ touch configure.ac

$ make
cd . && /bin/sh /tmp/am2/missing --run autoconf
autoconf: configure.in: No such file or directory
make: *** [configure] Error 1
Comment 1 Jens Petersen 2002-03-27 13:04:53 EST
Ah, but it seems to me that this may break portability, won't it?
Developers who use this would create project dists that won't build out of the
box on systems without versioned auto* scripts, after say configure.ac or
Makefile.am has been touched.

Perhaps a better solution to this, would be to use alternatives to choose which
autoconf and automake version is the default?
Comment 2 Enrico Scholz 2002-03-27 14:40:52 EST
Broken Portability
==================

Yes, it breaks the portability -- but IMHO this is not very important, because:

- after calling 'aclocal' the RH-specific changes are reverted
- changing the configure.ac or Makefile.am is a uncommon action for end-users, 
  the developer knows what he has to do and distributors are rebuilding these 
  files by calling auto* explicitly
- other people than these above will get a message from 'missing' telling that 
  the program was not found and can call auto* explicitly
(- configure.ac without AM_MAINTAINER_MODE are erroneous and a pain for the
   end-user)


Alternatives
============

I do not see much profit in the alternative-system (not all Debian-stuff makes
sense). 'alternatives' makes system-wide settings but autoconf-2.13 vs.
autoconf-2.5 is a per-user decision. 

Such an user-decision can be done already by setting environment variables, but
it is bloat because each AUTO* program requires such a variable.

Probably, you will run into problems with the slave-links of automake also
(Version 1.4 contains 4 info-files, version 1.5  5 ones, but alternatives
requires the same count of slave links).


Other ways
==========

The best solution would be if autoconf/automake are writing the needed
program-names into configure and the Makefile.am.

Another hac^Wfix would be the modification of ./missing in a way like:

| case "$1" in
| --run)
|   # Try to run requested program, and just exit if it succeeds.
|   run=
|   shift
|-  "$@" && exit 0
|+  prog="$1"
|+  shift
|+  case "$prog" in
|+    autoconf)
|+      for flavor in "-2.53" ""; do
|+        "$prog$flavor" "$@" && exit 0
|+      done;;
|+    automake)
|+      for flavor in "-1.6" "-1.5" ""; do
|+        "$prog$flavor" "$@" && exit 0
|+      done;;
|+    *) "$prog" "$@" && exit 0;;
|+  esac
|+  set -- "$prog" "$@"
|  ;;
|esac
Comment 3 Jens Petersen 2002-04-02 03:36:17 EST
*** Bug 62232 has been marked as a duplicate of this bug. ***
Comment 4 Bill Crawford 2002-04-02 18:01:33 EST
This is becoming something of an issue, because e.g. GNOME 2.0 prereleases won't
build with an "older" autoconf or automake.  Is there any way autoconf, automake
and aclocal can be updated without breaking "compatability" (strictly, this is a
source issue rather than an ABI one, isn't it) ?

Comment 5 Jens Petersen 2002-04-03 02:20:10 EST
billc, in the mean time you can use
  make AUTOCONF=autoconf-2.53 AUTOMAKE=automake-1.5 \
    ACLOCAL=aclocal-1.5
etc.

Enrico, what is the reason for the
  set -- "$prog" "$@"
in your suggested change to missing?
Comment 6 Enrico Scholz 2002-04-03 02:32:51 EST
Because I shift'ed the first argument out of $@

| prog="$1"
| shift

and want to keep the rest of 'missing' working as before, I restore $@ with the
'set -- ...' statement.

But as indicated above already, I consider the modification if 'missing' with
this hardcoded version-numbers as a dirty hack. The "correct" way will be the
modification of 'autoconf' so that it codes its version-number somewhere into
configure. 

The 'automake' case-clause is not needed for 'automake' >= 1.6 because it
encodes its version-info already.
Comment 7 Enrico Scholz 2002-04-03 02:37:38 EST
billc: don't forget to set 'AUTOHEADER=autoheader-2.53' in the way shown above
also...
Comment 8 Jens Petersen 2002-04-03 03:16:02 EST
Created attachment 51965 [details]
missing patch to search for versioned autoconf and automake programs
Comment 9 Jens Petersen 2002-04-03 03:18:30 EST
Ok, I'm going to try with the above patch based on Enrico's suggestion.
Does it look ok?
Comment 10 Jens Petersen 2002-04-03 03:33:39 EST
I put the latest package at:

http://people.redhat.com/petersen/SRPMS/automake15-1.5-2.src.rpm
http://people.redhat.com/petersen/RPMS/noarch/automake15-1.5-2.noarch.rpm

so if you could bang on it, it would be well appreciated.
Comment 11 Jens Petersen 2002-04-03 04:07:29 EST
While I agree that the missing patch is a bit of a hack, it is quite
flexible and making configure understanding versioning will create
more portability problems I would say.  So I think the above is a
reasonable compromise.
Comment 12 Jay Turner 2002-04-03 10:48:41 EST
Can someone confirm this is working as expected now with the latest packages?
Comment 13 Jens Petersen 2002-04-08 01:35:15 EDT
A mass rebuild of the tree was run by Tim Friday and there were no build
regressions relative to public beta2.
Comment 14 Jens Petersen 2002-04-12 03:32:33 EDT
The automake15-1.5-2 is in rawhide now.

Note You need to log in before you can comment on or make changes to this bug.