GNU bug report logs - #38261
Recent changes to emacs build system

Previous Next

Full log

View this message in rfc822 format

From: brettg <at> posteo.net
To: Bug guix <Bug-guix <at> gnu.org>, Ricardo Wurmus <rekado <at> elephly.net>
Cc: bug-Guix <bug-guix-bounces+brettg=posteo.net <at> gnu.org>
Subject: bug#38261: Recent changes to emacs build system
Date: Tue, 19 Nov 2019 02:58:33 +0100

On 19.11.2019 01:32, brettg <at> posteo.net wrote:
> On 19.11.2019 01:27, brettg <at> posteo.net wrote:
>> On 18.11.2019 22:34, brettg <at> posteo.net wrote:
>>> On 18.11.2019 21:33, brettg <at> posteo.net wrote:
>>>> On 18.11.2019 21:28, brettg <at> posteo.net wrote:
>>>>> On 18.11.2019 20:01, brettg <at> 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.
>>>>>> 
>>>>>> For example, I borrowed the technique used by emacs-pdf-tools to
>>>>>> package emacs-telega, resulting in both packages failing to build:
>>>>>> 
>>>>>> Here is the code for emacs-telega:
>>>>>> 
>>>>>> https://git.sr.ht/~brettgilio/cfg/tree/master/channel/non-gnu/packages/emacs-xyz.scm#L99
>>>>>> 
>>>>>> The issue is in this phase for both emacs-pdf-tools and my channel 
>>>>>> package:
>>>>>> 
>>>>>>  (add-after 'compress-documentation 'emacs-set-emacs-load-path
>>>>>> 			  (assoc-ref emacs:%standard-phases 'set-emacs-load-path))
>>>>>> 
>>>>>> Resulting in:
>>>>>> 
>>>>>> starting phase `emacs-set-emacs-load-path'
>>>>>> Backtrace:
>>>>>>            5 (primitive-load 
>>>>>> "/gnu/store/5b1p1gsvfyi4fbx4s42rhab2dns…")
>>>>>> In ice-9/eval.scm:
>>>>>>    191:35  4 (_ _)
>>>>>> In ice-9/boot-9.scm:
>>>>>>     829:9  3 (catch _ _ #<procedure 7ffff3bbb518 at 
>>>>>> /gnu/store/zmkg…> …)
>>>>>> In srfi/srfi-1.scm:
>>>>>>    863:16  2 (every1 #<procedure 7ffff30ae160 at 
>>>>>> /gnu/store/zmkgrvv…> …)
>>>>>> In
>>>>>> /gnu/store/zmkgrvvhmrix2b1z7id6zrg9bb7qxzdl-module-import/guix/build/gnu-build-system.scm:
>>>>>>    839:30  1 (_ _)
>>>>>> In unknown file:
>>>>>>            0 (_ #:source 
>>>>>> "/gnu/store/qw8xbmk6ryl9a2jrp0gip3yffmsdix…" …)
>>>>>> 
>>>>>> ERROR: Wrong type to apply: #f
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> Brett Gilio
>>>>> 
>>>>> I applied a hotfix to the package by replacing 'set-emacs-load-path
>>>>> with 'add-source-to-load-path. I believe this fix would work for 
>>>>> all
>>>>> other affected packages.
>>>> 
>>>> https://git.sr.ht/~brettgilio/cfg/commit/c24a6db9d25151c487e9db675bd74e4bb3912173
>>> 
>>> 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 lisp
>>> from guile-studio when creating my own emacs configuration dependent
>>> on guix, which resulted in
>>> 
>>> progn: Wrong number of arguments: (lambda nil "Autoload Emacs 
>>> packages
>>> found in EMACSLOADPATH.
>>> 
>>> 'Autoload' means to load the 'autoloads' files matching
>>> `guix-emacs-autoloads-regexp'." (interactive) (let* ((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 ":")))
>>> (autoloads (mapcan (function guix-emacs-find-autoloads)
>>> emacs-non-core-load-path-directories))) (mapc (function (lambda (f)
>>> (load f (quote noerror)))) autoloads))), 78
>>> 
>>> 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.
>>> 
>>> Brett
>> 
>> 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=47b3b4c2aa49e21f4cc32c97ff7bbbd069bb849c)
>> does not carry arguments anymore, instead depending on a variable
>> EMACSLOADPATH. However, whenever that is done it returns
>> 
>> split-string: Wrong type argument: stringp, nil
>> 
>> possibly because my system is not finding EMACSLOADPATH.
>> 
>> I will keep investigating.
> 
> 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.

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.

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

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.

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.

https://git.sr.ht/~brettgilio/cfg/commit/47bc9ae544ba10c0cacef1435625dcb0114e8cf5

Anyways,

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.

Best,
Brett Gilio

Previous Next

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