emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
  • * bug#10125: RFE: require and load-path-shadowing
           [not found] ` <mthamoy574.fsf@fencepost.gnu.org>
           [not found]   ` <jwvvcb47bs0.fsf-monnier+emacs__21035.4545656175$1357869514$gmane$org@gnu.org>
    @ 2013-01-11  1:57   ` Stefan Monnier
      1 sibling, 0 replies; 47+ messages in thread
    From: Stefan Monnier @ 2013-01-11  1:57 UTC (permalink / raw)
      To: Glenn Morris; +Cc: Achim Gratz, 10125
    
    >> 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
    
    ^ permalink raw reply	[flat|nested] 47+ messages in thread

  • end of thread, other threads:[~2013-01-16 15:46 UTC | newest]
    
    Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed)
    -- links below jump to the message on this page --
         [not found] <87sj68eogm.fsf@Rainer.invalid>
         [not found] ` <mthamoy574.fsf@fencepost.gnu.org>
         [not found]   ` <jwvvcb47bs0.fsf-monnier+emacs__21035.4545656175$1357869514$gmane$org@gnu.org>
    2011-11-24 12:12     ` 24.0.91; package.el (org): Macros in tar packages & order of byte compilation Jambunathan K
    2002-01-01  0:33       ` bug#10125: " Jambunathan K
    2011-11-24 13:05       ` Eli Zaretskii
    2011-11-24 17:22         ` Jambunathan K
    2011-11-24 19:09           ` Glenn Morris
         [not found]           ` <v062i9tk0d.fsf@fencepost.gnu.org>
    2011-11-24 19:53             ` Glenn Morris
    2011-11-24 22:55             ` Stelian Iancu
    2011-11-24 23:54               ` Glenn Morris
    2011-11-25  3:31               ` Jambunathan K
    2011-11-25 12:32                 ` Stelian Iancu
         [not found]                 ` <CAKvLAojUzYmrUF_64WXEbj9zmBjzZ4gn5cDYVqLTcik41PFJ7w@mail.gmail.com>
    2011-11-25 12:58                   ` Jambunathan K
    2011-11-25  8:10             ` Eli Zaretskii
         [not found]             ` <hffwhdqov3.fsf@fencepost.gnu.org>
    2011-11-25 12:15               ` Jambunathan K
    2011-11-25 14:07               ` Chong Yidong
         [not found]               ` <87r50w47o3.fsf@gnu.org>
    2011-11-25 14:57                 ` Stefan Monnier
    2011-11-25 19:15                   ` Glenn Morris
    2011-11-25 19:21                     ` Glenn Morris
    2011-11-25 18:19                 ` Glenn Morris
    2011-11-25 19:01                   ` Glenn Morris
         [not found]             ` <83vcq88vwt.fsf@gnu.org>
    2011-11-25 18:20               ` Glenn Morris
    2013-01-11 16:06       ` bug#10125: RFE: require and load-path-shadowing Achim Gratz
         [not found]         ` <jwvvcb34qjg.fsf-monnier+emacs@gnu.org>
    2013-01-11 16:56         ` Stefan Monnier
    2013-01-11 19:53       ` Achim Gratz
    2013-01-11 22:52         ` Stefan Monnier
         [not found]         ` <jwvlibz2v6e.fsf-monnier+emacs@gnu.org>
    2013-01-12  8:15           ` Eli Zaretskii
    2013-01-12 10:15       ` Achim Gratz
    2013-01-12 13:34         ` Bastien
    2013-01-12 14:03           ` Stefan Monnier
    2013-01-12 14:23             ` Bastien
         [not found]             ` <87liby7a57.fsf@bzg.ath.cx>
    2013-01-12 16:12               ` Stefan Monnier
    2013-01-12 17:34                 ` Bastien
    2013-01-12 10:20       ` Achim Gratz
    2013-01-12 12:07         ` Eli Zaretskii
    2013-01-12 13:28           ` Stefan Monnier
         [not found]           ` <jwvehhqy1k8.fsf-monnier+emacs@gnu.org>
    2013-01-12 13:55             ` Eli Zaretskii
         [not found]             ` <83wqvisdxx.fsf__30242.1131091707$1357998993$gmane$org@gnu.org>
         [not found]               ` <87ip72fi8f.fsf@Rainer.invalid>
    2013-01-12 18:39                 ` Eli Zaretskii
    2013-01-12 18:42             ` Glenn Morris
         [not found]             ` <71vcb22qgz.fsf__38024.2966501557$1358016217$gmane$org@fencepost.gnu.org>
         [not found]               ` <87hamlbk3w.fsf__41794.7558024482$1358063310$gmane$org@Rainer.invalid>
         [not found]                 ` <87hamis0js.fsf@Rainer.invalid>
    2013-01-16  9:45                   ` Kevin Rodgers
         [not found]                   ` <kd5spq$1hh$1@ger.gmane.org>
    2013-01-16 10:06                     ` Andreas Schwab
         [not found]                     ` <mvmtxqh5tn0.fsf@hawking.suse.de>
    2013-01-16 14:59                       ` Kevin Rodgers
    2013-01-12 16:29       ` Achim Gratz
    2013-01-12 17:01       ` Achim Gratz
    2013-01-13  7:46       ` Achim Gratz
    2013-01-13  7:52       ` Achim Gratz
    2013-01-15 19:34       ` Achim Gratz
    2013-01-11  2:45     ` Jambunathan K
    2013-01-11  1:57   ` Stefan Monnier
    

    Code repositories for project(s) associated with this public inbox
    
    	https://git.savannah.gnu.org/cgit/emacs/org-mode.git
    
    This is a public inbox, see mirroring instructions
    for how to clone and mirror all data and code used for this inbox;
    as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).