[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Building Emacs from a new MinGW environment

From: Dani Moncayo
Subject: Re: Building Emacs from a new MinGW environment
Date: Sat, 14 Sep 2013 16:25:03 +0200

> The %emacs_dir% part was supposed to be expanded.  If nothing else
> comes up from checking the installed packages, try to run the command
>   temacs --batch --load loadup bootstrap
> under GDB, and see why the expansion doesn't happen.

Caveat: my knowledge of gdb and debugging emacs is almost zero :).
However, after a few hours, I think I've found out something.

I've looked for the first call to "Fexpand_file_name" which returns a
"bad" file name (bad = containing a literal "%emacs_dir%").  It is
this one:

  #0  Fexpand_file_name (name=57476769, default_directory=57476785)
      at C:/msys/home/dani/emacs/emacs.git/src/fileio.c:1437
  #1  0x01119643 in Fexpand_file_name (name=57476753,
      at C:/msys/home/dani/emacs/emacs.git/src/fileio.c:930
  #2  0x011bf86f in init_callproc ()
      at C:/msys/home/dani/emacs/emacs.git/src/callproc.c:1616
  #3  0x010dad7c in main (argc=5, argv=0x972af8)
      at C:/msys/home/dani/emacs/emacs.git/src/emacs.c:1325

The parameters of the call in frame #0 were:
  (gdb) p SSDATA(name)
  $1 = 0x36c4d50 <__register_frame_info+57429328>
  (gdb) p SSDATA(default_directory)
  $3 = 0x36c4d7c <__register_frame_info+57429372>

The parameters of the call in frame #1 were:
  (gdb) p SSDATA(name)
  $4 = 0x36c4d48 <__register_frame_info+57429320> "GNU"
  (gdb) p SSDATA(default_directory)
  $5 = 0x36c4204 <__register_frame_info+57426436>

IIUC, the function call at frame 0 failed to expand the default
directory passed to the function call at frame 1.

Now, It seems to me that the code responsible for the expansion of
 "%emacs_dir%" is this snippet of "Fexpand_file_name":

  /* If the file name has special constructs in it,
     call the corresponding file handler.  */
  handler = Ffind_file_name_handler (name, Qexpand_file_name);
  if (!NILP (handler))
      handled_name = call3 (handler, Qexpand_file_name,
   name, default_directory);
      if (STRINGP (handled_name))
return handled_name;
      error ("Invalid handler in `file-name-handler-alist'");

But I observe that the call to "Ffind_file_name_handler" returns
"Qnil", and therefore the expansion (the call to "call3") is not
carried out.

Debugging inside "Ffind_file_name_handler", I see that the "for" loop
is never entered.

Does this gives you a clue of what is failing?  If you need more info,
just tell me what commands should I run.

Dani Moncayo

reply via email to

[Prev in Thread] Current Thread [Next in Thread]