Re: Changing a cl-defstruct definition in a published package

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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