Re: Building Emacs from a new MinGW environment

[Eli Zaretskii]

> Date: Sat, 14 Sep 2013 16:25:03 +0200
> From: Dani Moncayo <address@hidden>
> Cc: Emacs development discussions <address@hidden>
> 
> 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,
> default_directory=57422161)
>       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>
> "%emacs_dir%/share/emacs/24.3.50/etc/"
>   (gdb) p SSDATA(default_directory)
>   $3 = 0x36c4d7c <__register_frame_info+57429372>
> "c:/msys/home/dani/emacs/build/src/"
> 
> 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>
> "%emacs_dir%/share/emacs/24.3.50/etc/"
> 
> 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.

You need to step further down into init_callproc.  It should correctly
initialize Vdata_directory here:

  if (data_dir == 0)
    {
      Lisp_Object tem, tem1, srcdir;

      srcdir = Fexpand_file_name (build_string ("../src/"),
                                  build_string (PATH_DUMPLOADSEARCH));
      tem = Fexpand_file_name (build_string ("GNU"), Vdata_directory);
      tem1 = Ffile_exists_p (tem);
      if (!NILP (Fequal (srcdir, Vinvocation_directory)) || NILP (tem1))
        {
          Lisp_Object newdir;
          newdir = Fexpand_file_name (build_string ("../etc/"),
                                      build_string (PATH_DUMPLOADSEARCH));
          tem = Fexpand_file_name (build_string ("GNU"), newdir);
          tem1 = Ffile_exists_p (tem);
          if (!NILP (tem1))
            Vdata_directory = newdir;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
        }
    }

If that doesn't work, perhaps PATH_DUMPLOADSEARCH has the wrong value
(it comes from src/epaths.h).  If PATH_DUMPLOADSEARCH looks OK (it
should not have any %emacs_dir% in it, then look at the value of 'tem'
3 lines above the line I marked:

  (gdb) p tem
  (gdb) xtype
  (gdb) xstring

If the result of 'xstring' indeed shows the etc subdirectory of your
Emacs source tree, then perhaps the trouble happens inside
Ffile_exists_p: it should return non-nil in this case.  You can
display its result:

  (gdb) p tem1
  (gdb) xtype
  (gdb) xsymbol