Re: A better autogen.sh

[Eli Zaretskii]

> Date: Tue, 15 Mar 2011 23:39:59 -0700
> From: Paul Eggert <address@hidden>
> CC: Glenn Morris <address@hidden>, address@hidden
> 
> On 03/15/2011 10:53 PM, Eli Zaretskii wrote:
> > It will be, if there's a practical way to know how to update the
> > private config.in without having a Posix platform nearby.
> 
> The same way you know now.  Somebody sends email.
> Or, perhaps Emacs doesn't build on MS Windows, and
> the diagnostics reveal the problem.

When that happens now, I can diff src/config.in against an older
version.

> Other possibilities include running GNU/Linux under a virtual
> machine on a Windows machine; or running Autoconf and Automake
> under Windows, and then generating config.in directly
> on the Windows machine.  Or one can grab a recent pretest
> version.
> 
> This is not an exhaustive list.
> There are other simple and practical ways to address
> this problem, which don't require putting
> automatically-generated output into the repository.

They are neither simple nor practical, sorry.  I hope autoconf experts
can come up with something that is simpler and more practical.
Unfortunately, I cannot myself suggest anything, as I don't know
enough about the machinery involved.

> >> This would lessen the need for tight coupling between the mainline and
> >> the DOS version.
> > What "tight coupling"?
> 
> Currently, when I edit files under src/ and src-lib/,
> I often have to worry about porting to MS Windows or MS-DOS.

And I need to worry about Posix platforms when I edit files in those
same directories.  So what?  C is C and Lisp is Lisp and
makefile.w32-in is just a Makefile.  There's no magic about that.

> There are many #ifdefs and similar constructs that complicate
> the code, and are needed only because of the MS ports.

There are ifdefs because of Solaris as well.  So what?  We try to keep
them to the absolute minimum, and when someone points out to one of
them that is used by DOS alone, I'm always happy to move it away in
any reasonably practical way.

> It would be better if this porting code were isolated
> to the msdos/ and nt/ directories, so that developers
> under GNU and GNUish systems did not have to look at it
> or worry about it.

It is already done, as much as is practical.

> The src/config.in file is one example of these #ifdef-like
> constructs.  The main reason we put src/config.in in the
> repository, and keep track of it and commit it by hand,
> is for the MS Windows port.

It was never because of MS-DOS.  This file was there from day one.
This is the first time removal of this file is considered.  Until now
it was used by every platform.

> If we can think of another way to handle this, it would save us
> work.

Fine with me, but please try to be less unkind to maintainers of
non-Posix platforms.  They are volunteers like yourself.

If there's a reasonable way of gleaning the information about the
added and removed #defines in src/config.in, I will be the first to
embrace it.  What you suggested until now is unreasonable.

> Moving src/config.in to msdos/config.in is one way to do that.
> It may require a bit more work on the part of the Windows
> developers, but it'll require less work from the rest of us,
> and overall it will be a win.

A shockingly egotistic position.  MS-Windows is my main development
platform for working on the bidirectional editing support.  Maybe you
will also claim that bidirectional editing is not needed by "the rest
of us", so my work on that is not important.