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!


2012/11/13 David Engster <deng@randomsample.de>
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.