emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] master add49b6: * lisp/emacs-lisp/package.el: Reduce a


From: Artur Malabarba
Subject: Re: [Emacs-diffs] master add49b6: * lisp/emacs-lisp/package.el: Reduce autoloading before compiling
Date: Tue, 8 Sep 2015 15:55:41 +0100

2015-09-08 14:46 GMT+01:00 Stefan Monnier <address@hidden>:
>> IIUC, there are only two things in package-activate-1 that affect
>> byte-compilation: setting the load-path and loading the autoloads
>> file.
>
> Hmm... I think that "Call `load' on all files in `pkg-dir' already present in
> `load-history'" would also affect compilation, so it should be in
> package--activate-autoloads-and-load-path.

It can, but this wasn't done in the first activation anyway (because
the optional reload arg was nil) and I was trying to refactor without
changing any behavior. But I guess it would fix some issues if the
reloading happened before compilation as well.

>> 1) `package-activate-1' has a couple of line that shouldn't be called
>> twice, like (push name package-activated-list) and (push pkg-dir
>> Info-directory-list).
>
> They should be fixed to be idempotent since that can happen in any case
> if the package was activated and then gets updated (and hence re-activated).

OK

>> 2) It's just confusing to see a package being activated twice
>> throughout a single installation. I find it more informative to do
>> specifically what we want (i.e., load autloads and set load-path
>> before compilation).
>
> That makes sense.  I think compilation is a separate step which should
> be optional (and as mentioned elsewhere, we should have a command to
> perform (re)compilation of a package separately afterwards).
>
> So the presence of two "activation" calls is legitimate (the one for
> compilation is needed if the package was not activated yet, and the
> other is needed if compilation did not happen).  But I wonder why they
> should be different.  Can't we just have the "non-compilation
> activation" be performed before compilation takes place, and then change
> compilation so that it only activates the package if that was not
> done yet?

Yes, but we'll also have to add a third pseudo-activation step after
byte-compilation where we reload files already loaded. After all,
these files have now been compiled.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]