unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#18359: Macro expansion failure [MSYS2-MinGW64]
@ 2014-08-29 20:49 Angelo Graziosi
  2014-08-30  7:21 ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: Angelo Graziosi @ 2014-08-29 20:49 UTC (permalink / raw)
  To: 18359

With recent trunk, building the 64 bit build of Emacs on Windows using 
MSYS2/MinGW64 tools, produces many "macro-expansion failure" messages:

[...]
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
Eager macro-expansion failure: (error "Lisp nesting exceeds 
`max-lisp-eval-depth'")
[...]

Usually, when I see those messages, I stop the build... or should I 
continue?

Thanks,
  Angelo.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-29 20:49 bug#18359: Macro expansion failure [MSYS2-MinGW64] Angelo Graziosi
@ 2014-08-30  7:21 ` Eli Zaretskii
  2014-08-30 10:20   ` Angelo Graziosi
                     ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Eli Zaretskii @ 2014-08-30  7:21 UTC (permalink / raw)
  To: Angelo Graziosi; +Cc: 18359

> Date: Fri, 29 Aug 2014 22:49:21 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> 
> With recent trunk, building the 64 bit build of Emacs on Windows using 
> MSYS2/MinGW64 tools, produces many "macro-expansion failure" messages:
> 
> [...]
> Eager macro-expansion failure: (error "Lisp nesting exceeds 
> `max-lisp-eval-depth'")
> Eager macro-expansion failure: (error "Lisp nesting exceeds 
> `max-lisp-eval-depth'")

Please provide more context from the build log, around these
messages.  At least which Lisp files cause them.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-30  7:21 ` Eli Zaretskii
@ 2014-08-30 10:20   ` Angelo Graziosi
  2014-08-30 14:46   ` Angelo Graziosi
  2014-08-30 16:15   ` Angelo Graziosi
  2 siblings, 0 replies; 19+ messages in thread
From: Angelo Graziosi @ 2014-08-30 10:20 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 18359


Il 30/08/2014 09:21, Eli Zaretskii ha scritto:
>> Date: Fri, 29 Aug 2014 22:49:21 +0200
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>>
>> With recent trunk, building the 64 bit build of Emacs on Windows using
>> MSYS2/MinGW64 tools, produces many "macro-expansion failure" messages:
>>
>> [...]
>> Eager macro-expansion failure: (error "Lisp nesting exceeds
>> `max-lisp-eval-depth'")
>> Eager macro-expansion failure: (error "Lisp nesting exceeds
>> `max-lisp-eval-depth'")
>
> Please provide more context from the build log, around these
> messages.  At least which Lisp files cause them.
>

Oh yes..

[...]
make[2]: uscita dalla directory "/tmp/emacs.git/lisp"
EMACSLOADPATH= '../src/bootstrap-emacs.exe' -batch --no-site-file 
--no-site-lisp -l autoload \
    --eval "(setq generate-autoload-cookie \";;;###tramp-autoload\")" \
    --eval "(setq generated-autoload-file (expand-file-name 
(unmsys--file-name \"net/tramp-loaddefs.el\")))" \
    -f batch-update-autoloads ./net
Wrote c:/msys64/tmp/emacs.git/lisp/mh-e/mh-loaddefs.el
Wrote c:/msys64/tmp/emacs.git/lisp/net/tramp-loaddefs.el

[ Eager macro-expansion failure: MESSAGES ]

Generating autoloads for mh-acros.el...
Generating autoloads for mh-acros.el...done
Generating autoloads for mh-alias.el...
Generating autoloads for mh-alias.el...done
Generating autoloads for mh-buffers.el...
Generating autoloads for mh-buffers.el...done
Generating autoloads for mh-comp.el...

[ Eager macro-expansion failure: MESSAGES ]

Generating autoloads for mh-comp.el...done
Generating autoloads for mh-compat.el...
Generating autoloads for mh-compat.el...done

[ Eager macro-expansion failure: MESSAGES ]

Generating autoloads for mh-folder.el...
Generating autoloads for mh-folder.el...done
Generating autoloads for mh-funcs.el...
[...]
make[2]: ingresso nella directory "/tmp/emacs.git/lisp"
Compiling ../lisp/cus-start.el
Wrote c:/msys64/tmp/emacs.git/lisp/emacs-lisp/map-ynp.elc

[ Eager macro-expansion failure: MESSAGES ]

Wrote c:/msys64/tmp/emacs.git/lisp/cus-start.elc
make[2]: uscita dalla directory "/tmp/emacs.git/lisp"
make[2]: uscita dalla directory "/tmp/emacs.git/lisp"
[...]


Ciao,
Angelo.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-30  7:21 ` Eli Zaretskii
  2014-08-30 10:20   ` Angelo Graziosi
@ 2014-08-30 14:46   ` Angelo Graziosi
  2014-08-30 16:15   ` Angelo Graziosi
  2 siblings, 0 replies; 19+ messages in thread
From: Angelo Graziosi @ 2014-08-30 14:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 18359



Il 30/08/2014 09:21, Eli Zaretskii ha scritto:
>> Date: Fri, 29 Aug 2014 22:49:21 +0200
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>>
>> With recent trunk, building the 64 bit build of Emacs on Windows using
>> MSYS2/MinGW64 tools, produces many "macro-expansion failure" messages:
>>
>> [...]
>> Eager macro-expansion failure: (error "Lisp nesting exceeds
>> `max-lisp-eval-depth'")
>> Eager macro-expansion failure: (error "Lisp nesting exceeds
>> `max-lisp-eval-depth'")
>
> Please provide more context from the build log, around these
> messages.  At least which Lisp files cause them.
>

Some more informations...

In a previous build log (20140816) I find 96 of the above errors. The 
build failed with

...
Generating autoloads for cal-julian.el...
Generating autoloads for cal-julian.el...done
Loading macroexp.elc...
make[2]: ingresso nella directory "/tmp/emacs.git/lisp"
Opening input file: no such file or directory, 
c:/msys64/tmp/emacs.git/lisp/calendar/cal-loaddefs.el
Compiling ../lisp/subr.el
Makefile:465: set di istruzioni per l'obiettivo 
"calendar/hol-loaddefs.el" non riuscito
make[2]: *** [calendar/hol-loaddefs.el] Errore 127
make[2]: *** Attesa per i processi non terminati....
make[2]: ingresso nella directory "/tmp/emacs.git/lisp"
Compiling ../lisp/version.el
Wrote c:/msys64/tmp/emacs.git/lisp/calendar/cal-loaddefs.el
(No changes need to be saved)
make[2]: uscita dalla directory "/tmp/emacs.git/lisp"
Makefile:798: set di istruzioni per l'obiettivo "../lisp/loaddefs.el" 
non riuscito
make[1]: *** [../lisp/loaddefs.el] Errore 2
make[1]: *** Attesa per i processi non terminati....

In declare-function:
subr.el:32:11:Warning: macro declare-function used to take 2+ arguments, now
     takes 2-4

Wrote c:/msys64/tmp/emacs.git/lisp/version.elc
make[2]: uscita dalla directory "/tmp/emacs.git/lisp"
Wrote c:/msys64/tmp/emacs.git/lisp/subr.elc
make[2]: uscita dalla directory "/tmp/emacs.git/lisp"
...

and a few 'make -j3...' it was finished.

Now, with current trunk, 'grep -c failu...' finds 504 of those errors 
and the build fails always with

...
Loading startup...
Loading loaddefs.el (source)...
End of file during parsing: c:/msys64/tmp/emacs.git/lisp/loaddefs.el
Makefile:603: set di istruzioni per l'obiettivo "emacs.exe" non riuscito
make[2]: *** [emacs.exe] Errore 1
make[2]: uscita dalla directory "/tmp/emacs.git/src"
Makefile:379: set di istruzioni per l'obiettivo "src" non riuscito
make[1]: *** [src] Errore 2
make[1]: uscita dalla directory "/tmp/emacs.git"
Makefile:1061: set di istruzioni per l'obiettivo "bootstrap" non riuscito
make: *** [bootstrap] Errore 2

repeating 'make -j3...' or 'make bootstrap..' doesn't help.

I tried also what suggests INSTSLL.REPO,

$ cd lisp
$ make autoloads
for file in `find . -type d -print`; do case $file in .*/obsolete | 
.*/term ) ;; *) wins="$wins${wins:+ }$file" ;; esac; done; \
echo Directories: $wins; \
EMACSLOADPATH= '../src/emacs' -batch --no-site-file --no-site-lisp -l 
autoload \
     --eval '(setq autoload-ensure-writable t)' \
     --eval '(setq autoload-builtin-package-versions t)' \
     --eval '(setq generated-autoload-file (expand-file-name 
(unmsys--file-name "./loaddefs.el")))' \
     -f batch-update-autoloads $wins
Directories: . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic 
./cedet/semantic/analyze ./cedet/semantic/bovine 
./cedet/semantic/decorate ./cedet/semantic/symref 
./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emulation ./erc 
./eshell ./gnus ./international ./language ./leim ./leim/quail ./mail 
./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./vc
/bin/sh: riga 2: ../src/emacs: No such file or directory
Makefile:181: set di istruzioni per l'obiettivo "autoloads" non riuscito
make: *** [autoloads] Errore 127

Usually I build a native W64 Emacs on MSYS-MinGW64 with

./autogen.sh

./configure --prefix=/Emacs --with-wide-int --build=x86_64-w64-mingw32 
--without-imagemagick 'CFLAGS=-I/mingw64/include/noX -Ofast -g0 -pipe' 
LDFLAGS=-pipe

make -j3

BTW, I found also this reports:

http://lists.gnu.org/archive/html/emacs-devel/2014-08/msg00469.html
http://lists.gnu.org/archive/html/emacs-devel/2014-08/msg00372.html


Ciao,
   Angelo.






^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-30  7:21 ` Eli Zaretskii
  2014-08-30 10:20   ` Angelo Graziosi
  2014-08-30 14:46   ` Angelo Graziosi
@ 2014-08-30 16:15   ` Angelo Graziosi
  2014-08-30 16:37     ` Eli Zaretskii
  2 siblings, 1 reply; 19+ messages in thread
From: Angelo Graziosi @ 2014-08-30 16:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 18359



Il 30/08/2014 09:21, Eli Zaretskii ha scritto:
>> Date: Fri, 29 Aug 2014 22:49:21 +0200
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>>
>> With recent trunk, building the 64 bit build of Emacs on Windows using
>> MSYS2/MinGW64 tools, produces many "macro-expansion failure" messages:
>>
>> [...]
>> Eager macro-expansion failure: (error "Lisp nesting exceeds
>> `max-lisp-eval-depth'")
>> Eager macro-expansion failure: (error "Lisp nesting exceeds
>> `max-lisp-eval-depth'")
>
> Please provide more context from the build log, around these
> messages.  At least which Lisp files cause them.
>

OK, I solved the build errors.. switching to e pseudo-BZR repo, i.e. a 
repo from which I stripped all the .bzr*, .git*, .gdb* stuffs..

If I build in a source tree created with,

$ bzr checkout --lightweight http://bzr.savannah.gnu.org/r/emacs/trunk emacs

the build fails :

[...]
Making generated-autoload-file local to  *autoload-file* while let-bound!
Generating autoloads for dired-aux.el...
Loading macroexp.elc...
make[2]: ingresso nella directory "/tmp/emacs/lisp"
make[2]: ingresso nella directory "/tmp/emacs/lisp"
Compiling ../lisp/button.el
Compiling ../lisp/startup.el

Searching for program: no such file or directory, bzr
                                      ????? ^^^^^^^^^^^^^^^^ ?????

Makefile:181: set di istruzioni per l'obiettivo "autoloads" non riuscito
make[2]: *** [autoloads] Errore 127
make[2]: uscita dalla directory "/tmp/emacs/lisp"
Makefile:800: set di istruzioni per l'obiettivo "../lisp/loaddefs.el" 
non riuscito
make[1]: *** [../lisp/loaddefs.el] Errore 2
make[1]: *** Attesa per i processi non terminati....

In toplevel form:
startup.el:118:1:Warning: global/dynamic var `argi' lacks a prefix

Wrote c:/msys64/tmp/emacs/lisp/button.elc

make[2]: uscita dalla directory "/tmp/emacs/lisp"
Wrote c:/msys64/tmp/emacs/lisp/startup.elc

make[2]: uscita dalla directory "/tmp/emacs/lisp"
make[1]: uscita dalla directory "/tmp/emacs/src"
Makefile:379: set di istruzioni per l'obiettivo "src" non riuscito
make: *** [src] Errore 2

For some reason, I need to create the emacs tree folder with a command 
like this:

$ rsync -av --exclude=.bzr* --exclude=.git* --exclude=.gdb* 
~/work/emacs-trunk/ /tmp/emacs/


Ciao,
Angelo.







^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-30 16:15   ` Angelo Graziosi
@ 2014-08-30 16:37     ` Eli Zaretskii
  2014-08-30 16:42       ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2014-08-30 16:37 UTC (permalink / raw)
  To: Angelo Graziosi; +Cc: 18359

> Date: Sat, 30 Aug 2014 18:15:29 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> CC: 18359@debbugs.gnu.org
> 
> If I build in a source tree created with,
> 
> $ bzr checkout --lightweight http://bzr.savannah.gnu.org/r/emacs/trunk emacs
> 
> the build fails :
> 
> [...]
> Making generated-autoload-file local to  *autoload-file* while let-bound!
> Generating autoloads for dired-aux.el...
> Loading macroexp.elc...
> make[2]: ingresso nella directory "/tmp/emacs/lisp"
> make[2]: ingresso nella directory "/tmp/emacs/lisp"
> Compiling ../lisp/button.el
> Compiling ../lisp/startup.el
> 
> Searching for program: no such file or directory, bzr
>                                       ????? ^^^^^^^^^^^^^^^^ ?????

Probably because visiting files in a bzr repository invokes
"bzr status", and perhaps a few other bzr commands.

Why are you using lightweight checkouts?  Just use a normal branch,
and all these weird problems will go away.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-30 16:37     ` Eli Zaretskii
@ 2014-08-30 16:42       ` Eli Zaretskii
  2014-08-30 17:16         ` Angelo Graziosi
  0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2014-08-30 16:42 UTC (permalink / raw)
  To: angelo.graziosi; +Cc: 18359

> Date: Sat, 30 Aug 2014 19:37:02 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18359@debbugs.gnu.org
> 
> > Searching for program: no such file or directory, bzr
> >                                       ????? ^^^^^^^^^^^^^^^^ ?????
> 
> Probably because visiting files in a bzr repository invokes
> "bzr status", and perhaps a few other bzr commands.
> 
> Why are you using lightweight checkouts?  Just use a normal branch,
> and all these weird problems will go away.

Or maybe this is some problem with how MSYS2 sets up PATH (assuming
yuou have just started using MSYS2).  Make sure bzr.exe is on your
PATH in MSYS2 Bash session where you run "make".





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-30 16:42       ` Eli Zaretskii
@ 2014-08-30 17:16         ` Angelo Graziosi
  2014-08-30 17:55           ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: Angelo Graziosi @ 2014-08-30 17:16 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 18359



Il 30/08/2014 18:42, Eli Zaretskii ha scritto:
>> Date: Sat, 30 Aug 2014 19:37:02 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 18359@debbugs.gnu.org
>>
>>> Searching for program: no such file or directory, bzr
>>>                                        ????? ^^^^^^^^^^^^^^^^ ?????
>>
>> Probably because visiting files in a bzr repository invokes
>> "bzr status", and perhaps a few other bzr commands.
>>
>> Why are you using lightweight checkouts?  Just use a normal branch,
>> and all these weird problems will go away.
>
> Or maybe this is some problem with how MSYS2 sets up PATH (assuming
> yuou have just started using MSYS2).  Make sure bzr.exe is on your
> PATH in MSYS2 Bash session where you run "make".
>
Hmm... I build Emacs in the shelle started with

   C:\msys64\mingw64_shell.bat

where

$ echo $PATH
/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0:/usr/bin/vendor_perl:/usr/bin/core_perl

$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.9.1/configure --prefix=/mingw64 
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include 
--libexecdir=/mingw64/lib 
--with-gxx-include-dir=/mingw64/include/c++/4.9.1 --enable-bootstrap 
--with-arch=x86-64 --with-tune=generic 
--enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared 
--enable-static --enable-libatomic --enable-threads=posix 
--enable-graphite --enable-fully-dynamic-string 
--enable-libstdcxx-time=yes --disable-libstdcxx-pch 
--disable-libstdcxx-debug --enable-cloog-backend=isl 
--enable-version-specific-runtime-libs --disable-cloog-version-check 
--disable-isl-version-check --enable-lto --enable-libgomp 
--disable-multilib --enable-checking=release --disable-rpath 
--disable-win32-registry --disable-nls --disable-werror 
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 
--with-cloog=/mingw64 --with-pkgversion='Rev3, Built by MSYS2 project' 
--with-bugurl=http://sourceforge.net/projects/msys2 --with-gnu-as 
--with-gnu-ld
Thread model: posix
gcc version 4.9.1 (Rev3, Built by MSYS2 project)

and

$ which bzr
/usr/bin/bzr

I will try with the trunk created by

$ bzr branch bzr://bzr.sv.gnu.org/emacs/trunk emacs


which should not be 'lightweight'... Right?


Ciao,
  Angelo.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-30 17:16         ` Angelo Graziosi
@ 2014-08-30 17:55           ` Eli Zaretskii
  2014-08-30 20:01             ` Angelo Graziosi
  2014-08-31 21:51             ` Angelo Graziosi
  0 siblings, 2 replies; 19+ messages in thread
From: Eli Zaretskii @ 2014-08-30 17:55 UTC (permalink / raw)
  To: Angelo Graziosi; +Cc: 18359

> Date: Sat, 30 Aug 2014 19:16:58 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> CC: 18359@debbugs.gnu.org
> 
> I will try with the trunk created by
> 
> $ bzr branch bzr://bzr.sv.gnu.org/emacs/trunk emacs
> 
> 
> which should not be 'lightweight'... Right?

Right.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-30 17:55           ` Eli Zaretskii
@ 2014-08-30 20:01             ` Angelo Graziosi
  2014-08-31 12:45               ` Stefan Monnier
  2014-08-31 21:51             ` Angelo Graziosi
  1 sibling, 1 reply; 19+ messages in thread
From: Angelo Graziosi @ 2014-08-30 20:01 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 18359



Il 30/08/2014 19:55, Eli Zaretskii ha scritto:
>> Date: Sat, 30 Aug 2014 19:16:58 +0200
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>> CC: 18359@debbugs.gnu.org
>>
>> I will try with the trunk created by
>>
>> $ bzr branch bzr://bzr.sv.gnu.org/emacs/trunk emacs
>>
>>
>> which should not be 'lightweight'... Right?
>
> Right.
>

Bingo! With the above tree, the bzr issue seems fixed.


Thanks,
  Angelo.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-30 20:01             ` Angelo Graziosi
@ 2014-08-31 12:45               ` Stefan Monnier
  2014-08-31 15:21                 ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2014-08-31 12:45 UTC (permalink / raw)
  To: Angelo Graziosi; +Cc: 18359

> Bingo! With the above tree, the bzr issue seems fixed.

FWIW, the presence of a `bzr' executable should not be needed.  And it
should work regardless of the use of lightweight checkouts (which I use
systematically, BTW) or something else.


        Stefan





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-31 12:45               ` Stefan Monnier
@ 2014-08-31 15:21                 ` Eli Zaretskii
  2014-08-31 20:07                   ` Stefan Monnier
  0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2014-08-31 15:21 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: angelo.graziosi, 18359

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  18359@debbugs.gnu.org
> Date: Sun, 31 Aug 2014 08:45:57 -0400
> 
> FWIW, the presence of a `bzr' executable should not be needed.  And it
> should work regardless of the use of lightweight checkouts (which I use
> systematically, BTW)

With MSYS on MS-Windows?





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-31 15:21                 ` Eli Zaretskii
@ 2014-08-31 20:07                   ` Stefan Monnier
  2014-08-31 21:40                     ` Angelo Graziosi
  0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2014-08-31 20:07 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: angelo.graziosi, 18359

>> FWIW, the presence of a `bzr' executable should not be needed.  And it
>> should work regardless of the use of lightweight checkouts (which I use
>> systematically, BTW)
> With MSYS on MS-Windows?

Same difference.  No matter how broken/weird the bzr/git/myfavoritevcs
setup might be, Emacs should build just fine.

Here "should" means "if it doesn't, I'd consider it as a bug".


        Stefan





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-31 20:07                   ` Stefan Monnier
@ 2014-08-31 21:40                     ` Angelo Graziosi
  2014-09-01  0:58                       ` Stefan Monnier
                                         ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Angelo Graziosi @ 2014-08-31 21:40 UTC (permalink / raw)
  To: Stefan Monnier, Eli Zaretskii; +Cc: 18359



Il 31/08/2014 22:07, Stefan Monnier ha scritto:
>>> FWIW, the presence of a `bzr' executable should not be needed.  And it
>>> should work regardless of the use of lightweight checkouts (which I use
>>> systematically, BTW)
>> With MSYS on MS-Windows?
>
> Same difference.  No matter how broken/weird the bzr/git/myfavoritevcs
> setup might be, Emacs should build just fine.
>
> Here "should" means "if it doesn't, I'd consider it as a bug".

I have used the lightweight tree since there was the transition CVS --> 
BZR, and it worked just fine on Cygwin and GNU/Linux. It is only on 
MSYS2-MinGW64 that there were these issues..

BTW, recent trunk from GIT fails with the Eager macro expansion 
failure... (on emacs-devel, others have flagged similar issues)


Ciao,
  Angelo.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-30 17:55           ` Eli Zaretskii
  2014-08-30 20:01             ` Angelo Graziosi
@ 2014-08-31 21:51             ` Angelo Graziosi
  2014-09-01  2:45               ` Eli Zaretskii
  1 sibling, 1 reply; 19+ messages in thread
From: Angelo Graziosi @ 2014-08-31 21:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 18359



Il 30/08/2014 19:55, Eli Zaretskii ha scritto:
>> Date: Sat, 30 Aug 2014 19:16:58 +0200
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>> CC: 18359@debbugs.gnu.org
>>
>> I will try with the trunk created by
>>
>> $ bzr branch bzr://bzr.sv.gnu.org/emacs/trunk emacs
>>
>>
>> which should not be 'lightweight'... Right?
>
> Right.
>

I have created my local repo with:

$ bzr branch bzr://bzr.sv.gnu.org/emacs/trunk emacs-trunk

but

$ cd emacs-trunk
$ bzr up

prints always it is updated to revision 117783, instead the current 
trunk is at revision 117790.. So my question is : How is this repo 
updated? It needs a different command? 'bzr up' does not work anymore?

Thanks,
  Angelo.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-31 21:40                     ` Angelo Graziosi
@ 2014-09-01  0:58                       ` Stefan Monnier
  2014-09-01  2:40                       ` Eli Zaretskii
  2016-08-09  1:48                       ` npostavs
  2 siblings, 0 replies; 19+ messages in thread
From: Stefan Monnier @ 2014-09-01  0:58 UTC (permalink / raw)
  To: Angelo Graziosi; +Cc: 18359

> It is only on MSYS2-MinGW64 that there were these issues..

Sounds like a bug.  It might even be a bug in the generic code
(i.e. a failure to properly "move on" when faced with a VCS error).

> BTW, recent trunk from GIT fails with the Eager macro expansion
> failure... (on emacs-devel, others have flagged similar issues)

Makes it sound even more likely thatthe bug is in the generic part of
the code (e.g. maybe in VC).


        Stefan





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-31 21:40                     ` Angelo Graziosi
  2014-09-01  0:58                       ` Stefan Monnier
@ 2014-09-01  2:40                       ` Eli Zaretskii
  2016-08-09  1:48                       ` npostavs
  2 siblings, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2014-09-01  2:40 UTC (permalink / raw)
  To: Angelo Graziosi; +Cc: 18359

> Date: Sun, 31 Aug 2014 23:40:21 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> CC: 18359@debbugs.gnu.org
> 
> I have used the lightweight tree since there was the transition CVS --> 
> BZR, and it worked just fine on Cygwin and GNU/Linux. It is only on 
> MSYS2-MinGW64 that there were these issues..

You are encouraged to investigate the reasons for these issues, if you
have time.

TIA





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-31 21:51             ` Angelo Graziosi
@ 2014-09-01  2:45               ` Eli Zaretskii
  0 siblings, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2014-09-01  2:45 UTC (permalink / raw)
  To: Angelo Graziosi; +Cc: 18359

> Date: Sun, 31 Aug 2014 23:51:31 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> CC: 18359@debbugs.gnu.org
> 
> I have created my local repo with:
> 
> $ bzr branch bzr://bzr.sv.gnu.org/emacs/trunk emacs-trunk
> 
> but
> 
> $ cd emacs-trunk
> $ bzr up
> 
> prints always it is updated to revision 117783, instead the current 
> trunk is at revision 117790.. So my question is : How is this repo 
> updated? It needs a different command? 'bzr up' does not work anymore?

"bzr up" synchronizes with upstream in bound branches and lightweight
checkouts.  Your branch is not bound.  You can either make it bound,
like this:

  cd emacs-trunk && bzr bind bzr://bzr.sv.gnu.org/emacs/trunk

or you can continue using your un-bound branch, and use "bzr pull" to
synchronize with upstream.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#18359: Macro expansion failure [MSYS2-MinGW64]
  2014-08-31 21:40                     ` Angelo Graziosi
  2014-09-01  0:58                       ` Stefan Monnier
  2014-09-01  2:40                       ` Eli Zaretskii
@ 2016-08-09  1:48                       ` npostavs
  2 siblings, 0 replies; 19+ messages in thread
From: npostavs @ 2016-08-09  1:48 UTC (permalink / raw)
  To: Angelo Graziosi; +Cc: Stefan Monnier, 18359

close 18359 
quit

Angelo Graziosi <angelo.graziosi@alice.it> writes:

> Il 31/08/2014 22:07, Stefan Monnier ha scritto:
>>>> FWIW, the presence of a `bzr' executable should not be needed.  And it
>>>> should work regardless of the use of lightweight checkouts (which I use
>>>> systematically, BTW)
>>> With MSYS on MS-Windows?
>>
>> Same difference.  No matter how broken/weird the bzr/git/myfavoritevcs
>> setup might be, Emacs should build just fine.
>>
>> Here "should" means "if it doesn't, I'd consider it as a bug".
>
> I have used the lightweight tree since there was the transition CVS
> --> 
> BZR, and it worked just fine on Cygwin and GNU/Linux. It is only on
> MSYS2-MinGW64 that there were these issues..
>
> BTW, recent trunk from GIT fails with the Eager macro expansion
> failure... (on emacs-devel, others have flagged similar issues)

AFAIK, this is no longer a problem.





^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2016-08-09  1:48 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-29 20:49 bug#18359: Macro expansion failure [MSYS2-MinGW64] Angelo Graziosi
2014-08-30  7:21 ` Eli Zaretskii
2014-08-30 10:20   ` Angelo Graziosi
2014-08-30 14:46   ` Angelo Graziosi
2014-08-30 16:15   ` Angelo Graziosi
2014-08-30 16:37     ` Eli Zaretskii
2014-08-30 16:42       ` Eli Zaretskii
2014-08-30 17:16         ` Angelo Graziosi
2014-08-30 17:55           ` Eli Zaretskii
2014-08-30 20:01             ` Angelo Graziosi
2014-08-31 12:45               ` Stefan Monnier
2014-08-31 15:21                 ` Eli Zaretskii
2014-08-31 20:07                   ` Stefan Monnier
2014-08-31 21:40                     ` Angelo Graziosi
2014-09-01  0:58                       ` Stefan Monnier
2014-09-01  2:40                       ` Eli Zaretskii
2016-08-09  1:48                       ` npostavs
2014-08-31 21:51             ` Angelo Graziosi
2014-09-01  2:45               ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).