Re: Updating top-level autoconf to 2.59

Re: Updating top-level autoconf to 2.59

[Daniel Jacobowitz]

On Wed, Feb 07, 2007 at 04:11:18PM -0500, DJ Delorie wrote:
> 
> Daniel Jacobowitz <drow@false.org> writes:
> > Only a week late.  I have lightly retested this on x86_64-pc-linux-gnu
> > native; I am willing to do any specific testing requested.  OK to
> > commit, and what testing would you like to see first?
> 
> Could you test Solaris or Cygwin?  Preferably in a combined tree, or
> at least a gcc/binutils/newlib combo?
> 
> A canadian cross would be nice too.

This patch is just like yesterday's, except that it does not suffer
from the naming problem associated with explicit --host and --target.

I tested yesterday's patch by bootstrapping all languages on
sparc-sun-solaris2.10.1 (well, almost.  See if I ever volunteer to do
that again.  It's still going through libjava).

I tested today's by building and installing C on x86_64-pc-linux-gnu
(with and without explicit --build/--host/--target), and building and
installing an x86_64-linux -> Windows -> ARM EABI combined tree for C
and C++.

In all cases I inspected the arguments passed to subdirectory
configures.  They were the same except for replacement of s,x,x,
by s,y,y, in the "mostly native" case, as expected.

Is this OK?

Alexandre asked me to rename configure.in to configure.ac at the same
time as committing this; I'll do that too if approved.  Yay for svn mv.

-- 
Daniel Jacobowitz
CodeSourcery

2007-02-08  Daniel Jacobowitz  <dan@codesourcery.com>

	* Makefile.tpl (build_alias, host_alias, target_alias): Use
	noncanonical equivalents.
	* configure.in: Update AC_PREREQ.  Prevent error for AS_FOR_TARGET.
	Set build_noncanonical, host_noncanonical, and target_noncanonical.
	Use them.  Rewrite removal of configure arguments for autoconf
	2.59.  Discard variable settings.  Force program_transform_name for
	native tools.
	* Makefile.in: Regenerated.
	* configure: Regenerated with autoconf 2.59.

Index: Makefile.tpl
===================================================================
--- Makefile.tpl	(revision 121693)
+++ Makefile.tpl	(working copy)
@@ -28,15 +28,15 @@ in
 # -------------------------------
 VPATH=@srcdir@
 
-build_alias=@build_alias@
+build_alias=@build_noncanonical@
 build_vendor=@build_vendor@
 build_os=@build_os@
 build=@build@
-host_alias=@host_alias@
+host_alias=@host_noncanonical@
 host_vendor=@host_vendor@
 host_os=@host_os@
 host=@host@
-target_alias=@target_alias@
+target_alias=@target_noncanonical@
 target_vendor=@target_vendor@
 target_os=@target_os@
 target=@target@
Index: configure.in
===================================================================
--- configure.in	(revision 121693)
+++ configure.in	(working copy)
@@ -21,10 +21,27 @@
 sinclude(config/acx.m4)
 
 AC_INIT(move-if-change)
-AC_PREREQ(2.13)
+AC_PREREQ(2.59)
+
+# Find the build, host, and target systems.
+ACX_NONCANONICAL_BUILD
+ACX_NONCANONICAL_HOST
+ACX_NONCANONICAL_TARGET
+
+dnl Autoconf 2.5x and later will set a default program prefix if
+dnl --target was used, even if it was the same as --host.  Disable
+dnl that behavior.  This must be done before AC_CANONICAL_SYSTEM
+dnl to take effect.
+test "$host_noncanonical" = "$target_noncanonical" &&
+  test "$program_prefix$program_suffix$program_transform_name" = \
+    NONENONEs,x,x, &&
+  program_transform_name=s,y,y,
+
 AC_CANONICAL_SYSTEM
 AC_ARG_PROGRAM
 
+m4_pattern_allow([^AS_FOR_TARGET$])dnl
+
 # Get 'install' or 'install-sh' and its variants.
 AC_PROG_INSTALL
 ACX_PROG_LN
@@ -1016,9 +1033,9 @@ if test "${build}" != "${host}" ; then
   # If we are doing a Canadian Cross, in which the host and build systems
   # are not the same, we set reasonable default values for the tools.
 
-  CC=${CC-${host_alias}-gcc}
+  CC=${CC-${host_noncanonical}-gcc}
   CFLAGS=${CFLAGS-"-g -O2"}
-  CXX=${CXX-${host_alias}-c++}
+  CXX=${CXX-${host_noncanonical}-c++}
   CXXFLAGS=${CXXFLAGS-"-g -O2"}
   CC_FOR_BUILD=${CC_FOR_BUILD-gcc}
 
@@ -1584,7 +1601,7 @@ if test x"${with_headers}" != x && test 
     "") x=${prefix} ;;
     *) x=${exec_prefix} ;;
     esac
