* bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows
@ 2012-06-14 11:16 Kazuhiro Ito
2012-06-14 16:27 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Kazuhiro Ito @ 2012-06-14 11:16 UTC (permalink / raw)
To: 11707
When I 'make recompile' on Windows, Emacs outputs many "Lisp nesting
exceeds `max-lisp-eval-depth'" message.
The cause of the problem is that lisp/makefile.w32-in does not use
BYTE_COMPILE_FLAGS variable when recompile. On the other hand,
lisp/Makefile.in use it.
Please see the below patch.
=== modified file 'lisp/makefile.w32-in'
--- lisp/makefile.w32-in 2012-06-09 11:53:31 +0000
+++ lisp/makefile.w32-in 2012-06-14 00:18:51 +0000
@@ -396,7 +396,7 @@
# WARNING: Do NOT split the part inside $(ARGQUOTE)s into multiple lines as
# this can break with GNU Make 3.81 and later if sh.exe is used.
recompile: compile-first autoloads doit $(lisp)/progmodes/cc-mode.elc
- $(emacs) --eval $(ARGQUOTE)(batch-byte-recompile-directory 0)$(ARGQUOTE) $(lisp)
+ $(emacs) $(BYTE_COMPILE_FLAGS) --eval $(ARGQUOTE)(batch-byte-recompile-directory 0)$(ARGQUOTE) $(lisp)
$(lisp)/calendar/cal-loaddefs.el:
"$(EMACS)" $(EMACSOPT) -l autoload \
--
Kazuhiro Ito
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows
2012-06-14 11:16 bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows Kazuhiro Ito
@ 2012-06-14 16:27 ` Eli Zaretskii
2012-06-15 16:41 ` Kazuhiro Ito
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2012-06-14 16:27 UTC (permalink / raw)
To: Kazuhiro Ito; +Cc: 11707
> Date: Thu, 14 Jun 2012 20:16:42 +0900
> From: Kazuhiro Ito <kzhr@d1.dion.ne.jp>
>
> When I 'make recompile' on Windows, Emacs outputs many "Lisp nesting
> exceeds `max-lisp-eval-depth'" message.
>
> The cause of the problem is that lisp/makefile.w32-in does not use
> BYTE_COMPILE_FLAGS variable when recompile. On the other hand,
> lisp/Makefile.in use it.
lisp/makefile.w32-in doesn't use BYTE_COMPILE_FLAGS because they are
not supposed to be needed for that target.
Are you using "make recompile" with emacs.exe that has only source
(*.el) version of the byte compiler loaded? Otherwise, I don't
understand how come you get these errors.
I don't want to blindly enlarge the stack of the byte compiler without
understanding the problem which causes the errors.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows
2012-06-14 16:27 ` Eli Zaretskii
@ 2012-06-15 16:41 ` Kazuhiro Ito
2012-06-15 17:41 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Kazuhiro Ito @ 2012-06-15 16:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 11707
> > When I 'make recompile' on Windows, Emacs outputs many "Lisp nesting
> > exceeds `max-lisp-eval-depth'" message.
>
> lisp/makefile.w32-in doesn't use BYTE_COMPILE_FLAGS because they are
> not supposed to be needed for that target.
>
> Are you using "make recompile" with emacs.exe that has only source
> (*.el) version of the byte compiler loaded? Otherwise, I don't
> understand how come you get these errors.
Probablely yes. The problem occured when I accidentally stopped 'make
bootstrap' in byte-compiling process and then run 'make recompile'.
Because I noticed the below ChangeLog entry and I didn't know about
the reason of the difference between Makefile.in and makefile.w32-in,
I simply thought lisp/makefile.w32-in didn't use BYTE_COMPILE_FLAGS
unintendedly.
lisp/ChangeLog
> 2011-04-01 Stefan Monnier <monnier@iro.umontreal.ca>
>
> Add lexical binding.
(snip)
> * Makefile.in (BIG_STACK_DEPTH, BIG_STACK_OPTS, BYTE_COMPILE_FLAGS):
> New variables.
> (compile-onefile, .el.elc, compile-calc, recompile): Use them.
> (COMPILE_FIRST): Add macroexp and cconv.
> * makefile.w32-in: Mirror changes in Makefile.in.
Here is the more strict recipe for the problem. But I don't know
whether 'make recompile' is expected to be run in such condition.
1. 'make bootstrap'
2. rm ../lisp/emacs-lisp/macroexp.elc
3. touch ../lisp/image-dired.el
4. make recompile
The below error occurs.
> Compiling f:/build/emacs-trunk/lisp/image-dired.el...
> Compiler-macro error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
> Compiler-macro error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
> Compiler-macro error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
> Compiler-macro error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
> Compiler-macro error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
> Compiler-macro error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
> Compiler-macro error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
>
> In toplevel form:
> image-dired.el:2352:1:Error: Lisp nesting exceeds `max-lisp-eval-depth'
5. make recompile
Successfully finished.
--
Kazuhiro Ito
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows
2012-06-15 16:41 ` Kazuhiro Ito
@ 2012-06-15 17:41 ` Eli Zaretskii
2012-06-18 12:56 ` Kazuhiro Ito
2012-06-25 1:10 ` Glenn Morris
0 siblings, 2 replies; 16+ messages in thread
From: Eli Zaretskii @ 2012-06-15 17:41 UTC (permalink / raw)
To: Kazuhiro Ito; +Cc: 11707
> Date: Sat, 16 Jun 2012 01:41:25 +0900
> From: Kazuhiro Ito <kzhr@d1.dion.ne.jp>
> Cc: 11707@debbugs.gnu.org
>
>
> > > When I 'make recompile' on Windows, Emacs outputs many "Lisp nesting
> > > exceeds `max-lisp-eval-depth'" message.
> >
> > lisp/makefile.w32-in doesn't use BYTE_COMPILE_FLAGS because they are
> > not supposed to be needed for that target.
> >
> > Are you using "make recompile" with emacs.exe that has only source
> > (*.el) version of the byte compiler loaded? Otherwise, I don't
> > understand how come you get these errors.
>
> Probablely yes. The problem occured when I accidentally stopped 'make
> bootstrap' in byte-compiling process and then run 'make recompile'.
You should use "make compile" in this situation. "make recompile"
might produce incorrect byte code, because it compiles all the files
in the same Emacs session.
> Here is the more strict recipe for the problem. But I don't know
> whether 'make recompile' is expected to be run in such condition.
>
> 1. 'make bootstrap'
> 2. rm ../lisp/emacs-lisp/macroexp.elc
> 3. touch ../lisp/image-dired.el
> 4. make recompile
>
> The below error occurs.
> > Compiling f:/build/emacs-trunk/lisp/image-dired.el...
> > Compiler-macro error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
> > Compiler-macro error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
> > Compiler-macro error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
> > Compiler-macro error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
> > Compiler-macro error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
> > Compiler-macro error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
> > Compiler-macro error: (error "Lisp nesting exceeds `max-lisp-eval-depth'")
> >
> > In toplevel form:
> > image-dired.el:2352:1:Error: Lisp nesting exceeds `max-lisp-eval-depth'
>
> 5. make recompile
> Successfully finished.
"make compile" should be free from this problem.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows
2012-06-15 17:41 ` Eli Zaretskii
@ 2012-06-18 12:56 ` Kazuhiro Ito
2012-06-25 1:10 ` Glenn Morris
1 sibling, 0 replies; 16+ messages in thread
From: Kazuhiro Ito @ 2012-06-18 12:56 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 11707
> > The problem occured when I accidentally stopped 'make
> > bootstrap' in byte-compiling process and then run 'make recompile'.
>
> You should use "make compile" in this situation. "make recompile"
> might produce incorrect byte code, because it compiles all the files
> in the same Emacs session.
Thank you for the advice. "make compile" surely has no problem.
--
Kazuhiro Ito
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows
2012-06-15 17:41 ` Eli Zaretskii
2012-06-18 12:56 ` Kazuhiro Ito
@ 2012-06-25 1:10 ` Glenn Morris
2012-06-25 11:35 ` Juanma Barranquero
2012-06-25 14:35 ` Stefan Monnier
1 sibling, 2 replies; 16+ messages in thread
From: Glenn Morris @ 2012-06-25 1:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 11707, Kazuhiro Ito
Eli Zaretskii wrote:
> You should use "make compile" in this situation. "make recompile"
> might produce incorrect byte code, because it compiles all the files
> in the same Emacs session.
I would like to suggest just removing the "recompile" target altogether.
Although I have never used it for anything personally, so maybe I'm
missing something, but I cannot see why this target should exist.
"make compile" is always more correct (and also faster on GNU/Linux for
multi-core machines).
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows
2012-06-25 1:10 ` Glenn Morris
@ 2012-06-25 11:35 ` Juanma Barranquero
2012-06-26 16:28 ` Glenn Morris
2012-06-25 14:35 ` Stefan Monnier
1 sibling, 1 reply; 16+ messages in thread
From: Juanma Barranquero @ 2012-06-25 11:35 UTC (permalink / raw)
To: Glenn Morris; +Cc: 11707, Kazuhiro Ito
On Mon, Jun 25, 2012 at 3:10 AM, Glenn Morris <rgm@gnu.org> wrote:
> I would like to suggest just removing the "recompile" target altogether.
> Although I have never used it for anything personally,
You've used it if you ever did "make cvs-update" or "make bzr-update".
Juanma
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows
2012-06-25 11:35 ` Juanma Barranquero
@ 2012-06-26 16:28 ` Glenn Morris
2012-06-26 17:08 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Glenn Morris @ 2012-06-26 16:28 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 11707, Kazuhiro Ito
Juanma Barranquero wrote:
> You've used it if you ever did "make cvs-update" or "make bzr-update".
I never have. I don't know why those rules exist either.
The cvs-update alias should just be removed now.
bzr-update should use compile instead of recompile, since the former is
parallelizable, which I think is more useful these days for a majority.
But bzr-update seems to offer no advantage over lisp/'s "all" target, so
I don't know why it exists at all.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows
2012-06-26 16:28 ` Glenn Morris
@ 2012-06-26 17:08 ` Eli Zaretskii
2012-06-28 17:30 ` Glenn Morris
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2012-06-26 17:08 UTC (permalink / raw)
To: Glenn Morris; +Cc: lekktu, kzhr, 11707
> From: Glenn Morris <rgm@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, 11707@debbugs.gnu.org, Kazuhiro Ito <kzhr@d1.dion.ne.jp>
> Date: Tue, 26 Jun 2012 12:28:24 -0400
>
> But bzr-update seems to offer no advantage over lisp/'s "all" target
It does on Windows ;-) Observe:
ALL =
all: $(ALL)
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows
2012-06-26 17:08 ` Eli Zaretskii
@ 2012-06-28 17:30 ` Glenn Morris
2012-06-28 18:15 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Glenn Morris @ 2012-06-28 17:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: lekktu, kzhr, 11707
Eli Zaretskii wrote:
>> But bzr-update seems to offer no advantage over lisp/'s "all" target
>
> It does on Windows ;-) Observe:
Prefix everything I say with "on POSIX platforms..." unless otherwise
specified. :)
So would anyone object to my removing the "bzr-update" rule from
lisp/Makefile.in?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows
2012-06-28 17:30 ` Glenn Morris
@ 2012-06-28 18:15 ` Eli Zaretskii
0 siblings, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2012-06-28 18:15 UTC (permalink / raw)
To: Glenn Morris; +Cc: lekktu, kzhr, 11707
> From: Glenn Morris <rgm@gnu.org>
> Cc: lekktu@gmail.com, 11707@debbugs.gnu.org, kzhr@d1.dion.ne.jp
> Date: Thu, 28 Jun 2012 13:30:57 -0400
>
> So would anyone object to my removing the "bzr-update" rule from
> lisp/Makefile.in?
Instead of removing it, and thus causing pain to finger memory of some
of us, how about if bzr-update simply invokes whatever you think
should be used instead?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows
2012-06-25 1:10 ` Glenn Morris
2012-06-25 11:35 ` Juanma Barranquero
@ 2012-06-25 14:35 ` Stefan Monnier
2012-06-28 17:34 ` Glenn Morris
2012-07-06 7:44 ` Glenn Morris
1 sibling, 2 replies; 16+ messages in thread
From: Stefan Monnier @ 2012-06-25 14:35 UTC (permalink / raw)
To: Glenn Morris; +Cc: 11707, Kazuhiro Ito
>> You should use "make compile" in this situation. "make recompile"
>> might produce incorrect byte code, because it compiles all the files
>> in the same Emacs session.
Actually, I don't know of any case where it ends up generating incorrect
byte-code. It will signal different (fewer) warnings and things like
that, but AFAIK the generated byte-code should be pretty much
equivalent. Moreover, if it ever ends up generating incorrect
byte-code, it's most likely because of a bug in some other file
(typically, the bug would be that Emacs's behavior is modified just by
loading that file).
> I would like to suggest just removing the "recompile" target altogether.
> Although I have never used it for anything personally, so maybe I'm
> missing something, but I cannot see why this target should exist.
It is significantly faster on uniprocessor machines.
I don't think we should remove it, but we should definitely rename it
because nothing in "compile -vs- recompile" hints at the difference.
We could rename it to "single-process-compile" or something like that.
Stefan
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows
2012-06-25 14:35 ` Stefan Monnier
@ 2012-06-28 17:34 ` Glenn Morris
2012-06-28 18:11 ` Stefan Monnier
2012-07-06 7:44 ` Glenn Morris
1 sibling, 1 reply; 16+ messages in thread
From: Glenn Morris @ 2012-06-28 17:34 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 11707, Kazuhiro Ito
Stefan Monnier wrote:
> Actually, I don't know of any case where it ends up generating incorrect
> byte-code. It will signal different (fewer) warnings and things like
> that, but AFAIK the generated byte-code should be pretty much
> equivalent.
True. Though there's the "invalid byte code" issue with
byte-compile-dynamic that was noticed recently. That's an extra,
somewhat serious looking warning that it signals.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows
2012-06-28 17:34 ` Glenn Morris
@ 2012-06-28 18:11 ` Stefan Monnier
0 siblings, 0 replies; 16+ messages in thread
From: Stefan Monnier @ 2012-06-28 18:11 UTC (permalink / raw)
To: Glenn Morris; +Cc: 11707, Kazuhiro Ito
>> Actually, I don't know of any case where it ends up generating incorrect
>> byte-code. It will signal different (fewer) warnings and things like
>> that, but AFAIK the generated byte-code should be pretty much
>> equivalent.
> True. Though there's the "invalid byte code" issue with
> byte-compile-dynamic that was noticed recently. That's an extra,
> somewhat serious looking warning that it signals.
Good point. Tho I tend to count it against byte-compile-dynamic, which
is a feature I'd be happy to stop supporting.
Stefan
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows
2012-06-25 14:35 ` Stefan Monnier
2012-06-28 17:34 ` Glenn Morris
@ 2012-07-06 7:44 ` Glenn Morris
2013-12-18 21:40 ` Glenn Morris
1 sibling, 1 reply; 16+ messages in thread
From: Glenn Morris @ 2012-07-06 7:44 UTC (permalink / raw)
To: 11707
Stefan Monnier wrote:
> I don't think we should remove it, but we should definitely rename it
> because nothing in "compile -vs- recompile" hints at the difference.
>
> We could rename it to "single-process-compile" or something like that.
Done.
This MS Windows bug is still open; maybe it can be closed, I don't know.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2013-12-18 21:40 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-06-14 11:16 bug#11707: 24.1.50; 'make recompile' does not use BYTE_COMPILE_FLAGS on Windows Kazuhiro Ito
2012-06-14 16:27 ` Eli Zaretskii
2012-06-15 16:41 ` Kazuhiro Ito
2012-06-15 17:41 ` Eli Zaretskii
2012-06-18 12:56 ` Kazuhiro Ito
2012-06-25 1:10 ` Glenn Morris
2012-06-25 11:35 ` Juanma Barranquero
2012-06-26 16:28 ` Glenn Morris
2012-06-26 17:08 ` Eli Zaretskii
2012-06-28 17:30 ` Glenn Morris
2012-06-28 18:15 ` Eli Zaretskii
2012-06-25 14:35 ` Stefan Monnier
2012-06-28 17:34 ` Glenn Morris
2012-06-28 18:11 ` Stefan Monnier
2012-07-06 7:44 ` Glenn Morris
2013-12-18 21:40 ` Glenn Morris
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.