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

[Eli Zaretskii <eliz@elta.co.il>]

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