-    copy_dirs="${copy_dirs} ${with_headers} $x/${target_alias}/sys-include"
+    copy_dirs="${copy_dirs} ${with_headers} $x/${target_noncanonical}/sys-include"
   fi
 fi
 
@@ -1604,7 +1621,7 @@ if test x"${with_libs}" != x && test x"$
     *) x=${exec_prefix} ;;
     esac
     for l in ${with_libs}; do
-      copy_dirs="$l $x/${target_alias}/lib ${copy_dirs}"
+      copy_dirs="$l $x/${target_noncanonical}/lib ${copy_dirs}"
     done
   fi
 fi
@@ -1804,7 +1821,7 @@ esac
 
 # Some systems (e.g., one of the i386-aix systems the gas testers are
 # using) don't handle "\$" correctly, so don't use it here.
-tooldir='${exec_prefix}'/${target_alias}
+tooldir='${exec_prefix}'/${target_noncanonical}
 build_tooldir=${tooldir}
 
 # Create a .gdbinit file which runs the one in srcdir
@@ -2068,40 +2085,86 @@ serialization_dependencies=serdep.tmp
 AC_SUBST_FILE(serialization_dependencies)
 
 # Base args.  Strip norecursion, cache-file, srcdir, host, build,
-# target and nonopt.  These are the ones we might not want to pass
-# down to subconfigures.  Also strip program-prefix, program-suffix,
-# and program-transform-name, so that we can pass down a consistent
-# program-transform-name.  If autoconf has put single quotes around
-# any of these arguments (because they contain shell metacharacters)
-# then this will fail; in practice this only happens for
-# --program-transform-name, so be sure to override --program-transform-name
-# at the end of the argument list.
-# These will be expanded by make, so quote '$'.
-cat <<\EOF_SED > conftestsed
-s/ --no[[^ ]]*/ /g
-s/ --c[[a-z-]]*[[= ]][[^ ]]*//g
-s/ --sr[[a-z-]]*[[= ]][[^ ]]*//g
-s/ --ho[[a-z-]]*[[= ]][[^ ]]*//g
-s/ --bu[[a-z-]]*[[= ]][[^ ]]*//g
-s/ --t[[a-z-]]*[[= ]][[^ ]]*//g
-s/ --program-[[pst]][[a-z-]]*[[= ]][[^ ]]*//g
-s/ -cache-file[[= ]][[^ ]]*//g
-s/ -srcdir[[= ]][[^ ]]*//g
-s/ -host[[= ]][[^ ]]*//g
-s/ -build[[= ]][[^ ]]*//g
-s/ -target[[= ]][[^ ]]*//g
-s/ -program-prefix[[= ]][[^ ]]*//g
-s/ -program-suffix[[= ]][[^ ]]*//g
-s/ -program-transform-name[[= ]][[^ ]]*//g
-s/ [[^' -][^ ]*] / /
-s/^ *//;s/ *$//
-s,\$,$$,g
-EOF_SED
-sed -f conftestsed <<EOF_SED > conftestsed.out
- ${ac_configure_args} 
-EOF_SED
-baseargs=`cat conftestsed.out`
-rm -f conftestsed conftestsed.out
+# target, nonopt, and variable assignments.  These are the ones we
+# might not want to pass down to subconfigures.  Also strip
+# program-prefix, program-suffix, and program-transform-name, so that
+# we can pass down a consistent program-transform-name.
+baseargs=
+keep_next=no
+skip_next=no
+eval "set -- $ac_configure_args"
+for ac_arg; do
+  if test X"$skip_next" = X"yes"; then
+    skip_next=no
+    continue
+  fi
+  if test X"$keep_next" = X"yes"; then
+    case $ac_arg in
+      *\'*)
+	ac_arg=`echo "$ac_arg" | sed "s/'/'\\\\\\\\''/g"` ;;
+    esac
+    baseargs="$baseargs '$ac_arg'"
+    keep_next=no
+    continue
+  fi
+
+  # Handle separated arguments.  Based on the logic generated by
+  # autoconf 2.59.
+  case $ac_arg in
+    *=* | --config-cache | -C | -disable-* | --disable-* \
+      | -enable-* | --enable-* | -gas | --g* | -nfp | --nf* \
+      | -q | -quiet | --q* | -silent | --sil* | -v | -verb* \
+      | -with-* | --with-* | -without-* | --without-* | --x)
+      separate_arg=no
+      ;;
+    -*)
+      separate_arg=yes
+      ;;
+    *)
+      separate_arg=no
+      ;;
+  esac
+
+  case "$ac_arg" in
+    --no*)
+      continue
+      ;;
+    --c* | \
+    --sr* | \
+    --ho* | \
+    --bu* | \
+    --t* | \
+    --program-* | \
+    -cache_file* | \
+    -srcdir* | \
+    -host* | \
+    -build* | \
+    -target* | \
+    -program-prefix* | \
+    -program-suffix* | \
+    -program-transform-name* )
+      skip_next=$separate_arg
+      continue
+      ;;
+    -*)
+      # An option.  Add it.
+      case $ac_arg in
+	*\'*)
+	  ac_arg=`echo "$ac_arg" | sed "s/'/'\\\\\\\\''/g"` ;;
+      esac
+      baseargs="$baseargs '$ac_arg'"
+      keep_next=$separate_arg
+      ;;
+    *)
+      # Either a variable assignment, or a nonopt (triplet).  Don't
+      # pass it down; let the Makefile handle this.
+      continue
+      ;;
+  esac
+done
+# Remove the initial space we just introduced and, as these will be
+# expanded by make, quote '$'.
+baseargs=`echo "x$baseargs" | sed -e 's/^x *//' -e 's,\\$,$$,g'`
 
 # Add in --program-transform-name, after --program-prefix and
 # --program-suffix have been applied to it.  Autoconf has already
