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

[Steffen Dettmer]

On Mon, Mar 8, 2010 at 2:21 PM, Eric Blake <address@hidden> wrote:
> "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.

OK, thank you for clarification.
So it is for `documentary purposes' and should not harm
autoconf's functionality.

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

Yes, no doubt about that. Also no doubt that it is correct for
all projects started since the change that it is correct to start
with configure.ac instead of configure.in.

  (we have a some configure.in from 2001, for example. If I
  remember correctly even in 2003 one major compile server had a
  linux version from 2000 because known to work and never change
  a running system :-), under CVS control. Since then it had been
  a problem to rename, because at any time sandboxes existed, CVS
  diffs were needed etc. Since fortunately autoconf was backward
  [or be it bugward-compatible], it wasn't needed to pay the
  disadvantages just to have a better name. Also, I think, our
  configure.in script code is very outdated, not in the correct
  M4 Autoconf language (but mostly bash), but it works :))

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

ahh yes, I see. So have to keep an eye to that.

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

(ohh, so the obvious ln -s / cp workaround will not work)

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

Do you have a link where I can learn more about?
Or do you mean by copying / touching the ,v files, pretending
that it had been configure.ac all the time?
This breaks CVS Tags (or more precise, alters the contents of a
tag, thus reproducing an old cvs export generates a wrong result).

> Ultimately, it's your project, so it's your call.  But this list
> will stick by our recommendations to do the rename.

Yes, this is correct and helpful. I'm sure we had much less
problems if we had better listened to recommendations in the past.

oki,

Steffen