CEDET

Nate Schley writes:
> Last week, I updated my local image of the bzr trunk & now "make clean" hangs
> at "Generating autoloads:"  no errors, no warnings, no complaints of any kind. 
> Just a stop of all apparent processing (breakable via CTRL-C.)  Re-updating
> does nothing to clear the problem.
>
> Anybody have any thoughts?

First, please make sure using 'bzr revno' you are really using the
latest revisiopn (currently 8398). Then do

bzr revert
bzr clean-tree
bzr clean-tree --ignore

to get a clean checkout an try again, simply using 'make'.

If it still fails, please revert to 8392 using

bzr revert -r 8392

and try again. Does it work then?

-David

David,

Thanks for the advice!
I was at 8398 and had nothing checked out, but tried the first step
anyway:  no joy.
I reverted to 8392 and did not get the "hang" problem;
I got a new and weird problem!
>> (file-error "Opening output file" "permission denied"
"d:/cygdrive/c/DOCUME~1/...)

This tells me somebody's been meddling with how paths are employed!
The script runs with %CD% / $PWD =
/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/cedet/lisp/cedet
and the "make clean" portion runs fine with this.

The autoloads phase wants to put %CD% / $PWD on the Windows-syntaxed D:
drive (is "syntaxed" a word?)

I guess I could fix the issue locally, but I also guess it' may be a
problem that ought to be fixed properly in the bzr code.  Whoever put the
d:\ thing there was certainly out to address a different issue, and missed
this aspect.

More build output follows.  As background, cygwin environment has
cygwin-specific directories that show as /usr, /etc, etc.
The /cygdrive directory collects all the drives from the windows
environment.   this issue occurs for all autoload directories.

Generating autoloads.
make[1]: Entering directory
`/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/cedet/lisp/cedet'
/cygdrive/c/PROGRA~1/gnu/emacs-24.2/bin/emacs -batch --no-site-file --eval
'(setq debug-on-error t)' -l "../../cedet-remove-builtin.el" -L . --eval
'(progn (require (quote cedet-compat)) (require (quote mode-local)))' -L
../eieio/ -L ./ -L ./ --eval '(progn  (setq generated-autoload-file
"/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/cedet/lisp/cedet/loaddefs.el"))'
-f batch-update-autoloads
/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/cedet/lisp/cedet

Debugger entered--Lisp error: (file-error "Opening output file" "permission
denied"
"d:/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/cedet/lisp/cedet/loaddefs.el")
  write-region(";;; loaddefs.el --- automatically extracted
autoloads\n;;\n;;; Code:\n\n\f\n(provide 'loaddefs)\n;; Local
Variables:\n;; version-control: never\n;; no-byte-compile: t\n;;
no-update-autoloads: t\n;; coding: utf-8\n;; End:\n;;; loaddefs.el ends
here\n" nil
"d:/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/cedet/lisp/cedet/loaddefs.el")

autoload-ensure-default-file("d:/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/cedet/lisp/cedet/loaddefs.el")
  autoload-find-generated-file()

update-directory-autoloads("/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/cedet/lisp/cedet")
  apply(update-directory-autoloads
"/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/cedet/lisp/cedet")
  batch-update-autoloads()
  command-line-1(("--eval" "(setq debug-on-error t)" "-l"
"../../cedet-remove-builtin.el" "-L" "." "--eval" "(progn (require (quote
cedet-compat)) (require (quote mode-local)))" "-L" "../eieio/" "-L" "./"
"-L" "./" "--eval" "(progn  (setq generated-autoload-file
\"/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/cedet/lisp/cedet/loaddefs.el\"))"
"-f" "batch-update-autoloads"
"/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/cedet/lisp/cedet"))
  command-line()
  normal-top-level()

Makefile:34: recipe for target `autoloads' failed
make[1]: *** [autoloads] Error 127
make[1]: Leaving directory
`/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/cedet/lisp/cedet'

Thanks!

Nate

2012/11/12 David Engster <deng@...>

> Nate Schley writes:
> > Last week, I updated my local image of the bzr trunk & now "make clean"
> hangs
> > at "Generating autoloads:"  no errors, no warnings, no complaints of any
> kind.
> > Just a stop of all apparent processing (breakable via CTRL-C.)
> Re-updating
> > does nothing to clear the problem.
> >
> > Anybody have any thoughts?
>
> First, please make sure using 'bzr revno' you are really using the
> latest revisiopn (currently 8398). Then do
>
> bzr revert
> bzr clean-tree
> bzr clean-tree --ignore
>
> to get a clean checkout an try again, simply using 'make'.
>
> If it still fails, please revert to 8392 using
>
> bzr revert -r 8392
>
> and try again. Does it work then?
>
> -David
>
>


-- 
Thanks,

Nate

Nate Schley writes:
> I reverted to 8392 and did not get the "hang" problem;
> I got a new and weird problem!

This is the same issue. The latest checkout hangs because since
rev. 8393 the build script repeatedly tries to remove the built-in CEDET
version, which it cannot do because of path conversion (see below). I
guess I should put some upper limit in there so that it gives up
eventually with a proper error message.

>   autoload-ensure-default-file("d:/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/
> cedet/lisp/cedet/loaddefs.el")
>   autoload-find-generated-file()
>   update-directory-autoloads("/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/cedet/
> lisp/cedet")

There are no CEDET functions involved here; this is MSYS path conversion
kicking in. Don't use a native MSYS Emacs with Cygwin. Either use Emacs
from Cygwin or the cedet-build.el script for building latest CEDET.

-David

David,

By MSYS, I guess you're referring to the libraries GNU picks up when they
build the "NT" version of emacs - true?

I'm suspicious....  Blaming MSYS would be easier to swallow if
- I had *not* been building cedet this way for years on many versions of
emacs & cedet.
- I had *not* built cedet off bzr's trunk at least 3 times prior with the
very same version of emacs I'm using today.
- I had anything *on* a d: drive

Apparently something has changed at least once recently with how cedet is
config'd to generate and how it does generate autoloads between versions
8392 and 8398.  Why else would the builds for the 2 versions fail
differently.

I'm wondering if there could be something in a recent cygwin update....  I
can't figure who (what) would want to associate the d: drive....

Thanks for the advice!

Nate

2012/11/13 David Engster <deng@...>

> Nate Schley writes:
> > I reverted to 8392 and did not get the "hang" problem;
> > I got a new and weird problem!
>
> This is the same issue. The latest checkout hangs because since
> rev. 8393 the build script repeatedly tries to remove the built-in CEDET
> version, which it cannot do because of path conversion (see below). I
> guess I should put some upper limit in there so that it gives up
> eventually with a proper error message.
>
> >
> autoload-ensure-default-file("d:/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/
> > cedet/lisp/cedet/loaddefs.el")
> >   autoload-find-generated-file()
> >
> update-directory-autoloads("/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/cedet/
> > lisp/cedet")
>
> There are no CEDET functions involved here; this is MSYS path conversion
> kicking in. Don't use a native MSYS Emacs with Cygwin. Either use Emacs
> from Cygwin or the cedet-build.el script for building latest CEDET.
>
> -David
>



-- 
Thanks,

Nate

Nate Schley writes:
> By MSYS, I guess you're referring to the libraries GNU picks up when they build
> the "NT" version of emacs - true?

Kind of. I'm not really fluent with this stuff. It is used to build the
native Emacs Windows port, AFAIK.

> I'm suspicious....  Blaming MSYS would be easier to swallow if
> - I had *not* been building cedet this way for years on many versions of emacs
> & cedet.
> - I had *not* built cedet off bzr's trunk at least 3 times prior with the very
> same version of emacs I'm using today.
> - I had anything *on* a d: drive

I've no idea how that 'd:' gets there, but it has happened before. See
the thread "Latest CEDET on BZR does not compile with emacs 24.1" which
took place on this list recently. I guess it has to do with the native
Emacs not understanding the Cygwin mounts. I think the Cygwin FAQ has
something about that.

> Apparently something has changed at least once recently with how cedet is
> config'd to generate and how it does generate autoloads between versions 8392
> and 8398.  Why else would the builds for the 2 versions fail differently.

I already gave my best guess:

>>     This is the same issue. The latest checkout hangs because since
>>     rev. 8393 the build script repeatedly tries to remove the built-in CEDET
>>     version, which it cannot do because of path conversion (see below).

I'm building CEDET regularly under Cygwin using Cygwin-Emacs, and it
works without problems; that's all I can say. You can then use the
compiled CEDET with the native Emacs port if you want to.

-David

David - I understand everything.  (I mean, everything you say, not like,
everything in the world!)  and I appreciate your feedback.  I guess I break
down and pick up cygwin's emacs just to build cedet.  I'll also check the
refs you point out.

Thanks again!

2012/11/13 David Engster <deng@...>

> Nate Schley writes:
> > By MSYS, I guess you're referring to the libraries GNU picks up when
> they build
> > the "NT" version of emacs - true?
>
> Kind of. I'm not really fluent with this stuff. It is used to build the
> native Emacs Windows port, AFAIK.
>
> > I'm suspicious....  Blaming MSYS would be easier to swallow if
> > - I had *not* been building cedet this way for years on many versions of
> emacs
> > & cedet.
> > - I had *not* built cedet off bzr's trunk at least 3 times prior with
> the very
> > same version of emacs I'm using today.
> > - I had anything *on* a d: drive
>
> I've no idea how that 'd:' gets there, but it has happened before. See
> the thread "Latest CEDET on BZR does not compile with emacs 24.1" which
> took place on this list recently. I guess it has to do with the native
> Emacs not understanding the Cygwin mounts. I think the Cygwin FAQ has
> something about that.
>
> > Apparently something has changed at least once recently with how cedet is
> > config'd to generate and how it does generate autoloads between versions
> 8392
> > and 8398.  Why else would the builds for the 2 versions fail differently.
>
> I already gave my best guess:
>
> >>     This is the same issue. The latest checkout hangs because since
> >>     rev. 8393 the build script repeatedly tries to remove the built-in
> CEDET
> >>     version, which it cannot do because of path conversion (see below).
>
> I'm building CEDET regularly under Cygwin using Cygwin-Emacs, and it
> works without problems; that's all I can say. You can then use the
> compiled CEDET with the native Emacs port if you want to.
>
> -David
>



-- 
Thanks,

Nate