@@ -2144,7 +2207,7 @@ target_configargs=${baseargs}
 # sorts of decisions they want to make on this basis.  Please consider
 # this option to be deprecated.  FIXME.
 if test x${is_cross_compiler} = xyes ; then
-  target_configargs="--with-cross-host=${host_alias} ${target_configargs}"
+  target_configargs="--with-cross-host=${host_noncanonical} ${target_configargs}"
 fi
 
 # Default to --enable-multilib.

Re: Updating top-level autoconf to 2.59

[DJ Delorie]

> Alexandre asked me to rename configure.in to configure.ac at the same
> time as committing this; I'll do that too if approved.  Yay for svn mv.

newlib/gdb/binutils still uses cvs, though.

Re: Updating top-level autoconf to 2.59

[Daniel Jacobowitz]

On Thu, Feb 08, 2007 at 05:30:28PM -0500, DJ Delorie wrote:
> 
> > Alexandre asked me to rename configure.in to configure.ac at the same
> > time as committing this; I'll do that too if approved.  Yay for svn mv.
> 
> newlib/gdb/binutils still uses cvs, though.

Well, up to you: leave it unmoved or lose the CVS history?  gdb has a
configure.ac nowadays, bfd doesn't.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Updating top-level autoconf to 2.59

[DJ Delorie]

> > newlib/gdb/binutils still uses cvs, though.
> 
> Well, up to you: leave it unmoved or lose the CVS history?  gdb has a
> configure.ac nowadays, bfd doesn't.

It was more of a reminder that you needed to update both repositories.

As for the cvs history, I think the long-term gain of following
conventions exceeds the short term gain of making history more readily
accessible.  The history is still there, just not in the same file.

Re: Updating top-level autoconf to 2.59

[DJ Delorie]

> Is this OK?

This is OK to commit in the morning; to give everyone one last chance
to complain.  It looks OK to me, but it affects such a large range of
projects that I'm being extra paranoid.  Newlib added to the cc list,
too.

> 2007-02-08  Daniel Jacobowitz  <dan@codesourcery.com>
> 
> 	* Makefile.tpl (build_alias, host_alias, target_alias): Use
> 	noncanonical equivalents.
> 	* configure.in: Update AC_PREREQ.  Prevent error for AS_FOR_TARGET.
> 	Set build_noncanonical, host_noncanonical, and target_noncanonical.
> 	Use them.  Rewrite removal of configure arguments for autoconf
> 	2.59.  Discard variable settings.  Force program_transform_name for
> 	native tools.
> 	* Makefile.in: Regenerated.
> 	* configure: Regenerated with autoconf 2.59.

Re: Updating top-level autoconf to 2.59

[Daniel Jacobowitz]

On Thu, Feb 08, 2007 at 05:54:24PM -0500, DJ Delorie wrote:
> 
> > Is this OK?
> 
> This is OK to commit in the morning; to give everyone one last chance
> to complain.  It looks OK to me, but it affects such a large range of
> projects that I'm being extra paranoid.  Newlib added to the cc list,
> too.

Here is what I have checked in.  I had to duplicate a bit of a patch
from Paul in 2005, to work around an autoconf bug (already fixed
upstream): AC_PATH_PROG mangles IFS if the supplied path is empty.
That showed up when I tested in src without GCC.

-- 
Daniel Jacobowitz
CodeSourcery

