在使用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-file是:
"/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中被错误地使用了?
提前谢谢。
答案 0 :(得分:2)
最后我弄明白了原因。问题来自于使用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指向开发人员的计算机路径仍然是开放的。