Re: A better autogen.sh

[Glenn Morris]

Eli Zaretskii wrote:

> How would I know that a change needed, and (more importantly) how
> would I know what to update there?

I assume you at least have access to a POSIX platform, eg fencepost,
where you can run autoconf once in a while.

> And what do you mean by "your src/ version there"?  How will it help,
> if it is just a result of editing config.in with Sed?  I have no other
> src/ version.

The src/config.in version you get from running autoconf on a POSIX
platform.

> nt/config.nt is maintained by hand, allright, but that's done by
> tracking changes in src/config.in.  If src/config.in is removed from
> the repository, maintaining nt/config.nt will hit a snag, because
> there will be no file to "bzr diff" against the previous version and
> see what's changed, and how else would someone know how to update
> config.nt?

Whenever an AC_DEFINE is changed in configure.in, config.in might need
to be changed. Or, diff your generated src/config.in against the
msdos/config.in in the repository.

>> > autogen.sh could begin by removing config.in.
>> 
>> That's a bit ugly
>
> Why ugly, move-if-change should be fine.  What am I missing?

It's ugly because then everybody has a src/config.in file that appears
to be locally modified all the time. You're also relying on someone with
access to a POSIX platform to keep regenerating src/config.in and
committing it whenever it changes. Trying to avoid the need to do this
is part of the motivation for this proposal.

> It will be, if there's a practical way to know how to update the
> private config.in without having a Posix platform nearby.

I hope it's not unreasonable to assume the MS-DOS maintainer can access
a POSIX platform once in a while. Every Emacs developer can get a
fencepost account.

If it were me, I'd keep the same version of autoconf installed. I'd run
it periodically and diff the generated src/config.in against
msdos/config.in. If there was a difference, I'd copy the former to the
latter and commit it.


Personally I think it's still worth removing configure even if
config.in has to stay, because the latter changes a lot less often.
But I hope src/config.in doesn't have to be kept just for the sake of
MS.