2007-02-09  Daniel Jacobowitz  <dan@codesourcery.com>

	* Makefile.tpl (build_alias, host_alias, target_alias): Use
	noncanonical equivalents.
	* configure.in: Rename to...
	* configure.ac: ...this.  Update AC_PREREQ.  Prevent error for
	AS_FOR_TARGET.  Set build_noncanonical, host_noncanonical, and
	target_noncanonical.  Use them.  Rewrite removal of configure
	arguments for autoconf 2.59.  Discard variable settings.  Force
	program_transform_name for native tools.

	* Makefile.in: Regenerated.
	* configure: Regenerated with autoconf 2.59.

	* src-release (DEVO_SUPPORT, do-proto-toplev): Expect configure.ac.

2007-02-09  Daniel Jacobowitz  <dan@codesourcery.com>

	* acx.m4 (ACX_CHECK_INSTALLED_TARGET_TOOL): Avoid AC_PATH_PROG
	with an empty path.

Index: configure.ac
===================================================================
--- configure.ac	(revision 121749)
+++ configure.ac	(working copy)
@@ -21,10 +21,27 @@
 sinclude(config/acx.m4)
 
 AC_INIT(move-if-change)
-AC_PREREQ(2.13)
+AC_PREREQ(2.59)
+
+# Find the build, host, and target systems.
+ACX_NONCANONICAL_BUILD
+ACX_NONCANONICAL_HOST
+ACX_NONCANONICAL_TARGET
+
+dnl Autoconf 2.5x and later will set a default program prefix if
+dnl --target was used, even if it was the same as --host.  Disable
+dnl that behavior.  This must be done before AC_CANONICAL_SYSTEM
+dnl to take effect.
+test "$host_noncanonical" = "$target_noncanonical" &&
+  test "$program_prefix$program_suffix$program_transform_name" = \
+    NONENONEs,x,x, &&
+  program_transform_name=s,y,y,
+
 AC_CANONICAL_SYSTEM
 AC_ARG_PROGRAM
 
+m4_pattern_allow([^AS_FOR_TARGET$])dnl
+
 # Get 'install' or 'install-sh' and its variants.
 AC_PROG_INSTALL
 ACX_PROG_LN
@@ -1016,9 +1033,9 @@ if test "${build}" != "${host}" ; then
   # If we are doing a Canadian Cross, in which the host and build systems
   # are not the same, we set reasonable default values for the tools.
 
-  CC=${CC-${host_alias}-gcc}
+  CC=${CC-${host_noncanonical}-gcc}
   CFLAGS=${CFLAGS-"-g -O2"}
-  CXX=${CXX-${host_alias}-c++}
+  CXX=${CXX-${host_noncanonical}-c++}
   CXXFLAGS=${CXXFLAGS-"-g -O2"}
   CC_FOR_BUILD=${CC_FOR_BUILD-gcc}
 
@@ -1584,7 +1601,7 @@ if test x"${with_headers}" != x && test 
     "") x=${prefix} ;;
     *) x=${exec_prefix} ;;
     esac
-    copy_dirs="${copy_dirs} ${with_headers} $x/${target_alias}/sys-include"
+    copy_dirs="${copy_dirs} ${with_headers} $x/${target_noncanonical}/sys-include"
   fi
 fi
 
@@ -1604,7 +1621,7 @@ if test x"${with_libs}" != x && test x"$
     *) x=${exec_prefix} ;;
     esac
     for l in ${with_libs}; do
-      copy_dirs="$l $x/${target_alias}/lib ${copy_dirs}"
+      copy_dirs="$l $x/${target_noncanonical}/lib ${copy_dirs}"
     done
   fi
 fi
@@ -1804,7 +1821,7 @@ esac
 
 # Some systems (e.g., one of the i386-aix systems the gas testers are
 # using) don't handle "\$" correctly, so don't use it here.
-tooldir='${exec_prefix}'/${target_alias}
+tooldir='${exec_prefix}'/${target_noncanonical}
 build_tooldir=${tooldir}
 
 # Create a .gdbinit file which runs the one in srcdir
@@ -2068,40 +2085,86 @@ serialization_dependencies=serdep.tmp
 AC_SUBST_FILE(serialization_dependencies)
 
 # Base args.  Strip norecursion, cache-file, srcdir, host, build,
