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

[Maxim Cournoyer]

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