Emacs elisp expand-file-name behaviour on windows

Question

I encountered strange behaviour of expand-file-name function on windows during installation of last cedet using el-get. The issue is related to generation of autoloads.

The autoload.el on last emacs 24.1.50 contains the following function:

(defun autoload-generated-file ()
  (expand-file-name generated-autoload-file
                ;; File-local settings of generated-autoload-file should
                ;; be interpreted relative to the file's location,
                ;; of course.
                (if (not (local-variable-p 'generated-autoload-file))
                    (expand-file-name "lisp" source-directory))))

In my case generated-autoload-file is:

"/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/srecode/loaddefs.el"

as I have $HOME$ environment variable pointed to C:/home/ngulyamov. In this case above function returns:

"d:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/srecode/loaddefs.el"

due to source-directory contains:

"d:/devel/emacs/emacs-bzr/trunk_jenkins/".

As you can see it changes drive letter from C: to D:. At the same time on emacs 23.3 this function returns semi-correct value as source-directory contains value:

"c:/Users/Sean/Downloads/emacs-23.3/".

According to expand-file-name function description:

(expand-file-name NAME &optional DEFAULT-DIRECTORY)

Convert filename NAME to absolute, and canonicalize it. Second arg DEFAULT-DIRECTORY is directory to start with if NAME is relative (does not start with slash or tilde); if DEFAULT-DIRECTORY is nil or missing, the current buffer's value of `default-directory' is used.

The paths on Windows never start from slash or tilde.

Now my questions: 1. Does expand-file-name function behaviour correct on Windows? 2. Why source-directory contains value of developers paths?

Could we consider expand-file-name as buggy on windows? Or it is just wrongly used in autoload.el?

Thank you in advance.

@phils Hi, no, it doesn't start with C: but everything works pretty good: C:\home\ngulyamov>set HOME HOME=C:\home\ngulyamov C:\home\ngulyamov>env | grep HOME HOME=/home/ngulyamov C:\home\ngulyamov>ls /home/ngulyamov ... file list .... — Nodir Gulyamov
This is obviously some kind of Windows shell I've never seen before, if it uses forward slashes, and accepts ls as a command. (Is that Windows 7?) — phils
@phils No, it is just a normal cmd.exe, I have cygwin installed and its bin directory in my PATH. And it is Windows XP. — Nodir Gulyamov
Is Emacs configured to integrate with Cygwin? If so, that could be a relevant point. — phils

Nodir Gulyamov Nodir Gulyamov · Accepted Answer · 2012-05-14T13:05:55

Finally I figured out the reason. The issue is coming from Makefile of cedet which uses $(abspath) functionality of make 3.8. The cygwin version of make in this case returns UNIX way of path, i.e. /home/ngulyamov/... which then replaces by source-directory root in autoload by d:/home/ngulyamov/.... The GnuWin32 version of make works correctly but by strange reason I have the following issue:

C:\home\ngulyamov\.emacs.d\el-get\cedet>\gnuwin32\bin\make all
Removing loaddefs.el files from subprojects.
Generating autoloads.
make[1]: Entering directory `C:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet'
    > autoloads
Wrote C:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/loaddefs.el
Loading vc-bzr...
Generating autoloads for C:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/cedet-android.el...
Memory exhausted--use C-x s then exit and restart Emacs
make[1]: *** [autoloads] Error 127

So dirty fix is specifying source-directory in autoload.el itself like:

(setq-default source-directory "C:/home/ngulyamov/.emacs.d/")

Anyway, why source-directory is pointing to developer's computer path is remaining open.

Emacs elisp expand-file-name behaviour on windows

1 Answers