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

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

[Juanma Barranquero]

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

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

[Eli Zaretskii]

> Date: Sun, 21 Mar 2004 19:01:46 +0100
> From: Juanma Barranquero <lektu@mi.madritel.es>
> 
> 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:

Is it true that the variables in the registry are actually pushed
into the environment of the running Emacs, so that `getenv' sees
them?  If so, can we override these variables with real environment
variables set either by the shell or by Make?

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

I don't think this is a hack no more than the whole Makefile system
for building Emacs on Windows, which is already full of worse tricks
in order to support the different makes of shells, compilers, and Make
varieties.

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

[Juanma Barranquero]

On 22 Mar 2004 07:49:22 +0200
Eli Zaretskii <eliz@elta.co.il> wrote:

> Is it true that the variables in the registry are actually pushed
> into the environment of the running Emacs, so that `getenv' sees
> them?

Well, if I change HKLM\SOFTWARE\GNU\Emacs\SHELL to point to a
non-existent exe, M-x shell fails, so yes.

> I don't think this is a hack no more than the whole Makefile system
> for building Emacs on Windows, which is already full of worse tricks
> in order to support the different makes of shells, compilers, and Make
> varieties.

The "hack", in my view, is having to process %COMSPEC% to escape \'s
before passing it to Emacs. But, hey, I agree: the Windows makefile
system is a bit of a nightmare (though I *fully* understand why it's
done the way it is, I'm not pointing fingers).

> If so, can we override these variables with real environment
> variables set either by the shell or by Make?

Yes, you're right! I overlooked that :)

So, you're proposing this fix instead of deleting the registry entries?
If so, what's a good default to SHELL? %COMSPEC%?


                                                                Juanma

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

[Eli Zaretskii]

> Date: Mon, 22 Mar 2004 12:38:19 +0100
> From: Juanma Barranquero <jmbarranquero@wke.es>
> 
> > If so, can we override these variables with real environment
> > variables set either by the shell or by Make?
> 
> Yes, you're right!

Good.

> So, you're proposing this fix instead of deleting the registry entries?

Yes.  It seems to me that something like

      export SHELL = ....

in the Makefile is better than the other tricks.  (I hope nmake has a
similar feature.)

> If so, what's a good default to SHELL? %COMSPEC%?

I'd try ComSpec first, and if that's not defined (on Windows 9X), use
COMSPEC.