(Windows:) cmdproxy non-existent on bootstrapping after make realclean

[Juanma Barranquero <lektu@mi.madritel.es>]

A not-serious-but-annoying problem on realclean/bootstrap situations on
Windows:

If you've already built and installed Emacs, you're likely to have these
entries (among other) on the registry:

HKLM\SOFTWARE\GNU\Emacs\emacs_dir = "c:\emacs"
HKLM\SOFTWARE\GNU\Emacs\SHELL = "%emacs_dir%/bin/cmdproxy.exe"

Now, if you ever do "nmake realclean", you're gona delete
c:\emacs\bin\*.*, including cmdproxy.exe.

Next time you do "nmake bootstrap", all .el files will be compiled. The
trouble is, some .el files (gnus/gnus-art.el, gnus/gnus-ems.el) use
`shell-command-to-string' during compilation, to compute the initial
value of several variables. `shell-command-to-string' fails because it
cannot find cmdproxy.exe, so these files fail to compile. As they're
included, directly or indirectly, by most Gnus files, the net result is
that, after bootstrapping, a bunch of .el files did not generate their
corresponding .elc file.

The problem does not happen on the first bootstrapping (because there's
no SHELL variable on the registry), on subsequent bootstrapping (because
bin/*.* is not deleted), or on normal compile (because the .el files are
not regenerated and bin/cmdproxy.exe exists anyway). It only happens in
bootstrappings after realclean.

As far as I can see, it's neither a problem in the Gnus files (they're
not doing anything forbidden), nor in `shell-command-to-string' (works as
defined).

After pondering it a bit, I'm not sure what to do:

 - Deleting the SHELL registry entry on "nmake realclean" seems
   dangerously non-kosher (not good deleting something the user could
   have customized), but OTOH, it's perhaps the best answer, as SHELL is
   already overwritten by any "nmake install". OTTH, there's no tool to
   delete registry entries now, so that knowledge would have to be added
   to addpm (or another tool added to the toolset).

 - Modifying the makefiles to add "--eval (setq shell-file-name
   %COMSPEC%)" to compilation commands would work (after suitably escaping
   \'s in COMSPEC), but looks like a hack.

 - Delaying compilation of some .el files to after building the tools
   would also work, but it doesn't seem too clean either (I have the
   feeling the order things are done on a bootstrap is a bit of dark
   magic and quite fragile, and this fix would only add to the situation).

 - Doing nothing is another possibility: after all, the problem is only
   going to affect Windows developers, and we can do two "nmake
   bootstrap"s in a row on the rare case that we did "nmake realclean"
   before. Or we can manually delete SHELL from the registry. This is
   the easier fix, just a line or three on nt/INSTALL.

I'm leaning towards the first answer, because I've got the feeling that
on "nmake realclean", the most well-behaved thing would be deleting all
HKLM\SOFTWARE\GNU\Emacs entries which have default values (non-default
ones should be left untouched).

Else, last option, i.e., documenting the "problem", would be fine too.

Ideas/comments?


                                                           /L/e/k/t/u