From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: (Windows:) cmdproxy non-existent on bootstrapping after make realclean Date: Sun, 21 Mar 2004 19:01:46 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20040321190023.5D7E.LEKTU@mi.madritel.es> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1079892270 12593 80.91.224.253 (21 Mar 2004 18:04:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 21 Mar 2004 18:04:30 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Mar 21 19:04:17 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B57J3-0008So-00 for ; Sun, 21 Mar 2004 19:04:17 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B57J3-0005HL-00 for ; Sun, 21 Mar 2004 19:04:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B57Hb-0005SP-2z for emacs-devel@quimby.gnus.org; Sun, 21 Mar 2004 13:02:47 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B57HF-0005QM-OY for emacs-devel@gnu.org; Sun, 21 Mar 2004 13:02:25 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B57Gj-0005DJ-G0 for emacs-devel@gnu.org; Sun, 21 Mar 2004 13:02:24 -0500 Original-Received: from [62.81.186.17] (helo=smtp07.retemail.es) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B57Gi-0005Cm-Hj for emacs-devel@gnu.org; Sun, 21 Mar 2004 13:01:52 -0500 Original-Received: from [127.0.0.1] ([213.37.34.81]) by smtp07.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040321180145.WGBU1216.smtp07.retemail.es@[127.0.0.1]> for ; Sun, 21 Mar 2004 19:01:45 +0100 Original-To: emacs-devel@gnu.org X-Mailer: Becky! ver. 2.08.01 [en] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:20690 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20690 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