From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Arun Isaac <arunisaac@systemreboot.net>
Cc: 31018@debbugs.gnu.org
Subject: [bug#31018] [PATCHv2] Improvements for our Emacs build system and fixes.
Date: Mon, 07 May 2018 08:13:48 -0400 [thread overview]
Message-ID: <878t8vacjn.fsf@gmail.com> (raw)
In-Reply-To: <5b6467d3.AMMAAAVkQu8AAAAAAAAAAAPHPfsAAAACwQwAAAAAAAW9WABa2idv@mailjet.com> (Arun Isaac's message of "Fri, 20 Apr 2018 23:16:15 +0530")
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 <arunisaac@systemreboot.net> 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
next prev parent reply other threads:[~2018-05-07 12:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-01 15:57 [bug#31018] [PATCH] Improvements for our Emacs build system and fixes Maxim Cournoyer
2018-04-13 20:41 ` Arun Isaac
[not found] ` <faec7bc3.AM8AAAStCIYAAAAAAAAAAAPHPfsAAAACwQwAAAAAAAW9WABa0RYW@mailjet.com>
2018-04-14 1:28 ` Maxim Cournoyer
2018-04-14 16:51 ` Arun Isaac
[not found] ` <9925e912.AM4AAAS8QCUAAAAAAAAAAAPHPfsAAAACwQwAAAAAAAW9WABa0jGH@mailjet.com>
2018-04-17 2:59 ` [bug#31018] [PATCHv2] " Maxim Cournoyer
2018-04-20 17:46 ` Arun Isaac
2018-05-03 16:32 ` bug#31018: " Arun Isaac
2018-05-03 16:54 ` [bug#31018] " Arun Isaac
[not found] ` <5b6467d3.AMMAAAVkQu8AAAAAAAAAAAPHPfsAAAACwQwAAAAAAAW9WABa2idv@mailjet.com>
2018-05-07 12:13 ` Maxim Cournoyer [this message]
2018-05-07 14:14 ` Arun Isaac
[not found] ` <handler.31018.D31018.152536517825664.notifdone@debbugs.gnu.org>
2018-05-07 12:21 ` [bug#31018] closed (Re: [bug#31018] [PATCHv2] Improvements for our Emacs build system and fixes.) Maxim Cournoyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878t8vacjn.fsf@gmail.com \
--to=maxim.cournoyer@gmail.com \
--cc=31018@debbugs.gnu.org \
--cc=arunisaac@systemreboot.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.