Re: Recursive compilation?

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> > 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