[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Changing a cl-defstruct definition in a published package
From: |
Stefan Monnier |
Subject: |
Re: Changing a cl-defstruct definition in a published package |
Date: |
Sun, 15 Jul 2018 21:51:09 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
>> Note that the recompilation issue can be solved outside of package.el:
>> - "recompile package" doesn't have to be in package.el (tho it is its
>> most natural place).
>> - you could have code in flycheck.el that does:
>>
>> (eval-when-compile
>> (dolist (pkg (find-pkgs-using-the-old-flycheck-object-layout))
>> (recompile-package pkg)))
>>
>> so it will be executed when flycheck is compiled.
>
> That's a interesting idea, and a good point.
> But wouldn't it have to run *after* Flycheck is compiled?
I don't think so, no (by the time we're compiling the file, the package
is already installed and activated).
You'd need to add some mechanism to avoid infinite-recursion, ideally by
somehow checking that we're running this eval-when-compile because of
a compilation and not because we're loading the .el file.
We could use an ugly hack like (guaranteed 100% untested):
(eval-when-compile
;; When handling eval-when-compile, the byte-compiler compiles
;; the form before evaluating it, so in that case the
;; (lambda (x) (+ x 1)) below will be turned into byte-code before
;; we get to the `if` test. In contrast, when we're just loading
;; the .el file, the `lambda` is either left as is or turned into
;; a (closure ...) object (depending on lexical-binding), but in
;; either case it won't be turned into a byte-code.
;; Of course, all of this can be subject to change :-(
(when (byte-code-function-p (lambda (x) (+ x 1)))
;; We're in the middle of byte-compiling this file.
(dolist (pkg (find-pkgs-using-the-old-flycheck-object-layout))
(recompile-package pkg))))
Better would be to introduce some dedicated feature, like
`eval-only-when-compile`.
Stefan
- Re: Changing a cl-defstruct definition in a published package, (continued)
- Re: Changing a cl-defstruct definition in a published package, Clément Pit-Claudel, 2018/07/13
- Re: Changing a cl-defstruct definition in a published package, João Távora, 2018/07/13
- Re: Changing a cl-defstruct definition in a published package, Clément Pit-Claudel, 2018/07/13
- Re: Changing a cl-defstruct definition in a published package, Stefan Monnier, 2018/07/13
- Re: Changing a cl-defstruct definition in a published package, Clément Pit-Claudel, 2018/07/13
- Re: Changing a cl-defstruct definition in a published package, Stefan Monnier, 2018/07/13
- Re: Changing a cl-defstruct definition in a published package, Clément Pit-Claudel, 2018/07/15
- Re: Changing a cl-defstruct definition in a published package, Stefan Monnier, 2018/07/15
- Re: Changing a cl-defstruct definition in a published package, Clément Pit-Claudel, 2018/07/15
- Re: Changing a cl-defstruct definition in a published package,
Stefan Monnier <=
- Re: Changing a cl-defstruct definition in a published package, Clément Pit-Claudel, 2018/07/30
- Re: Changing a cl-defstruct definition in a published package, Stefan Monnier, 2018/07/30
- Re: Changing a cl-defstruct definition in a published package, Clément Pit-Claudel, 2018/07/30
Re: Changing a cl-defstruct definition in a published package, Jake, 2018/07/19