GNU bug report logs - #10125
24.0.91; package.el (org): Macros in tar packages & order of byte compilation

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Achim Gratz <Stromeko <at> nexgo.de>, 10125 <at> debbugs.gnu.org
Subject: bug#10125: RFE: require and load-path-shadowing
Date: Thu, 10 Jan 2013 20:57:41 -0500

>> There is currently a problem with package manager when a package is
>> installed from a package archive,that package is already installed
>> either in Emacs core or site-lisp, and when (parts of) said package have
>> already been loaded when ELPA tries to install: the byte-compiler will
>> use the already loaded definitions rather than the new ones from the
>> package to install.
> I guess this would be http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125

Indeed, and as I mentioned back then I think it's a general enough
problem that we should try and think up a good solution.

Currently, we have two proposals:

1- run a separate Emacs instance: this gives you a clean slate, and lets
   you compile in parallel, but runs into the difficulty of figuring out
   exactly which clean slate to use.
   I guess we could fork Emacs early on and keep this second process
   around as a "process from which to generate new clean slates".

2- improve bytecomp.el to try and better isolate the compiled file from
   the previously loaded packages.

I don't see a clear winner, but since I'm biased in favor of the second
(not sure why, to tell you the truth), I'll add a few points related to
it.  The current behavior of bytecomp.el leads to various related
problems:
- outdated but already loaded packages can lead to mis-compilation.
  for the bootstrap we try to workaround this with
  byte-compile-refresh-preloaded, tho it only takes care of some
  particular cases.
- outdated .elc file taking precedence over the new .el file can do
  the same.
- bytecompiling a file affects the running session by side-effects such
  as requiring packages.
- if a package calls `byte-compile' during its own compilation, this
  sub-compilation will tend to complain about undeclared variables
  because it doesn't know about the vars that have been defvar'd in the
  outer compilation.  That's one of the main reasons for cc-bytecomp's
  hideous gymnastics.

Maybe we should (similarly to the fork idea above) keep a "clean
obarray", and run byte-compilations in a fresh copy of this
clean obarray.

I suggested a quick&dirty solution:
> > E.g. we could add to bytecomp.el the ability to force `require' to
> > reload a package if it's not already loaded from the file that
> > locate-library returns.

I still think it's not a bad option.

Of course, we'd still get trouble when the loading is not performed via
`require' but via autoload (maybe we could try and attack this problem
by allowing `autoload' to override an already existing definition, but
that could be delicate).

> That will probably work fine most of the time, but what if a package is
> restructed so that the feature names are different? Or a feature is
> removed?

I don't see why that would introduce a difficulty.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.