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")
  apply(update-directory-autoloads "/cygdrive/c/DOCUME~1/nschley/MYDOCU~1/C++/cedet/lisp/cedet")
  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"))

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'



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