From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.devel Subject: Re: Should lisp/Makefile.in custom-deps be using EMACS or emacs? Date: Sat, 27 Jul 2002 15:28:32 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <87k7ng3ogf.fsf@raven.i.defaultvalue.org> References: <87k7o86ycp.fsf@raven.i.defaultvalue.org> <200207091852.g69Iq3A13934@aztec.santafe.edu> <87vg76qsjh.fsf@raven.i.defaultvalue.org> <200207251807.g6PI7S207666@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1027801744 27619 127.0.0.1 (27 Jul 2002 20:29:04 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 27 Jul 2002 20:29:04 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17YYBS-0007BM-00 for ; Sat, 27 Jul 2002 22:29:02 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17YYRs-0007WB-00 for ; Sat, 27 Jul 2002 22:46:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17YYBj-0003Hh-00; Sat, 27 Jul 2002 16:29:19 -0400 Original-Received: from dsl-209-87-109-2.constant.com ([209.87.109.2] helo=defaultvalue.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17YYAz-0003Gz-00; Sat, 27 Jul 2002 16:28:33 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id CFA09FDB; Sat, 27 Jul 2002 15:28:32 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 3254384C; Sat, 27 Jul 2002 15:28:32 -0500 (CDT) Original-To: rms@gnu.org Original-Lines: 103 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-pc-linux-gnu) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:6096 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6096 Richard Stallman writes: > In the case that fails, can you try running by hand under GDB the > command that actually uses cus-dep.el and step through the code in > init_lread which sets up load-path, to see why the installed Lisp > directories end up in the value? OK, I ran the function under gdb and below is what's happening (if you'd like more detailed or different information, just let me know). This was generated by running "make custom-deps" from the lisp directory after altering the Makefile.in to say wd=$(lisp); $(setwins); \ echo Directories: $$wins; \ gdb -x tmpgdbinit --args $(EMACS) $(EMACSOPT) \ -l cus-dep -f custom-make-dependencies $$wins so this should be the exact command that's normally used. Note that the line numbers are off a bit from the upstream because I added two dumy char*'s for PATH_LOADSEARCH and PATH_DUMPLOADSEARCH so I could look at their values. Breakpoint 3, init_lread () at lread.c:3338 3338 int turn_off_warning = 0; (gdb) n 3340 volatile char *pls = PATH_LOADSEARCH; (gdb) n 3341 volatile char *pdls = PATH_DUMPLOADSEARCH; (gdb) n 3348 if (NILP (Vpurify_flag)) (gdb) n 3349 normal = PATH_LOADSEARCH; (gdb) n 3358 if (initialized) (gdb) n 3360 if (! NILP (Fequal (dump_path, Vload_path))) (gdb) n 3362 Vload_path = decode_env_path (0, normal); (gdb) p normal $15 = 0x817a180 "/usr/share/emacs/21.2/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/21.2/leim:/usr/share/emacs/21.2/lisp" (gdb) p Vload_path $16 = 1478995844 (gdb) pr ("/opt/testemacs21/emacs-21.2/lisp") So Vload_path is just the build tree lisp dir at this point.. (gdb) n 3363 if (!NILP (Vinstallation_directory)) (gdb) p Vload_path $17 = 1479341396 (gdb) pr ("/usr/share/emacs/21.2/site-lisp" "/usr/share/emacs/site-lisp" "/usr/share/emacs/21.2/leim" "/usr/share/emacs/21.2/lisp") but now, after line 3362 has run, we can see that the load path is now the same as the "normal" var expanded, which was originally set from PATH_LOADSEARCH. There are no build tree elements anymore. After that, the lisp, leim, and site-lisp build-tree directories are added, but they're added to the *end* of Vload_path via nconc2 as can bee seen in the code below (and if you step through the code, you can see that the block including turn_off_warning below does in fact execute: /* Add to the path the lisp subdir of the installation dir, if it exists. */ Lisp_Object tem, tem1; tem = Fexpand_file_name (build_string ("lisp"), Vinstallation_directory); tem1 = Ffile_exists_p (tem); if (!NILP (tem1)) { if (NILP (Fmember (tem, Vload_path))) { turn_off_warning = 1; Vload_path = nconc2 (Vload_path, Fcons (tem, Qnil)); } } and so by the end of the function we have: 3502 Vstandard_input = Qt; (gdb) 3503 Vloads_in_progress = Qnil; (gdb) 3504 } (gdb) p Vload_path $18 = 1479341396 (gdb) pr ("/usr/share/emacs/21.2/site-lisp" "/usr/share/emacs/site-lisp" "/usr/share/emacs/21.2/leim" "/usr/share/emacs/21.2/lisp" "/opt/testemacs21/emacs-21.2/lisp" "/opt/testemacs21/emacs-21.2/leim" "/opt/testemacs21/emacs-21.2/site-lisp") (gdb) with all the build-tree elements at the end, *after* the install tree directories. Hope this helps. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD