2012-05-10 15 views
5

Encontré un comportamiento extraño de la función expand-file-name en Windows durante la instalación de la última versión de cedet usando el-get. El problema está relacionado con la generación de autocarga.Comportamiento de Emacs elisp expand-file-name en Windows

El autoload.el en emacs últimos 24/01/50 contiene la siguiente función:

(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)))) 

En mi caso-autocarga-archivo generado es:

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

como tengo $ entorno $ HOME variable apuntada a C:/home/ngulyamov. En este caso por encima de función devuelve:

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

debido a la fuente-directorio contiene:

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

Como se puede ver que cambia la letra de unidad de C: a D :. Al mismo tiempo, en Emacs 23.3 esta función devuelve semi-correcta valor como fuente-directorio contiene el valor:

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

Según ampliar-archivo-nombre de la función Descripción:

(expand-archivo- nombre NOMBRE & DEFAULT-DIRECTORY opcional)

Convierta el nombre de archivo NAME en absoluto y canonicalícelo. Segundo arg DEFAULT-DIRECTORY es el directorio para comenzar si NAME es relativo (no comienza con barra o tilde); si DEFAULT-DIRECTORY es nulo o falta, se usa el valor actual del buffer de `default-directory '.

Las rutas en Windows nunca comienzan desde barras o tilde.

Ahora mis preguntas: 1. ¿El comportamiento de la función expand-file-name es correcto en Windows? 2. ¿Por qué source-directory contiene el valor de las rutas de los desarrolladores?

¿Podríamos considerar expand-file-name como buggy en Windows? ¿O simplemente se usa erróneamente en autoload.el?

Gracias de antemano.

+0

¿Se suponía que el primer camino comenzaba con 'c:'? – phils

+0

@phils Hola, no, no se inicia con C: pero todo funciona bastante bien: 'C: \ home \ ngulyamov> set INICIO HOME = C: \ home \ ngulyamov C: \ home \ ngulyamov> env | grep INICIO HOME =/home/ngulyamov C: \ home \ ngulyamov ls/home/ngulyamov ... lista de archivos> .... ' –

+0

Obviamente, esto es una especie de shell de Windows que nunca he visto antes, si usa barras diagonales, y acepta 'ls' como un comando. (¿Es ese Windows 7?) – phils

Respuesta

2

Finalmente descubrí el motivo. El problema proviene de Makefile of cedet que usa la funcionalidad $ (abspath) de make 3.8. La versión cygwin de make en este caso devuelve el modo de ruta UNIX, es decir,/home/ngulyamov/... que luego reemplaza por source-directory root en autocarga por d:/home/ngulyamov/.... La versión GnuWin32 de make funciona correctamente, pero por extraña razón por la que tienen la siguiente cuestión:

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 

solución sucia Así es especificar la fuente-directorio en el autoload.el sí mismo como:

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

de todos modos, ¿por qué fuente-directorio está apuntando a la ruta de la computadora del desarrollador permanece abierta.

Cuestiones relacionadas