-# target and nonopt.  These are the ones we might not want to pass
-# down to subconfigures.  Also strip program-prefix, program-suffix,
-# and program-transform-name, so that we can pass down a consistent
-# program-transform-name.  If autoconf has put single quotes around
-# any of these arguments (because they contain shell metacharacters)
-# then this will fail; in practice this only happens for
-# --program-transform-name, so be sure to override --program-transform-name
-# at the end of the argument list.
-# These will be expanded by make, so quote '$'.
-cat <<\EOF_SED > conftestsed
-s/ --no[[^ ]]*/ /g
-s/ --c[[a-z-]]*[[= ]][[^ ]]*//g
-s/ --sr[[a-z-]]*[[= ]][[^ ]]*//g
-s/ --ho[[a-z-]]*[[= ]][[^ ]]*//g
-s/ --bu[[a-z-]]*[[= ]][[^ ]]*//g
-s/ --t[[a-z-]]*[[= ]][[^ ]]*//g
-s/ --program-[[pst]][[a-z-]]*[[= ]][[^ ]]*//g
-s/ -cache-file[[= ]][[^ ]]*//g
-s/ -srcdir[[= ]][[^ ]]*//g
-s/ -host[[= ]][[^ ]]*//g
-s/ -build[[= ]][[^ ]]*//g
-s/ -target[[= ]][[^ ]]*//g
-s/ -program-prefix[[= ]][[^ ]]*//g
-s/ -program-suffix[[= ]][[^ ]]*//g
-s/ -program-transform-name[[= ]][[^ ]]*//g
-s/ [[^' -][^ ]*] / /
-s/^ *//;s/ *$//
-s,\$,$$,g
-EOF_SED
-sed -f conftestsed <<EOF_SED > conftestsed.out
- ${ac_configure_args} 
-EOF_SED
-baseargs=`cat conftestsed.out`
-rm -f conftestsed conftestsed.out
+# target, nonopt, and variable assignments.  These are the ones we
+# might not want to pass down to subconfigures.  Also strip
+# program-prefix, program-suffix, and program-transform-name, so that
+# we can pass down a consistent program-transform-name.
+baseargs=
+keep_next=no
+skip_next=no
+eval "set -- $ac_configure_args"
+for ac_arg; do
+  if test X"$skip_next" = X"yes"; then
+    skip_next=no
+    continue
+  fi
+  if test X"$keep_next" = X"yes"; then
+    case $ac_arg in
+      *\'*)
+	ac_arg=`echo "$ac_arg" | sed "s/'/'\\\\\\\\''/g"` ;;
+    esac
+    baseargs="$baseargs '$ac_arg'"
+    keep_next=no
+    continue
+  fi
+
+  # Handle separated arguments.  Based on the logic generated by
+  # autoconf 2.59.
+  case $ac_arg in
+    *=* | --config-cache | -C | -disable-* | --disable-* \
+      | -enable-* | --enable-* | -gas | --g* | -nfp | --nf* \
+      | -q | -quiet | --q* | -silent | --sil* | -v | -verb* \
+      | -with-* | --with-* | -without-* | --without-* | --x)
+      separate_arg=no
+      ;;
+    -*)
+      separate_arg=yes
+      ;;
+    *)
+      separate_arg=no
+      ;;
+  esac
+
+  case "$ac_arg" in
+    --no*)
+      continue
+      ;;
+    --c* | \
+    --sr* | \
+    --ho* | \
+    --bu* | \
+    --t* | \
+    --program-* | \
+    -cache_file* | \
+    -srcdir* | \
+    -host* | \
+    -build* | \
+    -target* | \
+    -program-prefix* | \
+    -program-suffix* | \
+    -program-transform-name* )
+      skip_next=$separate_arg
+      continue
+      ;;
+    -*)
+      # An option.  Add it.
+      case $ac_arg in
+	*\'*)
+	  ac_arg=`echo "$ac_arg" | sed "s/'/'\\\\\\\\''/g"` ;;
+      esac
+      baseargs="$baseargs '$ac_arg'"
+      keep_next=$separate_arg
+      ;;
+    *)
+      # Either a variable assignment, or a nonopt (triplet).  Don't
+      # pass it down; let the Makefile handle this.
+      continue
+      ;;
+  esac
+done
+# Remove the initial space we just introduced and, as these will be
+# expanded by make, quote '$'.
+baseargs=`echo "x$baseargs" | sed -e 's/^x *//' -e 's,\\$,$$,g'`
 
 # Add in --program-transform-name, after --program-prefix and
 # --program-suffix have been applied to it.  Autoconf has already
@@ -2144,7 +2207,7 @@ target_configargs=${baseargs}
 # sorts of decisions they want to make on this basis.  Please consider
 # this option to be deprecated.  FIXME.
 if test x${is_cross_compiler} = xyes ; then
-  target_configargs="--with-cross-host=${host_alias} ${target_configargs}"
+  target_configargs="--with-cross-host=${host_noncanonical} ${target_configargs}"
 fi
 
 # Default to --enable-multilib.
Index: Makefile.tpl
===================================================================
--- Makefile.tpl	(revision 121749)
+++ Makefile.tpl	(working copy)
@@ -28,15 +28,15 @@ in
 # -------------------------------
 VPATH=@srcdir@
 
-build_alias=@build_alias@
+build_alias=@build_noncanonical@
 build_vendor=@build_vendor@
 build_os=@build_os@
 build=@build@
-host_alias=@host_alias@
+host_alias=@host_noncanonical@
 host_vendor=@host_vendor@
 host_os=@host_os@
 host=@host@
