From mboxrd@z Thu Jan 1 00:00:00 1970 From: brettg@posteo.net Subject: bug#38261: Recent changes to emacs build system Date: Tue, 19 Nov 2019 22:16:43 +0100 Message-ID: References: <848bb376e0d6e171347afe53ce79bd96@posteo.net> <421db4d1a206488fa1883e40666846c5@posteo.net> <805ec3dde9328f427bc34126c36735d3@posteo.net> <70112f45226b44a1234a4d41aa7ac610@posteo.net> <26711cb3bba8555dea8ac4e9f8220726@posteo.net> <57dee66c6531e9c8afbc5a22518d9917@posteo.net> <87ftijwou1.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:58166) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iXAs1-0001iM-9f for bug-guix@gnu.org; Tue, 19 Nov 2019 16:17:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iXArz-0001og-KJ for bug-guix@gnu.org; Tue, 19 Nov 2019 16:17:09 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:39802) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iXArz-0001oY-GU for bug-guix@gnu.org; Tue, 19 Nov 2019 16:17:07 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iXArt-00019w-Ih for bug-guix@gnu.org; Tue, 19 Nov 2019 16:17:07 -0500 Sender: "Debbugs-submit" Resent-Message-ID: Received: from eggs.gnu.org ([2001:470:142:3::10]:58122) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iXArh-0001hw-SV for Bug-guix@gnu.org; Tue, 19 Nov 2019 16:16:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iXArg-0001gg-0T for Bug-guix@gnu.org; Tue, 19 Nov 2019 16:16:49 -0500 Received: from mout01.posteo.de ([185.67.36.65]:41913) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iXArf-0001fj-6c for Bug-guix@gnu.org; Tue, 19 Nov 2019 16:16:47 -0500 Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 0CFD0160063 for ; Tue, 19 Nov 2019 22:16:44 +0100 (CET) In-Reply-To: <87ftijwou1.fsf@gmail.com> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Maxim Cournoyer Cc: bug-Guix , Bug guix On 19.11.2019 22:14, Maxim Cournoyer wrote: > Hello Brett, >=20 > Thank you for the heads-up concerning the latest changes to the way > Emacs find its libraries and the adjustments done to the > emacs-build-system. >=20 > brettg@posteo.net writes: >=20 >> On 19.11.2019 01:32, brettg@posteo.net wrote: >>> On 19.11.2019 01:27, brettg@posteo.net wrote: >>>> On 18.11.2019 22:34, brettg@posteo.net wrote: >>>>> On 18.11.2019 21:33, brettg@posteo.net wrote: >>>>>> On 18.11.2019 21:28, brettg@posteo.net wrote: >>>>>>> On 18.11.2019 20:01, brettg@posteo.net wrote: >>>>>>>> Hey all, the recent changes to the emacs build system result in >>>>>>>> a few >>>>>>>> broken packages like emacs-pdf-tools, or basically anything >>>>>>>> that uses >>>>>>>> a phase for emacs-set-emacs-load-path. >>>>>>>>=20 >>>>>>>> For example, I borrowed the technique used by emacs-pdf-tools to >>>>>>>> package emacs-telega, resulting in both packages failing to=20 >>>>>>>> build: >>>>>>>>=20 >>>>>>>> Here is the code for emacs-telega: >>>>>>>>=20 >>>>>>>> https://git.sr.ht/~brettgilio/cfg/tree/master/channel/non-gnu/pack= ages/emacs-xyz.scm#L99 >>>>>>>>=20 >>>>>>>> The issue is in this phase for both emacs-pdf-tools and my >>>>>>>> channel package: >>>>>>>>=20 >>>>>>>> (add-after 'compress-documentation 'emacs-set-emacs-load-path >>>>>>>> (assoc-ref emacs:%standard-phases 'set-emacs-load-path)) >>>>>>>>=20 >>>>>>>> Resulting in: >>>>>>>>=20 >>>>>>>> starting phase `emacs-set-emacs-load-path' >>>>>>>> Backtrace: >>>>>>>> 5 (primitive-load >>>>>>>> "/gnu/store/5b1p1gsvfyi4fbx4s42rhab2dns=E2=80=A6") >>>>>>>> In ice-9/eval.scm: >>>>>>>> 191:35 4 (_ _) >>>>>>>> In ice-9/boot-9.scm: >>>>>>>> 829:9 3 (catch _ _ #>>>>>>> /gnu/store/zmkg=E2=80=A6> =E2=80=A6) >>>>>>>> In srfi/srfi-1.scm: >>>>>>>> 863:16 2 (every1 #>>>>>>> /gnu/store/zmkgrvv=E2=80=A6> =E2=80=A6) >>>>>>>> In >>>>>>>> /gnu/store/zmkgrvvhmrix2b1z7id6zrg9bb7qxzdl-module-import/guix/bui= ld/gnu-build-system.scm: >>>>>>>> 839:30 1 (_ _) >>>>>>>> In unknown file: >>>>>>>> 0 (_ #:source >>>>>>>> "/gnu/store/qw8xbmk6ryl9a2jrp0gip3yffmsdix=E2=80=A6" =E2=80=A6) >>>>>>>>=20 >>>>>>>> ERROR: Wrong type to apply: #f >=20 > Sorry for failing to foresee this problem. I've fixed the couple > packages that were impacted on master now. You can have a look at the > fixes (they are fairly simple). >=20 >>>>>>>> If we suspect that changes are going to be non-backwards >>>>>>>> compatible >>>>>>>> could we use the news system to pass along that message? Much >>>>>>>> appreciated. Thanks. >>>>>>>>=20 >>>>>>>> Brett Gilio >>>>>>>=20 >>>>>>> I applied a hotfix to the package by replacing=20 >>>>>>> 'set-emacs-load-path >>>>>>> with 'add-source-to-load-path. I believe this fix would work for >>>>>>> all >>>>>>> other affected packages. >>>>>>=20 >>>>>> https://git.sr.ht/~brettgilio/cfg/commit/c24a6db9d25151c487e9db675bd= 74e4bb3912173 >=20 > Indeed! >=20 >>>>> Ricardo, just wanted to make you aware that this emacs-build-system >>>>> change does break your guile-studio. I discovered this because I >>>>> adopted some of your ideas of autoloading in the generated emacs=20 >>>>> lisp >>>>> from guile-studio when creating my own emacs configuration=20 >>>>> dependent >>>>> on guix, which resulted in >>>>>=20 >>>>> progn: Wrong number of arguments: (lambda nil "Autoload Emacs >>>>> packages >>>>> found in EMACSLOADPATH. >>>>>=20 >>>>> 'Autoload' means to load the 'autoloads' files matching >>>>> `guix-emacs-autoloads-regexp'." (interactive) (let*=20 >>>>> ((emacs-load-path >>>>> (getenv "EMACSLOADPATH")) (emacs-non-core-load-path-directories >>>>> (seq-filter (function (lambda (dir) (string-match-p >>>>> "/share/emacs/site-lisp" dir))) (split-string emacs-load-path=20 >>>>> ":"))) >>>>> (autoloads (mapcan (function guix-emacs-find-autoloads) >>>>> emacs-non-core-load-path-directories))) (mapc (function (lambda (f) >>>>> (load f (quote noerror)))) autoloads))), 78 >>>>>=20 >>>>> I'll let you know if I can find any fix for this when I get some >>>>> time. >>>>> But just wanted to pass the message along. >>>>>=20 >>>>> Brett >>>>=20 >>>> I tried removing the arguments passed to >>>> `guix-emacs-autoload-packages' as the updated version >>>> (http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/aux-files= /emacs/guix-emacs.el?id=3D47b3b4c2aa49e21f4cc32c97ff7bbbd069bb849c) >>>> does not carry arguments anymore, instead depending on a variable >>>> EMACSLOADPATH. However, whenever that is done it returns >>>>=20 >>>> split-string: Wrong type argument: stringp, nil >>>>=20 >>>> possibly because my system is not finding EMACSLOADPATH. >=20 > Yes, that's the reason. Perhaps it could be worthwhile to give a=20 > better > message in this condition, but it's unclear to me why this condition > would arise at all. Would you mind giving some more background to how > you got into that situation? I'll try building guile-studio and see if > I could get a hint or two. >=20 >>>> I will keep investigating. >>>=20 >>> I can confirm, when running something analogous to `guix environment >>> --ad-hoc emacs-dashboard` no changes are being made to the >>> $GUIX_ENVIRONMENT/etc/profile to resemble EMACSLOADPATH. >>=20 >> So I have investigated the issue with EMACSLOADPATH: Similar to >> Ricardo's guile-studio, >> my package enlign was using the autoload function from guix-emacs.el >> to propagate a list >> of packages called from inputs to be loaded with the start of emacs. >>=20 >> I have since revised this to just call the autoload function directly, >> no longer passing any arguments, and had to modify my enlign package >> to respect the EMACSLOADPATH variable. This is only possible if all of >> the packages are passed as propagated-inputs though, which is less >> than desirable in my opinion (though I am willing to be convinced.) >=20 > Is your package an Emacs library/package? If so, just defining the=20 > other > Elisp dependencies of this package as propagated inputs would be the > correct solution. >=20 > For other cases (I can't think of how that would work exactly), perhaps > wrapping the package's script with the computed EMACSLOADPATH > environment variable could do? >=20 >> This additionally leads to having to require emacs as a propagated >> input as well, as leading it native or regular input leads to an error >> with emacs not recognizing simple.el or mule-util. >=20 > Do you mean, that your package somehow uses Emacs without having Emacs > installed in the profile (not being propagated)? If this is the case, > wrapping your program with EMACSLOADPATH (and patching its reference to > Emacs) should work, without having to propagate anything. >=20 >> Overall, I am not sure if I like the recent change to guix-emacs.el. I >> understand where the incentive is to do this, but ultimately it seems >> to lead to more headache when creating packages around emacs. >>=20 >> https://git.sr.ht/~brettgilio/cfg/commit/47bc9ae544ba10c0cacef1435625dcb= 0114e8cf5 >>=20 >> Anyways, >>=20 >> If there is no other comment, this issue really just needs to fix >> emacs-pdf-tools and other affected packages from the recent string of >> changes. >=20 > I'm sorry you've had some problems with this recent change! Thanks for > bringing them out. Please do continue, I'm interested to know about=20 > any > remaining issues you might find. >=20 > Maxim Thank you for your work Maxim, I think most of them are resolved now. I=20 do wonder about what prompted the change, though. Perhaps you might=20 share? Brett