[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#31018] [PATCHv2] Improvements for our Emacs build system and fixes.

From: Maxim Cournoyer
Subject: [bug#31018] [PATCHv2] Improvements for our Emacs build system and fixes.
Date: Mon, 07 May 2018 08:13:48 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Hi Arun,

Better late than never... eh. Thanks for merging the changes. I'll
address some of your points post-mortem, in case you'd still like to
know my ideas on them :)

Arun Isaac <address@hidden> writes:

> I've pushed all patches except those concerning strict byte compilation,
> emacs-scel, emacs-org-contrib, emacs-howm and emacs-calfw.
> Some comments follow.
>> Done, although match-let appears to be undocumented :/.
> Yes, match-let is currently undocumented. But, I have a pending patch to
> guile regarding this. So, hopefully, this will be fixed soon.
>> In the past I played with attempting to define a
>> search-path-specification for our Emacs package, which would
>> generalize even more the way our Emacs packages are discovered in
>> Guix. That ended up looking like the following:
>> --8<---------------cut here---------------start------------->8---
>> +    (native-search-paths
>> +     (list (search-path-specification
>> +            (variable "EMACSLOADPATH")
>> +            (files '("share/emacs/site-lisp"))
>> +            (file-pattern ".*")
>> +            (append-separator? #t))))))
>> --8<---------------cut here---------------end--------------->8---
>> Where the new "append-separator?" argument was added by myself (this is
>> a world rebuilding change and also changes the manifest file). I didn't
>> pursue that for now given that it still suffers from 1. explained above.
>> The nice properties of this however was that it was now possible to have
>> the Emacs dependencies found in `guix environment' as well as in the
>> build system (anywhere), by using the native mechanism that Guix comes
>> with. If you have interest in going that way I could revive those two
>> old patches.
> For now, I've pushed with the set-emacs-load-path function you
> provided. But, you could pursue this world rebuilding search-paths
> approach as a separate bug report.

I will, as free time allows :)

>>>> Subject: [PATCH 15/27] gnu: Add emacs-scel.
>>>> +(define-public emacs-scel
>>>> +  (let ((version "20170629")
>>>> +        (revision "1")
>>>> +        (commit "aeea3ad4be9306d14c3a734a4ff54fee10ac135b"))
>>>> +    (package
>>>> +      (name "emacs-scel")
>>>> +      (version (git-version version revision commit))
>>>> +      (source (origin
>>>> +                (method git-fetch)
>>>> +                (uri (git-reference
>>>> +                      (url "";)
>>>> +                      (commit commit)))
>>>> +                (file-name (string-append name "-" version "-checkout"))
>>>> +                (sha256
>>>> +                 (base32
>>>> +                  
>>>> "0jvmzs1lsjyndqshhii2y4mnr3wghai26i3p75453zrpxpg0zvvw"))))
>>>> +      (build-system emacs-build-system)
>>> This package seems to use a cmake-build-system. Did you try that?
>> I didn't, on purpose. I wanted the Elisp files to be processed the same
>> as most of our other Emacs packages (with the patch-el-files phase
>> patching binaries, for example) that we would miss otherwise).
> I get your point. But, I think we can use phases from both the
> emacs-build-system and the cmake-build-system, like I have done in the
> attached patch. This keeps us more in line with the upstream repo,
> rather than us reinventing too much. WDYT?

Seems reasonable.


>>>> Subject: [PATCH 26/27] gnu: Add emacs-howm.
>>> This package seems to use the gnu-build-system. Did you try that?
>> No, for the same reasons explained above for the emacs-scel package.
> Likewise. In this case, if we don't use the gnu-build-system, we'd miss
> installing some of the files. Please look at my attached patch and see
> if that is acceptable.

I've taken a look, it looks more complete (you've got the tests enabled
now). Great work.

> Also, all of howm's source files declare gpl1+ to be the license. But,
> their COPYING file is of gpl2. Could you bring this contradiction to the
> attention of upstream?

This is surprising indeed. I've let a note about it to the author here:

Thank you,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]