Re: Should lisp/Makefile.in custom-deps be using EMACS or emacs?

[Rob Browning]

Richard Stallman <address@hidden> 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