----- "Steffen Dettmer" <steffen.dettmer@xxxxxxxxxxxxxx> wrote: > ok, let me rephrase my question: > What was the motivation to change the name of the main file to be > processfrom by autoconf to .ac? Because *.in designates a file that will be processed by config.status, as part of running ./configure. Note that 'configure' is NOT created by config.status by processing configure.in during the ./configure, so it is NOT a good fit for the *.in namespace. Rather, it is created by autoconf PRIOR to running configure. Using the separate suffix namespace *.ac makes a clear delineation of which tool is used to process the file. > > There are many other files processed by autoconf, such as macro > include files. I looked to a few examples in > http://www.gnu.org/software/autoconf-archive but all I picked > were called file.m4 not file.ac (which is fine of course!). Yes, the naming convention is that ALL OTHER files processed by autoconf are *.m4, since they are m4 macro snippets to be included in addition to the configure.ac shell that ties them all together. > > Do we have to expect in future to see a renaming here too? Not likely, and not without lots of discussion. But the naming change to configure.ac was YEARS ago, for autoconf 2.50. And now that autoconf 2.59 is about as old as you can reliably go (for example, RHEL 5 still uses autoconf 2.59), it is completely safe to use the (not so) new naming convention. > > > Is the renaming configure.in to configure.ac cosmetic only > > > > No (cf. above) > > Sorry, I didn't get it. Above I understood that it is cosmetic > only (by some convention because configure.in isn't arbitrarily > formated but written in the "autoconf-language", it should be > called configure.ac), so the answer here should be `yes', > shouldn't it? At one point, it was mainly cosmetic. But these days, there are a number of other projects that have sprung up that EXPECT the name configure.ac. For example, gnulib assumes that you use the new naming convention, and if you want to use the gnulib maintainer-makefile module, it will fall flat on its face if you still use configure.in. > > > > and is it safe to keep configure.in in old projects/branches? > > No, you should rename them. Keeping configure.in's doesn't make > > no sense at all. autoconf will warn about the existence of configure.in, but proceed to process configure.ac, if both exist. Not all other tools are prepared to handle both existing in the same directory. > > IMHO, it can make: > it saves work, > it does not break existing sandboxes, > it keeps the file history (there are projects that cannot use GIT > :-)), CVS can keep file history across renames, with proper admin rights. And many projects did the rename even before git was a twinkle in Linus' eyes. > it keeps diffs between releases small, > it keeps old branches the same as new branches, > switching brances is less problematic > (switching brances break the sandbox when configure.in/.ac gets > renamed), > it can be merged even in projects that aren't using GIT, > and I guess there are many more :) Ultimately, it's your project, so it's your call. But this list will stick by our recommendations to do the rename. -- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
