help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: using use-package


From: Stefan Monnier
Subject: Re: using use-package
Date: Thu, 13 Aug 2015 16:31:03 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

>> Please do keep us informed of those problems: it's indeed very important
>> to make package.el more robust.
> My hunch now is that the package brought with it an .elc file (probably
> magit.elc) compiled with the wrong Emacs version.

Sounds unlikely both because of the way the ELPA package gets built and
because many other people would have bumped into this problem.

> Removing all .elc and recompiling the directory seems to succeed (I've
> ditched magit now for anoter reason -- it doesn't like my git 1.7.x
> and wants 1.9.x, I'd have to resort to an older magit, sigh).
> I'll try to verify (or falsify) my hunch.

My crystal ball tells me that you upgraded Magit from an Emacs where the
previous Magit was already loaded, and the old (loaded) version
interfered while byte-compiling the new version.
[ The typical interference, looks like this: Emacs tries to compile
  foo-1.el which does (require 'foo-2) to get some macros, but (the old)
  `foo-2' is already loaded so we end up using the old version of the
  macros (or the macros may simply not be defined at all).  ]

This is a problem in package.el that hit Helm pretty badly, apparently.
We have a tentative patch for that in Emacs-25.

This said, if you've erased the old problematic .elc files it'll be
difficult to verify/falsify my hunch.

Tho maybe if you can re-install the previous version of Magit, then run
Emacs, then use Magit, then in that same Emacs session upgrade Magit,
you might be able to reproduce the problem.

>> We should probably also add a package-(re)compile command (after all,
>> the compilation step is conceptually independent from the actual
>> installation).
> Perhaps there should be a way for Emacs to find out that an .elc file
> doesn't match the current binary interface (I've been stumped by
> "wrong" .elc files (i.e such compiled by an Emacs with different
> byte code conventions) more than once).

Normally byte-code is upward compatible, so the problem is only if you
compile with Emacs-NN and then use that file with Emacs-MM where MM<NN.
Admittedly, handling this more cleanly would be good.


        Stefan


reply via email to

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