This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] [4/14] Completes renaming of configure.in files to .ac
- From: Michael Darling <darlingm at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>, GDB <gdb-patches at sourceware dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 17 Jul 2015 04:26:41 +0000
- Subject: Re: [PATCH] [4/14] Completes renaming of configure.in files to .ac
- Authentication-results: sourceware.org; auth=none
- References: <CABRuA+gsYZgBf0UL4hW7LWVDsz6cLkaxC2zgZGhHQ0gfQxhc1w at mail dot gmail dot com> <CAMe9rOocswe_Vbx9T+NWojSXqFw5Bvf+u1Fm7e2=B7k79btYnQ at mail dot gmail dot com>
> 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.