[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4] gnu: emacs: Update to 27.1.

From: Morgan Smith
Subject: Re: [PATCH v4] gnu: emacs: Update to 27.1.
Date: Fri, 28 Aug 2020 17:10:31 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0


It seems I am taking some credit for Jack Hill's patch. I simply took
Jack's patch (labeled as patch v3 in the debbugs thread) and attempted
to build it with my personal config. I noticed that it wouldn't build
properly since emacs wanted libxaw and emacs-no-x wanted some image
librarys (libtiff, libjpeg, etc). The only contributions I made, where
to add libxaw to emacs and to add the configure flags to emacs-no-x. I
made these changes and posted them as patch v4. However, the patch Mark
committed does build for me so you can ignore my contributions (which
weren't well thought out to begin with).

The rest of your questions should be directed to Jack.

(Also just my 2 cents, we should have upgraded emacs-next to 27.1 and
only upgraded emacs a week later. Emacs deserves more care than most
packages due to its dependence on so many other packages. Not trying to
shame anyone, just something to think of for next time.)


On 8/28/20 2:57 PM, Mark H Weaver wrote:
> 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 <> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]