Re: CEDET Merge

[Edward John Steere <edward.steere@gmail.com>]

> Hi Bastian,
>
>> It's great to hear that you have been working on this. I'm also very
>> interested in getting CEDET upstream and CEDET in emacs synchronized
>> again. Please see also this bug report:
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23792
>
> I remember seeing your post a while ago, but had forgotten about it.
> I'll take a look now.
>
>> This also contains a patch for the emacs sources which I've come up
>> with half a year ago, but it's probably incomplete and even wrong in
>> places. But maybe we can compare what we did.
>>
>> Do you have a git repository cloned from CEDET upstream which contains
>> your work somewhere? Or did you start by modifying the built-in CEDET
>> in emacs?
>
> I tried various approaches (with varying degrees of success) before
> going for something rather brute force: I diffed every file in CEDET
> from Emacs core to it's corresponding file in upstream (creating a diff
> file per file-pair) and applied the changes to upstream by hand.
>
> At the moment my changes are living on a private repository.  I'd like
> to do some tidying up with regards to commits before I make them
> available.  I'll get to work on that tomorrow.
>
>> Cheers
>> Bastian
>
> Kind regards,
>
> Edward Steere

Hi All,

Please may I have some advice.  I've been trying to get my change merged
into Emacs core locally, and have had little (read no) success.  These
are the approaches I've tried so far (not verbatim):

 1. git remote add ~/wip/cedet cedet && git merge
 --allow-unrelated-histories etc.
 2. git subtree (not the right model because Cedet mirrors the layout of
    sources in Emacs core)
 3. rm -rf ~/wip/emacs/lisp/cedet && cp ~/wip/cedet/lisp/cedet ~/wip/emacs/cedet

I've opted for option 3 because I realised that I'd already done the
merge in the other direction and now the state of that branch should be
exactly reflected in core.  However, when I try to bootstrap Emacs I get
errors when loading loaddefs.el in lisp/.  It complains about
eieio-defclass-autoload being undefined -- which is fair enough because
that's only autoloaded later, removing the class autoloads which caused
the autoloads to be added produces the same error for
ede-project-autoload.  In the interests of seeing how far I could go
before completely bombing out I removed this autoload as well and I was
confronted with another autoload error, this time in the `jka'
compression library (!?)

What follows is the error with a few lines before it for context (you
can substitute the void variable error with a similar function is void
error for an idea of how the previous two errors looked):

make[3]: Leaving directory '/home/edward/emacs/leim'
LC_ALL=C ./temacs -batch  -l loadup dump
Loading loadup.el (source)...
Using load-path (/home/edward/emacs/lisp)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/backquote...
Loading subr...
Loading version...
Loading widget...
Loading custom...
Loading emacs-lisp/map-ynp...
Loading international/mule...
Loading international/mule-conf...
Loading env...
Loading format...
Loading bindings...
Loading window...
Loading files...
Loading emacs-lisp/macroexp...
Loading cus-face...
Loading faces...
Loading button...
Loading loaddefs.el (source)...
Symbol's value as variable is void: jka-compr-load-suffixes
Makefile:546: recipe for target 'emacs' failed
make[2]: *** [emacs] Error 255
make[2]: Leaving directory '/home/edward/emacs/src'
Makefile:409: recipe for target 'src' failed
make[1]: *** [src] Error 2
make[1]: Leaving directory '/home/edward/emacs'
Makefile:1123: recipe for target 'bootstrap-build' failed
make: *** [bootstrap-build] Error 2

I would greatly appreciate any advice with regards to the best way to
debug errors like this in the build process.

Kind regards,

Edward Steere