-target_alias=@target_alias@
+target_alias=@target_noncanonical@
 target_vendor=@target_vendor@
 target_os=@target_os@
 target=@target@
@@ -1588,7 +1588,7 @@ config.status: configure
 
 # Rebuilding configure.
 AUTOCONF = autoconf
-$(srcdir)/configure: @MAINT@ $(srcdir)/configure.in $(srcdir)/config/acx.m4
+$(srcdir)/configure: @MAINT@ $(srcdir)/configure.ac $(srcdir)/config/acx.m4
 	cd $(srcdir) && $(AUTOCONF)
 
 # ------------------------------
Index: config/acx.m4
===================================================================
--- config/acx.m4	(revision 121749)
+++ config/acx.m4	(working copy)
@@ -300,7 +300,7 @@ if test -z "$ac_cv_path_$1" ; then
     ac_cv_path_$1=[$]$1
   fi
 fi
-if test -z "$ac_cv_path_$1" ; then
+if test -z "$ac_cv_path_$1" && test -n "$gcc_cv_tool_dirs"; then
   AC_PATH_PROG([$1], [$2], [], [$gcc_cv_tool_dirs])
 fi
 if test -z "$ac_cv_path_$1" ; then
Index: src-release
===================================================================
RCS file: /cvs/src/src/src-release,v
retrieving revision 1.21
diff -u -p -r1.21 src-release
--- src-release	31 May 2006 15:14:34 -0000	1.21
+++ src-release	9 Feb 2007 15:03:34 -0000
@@ -46,7 +46,7 @@ PWD = $${PWDCMD-pwd}
 # Files in devo used in any net release.
 # ChangeLog omitted because it may refer to files which are not in this
 # distribution (perhaps it would be better to include it anyway).
-DEVO_SUPPORT= README Makefile.in configure configure.in \
+DEVO_SUPPORT= README Makefile.in configure configure.ac \
 	config.guess config.sub config move-if-change \
 	COPYING COPYING.LIB install-sh config-ml.in symlink-tree \
 	mkinstalldirs ltconfig ltmain.sh missing ylwrap \
@@ -184,9 +184,9 @@ do-proto-toplev: $(DEVO_SUPPORT) $(SUPPO
 	 done)
 	#
 	# Take out texinfo from configurable dirs
-	rm proto-toplev/configure.in
+	rm proto-toplev/configure.ac
 	sed -e '/^host_tools=/s/texinfo //' \
-	    <configure.in >proto-toplev/configure.in
+	    <configure.ac >proto-toplev/configure.ac
 	#
 	mkdir proto-toplev/texinfo
 	ln -s ../../texinfo/texinfo.tex		proto-toplev/texinfo/

Re: Updating top-level autoconf to 2.59

[Maciej W. Rozycki]

On Fri, 9 Feb 2007, Daniel Jacobowitz wrote:

> Here is what I have checked in.  I had to duplicate a bit of a patch
> from Paul in 2005, to work around an autoconf bug (already fixed
> upstream): AC_PATH_PROG mangles IFS if the supplied path is empty.
> That showed up when I tested in src without GCC.

 Could using autoconf 2.61 have helped?

  Maciej

Re: Updating top-level autoconf to 2.59

[Daniel Jacobowitz]

On Fri, Feb 09, 2007 at 03:37:00PM +0000, Maciej W. Rozycki wrote:
> On Fri, 9 Feb 2007, Daniel Jacobowitz wrote:
> 
> > Here is what I have checked in.  I had to duplicate a bit of a patch
> > from Paul in 2005, to work around an autoconf bug (already fixed
> > upstream): AC_PATH_PROG mangles IFS if the supplied path is empty.
> > That showed up when I tested in src without GCC.
> 
>  Could using autoconf 2.61 have helped?

Yes, but I am unwilling to try migrating more than one thing at a time
right now.  This patch puts all of gcc and src, at long last, on the
same version of autoconf.  Moving the whole tree to 2.61 is a separate
project.

(Oh dear, there must be some documentation I didn't update
somewhere...)

-- 
Daniel Jacobowitz
CodeSourcery

Re: Updating top-level autoconf to 2.59

[Maciej W. Rozycki]

On Fri, 9 Feb 2007, Daniel Jacobowitz wrote:

> >  Could using autoconf 2.61 have helped?
> 
> Yes, but I am unwilling to try migrating more than one thing at a time
> right now.  This patch puts all of gcc and src, at long last, on the
> same version of autoconf.  Moving the whole tree to 2.61 is a separate
> project.

 I see, though frankly I wouldn't consider switching from 2.59 to 2.61 too 
