[PATCH] [4/14] Completes renaming of configure.in files to .ac

[PATCH] [4/14] Completes renaming of configure.in files to .ac

[Michael Darling]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

(I was requested by binutils to split my May 24 and Jul 16 patches
into separate files for each binutils-gdb main subdirectory.)

Combined builds has been broken for about 10 months, because some binutils
configure.in files were renamed to configure.ac, but gcc's references to them
were not updated.  Fixing gcc's references to them is much easier by renaming
the few straggling configure.in files to configure.ac. gcc's configure.in
files were entirely renamed to configure.ac some time ago. There are
corresponding patches submitted to gcc, which updates all references to
binutils-gdb configure.in files to configure.ac, which is what ultimately
fixes combined builds.

See PR binutils-gdb/binutils/18450 and gcc/other/66259.

Signed-off by: Michael Darling <darlingm@gmail.com>
---
 config/ChangeLog  | 8 ++++++++
 config/gettext.m4 | 4 ++--
 config/po.m4      | 4 ++--
 config/stdint.m4  | 2 +-
 config/tcl.m4     | 4 ++--
 5 files changed, 15 insertions(+), 7 deletions(-)

[-- Attachment #2: 0001-4-14-Completes-renaming-of-configure.in-files-to-con.patch --]
[-- Type: application/octet-stream, Size: 5416 bytes --]

From 0fdcfc7e99aa40a87a931d86d091f0aced581cb5 Mon Sep 17 00:00:00 2001
From: Michael Darling <darlingm@gmail.com>
Date: Thu, 16 Jul 2015 22:30:01 -0400
Subject: [PATCH] [4/14] Completes renaming of configure.in files to .ac

Combined builds has been broken for about 10 months, because some binutils
configure.in files were renamed to configure.ac, but gcc's references to them
were not updated.  Fixing gcc's references to them is much easier by renaming
the few straggling configure.in files to configure.ac. gcc's configure.in
files were entirely renamed to configure.ac some time ago. There are
corresponding patches submitted to gcc, which updates all references to
binutils-gdb configure.in files to configure.ac, which is what ultimately
fixes combined builds.

See PR binutils-gdb/binutils/18450 and gcc/other/66259.

Signed-off by: Michael Darling <darlingm@gmail.com>
---
 config/ChangeLog  | 8 ++++++++
 config/gettext.m4 | 4 ++--
 config/po.m4      | 4 ++--
 config/stdint.m4  | 2 +-
 config/tcl.m4     | 4 ++--
 5 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/config/ChangeLog b/config/ChangeLog
index 5e36bee..c8f1ffd 100644
--- a/config/ChangeLog
+++ b/config/ChangeLog
@@ -1,3 +1,11 @@
+2015-07-16  Micahel Darling  <darlingm@gmail.com>
+
+	PR binutils/18450
+	* gettext.m4: Reflects renaming of configure.in to configure.ac
+	* po.m4: Likewise
+	* stdint.m4: Likewise
+	* tcl.m4: Likewise
+
 2015-07-14  H.J. Lu  <hongjiu.lu@intel.com>
 
 	Sync with GCC
diff --git a/config/gettext.m4 b/config/gettext.m4
index 16070b4..45fa6b4 100644
--- a/config/gettext.m4
+++ b/config/gettext.m4
@@ -81,7 +81,7 @@ AC_DEFUN([AM_GNU_GETTEXT],
   dnl Ideally we would do this search only after the
   dnl      if test "$USE_NLS" = "yes"; then
   dnl        if test "$gt_cv_func_gnugettext_libc" != "yes"; then
-  dnl tests. But if configure.in invokes AM_ICONV after AM_GNU_GETTEXT
+  dnl tests. But if configure.ac invokes AM_ICONV after AM_GNU_GETTEXT
   dnl the configure script would need to contain the same shell code
   dnl again, outside any 'if'. There are two solutions:
   dnl - Invoke AM_ICONV_LINKFLAGS_BODY here, outside any 'if'.
@@ -303,7 +303,7 @@ return (int) gettext ("")]ifelse([$2], [need-ngettext], [ + (int) ngettext ("",
     AC_SUBST(USE_INCLUDED_LIBINTL)
     AC_SUBST(CATOBJEXT)
 
-    dnl For backward compatibility. Some configure.ins may be using this.
+    dnl For backward compatibility. Some configure.acs may be using this.
     nls_cv_header_intl=
     nls_cv_header_libgt=
 
diff --git a/config/po.m4 b/config/po.m4
index 2edd5a7..6ceef42 100644
--- a/config/po.m4
+++ b/config/po.m4
@@ -117,14 +117,14 @@ AC_DEFUN([AM_PO_SUBDIRS],
           if test -f "$ac_given_srcdir/$ac_dir/LINGUAS"; then
             # The LINGUAS file contains the set of available languages.
             if test -n "$OBSOLETE_ALL_LINGUAS"; then
-              test -n "$as_me" && echo "$as_me: setting ALL_LINGUAS in configure.in is obsolete" || echo "setting ALL_LINGUAS in configure.in is obsolete"
+              test -n "$as_me" && echo "$as_me: setting ALL_LINGUAS in configure.ac is obsolete" || echo "setting ALL_LINGUAS in configure.ac is obsolete"
             fi
             ALL_LINGUAS_=`sed -e "/^#/d" "$ac_given_srcdir/$ac_dir/LINGUAS"`
             # Hide the ALL_LINGUAS assigment from automake.
             eval 'ALL_LINGUAS''=$ALL_LINGUAS_'
             POMAKEFILEDEPS="$POMAKEFILEDEPS LINGUAS"
           else
-            # The set of available languages was given in configure.in.
+            # The set of available languages was given in configure.ac.
             eval 'ALL_LINGUAS''=$OBSOLETE_ALL_LINGUAS'
           fi
           case "$ac_given_srcdir" in
diff --git a/config/stdint.m4 b/config/stdint.m4
index 61898a7..59f4359 100644
--- a/config/stdint.m4
+++ b/config/stdint.m4
@@ -39,7 +39,7 @@ dnl If your installed header files require the stdint-types you will want to
 dnl create an installable file mylib-int.h that all your other installable
 dnl header may include. So, for a library package named "mylib", just use
 dnl      GCC_HEADER_STDINT(mylib-int.h)
-dnl in configure.in and install that header file in Makefile.am along with
+dnl in configure.ac and install that header file in Makefile.am along with
 dnl the other headers (mylib.h).  The mylib-specific headers can simply
 dnl use "#include <mylib-int.h>" to obtain the stdint-types.
 dnl
diff --git a/config/tcl.m4 b/config/tcl.m4
index 59a0c7e..4542a4b 100644
--- a/config/tcl.m4
+++ b/config/tcl.m4
@@ -2136,7 +2136,7 @@ dnl # preprocessing tests use only CPPFLAGS.
             INSTALL_LIB='$(INSTALL_LIBRARY) $(LIB_FILE) $(LIB_INSTALL_DIR)/$(LIB_FILE) ; (cd $(LIB_INSTALL_DIR) ; $(RANLIB) $(LIB_FILE))'
         fi
 
-dnl        Not at all clear what this was doing in Tcl's configure.in
+dnl        Not at all clear what this was doing in Tcl's configure.ac
 dnl        or why it was needed was needed. In any event, this sort of
 dnl        things needs to be done in the big loop above.
 dnl        REMOVE THIS BLOCK LATER! (mdejong)
@@ -3235,7 +3235,7 @@ AC_DEFUN([SC_TCL_GETGRNAM_R], [AC_CHECK_FUNC(getgrnam_r, [
 #		created. Accumulates.
 #
 #	Requires presence of SC_OUTPUT_COMMANDS_PRE at the end
-#	of configure.in (right before AC_OUTPUT).
+#	of configure.ac (right before AC_OUTPUT).
 #
 #--------------------------------------------------------------------
 
-- 
2.4.4

Re: [PATCH] [4/14] Completes renaming of configure.in files to .ac

[H.J. Lu]

On Thu, Jul 16, 2015 at 8:09 PM, Michael Darling <darlingm@gmail.com> wrote:
> (I was requested by binutils to split my May 24 and Jul 16 patches
> into separate files for each binutils-gdb main subdirectory.)
>
> Combined builds has been broken for about 10 months, because some binutils
> configure.in files were renamed to configure.ac, but gcc's references to them
> were not updated.  Fixing gcc's references to them is much easier by renaming
> the few straggling configure.in files to configure.ac. gcc's configure.in
> files were entirely renamed to configure.ac some time ago. There are
> corresponding patches submitted to gcc, which updates all references to
> binutils-gdb configure.in files to configure.ac, which is what ultimately
> fixes combined builds.
>
> See PR binutils-gdb/binutils/18450 and gcc/other/66259.
>
> Signed-off by: Michael Darling <darlingm@gmail.com>
> ---
>  config/ChangeLog  | 8 ++++++++
>  config/gettext.m4 | 4 ++--
>  config/po.m4      | 4 ++--
>  config/stdint.m4  | 2 +-
>  config/tcl.m4     | 4 ++--
>  5 files changed, 15 insertions(+), 7 deletions(-)

Since all configure files are generated from them, this patch must be
checked in first.
But some of them are imported and some imported packages still use configure.in,
not configure.ac.

What is the real value of changing "configure.in" in comments/messages to
"configure.ac" when both are used in packages?

-- 
H.J.

Re: [PATCH] [4/14] Completes renaming of configure.in files to .ac

[Michael Darling]

> Since all configure files are generated from them, this patch must be
> checked in first.
> But some of them are imported and some imported packages still use configure.in,
> not configure.ac.
>
> What is the real value of changing "configure.in" in comments/messages to
> "configure.ac" when both are used in packages?

Before binutils commit 35eafcc7 a year ago, I'm pretty sure everything
in binutils-gdb used the .in extension.  And, around that time, I'm
pretty sure everything in gcc also used the .in extension.
Binutils-gdb partially moved over to the .ac extension, and gcc
completely moved over to the .ac extension.

This left a lot of references pointing to the wrong extension.
Allowing both extensions, even if made to work now, will break again
someday.  I think having comments, messages, and documentation point
semi-randomly to one or the other is inviting future confusion.

I think the only way to permanently fix this is to complete the
(almost complete) transition to the .ac extension.  I would have
probably personally left everything as a .in extension, since for now
there's no real difference, but I think the transition should either
be complete or not there at all.  Since the conversion already
started, I think all references anywhere to the .in extension should
be updated.  (Unless in a historical context like a ChangeLog.)

Which imported packages use configure.in?  I'm happy to submit patches
for those, too.

Re: [PATCH] [4/14] Completes renaming of configure.in files to .ac

[Jan Beulich]

>>> On 17.07.15 at 06:26, <darlingm@gmail.com> wrote:
> Which imported packages use configure.in?  I'm happy to submit patches
> for those, too.

The answer to this may not even matter - consuming components
(like gcc is in respect to binutils) shouldn't assume only the newer
name is used: It should remain to be possible to build with older
versions. I.e. you always have to check for both .ac and .in when
looking for a file.

Jan

Re: [PATCH] [4/14] Completes renaming of configure.in files to .ac

[Michael Darling]

Perhaps the best solution is both sets of patches.

Yours to modify the build system so it can work with either extension,
old versions, and other imported packages.

Mine to complete binutils-gdb and gcc moving from configure.in to .ac
extension.  There have been several commits spread out across the last
year slowly moving the migration along.  People have been slowly
changing the extension over in their areas for the past year, but not
getting everything moved over at once.

Finish it up, have consistency, use the "prefered" extension, prevent
the warning about old ".in" extensions, make it robust so it works
with the old extension, and get combined builds working again.

On Fri, Jul 17, 2015 at 6:43 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 17.07.15 at 06:26, <darlingm@gmail.com> wrote:
>> Which imported packages use configure.in?  I'm happy to submit patches
>> for those, too.
>
> The answer to this may not even matter - consuming components
> (like gcc is in respect to binutils) shouldn't assume only the newer
> name is used: It should remain to be possible to build with older
> versions. I.e. you always have to check for both .ac and .in when
> looking for a file.
>
> Jan
>