[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#44775] [PATCH] WIP: Add gccemacs
From: |
zimoun |
Subject: |
[bug#44775] [PATCH] WIP: Add gccemacs |
Date: |
Fri, 18 Dec 2020 03:50:18 +0100 |
Hi John,
On Tue, 24 Nov 2020 at 07:06, John Soo <jsoo1@asu.edu> wrote:
>> Thanks! This motivates me to resume what had been discussed here [1]:
>> be able to somehow run:
>>
>> guix build emacs-magit emacs-foo emacs-bar --with-input=emacs=gccemacs
>>
>> At least, have a package transformation that allow to rebuild all the
>> Emacs packages with the ’gccemacs’ VM instead of the current Emacs 27 one.
>>
>>> It feels fast but there are bugs and the closure is huge. Also these
>>> patches do not use any of the parameterization machinery.
>>
>> What do you mean by “parameterization machinery”? The new
>> ’with-parameter’ introduced here [2] or the package transformation that
>> replaces all the dependencies (explicit and implicit).
> I am referring to https://yhetil.org/guix-devel/87eeku8trb.fsf@gnu.org
>
> --with-parameter=gccemacs or similar seem to be required since the
> native-comp branch requires a different source, configure flags, and
> probably native-search-paths at least.
I am not convinced that the “parameterization machinery” could help here
(aside it is far to be ready :-)) because in this case, “gccemacs” is
not a «parameter» but an «argument» of the Emacs build system.
Maybe I miss something.
> There appears to be a separate compiled artifact directory under
> $out/lib/emacs/$version/native-lisp/$version-triple which has the
> compiled native libraries (.eln files). That directory seems to not be
> in the search path. That appears to be causing the first error
> I see. I am not sure which env variable would be tweaked to pick those
> paths up.
Thanks for the explanations.
All the best,
simon