autoload failure

autoload failure

[Tak Ota]

When calling a function `grep' first time autoload fails by saying
"Autoloading failed to define function grep".

describe-function says `grep' is a function in `compile' instead of
`grep'.  (indirect-function 'grep) returns (autoload "compile" 828127
t nil)

Manually performing (load-library "grep") fixes.

Why does emacs think grep belongs to compile?

-Tak

Re: autoload failure

[Guy Gascoigne - Piggford]

I was getting that when I ran emacs from the build directory rather than 
after running make install and then running that version.

Guy

Tak Ota wrote:

>When calling a function `grep' first time autoload fails by saying
>"Autoloading failed to define function grep".
>
>describe-function says `grep' is a function in `compile' instead of
>`grep'.  (indirect-function 'grep) returns (autoload "compile" 828127
>t nil)
>
>Manually performing (load-library "grep") fixes.
>
>Why does emacs think grep belongs to compile?
>
>-Tak
>
>
>_______________________________________________
>Emacs-devel mailing list
>Emacs-devel@gnu.org
>http://lists.gnu.org/mailman/listinfo/emacs-devel
>
>
>
>  
>

Re: autoload failure

[Tak Ota]

I am running the installed executable.  On my platform it is actually
runemacs.exe in the installed directory.

-Tak

Wed, 27 Oct 2004 15:44:14 -0700: Guy Gascoigne - Piggford <guy@wyrdrune.com> wrote:

> I was getting that when I ran emacs from the build directory rather than 
> after running make install and then running that version.
> 
> Guy
> 
> Tak Ota wrote:
> 
> >When calling a function `grep' first time autoload fails by saying
> >"Autoloading failed to define function grep".
> >
> >describe-function says `grep' is a function in `compile' instead of
> >`grep'.  (indirect-function 'grep) returns (autoload "compile" 828127
> >t nil)
> >
> >Manually performing (load-library "grep") fixes.
> >
> >Why does emacs think grep belongs to compile?
> >
> >-Tak
> >
> >
> >_______________________________________________
> >Emacs-devel mailing list
> >Emacs-devel@gnu.org
> >http://lists.gnu.org/mailman/listinfo/emacs-devel
> >
> >
> >
> >  
> >

Re: autoload failure

[Richard Stallman]

    >Why does emacs think grep belongs to compile?

Perhaps loaddefs.el needs to be updated.
In the lisp directory, you can do `make autoloads'.

Re: autoload failure

[Tak Ota]

Fri, 29 Oct 2004 00:32:50 -0400: Richard Stallman <rms@gnu.org> wrote:

