From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47504) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fFf1r-0002ub-Iu for guix-patches@gnu.org; Mon, 07 May 2018 08:14:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fFf1m-000154-Vm for guix-patches@gnu.org; Mon, 07 May 2018 08:14:07 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:44202) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fFf1m-00014o-Ql for guix-patches@gnu.org; Mon, 07 May 2018 08:14:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fFf1m-0005qt-Fc for guix-patches@gnu.org; Mon, 07 May 2018 08:14:02 -0400 Subject: [bug#31018] [PATCHv2] Improvements for our Emacs build system and fixes. Resent-Message-ID: From: Maxim Cournoyer References: <87y3i6538o.fsf@gmail.com> <9925e912.AM4AAAS8QCUAAAAAAAAAAAPHPfsAAAACwQwAAAAAAAW9WABa0jGH@mailjet.com> <87d0yyo7vm.fsf_-_@gmail.com> <5b6467d3.AMMAAAVkQu8AAAAAAAAAAAPHPfsAAAACwQwAAAAAAAW9WABa2idv@mailjet.com> Date: Mon, 07 May 2018 08:13:48 -0400 In-Reply-To: <5b6467d3.AMMAAAVkQu8AAAAAAAAAAAPHPfsAAAACwQwAAAAAAAW9WABa2idv@mailjet.com> (Arun Isaac's message of "Fri, 20 Apr 2018 23:16:15 +0530") Message-ID: <878t8vacjn.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Arun Isaac Cc: 31018@debbugs.gnu.org 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 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