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

[Steffen Dettmer]

On Mon, Mar 8, 2010 at 12:29 PM, Ralf Corsepius <address@hidden> wrote:
> * On 03/08/2010 12:12 PM, Steffen Dettmer wrote:
> > I'm trying to understand the motivation for renaming configure.in
> > to configure.ac. If I remember correctly it was related to the
> > fact that ./config.status or whoever else processes .in files.
>
> The reason is suffix rules:
>
> *.ac's are processed by "autoconf" (written in the "autoconf-language")

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?

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

Do we have to expect in future to see a renaming here too?

> *.in's are arbitrarily formated, arbitrarily formated files.

only from autoconf point of view. From projects point of view
each .in file must match the syntax rules of course.

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

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

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 :-)),
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 :)

(I wonder how the other projects did upgrade. Or maybe
compatiblity isn't such a big issue anymore? I found myself
unable to compile a recent gcc on a maybe three year old linux,
which surprised me a bit).

So I think to pay the disadvantages of a rename, a reason and a
benefit should outweigth it, shouldn't it?

oki,

Steffen