[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Recursive compilation?
From: |
Stefan Monnier |
Subject: |
Re: Recursive compilation? |
Date: |
Mon, 06 Jun 2011 17:05:24 -0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
>> > There's a controversy about that, because there are legitimate and
>> > important use cases where Stefan's simpler solution causes trouble.
>> I think I missed that discussion. Do you have a recap, by any chance?
> The one use case I remember is when you are developing a Lisp package
> and it is not yet ready for prime time (e.g., loading it would break Emacs).
If we only change the "newest" behavior for byte-compilation, it means
the above will only apply when byte-compiling a file which requests your
temporarily-broken package. There are plenty of other ways to break
Emacs with local changes (e.g. changes that aren't ready for prime-time
applied to the Makefiles, or to C files, or ...), and there are plenty
of ways to handle this problem (e.g. "bzr shelve; make; bzr unshelve"),
so I'm really not convinced it's worth the hassle any more.
>> In any case, I think it would make sense to make this an option.
>> For instance, a new variable `byte-compile-load-newest-file'
>> defaulting to nil.
> If foo.el requires 'bar, and bar.elc is outdated, won't loading bar.el
> make the result of compiling foo.el less optimized?
No. AFAIK the only difference is for inlined functions which will be
inlined in a different way, thus resulting in different results.
I don't know of anyone who bothered to check which result is better, but
my guess is that it's a wash.
>> The obvious use case would be for the Emacs makefiles to set that
>> to t before compiling the .el files, which I'm sure would save us all a
>> bit of time over the coming years.
> Even in the Makefile's, I'm not sure it should be an obvious default:
> there could be important use cases when you'd want the warning/error
> even when building Emacs, e.g. when making a release or pretest
> tarball.
Glenn already pointed out that it's not an issue.
Any other objection?
Stefan
- Re: Recursive compilation?, Lars Magne Ingebrigtsen, 2011/06/01
- Re: Recursive compilation?, Dimitri Fontaine, 2011/06/01
- Re: Recursive compilation?, Lars Magne Ingebrigtsen, 2011/06/03
- Re: Recursive compilation?, Eli Zaretskii, 2011/06/04
- Re: Recursive compilation?, Lars Magne Ingebrigtsen, 2011/06/04
- Re: Recursive compilation?, Eli Zaretskii, 2011/06/04
- Re: Recursive compilation?, Glenn Morris, 2011/06/04
- Re: Recursive compilation?,
Stefan Monnier <=
- Re: Recursive compilation?, Lars Magne Ingebrigtsen, 2011/06/09
- Re: Recursive compilation?, Glenn Morris, 2011/06/04
- Re: Recursive compilation?, Dimitri Fontaine, 2011/06/06
- Re: Recursive compilation?, Daniel Colascione, 2011/06/06