Content-Type: multipart/alternative; boundary="_c15512eb-82c5-4ee2-bece-9e0ba5bc6156_" --_c15512eb-82c5-4ee2-bece-9e0ba5bc6156_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear David=2C I am compiling under MSWindows XP with MSYS. In order to compile I launch bash script vbl_update.sh hereinattached under= a bash interactive shell opened in EMACS. I have redirected the output of = make inside vbl_update.sh and this produces the file compile.log also attac= hed. I have also saved the whole shell buffer to shell_output.log. I have noticed something quite abnormal which I did not noticed the first t= ime=2C in shell_output.log I can read=20 Debugger entered--Lisp error: (file-error "Opening output file" "no such fi= le or directory" "d:/c/Programme/GNU/installation/cedet-install/cedet/lisp/= cedet/loaddefs.el") The path is actually c:/Programme/GNU/installation/cedet-install/cedet/lis= p/cedet/loaddefs.el=20 Replacing c: by /c is just an MSYS trick. when you use the pwd command in MSYS you get some path=2C real MS Windows p= ath can be derived from those paths by two rules: - /c or /d and suchlikes stand for c: or d: and so on - file /etc/fstab=2C maybe in emacs-lisp this can be found as (concat (gete= nv "MSYS") "etc\\fstab")=2C contains also some mounting information. VBR=2C Vincent. > From: deng@randomsample.de > To: vincent.b.1@hotmail.fr > CC: cedet-semantic@lists.sourceforge.net > Subject: Re: [cedet-semantic] Latest CEDET on BZR does not compile with e= macs 24.1 > Date: Thu=2C 27 Sep 2012 08:13:54 +0200 >=20 > Vincent Bela=EFche writes: > > In my first email (that of September the 7th) there were attachment to = be more > > specific about what happens. >=20 > Oh. I'm sorry=2C I should have looked again at your first mail. >=20 > > in the compile log=2C the first error met was: > > > > In toplevel form: > > cedet-android.el:35:13:Error: Cannot open load file: ede/loaddefs > > make[2]: *** [cedet-android.elc] Error 1 >=20 > I see you're compiling on Windows. Are you using cygwin or something > else? Which version of 'make' are you using? The buildbot does test > compilation with cygwin=2C and it works there. It seems there's some > problem with properly setting up the load-path. Unfortunately=2C your > backtrace is rather difficult to read because the line breaks are all > messed up. If you're working on a shell supporting redirection=2C maybe > you could redirect the output to a file and attach it. >=20 > -David = --_c15512eb-82c5-4ee2-bece-9e0ba5bc6156_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear David=2C


I am compiling under MSWindows XP with MSYS.

In order to compile I launch bash script vbl_update.sh hereinattached= under a bash interactive shell opened in EMACS. I have redirected the outp= ut of make inside vbl_update.sh and this produces the file compile.log also= attached. I have also saved the whole shell buffer to shell_output.log.

I have noticed something quite abnormal which I did not noticed th= e first time=2C in shell_output.log I can read =3B


Debugger = entered--Lisp error: (file-error "Opening output file" "no such file or dir= ectory" "d:/c/Programme/GNU/installation/cedet-install/cedet/lisp/cedet/loa= ddefs.el")


The path is actually =3B c:/Programme/GNU/install= ation/cedet-install/cedet/lisp/cedet/loaddefs.el =3B


Replaci= ng c: by /c is just an MSYS trick.


when you use the pwd command = in MSYS you get some path=2C real MS Windows path can be derived from those= paths by two rules:
- /c or /d and suchlikes stand for c: or d: and so = on
- file /etc/fstab=2C maybe in emacs-lisp this can be found as (concat= (getenv "MSYS") "etc\\fstab")=2C contains also some mounting information.<= BR>

VBR=2C
 =3B  =3BVincent.

>=3B From: den= g@randomsample.de
>=3B To: vincent.b.1@hotmail.fr
>=3B CC: cedet-= semantic@lists.sourceforge.net
>=3B Subject: Re: [cedet-semantic] Late= st CEDET on BZR does not compile with emacs 24.1
>=3B Date: Thu=2C 27 = Sep 2012 08:13:54 +0200
>=3B
>=3B Vincent Bela=EFche writes:
= >=3B >=3B In my first email (that of September the 7th) there were atta= chment to be more
>=3B >=3B specific about what happens.
>=3B <= br>>=3B Oh. I'm sorry=2C I should have looked again at your first mail.>=3B
>=3B >=3B in the compile log=2C the first error met was:>=3B >=3B
>=3B >=3B In toplevel form:
>=3B >=3B cedet-a= ndroid.el:35:13:Error: Cannot open load file: ede/loaddefs
>=3B >=3B= make[2]: *** [cedet-android.elc] Error 1
>=3B
>=3B I see you're= compiling on Windows. Are you using cygwin or something
>=3B else? Wh= ich version of 'make' are you using? The buildbot does test
>=3B compi= lation with cygwin=2C and it works there. It seems there's some
>=3B p= roblem with properly setting up the load-path. Unfortunately=2C your
>= =3B backtrace is rather difficult to read because the line breaks are all>=3B messed up. If you're working on a shell supporting redirection=2C = maybe
>=3B you could redirect the output to a file and attach it.
&= gt=3B
>=3B -David
= --_c15512eb-82c5-4ee2-bece-9e0ba5bc6156_--