[Top][All Lists]

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

Re: Motivation for renaming to and its effect

From: Steffen Dettmer
Subject: Re: Motivation for renaming to and its effect?
Date: Mon, 8 Mar 2010 19:10:11 +0100

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
> 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 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 instead of

  (we have a some 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 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 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

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

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

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



reply via email to

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