[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Motivation for renaming to and its effect?

From: Eric Blake
Subject: Re: Motivation for renaming to and its effect?
Date: Mon, 8 Mar 2010 08:21:12 -0500 (EST)

----- "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 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
> but all I picked
> were called file.m4 not (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 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 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 to cosmetic only
> >
> > No (cf. above)
> Sorry, I didn't get it. Above I understood that it is cosmetic
> only (by some convention because isn't arbitrarily
> formated but written in the "autoconf-language", it should be
> called, 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  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

> > > and is it safe to keep in old projects/branches?
> > No, you should rename them. Keeping's doesn't make
> > no sense at all.

autoconf will warn about the existence of, but proceed
to process, 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 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]