>     >Why does emacs think grep belongs to compile?
> 
> Perhaps loaddefs.el needs to be updated.
> In the lisp directory, you can do `make autoloads'.

It fails like this:

bash-2.05b$ make autoloads
[Please ignore a syntax error on the next line - it is intentional]
Syntax error: Unterminated quoted string
Directories: calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url
"./../bin/emacs.exe" -batch --no-init-file --no-site-file --multibyte -l autoload \
        --eval '(setq find-file-hooks nil \
                find-file-suppress-same-file-warnings t \
                generated-autoload-file \
                  "/cygdrive/d/pub/emacs/emacs-21.3.50/lisp/loaddefs.el")' \
        -f batch-update-autoloads /cygdrive/d/pub/emacs/emacs-21.3.50/lisp calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url
Cannot open load file: autoload
Signal 127
make: *** [autoloads] Error 255
bash-2.05b$ ls auto*
autoarg.el     autoinsert.el  autorevert.el  


-Tak

Re: autoload failure

[Richard Stallman]

I suspect this is a Windows-specific problem, so I can't help you.
You could try debugging WHY it gets this error:

"./../bin/emacs.exe" -batch --no-init-file --no-site-file --multibyte -l autoload \
        --eval '(setq find-file-hooks nil \
                find-file-suppress-same-file-warnings t \
                generated-autoload-file \
                  "/cygdrive/d/pub/emacs/emacs-21.3.50/lisp/loaddefs.el")' \
        -f batch-update-autoloads /cygdrive/d/pub/emacs/emacs-21.3.50/lisp calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url
Cannot open load file: autoload

Re: autoload failure

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

> I suspect this is a Windows-specific problem, so I can't help you.
> You could try debugging WHY it gets this error:
>
> "./../bin/emacs.exe" -batch --no-init-file --no-site-file --multibyte -l autoload \
>         --eval '(setq find-file-hooks nil \
>                 find-file-suppress-same-file-warnings t \
>                 generated-autoload-file \
>                   "/cygdrive/d/pub/emacs/emacs-21.3.50/lisp/loaddefs.el")' \
>         -f batch-update-autoloads /cygdrive/d/pub/emacs/emacs-21.3.50/lisp calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url
> Cannot open load file: autoload

The path "/cygdrive/d/pub/emacs" is not valid on Windows. It is an
indication that you are using Cygwin make, which the docs explicitly
say to avoid for this reason.

Re: autoload failure

[Stefan]

> The path "/cygdrive/d/pub/emacs" is not valid on Windows.  It is an
> indication that you are using Cygwin make, which the docs explicitly
> say to avoid for this reason.

I really think it would be more constructive to add a file-name-handler
for "/cygdrive/" seeing how common this kind of problem is (it might at
least save us some time replying to such email).

Something like the 100% untested patch below,


        Stefan


--- orig/lisp/w32-fns.el
+++ mod/lisp/w32-fns.el
@@ -34,6 +34,8 @@
 
 ;;; Code:
 
+(eval-when-compile (require 'cl))
+
 ;; Map delete and backspace
 (define-key function-key-map [backspace] "\177")
 (define-key function-key-map [delete] "\C-d")
@@ -257,6 +259,37 @@
 	(setq start (match-end 0))))
     name))
 
+;;; Try to handle the most common misuses of cygwin paths.
+(defconst w32-cygdrive-name-regexp "\\`/cygdrive/\\(.\\)/")
+
+(defun w32-cygdrive-run-real-handler (op args)
+  (let ((inhibit-file-name-handlers
+	 (cons 'w32-cygdrive-name-handler
+	       (if (eq inhibit-file-name-operation op)
+		   inhibit-file-name-handlers)))
+	(inhibit-file-name-operation op))
+    (apply op args))))
+
+(defun w32-cygdrive-name-handler (op &rest args)
+  (case op
+    (expand-file-name
+     (let ((file (car args)))
+       (cond
+	((string-match w32-cygdrive-name-regexp file)
+	 (w32-cygdrive-run-real-handler
+	  op (cons (replace-match "\\1:/" t nil file) args)))
+	((string-match w32-cygdrive-name-regexp (car args))
+	 (w32-cygdrive-run-real-handler
+	  op (list* file (replace-match "\\1:/" t nil (car args))
+		    (cdr args))))
+	;; This is actually an error (we should never get here),
+	;; but let's be defensive.
+	(t (w32-cygdrive-run-real-handler op args)))))
+    (t (w32-cygdrive-run-real-handler op args))))
+
+(push (cons w32-cygdrive-name-regexp 'w32-cygdrive-name-handler)
+      file-name-handler-alist)
+
 ;;; Fix interface to (X-specific) mouse.el
 (defun x-set-selection (type data)
   (or type (setq type 'PRIMARY))

Re: autoload failure

[Jason Rumney]

Stefan <monnier@iro.umontreal.ca> writes:

>> The path "/cygdrive/d/pub/emacs" is not valid on Windows.  It is an
>> indication that you are using Cygwin make, which the docs explicitly
>> say to avoid for this reason.
>
> I really think it would be more constructive to add a file-name-handler
> for "/cygdrive/" seeing how common this kind of problem is (it might at
> least save us some time replying to such email).

Its there already I beleive:

2001-10-29  Sam Steingold  <sds@gnu.org>

	* w32-fns.el (convert-standard-filename): Handle cygwin-specific
	"/cygdrive/LETTER/" pathnames.


The problem is that this is happening during bootstrap, when
w32-fns.el is not loaded yet.

Re: autoload failure

[Lennart Borgman]

----- Original Message ----- 
From: "Jason Rumney" <jasonr@gnu.org>
To: "Stefan" <monnier@iro.umontreal.ca>
Cc: <guy@wyrdrune.com>; "Tak Ota" <Takaaki.Ota@am.sony.com>;
<emacs-devel@gnu.org>
Sent: Saturday, October 30, 2004 8:55 PM
Subject: Re: autoload failure


: Stefan <monnier@iro.umontreal.ca> writes:
:
: >> The path "/cygdrive/d/pub/emacs" is not valid on Windows.  It is an
: >> indication that you are using Cygwin make, which the docs explicitly
: >> say to avoid for this reason.
: >
: > I really think it would be more constructive to add a file-name-handler
: > for "/cygdrive/" seeing how common this kind of problem is (it might at
: > least save us some time replying to such email).
:
: Its there already I beleive:
:
: 2001-10-29  Sam Steingold  <sds@gnu.org>
:
: * w32-fns.el (convert-standard-filename): Handle cygwin-specific
: "/cygdrive/LETTER/" pathnames.
:
:
: The problem is that this is happening during bootstrap, when
: w32-fns.el is not loaded yet.

Stefans idea sounded like a very good one to me
- and it probably is since it is already used ;-)

I do not know the limitations here since I have no clear picture of the
bootstrap process yet, but could not w32-fns.el be explicitly loaded on w32?
What we are talking about is maybe only one call in lisp\makefile:

autoloads: loaddefs.el doit
 @echo Directories: $(WINS)
 $(emacs) -l autoload \
  --eval $(ARGQUOTE)(setq find-file-hooks nil \
   find-file-suppress-same-file-warnings t \
   generated-autoload-file \
     $(DQUOTE)$(lisp)/loaddefs.el$(DQUOTE))$(ARGQUOTE) \
  -f batch-update-autoloads $(lisp) $(WINS)

I think that fixing this would make people much less confused when they are
trying to build on w32. And this gives more time to do useful work.

I believe that with a small change in convert-standard-filename we could
also make it possible to use MSYS to build Emacs. (Just look for
"/\\(a-zA-Z\\)/".)

A message from Earnie Boyd (MSYS maintainer?) convinced me that it might be
worth the time to look a bit deeper into the problems with using MSYS so I
did this. I again now believe that MSYS also could be an easy to use build
environment for Emacs. I will come back on this later.

- Lennart

Re: autoload failure

[Jason Rumney]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> I do not know the limitations here since I have no clear picture of the
> bootstrap process yet, but could not w32-fns.el be explicitly loaded on w32?
> What we are talking about is maybe only one call in lisp\makefile:

It is quite early in the bootstrap process and I don't know how many
dependancies w32-fns.el will pull in, and whether Emacs is ready to
load those dependencies before the autoloads file is generated.

You are welcome to try though.

> I believe that with a small change in convert-standard-filename we could
> also make it possible to use MSYS to build Emacs. (Just look for
> "/\\(a-zA-Z\\)/".)

Does MSYS fail at the same point? (It fails right at the start for me,
so I think there is more work than just that).

Re: autoload failure

[Lennart Borgman]

----- Original Message ----- 
From: "Jason Rumney" <jasonr@gnu.org>

: It is quite early in the bootstrap process and I don't know how many
: dependancies w32-fns.el will pull in, and whether Emacs is ready to
: load those dependencies before the autoloads file is generated.

In what ways could this disturb the building process? Could it be disturbed
even if loading w32-fns.el succeeds?

: You are welcome to try though.

I will try. But it takes me some time on this computer ;-(

: > I believe that with a small change in convert-standard-filename we could
: > also make it possible to use MSYS to build Emacs. (Just look for
: > "/\\(a-zA-Z\\)/".)
:
: Does MSYS fail at the same point? (It fails right at the start for me,
: so I think there is more work than just that).

Yes, it fails at the same point I believe. It does not fail exactly in the
same way, but still at the same point. Actually MSYS avoids half of the
problem I believe, but it does not help. (The filename that is a single
argument is given to Emacs in w32 format, but the one inside eval is not.
There is no way for MSYS to do that - unless it understands elisp ;-)

It however hangs right at the beginning if not the GNU make that comes with
MSYS is used. The problem is that make calls "cmd echo" in that case. I do
not know how MSYS makes avoids this, but it does not hang. (Maybe it sends
"cmd /c echo" which would be correct? Documentation for MSYS is not very
extensive.)

- Lennart

Re: autoload failure

[Stefan]

>>> The path "/cygdrive/d/pub/emacs" is not valid on Windows.  It is an
>>> indication that you are using Cygwin make, which the docs explicitly
>>> say to avoid for this reason.
>> 
>> I really think it would be more constructive to add a file-name-handler
>> for "/cygdrive/" seeing how common this kind of problem is (it might at
>> least save us some time replying to such email).

> Its there already I beleive:

> 2001-10-29  Sam Steingold  <sds@gnu.org>

> 	* w32-fns.el (convert-standard-filename): Handle cygwin-specific
> 	"/cygdrive/LETTER/" pathnames.

But is `convert-standard-filename' used often enough?
A quick grep gives me the impression it doesn't cut it: most filenames that
come from arguments are presumed to be already valid and aren't passed
through `convert-standard-filename'.  Only hardcoded filenames are passed
through `convert-standard-filename', it seems.

> The problem is that this is happening during bootstrap, when
> w32-fns.el is not loaded yet.

Are you sure?  The problem is when re-building loaddefs.el which happens
after the first dump (i.e. the special bootstrap-dump).  Are you saying that
the bootstrap-dump does not load w32-fns.el?  How could that be?  loadup.el
seems to load it whether it's the normal dump or the boostrap dump.


        Stefan

Re: autoload failure

[Eli Zaretskii]

> From: Stefan <monnier@iro.umontreal.ca>
> Date: Sat, 30 Oct 2004 20:25:39 -0400
> Cc: guy@wyrdrune.com, Tak Ota <Takaaki.Ota@am.sony.com>, emacs-devel@gnu.org
> 
> Only hardcoded filenames are passed through
> `convert-standard-filename', it seems.

Yes, because that's what `convert-standard-filename' is all about.

Re: autoload failure

[Stefan]

>>>>> "Stefan" == Stefan  <monnier@iro.umontreal.ca> writes:
>> The path "/cygdrive/d/pub/emacs" is not valid on Windows.  It is an
>> indication that you are using Cygwin make, which the docs explicitly
>> say to avoid for this reason.
> I really think it would be more constructive to add a file-name-handler
> for "/cygdrive/" seeing how common this kind of problem is (it might at
> least save us some time replying to such email).
> Something like the 100% untested patch below,

Has someone tried my patch?


        Stefan

Re: autoload failure

[Lennart Borgman]

----- Original Message ----- 
From: "Stefan" <monnier@iro.umontreal.ca>

: >>>>> "Stefan" == Stefan  <monnier@iro.umontreal.ca> writes:
: >> The path "/cygdrive/d/pub/emacs" is not valid on Windows.  It is an
: >> indication that you are using Cygwin make, which the docs explicitly
: >> say to avoid for this reason.
: > I really think it would be more constructive to add a file-name-handler
: > for "/cygdrive/" seeing how common this kind of problem is (it might at
: > least save us some time replying to such email).
: > Something like the 100% untested patch below,
:
: Has someone tried my patch?

After some small corrections it worked for me with 21.3. Put the code below
in a buffer and do eval-buffer. You should get a buffer visiting
c:\hello.txt. The file name I used in the bottom is an MSYS style file name
(if I remember right at the moment), but the file name pattern should work
for Cygwin style file names too.

Maybe should the the object be renamed to reflect that the code handles MSYS
too?

- Lennart


;;; Try to handle the most common misuses of cygwin paths.
;;(defconst w32-cygdrive-name-regexp "\\`/cygdrive/\\(.\\)/")
(defconst w32-cygdrive-name-regexp "^\\(?:/cygwin\\)?/\\(.\\)/")
;;(defconst w32-cygdrive-name-regexp "^/\\(.\\)/")

(defun w32-cygdrive-run-real-handler (op args)
  (let ((inhibit-file-name-handlers
  (cons 'w32-cygdrive-name-handler
        (if (eq inhibit-file-name-operation op)
     inhibit-file-name-handlers)))
 (inhibit-file-name-operation op))
    (apply op args)))

(defun w32-cygdrive-name-handler (op &rest args)
(message "handler %s %s" op args)
(case op
  (expand-file-name
   (let ((file (car args))
  (args (cdr args)))
     (cond
      ((= 0 (string-match w32-cygdrive-name-regexp file))
       (w32-cygdrive-run-real-handler
 op (cons (replace-match "\\1:/" t nil file) args)))
      ((= 0 (string-match w32-cygdrive-name-regexp (car args)))
       (w32-cygdrive-run-real-handler
 op (list* file (replace-match "\\1:/" t nil (car args))
    (cdr args))))
      ;; This is actually an error (we should never get here),
      ;; but let's be defensive.
      (t (w32-cygdrive-run-real-handler op args)))))
  (t (w32-cygdrive-run-real-handler op args))))

(push (cons w32-cygdrive-name-regexp 'w32-cygdrive-name-handler)
file-name-handler-alist)
(find-file "/c/hello.txt/")

Re: autoload failure

[Tak Ota]

Sat, 30 Oct 2004 17:39:36 +0100: Jason Rumney <jasonr@gnu.org> wrote:

> Richard Stallman <rms@gnu.org> writes:
> 
> > I suspect this is a Windows-specific problem, so I can't help you.
> > You could try debugging WHY it gets this error:
> >
> > "./../bin/emacs.exe" -batch --no-init-file --no-site-file --multibyte -l autoload \
> >         --eval '(setq find-file-hooks nil \
> >                 find-file-suppress-same-file-warnings t \
> >                 generated-autoload-file \
> >                   "/cygdrive/d/pub/emacs/emacs-21.3.50/lisp/loaddefs.el")' \
> >         -f batch-update-autoloads /cygdrive/d/pub/emacs/emacs-21.3.50/lisp calc calendar emacs-lisp emulation eshell gnus international language mail mh-e net obsolete play progmodes term textmodes toolbar url
> > Cannot open load file: autoload
> 
> The path "/cygdrive/d/pub/emacs" is not valid on Windows. It is an
> indication that you are using Cygwin make, which the docs explicitly
> say to avoid for this reason.

You are right.  I am using cygwin make.  The reason is recent
suggestion by Guy Gascoigne.  Until recently I used to use mingw to
build emacs with MSYS tools.  It builds emacs but I encountered a
problem with "grep" package autoload.  Guy's suggestion is to use
cygwin environment since MSYS sh has some known problem.  That
automatically let me opt to use cygwin make.

What is the right way to build emacs with mingw now?

-Tak

Re: autoload failure

[Jason Rumney]

Tak Ota wrote:

>You are right.  I am using cygwin make.  The reason is recent
>suggestion by Guy Gascoigne.  Until recently I used to use mingw to
>build emacs with MSYS tools.  It builds emacs but I encountered a
>problem with "grep" package autoload.
>
I think that problem can be overcome by bootstrapping again, maybe even 
just a "make autoloads" in the lisp directory. I had the problem myself 
a while back.