Re: A better autogen.sh

[Eli Zaretskii]

> From: Glenn Morris <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Wed, 16 Mar 2011 02:43:10 -0400
> 
> 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.

What would you or other maintainers say if I suggested a change that
would require them to log in to a remote system each time they wanted
to build the latest trunk, generate some file there, then copy it to
their local machine?  How can a member of a team even suggest
something like that to another member?

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

I don't think this is enough.  Don't other m4/* files contribute to
config.in eventually?  If I'm mistaken and it's all in configure.in,
this could be an okay alternative.  Even if it's not only in
configure.in, but grepping for AC_DEFINE in *.m4 files is all that's
needed, that would be good enough to make this a reasonable way of
maintaining the Windows and DOS config.h files.  I hope some autoconf
expert could tell one way or the other.

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

I don't see why it will appear modified, if its content is identical.
bzr is smart enough to not flag such files as modified.  Or am I
missing something?

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

I rather hope this will not the way, because it _is_ unreasonable,
both in practical terms and in its underlying attitude, which frankly
is revolting.

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

The trouble is, we keep requiring newer versions of autoconf from time
to time, and later more frequently than in the past.  Experience shows
that upgrading autoconf on fencepost involves asking GNU sysadmins to
do that, which takes a non-trivial amount of time and sometimes
repeated pinging.  I would like to avoid that, because it will make my
life as Emacs developer miserable.  Likewise with other contributors
to the maintenance of the Windows port (I don't think they even have a
fencepost account, btw).

> But I hope src/config.in doesn't have to be kept just for the sake
> of MS.

Me too, but it will take someone with working knowledge of the
machinery involved and a friendly attitude to help resolve this in a
way that we all can live with.