Re: Broken lisp/Makefile.w32-in

[Juanma Barranquero <lektu@terra.es>]

On Tue, 30 Jul 2002 23:59:11 -0700 (PDT), Tak Ota <Takaaki.Ota@am.sony.com> wrote:

> I suspect the use of an environment variable above is flawed since
> each action line is executed by independent shell (cmd.exe) thus the
> variable QWINS is not shared.  It should be corrected to something
> like this.
> 
> update-subdirs-CMD: doit
> 	echo ;; In load-path, after this directory should come> subdirs.el
> 	echo ;; certain of its subdirectories.  Here we specify them.>> subdirs.el
> 	echo (normal-top-level-add-to-load-path $(SQUOTE)(>> subdirs.el
> 	@for %d in ($(WINS)) do if not (%d)==(term) echo "%d">> subdirs.el
> 	echo ))>> subdirs.el

Before commiting this code to lisp/makefile.w32-in, "nmake
update-subdirs" didn't work in any Windows target that I tried. With it,
updating subdirs works in modern Windows, but still fails on W95 with
COMMAND.COM (the "for" somehow manages to send just one directory to
subdirs.el). I'm not sure about W98 and Me, although I'd love to know.

There's no question that the Windows port should continue supporting
*running* in old W95 and W98 machines, but it is really worthwhile to
continue supporting *building* on those machines?

I'd bet Emacs users on W95/98 do use binary tarballs and don't build
their own Emacs.

And there aren't many developers working on W95 either, because a recent
bug with stat() in HEAD that totally precluded compiling Emacs stood
unfixed for about a month without a single bug report about it.


                                                           /L/e/k/t/u