From: Mark H Weaver <mhw@netris.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org, cjpeople2013@gmail.com,
Morgan.J.Smith@outlook.com, 42738@debbugs.gnu.org,
dnbarbato@posteo.de
Subject: Re: [PATCH v4] gnu: emacs: Update to 27.1.
Date: Fri, 28 Aug 2020 14:57:16 -0400 [thread overview]
Message-ID: <87lfhybntk.fsf@netris.org> (raw)
In-Reply-To: <87sgc6onvi.fsf@gnu.org>
Hello Guix,
Ludovic Courtès <ludo@gnu.org> wrote:
> Morgan.J.Smith@outlook.com skribis:
>
>> From: Morgan Smith <Morgan.J.Smith@outlook.com>
>>
>> * gnu/packages/emacs.scm (emacs): Update to 27.1.
>> [arguments]: Add --with-cairo and --with-modules to #:configure-flags. Add
>> restore-emacs-pdump phase.
>> [inputs]: Add cairo, libxaw, jansson, gmp, and harfbuzz. Remove imagemagick
>> and libxft.
>> [native-inputs]: Add texlive.
>> (emacs-wide-int): Mark as deprecated package.
>> (emacs-no-x):
>> [arguments]: Add --with-jpeg=no --with-gif=no --with-tiff=no
>> to #:configure-flags.
>
> I see that Mark committed a similar patch just yesterday:
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=36a09d185343375a5cba370431870f9c4435d623
>
> I suppose Mark hadn’t seen the ongoing discussion.
Indeed, I hadn't. Gah, I'm terribly sorry about this. I had done some
quick web searches for preexisting work on this, but clearly they were
insufficient, and I've never subscribed to the patches list. In the
future, I'll know not to rely on web search engines for this.
> Mark, Morgan: could you see if there’s anything we’re missing from the
> patch Morgan submitted?
Looking now, here are the main differences I see between our patches:
* I found that I had to remove the 'restore-emacs-pdump' phase from most
of the other emacs variants, namely the ones that use
'gnu-build-system', because otherwise the inherited
'restore-emacs-pdump' phase would fail. Morgan's patch seems not to
consider most of the other emacs variants, and I'm not sure if they
were tested. I briefly tested all of them except for 'guile-emacs'.
* Morgan removed the snippet code that deletes "eshell/esh-groups.el",
whereas I replaced it with a call to 'find-files' to remove it only if
present, as the previous comment suggested. I'm not sure if this is
still needed, though.
* Morgan's patch adds "libxaw" to inputs and "texinfo" to native-inputs.
What's the rationale for these?
* I added 'pango' to the inputs, because the Emacs NEWS mentioned that
Pango was used for font rendering when "--with-cairo" is used.
However, it may be that "pango" finds its way into the build inputs
without being explicitly mentioned.
* Morgan removed 'libxft' from the inputs of 'emacs', whereas I didn't.
This was an oversight on my part. However, if we remove it, it's
possible that we might need to add it back to 'emacs-no-x-toolkit'.
The references that I see to Pango in the Emacs code are within
"#ifdef HAVE_GTK3".
* In 'emacs-no-x', my patch removes the new graphical library inputs
(cairo, pango, and harfbuzz) and the "--with-cairo" flag, whereas
Morgan's patch leaves "cairo" and "harfbuzz" as inputs, and overwrites
the inherited configure-flags to be precisely ("--with-jpeg=no"
"--with-gif=no" "--with-tiff=no"), apparently discarding the inherited
"--with-modules" and "--disable-build-details" flags.
* Morgan made 'emacs-wide-int' into a deprecated package, whereas I
thought that it might still be useful. My rationale was this: from a
brief skim, it looks like '--with-wide-int' might make *immediate*
integers wider, which for some applications might perform much better
than the heap-allocated arbitrary-size integers supported by Emacs 27.
However, I didn't look carefully at this.
* I updated "emacs-exec-path.patch" and removed
"emacs27-exec-path.patch", whereas Morgan's patch keeps both files and
possibly leaves "emacs-exec-path.patch" orphaned.
* I updated the patches to apply cleanly to Emacs 27, although this was
not strictly needed.
* I updated 'notmuch' in the previous commit to a version that builds
successfully with Emacs 27.
Pierre Neidhardt <mail@ambrevar.xyz> wrote:
> I confirm that with Mark's commit
> emacs-clojure-mode and emacs-elisp-refs are also broken.
Sorry about that. If the Emacs 27 update breaks important packages, it
might be that reverting it is the proper action. If the maintainers
decide to do this, I would not object.
Best regards,
Mark
next prev parent reply other threads:[~2020-08-28 19:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200819040941.32696-1-jackhill@jackhill.us>
[not found] ` <DM5PR1001MB210589E35972B5314D4D8381C5550@DM5PR1001MB2105.namprd10.prod.outlook.com>
2020-08-28 14:18 ` [PATCH v4] gnu: emacs: Update to 27.1 Ludovic Courtès
2020-08-28 14:38 ` Pierre Neidhardt
2020-08-28 17:00 ` [bug#42738] " Brett Gilio
2020-08-28 17:08 ` Jack Hill
2020-08-28 17:34 ` Amin Bandali
2020-08-28 20:04 ` Mark H Weaver
2020-08-29 10:13 ` Ludovic Courtès
2020-08-29 21:53 ` Mark H Weaver
2020-09-07 9:00 ` Ludovic Courtès
2020-08-28 18:57 ` Mark H Weaver [this message]
2020-08-28 21:10 ` Morgan Smith
2020-08-29 20:35 ` Mark H Weaver
2020-08-30 1:50 ` [bug#42738] " Brett Gilio
2020-08-29 17:19 ` Giovanni Biscuolo
2020-09-04 9:03 ` Pierre Neidhardt
[not found] ` <87pn713nr7.fsf@ambrevar.xyz>
2020-09-04 10:20 ` Giovanni Biscuolo
2020-09-07 9:44 ` Pierre Neidhardt
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lfhybntk.fsf@netris.org \
--to=mhw@netris.org \
--cc=42738@debbugs.gnu.org \
--cc=Morgan.J.Smith@outlook.com \
--cc=cjpeople2013@gmail.com \
--cc=dnbarbato@posteo.de \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).