[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Building Emacs from a new MinGW environment
From: |
Eli Zaretskii |
Subject: |
Re: Building Emacs from a new MinGW environment |
Date: |
Sat, 14 Sep 2013 17:50:40 +0300 |
> 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
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/13
- Re: Building Emacs from a new MinGW environment, Eli Zaretskii, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/14
- Re: Building Emacs from a new MinGW environment,
Eli Zaretskii <=
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Eli Zaretskii, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Eli Zaretskii, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Eli Zaretskii, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Eli Zaretskii, 2013/09/15
- Re: Building Emacs from a new MinGW environment, Eli Zaretskii, 2013/09/15