[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.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30144
>
>> 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 "https://github.com/supercollider/scel.git")
>>>> + (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:
https://osdn.net/projects/howm/ticket/38251.
Thank you,
Maxim
- [bug#31018] [PATCHv2] Improvements for our Emacs build system and fixes.,
Maxim Cournoyer <=