much of a project.  And certainly much less than doing the 2.13 to 2.59 
conversion at the top level.  Of course in 2.61 there may be different 
bugs than in 2.59, but I gather the new version is not meant to imply any 
kind of revolution.  Even if there were some subtle problems somewhere, 
they should get sorted out as things go by stage 3.

 Or is it because of the new structure of install directories?

  Maciej

Re: Updating top-level autoconf to 2.59

[Daniel Jacobowitz]

On Fri, Feb 09, 2007 at 04:13:43PM +0000, Maciej W. Rozycki wrote:
>  I see, though frankly I wouldn't consider switching from 2.59 to 2.61 too 
> much of a project.  And certainly much less than doing the 2.13 to 2.59 
> conversion at the top level.  Of course in 2.61 there may be different 
> bugs than in 2.59, but I gather the new version is not meant to imply any 
> kind of revolution.  Even if there were some subtle problems somewhere, 
> they should get sorted out as things go by stage 3.
> 
>  Or is it because of the new structure of install directories?

There's simply too many directories.  We'd want to upgrade all of src
and gcc at once.

And yes, there are some troublesome changes - like, if you don't adjust
your makefiles, you get warnings about ignoring datarootdir.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Updating top-level autoconf to 2.59

[Joseph S. Myers]

On Fri, 9 Feb 2007, Maciej W. Rozycki wrote:

>  Or is it because of the new structure of install directories?

Yes, new install directories.  You don't want "make install" to produce a 
tree with some files in the new locations and some in the old.

New makefile variables need adding everywhere.  Automake needs upgrading 
to 1.10 at the same time.

A number of local configure options (--with-datarootdir --with-docdir 
--with-htmldir) need removing everywhere since new autoconf has standard 
replacements for them.  The documentation needs updating to remove those 
options and reflect the standard replacements.

The local install-html support in automake-using directories (which those 
configure options are present to support) needs removing when upgrading to 
new automake with built-in install-html support.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Updating top-level autoconf to 2.59

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> And yes, there are some troublesome changes - like, if you don't adjust
> your makefiles, you get warnings about ignoring datarootdir.

That's true, but those are benign and can be dealt with incrementally.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Updating top-level autoconf to 2.59

[Maciej W. Rozycki]

On Fri, 9 Feb 2007, Daniel Jacobowitz wrote:

> On Fri, Feb 09, 2007 at 04:13:43PM +0000, Maciej W. Rozycki wrote:
> >  I see, though frankly I wouldn't consider switching from 2.59 to 2.61 too 
> > much of a project.  And certainly much less than doing the 2.13 to 2.59 
> > conversion at the top level.  Of course in 2.61 there may be different 
> > bugs than in 2.59, but I gather the new version is not meant to imply any 
> > kind of revolution.  Even if there were some subtle problems somewhere, 
> > they should get sorted out as things go by stage 3.
> > 
> >  Or is it because of the new structure of install directories?
> 
> There's simply too many directories.  We'd want to upgrade all of src
> and gcc at once.

 Sure -- I use a script like this for regenerating all the scripts:

for name in `find . -name 'configure.[ai][cn]' -exec dirname "{}" \;`; do
	(cd $name && autoconf)
	STATUS=$?
	if [ $STATUS -ne 0 ]; then
		exit $STATUS
	fi
done

