GNU bug report logs - #79188
31.0.50; Cannot build packages installed from VC

Previous Next

Full log

Message #14 received at 79188 <at> debbugs.gnu.org (full text, mbox):

From: Przemysław Kryger <pkryger <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 79188 <at> debbugs.gnu.org
Subject: Re: bug#79188: 31.0.50; Cannot build packages installed from VC
Date: Fri, 08 Aug 2025 12:07:14 +0100

[Message part 1 (text/plain, inline)]

tags 79188 + patch
quit

Przemysław Kryger <pkryger <at> gmail.com> writes:
>> That seems reasonable, but in that case we should be able to reproduce
>> the issue with a more simple example (especially one that doesn't involve
>> use-package, MELPA and missing dependencies). [...]

I managed to reproduce the issue with
https://github.com/pkryger/basic-stats.el, which has no extra
dependencies.  I could reproduce all the issues I described in previous
message (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79188#11).

In addition I noticed, that `package-vc-upgrade' doesn't work as
well. This one was trying to pull inside the package install directory,
i.e, under `packgage-user-dir'.

>> This should fix the first issue, but it probably won't change anything
>> about the latter:
>>
>> diff --git a/lisp/package/package-vc.el b/lisp/package/package-vc.el
>> index db12c76133e..f2c7c460f6d 100644
>> --- a/lisp/package/package-vc.el
>> +++ b/lisp/package/package-vc.el
>> @@ -549,7 +549,14 @@ package-vc--unpack-1
>>          ;; FIXME: Compilation should be done as a separate, optional, st=
> ep.
>>          ;; E.g. for multi-package installs, we should first install all =
> packages
>>          ;; and then compile them.
>> -        (package--compile new-desc)
>> +        (package--compile
>> +         (if lisp-dir
>> +             ;; In case we are installing a package from a local
>> +             ;; checkout, we want to compile the checkout, not the
>> +             ;; redirection!
>> +             (package-desc-create :dir lisp-dir)
>> +          new-desc))
>> +
>>          (when package-native-compile
>>            (package--native-compile-async new-desc))
>>          ;; After compilation, load again any files loaded by
>>
>
> I don't have lisp/pakcage/package-vc.el, but I changed the file name to
> lisp/emacs-lisp/packgage-vc.el and the patch applied cleanly.
>
> [...]
>
> After I repeated the experiment the package installed with just
> `package-vc-install-from-checkout' (as described above) and
> helm-projectile.elc file has been produced into package source
> directory.

Based on that work I developed a new patch.  With both of the attached
patches applied I was able to run `package-vc-rebuild' and
`package-vc-reinstall' on the aforementioned package basic-stats and
observed that *.elc files were created in the source directory (i.e.,
the local checkout) and not in package install directory.

> A question: shouldn't the newly generated *.elc files be put in
> package install directory, just like the (non compiled) autoloads file
> is?  In my - very na=C3=AFve - view this would not only remove burden
> of doubling `load-path' entries (will that happen) but would also
> allow for a complete separation of compiled files between multiple
> Emacs versions coexisting on the same machine and reusing the same
> package source directories.

While the patch attached fixes basic workflows, I wonder idea of having
*.elc in a package install directory is worth exploring.  Would that
affect other functionalities?  For example `load' and `require' should
just work (provided the package install directory is in front of package
source directory in `load-pat'), but what will happen with
`find-library'/`locate-library'?  Are there any others?

[0001-Compile-file-in-local-checkout-directory.patch (text/plain, attachment)]

[0002-Store-local-checkout-directory-in-autoloads-indirect.patch (text/plain, attachment)]

Previous Next

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