Re: Motivation for renaming configure.in to configure.ac and its effect?

[Eric Blake]

----- "Steffen Dettmer" <address@hidden> 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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org