I have similar scripts for running `libtoolize', `aclocal', `autoheader' 
and `automake' if interested.  They should make the tree consistent, 
though configuring and running `make' may be necessary afterwards and 
before committing the changes for some timestamps to be updated (most 
notably for results of `autoheader').

 BTW, do we still want to carry local copies of severely obsolete libtool 
scripts?  I have had success with libtool 1.5.22 and GCC 4.1.1 after a 
moderate amount of work (mostly shuffling bits around; libjava/ was the 
most involving part) -- if there is interest in upgrading (which might 
help some people with less common configurations) I could port them to the 
trunk sooner rather than later.

> And yes, there are some troublesome changes - like, if you don't adjust
> your makefiles, you get warnings about ignoring datarootdir.

 Indeed, though they are not fatal.  Perhaps Makefile.in files in the 
affected directories (Makefile.am are OK as sufficiently new automake will 
deal with that) could get updated beforehand?  It should not hurt at all.

  Maciej

Re: Updating top-level autoconf to 2.59

[Daniel Jacobowitz]

On Fri, Feb 09, 2007 at 05:39:27PM +0000, Maciej W. Rozycki wrote:
>  Sure -- I use a script like this for regenerating all the scripts:

That's not what I meant.  There's just too many cases that need to be
tested.  Anyway, you're welcome to do it now that the top level has
moved up :-)  I'm out of time for the moment.

>  BTW, do we still want to carry local copies of severely obsolete libtool 
> scripts?  I have had success with libtool 1.5.22 and GCC 4.1.1 after a 
> moderate amount of work (mostly shuffling bits around; libjava/ was the 
> most involving part) -- if there is interest in upgrading (which might 
> help some people with less common configurations) I could port them to the 
> trunk sooner rather than later.

I believe the plan was to upgrade top level configure first, then
libtool and automake (I don't remember if they were supposed to be done
together or in a particular order).  Definitely I want to remove the
libtool fork.  But talk about a change needing a lot of testing...

Your patches would definitely be welcome.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Updating top-level autoconf to 2.59

[Steve Ellcey]

>  BTW, do we still want to carry local copies of severely obsolete libtool 
> scripts?  I have had success with libtool 1.5.22 and GCC 4.1.1 after a 
> moderate amount of work (mostly shuffling bits around; libjava/ was the 
> most involving part) -- if there is interest in upgrading (which might 
> help some people with less common configurations) I could port them to the 
> trunk sooner rather than later.
> 
>   Maciej

Actually, getting libtool updated was my original goal in all of this.
I was told that we couldn't update libtool until we had updated
autoconf.  So now that autoconf is updated, I hope we can work on
libtool.

Steve Ellcey
sje@cup.hp.com

Re: Updating top-level autoconf to 2.59

[Maciej W. Rozycki]

On Fri, 9 Feb 2007, Daniel Jacobowitz wrote:

> That's not what I meant.  There's just too many cases that need to be
> tested.  Anyway, you're welcome to do it now that the top level has
> moved up :-)  I'm out of time for the moment.

 I'll have a look.

> I believe the plan was to upgrade top level configure first, then
> libtool and automake (I don't remember if they were supposed to be done
> together or in a particular order).  Definitely I want to remove the
> libtool fork.  But talk about a change needing a lot of testing...

 Of course testing is needed.  But my feeling is keeping jumps between 
versions of auxiliary tools as small as possible should give us less 
breakage at a time.  I think it may be quite a reasonable idea to check 
whether the tools might be updated every time we are in stage 1.

> Your patches would definitely be welcome.

 OK, I'll raise the priority for this task.  At least problems that I have 
already discovered will be known if not fixed this way.

  Maciej

Re: Updating top-level autoconf to 2.59

[Tom Tromey]

>>>>> "Maciej" == Maciej W Rozycki <macro@linux-mips.org> writes:

Maciej>  Sure -- I use a script like this for regenerating all the scripts:

autoreconf ought to do a lot of the work for you.
Though I don't recall whether it knows to read ACLOCAL_AMFLAGS, which
is necessary for proper operation...

>> And yes, there are some troublesome changes - like, if you don't adjust
>> your makefiles, you get warnings about ignoring datarootdir.

Maciej>  Indeed, though they are not fatal.  Perhaps Makefile.in files
Maciej> in the affected directories (Makefile.am are OK as
Maciej> sufficiently new automake will deal with that) could get
Maciej> updated beforehand?  It should not hurt at all.

I think automake 1.10 requires the new autoconf.  So, Makefile.ins
can't be updated first.

Tom

Re: Updating top-level autoconf to 2.59

[Maciej W. Rozycki]

On Fri, 9 Feb 2007, Tom Tromey wrote:

> Maciej>  Indeed, though they are not fatal.  Perhaps Makefile.in files
> Maciej> in the affected directories (Makefile.am are OK as
> Maciej> sufficiently new automake will deal with that) could get
> Maciej> updated beforehand?  It should not hurt at all.
> 
> I think automake 1.10 requires the new autoconf.  So, Makefile.ins
> can't be updated first.

 Well, adding a definition of the $(datarootdir) variable like this:

datarootdir = @datadir@
datadir = $(datarootdir)

should not require any updates for tools and can then be converted to the 
final form of:

datarootdir = @datarootdir@
datadir = @datadir@

for Makefile.in or removed altogether for Makefile.am files once the tools 
have been updated.  At least it seems to work on my system. :-)

  Maciej

Re: Updating top-level autoconf to 2.59

[Andreas Schwab]

"Maciej W. Rozycki" <macro@linux-mips.org> writes:

> On Fri, 9 Feb 2007, Tom Tromey wrote:
>
>> Maciej>  Indeed, though they are not fatal.  Perhaps Makefile.in files
>> Maciej> in the affected directories (Makefile.am are OK as
>> Maciej> sufficiently new automake will deal with that) could get
>> Maciej> updated beforehand?  It should not hurt at all.
>> 
>> I think automake 1.10 requires the new autoconf.  So, Makefile.ins
>> can't be updated first.
>
>  Well, adding a definition of the $(datarootdir) variable like this:
>
> datarootdir = @datadir@
> datadir = $(datarootdir)
>
> should not require any updates for tools and can then be converted to the 
> final form of:
>
> datarootdir = @datarootdir@
> datadir = @datadir@

You don't need the intermediate form.  The final form will work for both.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."