在使用el-get安装最后一个cedet时,我在
windows上遇到了expand-file-name函数的奇怪行为.该问题与自动加载的生成有关.
最后一个emacs 24.1.50上的autoload.el包含以下功能：
(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))))
在我的例子中,generated-autoload文件是：
"/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/srecode/loaddefs.el"
因为我有$HOME $环境变量指向C：/ home / ngulyamov.在这种情况下,上面的函数返回
"d:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/srecode/loaddefs.el"
由于源目录包含：
"d:/devel/emacs/emacs-bzr/trunk_jenkins/".
正如您所看到的,它将驱动器号从C：更改为D：.
同时在emacs 23.3上,此函数返回半正确值,因为source-directory包含值：
"c:/Users/Sean/Downloads/emacs-23.3/".
根据expand-file-name函数说明：
(expand-file-name NAME& optional DEFAULT-DIRECTORY)
将文件名NAME转换为绝对值,并将其规范化.
如果NAME是相对的,则第二个arg DEFAULT-DIRECTORY是要开始的目录
(不以斜线或波浪线开头);如果DEFAULT-DIRECTORY为零或缺失,
使用当前缓冲区的“default-directory”值.
Windows上的路径永远不会从斜线或波浪线开始.
现在我的问题：
1.在Windows上,expand-file-name函数行为是否正确？
2.为什么source-directory包含开发人员路径的值？
我们可以将expand-file-name视为Windows上的bug吗？或者它在autoload.el中被错误地使用了？
先感谢您.
解决方法
最后我弄明白了原因.问题来自于使用make 3.8的$(abspath)功能的cedet的Makefile.在这种情况下,make的cygwin版本返回UNIX路径,即/ home / ngulyamov / …然后由自动加载中的源目录根替换为d：/ home / ngulyamov / …. GnuWin32版本的make工作正常,但奇怪的是我有以下问题：
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
所以脏修复是在autoload.el本身中指定source-directory,如：
(setq-default source-directory "C:/home/ngulyamov/.emacs.d/")
无论如何,为什么source-directory指向开发人员的计算机路径仍然是开放的.
