> 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.
