Created attachment 586296 [details, diff] ebuild patch There are some upstream features in the emacs repo which the current emacs-vcs-27.0.9999.ebuild does not expose. In particular the new pdumper and harfbuzz support. I took a stab at adding those features to the ebuild. Also upstream no longer considers cairo support unstable, it might be a good idea to remove the cairo use flag from package.use.mask (for emacs/emacs-vcs >= 27 only). Cheers, Simon
If I understand the logic in configure.ac correctly, --with-pdumper works as follows: --with-pdumper=yes will result in the following variable values: with_pdumper=yes with_unexec=no with_dumping=pdumper This is the desired result, of course. --with-pdumper=no: with_pdumper=no with_unexec=no with_dumping=pdumper Here we have a contradiction between with_pdumper and with_dumping, which causes the following sanity check to error out. I think the right option to pass is --with-dumping={pdumper,unexec}. However, I wonder if we really should make this configurable, or just go with pdumper as the upstream default (because supporting unexec was a nightmare in the past). Also, why do we need exclusion between harfbuzz and m17n-lib? I don't see that in the upstream build system.
(In reply to Ulrich Müller from comment #1) > If I understand the logic in configure.ac correctly, --with-pdumper works as > follows: > > --with-pdumper=yes will result in the following variable values: > with_pdumper=yes > with_unexec=no > with_dumping=pdumper > This is the desired result, of course. > > --with-pdumper=no: > with_pdumper=no > with_unexec=no > with_dumping=pdumper > Here we have a contradiction between with_pdumper and with_dumping, which > causes the following sanity check to error out. > > I think the right option to pass is --with-dumping={pdumper,unexec}. > However, I wonder if we really should make this configurable, or just go > with pdumper as the upstream default (because supporting unexec was a > nightmare in the past). You are correct, doing it the way I did is wrong (I just tested it). --with-dumping={pdumper,unexec} works as intended. About making it a use flag: I guess there is a reason, upstream still supports it , maybe it is not yet as tested on some architectures, so I thought it might be useful for someone to have the option. But there is probably not much lost if it is not configurable. > Also, why do we need exclusion between harfbuzz and m17n-lib? I don't see > that in the upstream build system. Apparently emacs allows for building with both harfbuzz and m17n-flt, but i don't understand the reason behind it. AFAIK m17n-flt sole job is font layout/shape exactly the same job harfbuzz has.I looked at the code and I got the impression that by default the xft/m17n-flt "font_driver" will not be used when harfbuzz is configured. From the current emacs master: > src/ftcrfont.c > 609: Fput (Qftcr, Qfont_driver_superseded_by, Qftcrhb); > src/ftfont.c > 3069: Fput (Qfreetype, Qfont_driver_superseded_by, Qfreetypehb); > src/w32uniscribe.c > 1545: Fput (Quniscribe, Qfont_driver_superseded_by, Qharfbuzz); > src/xftfont.c > 681: Fput (Qxft, Qfont_driver_superseded_by, Qxfthb); The font_driver_superseded_by table is used when initializing the "font_driver". But those settings could probably be override at runtime.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8262bb3cc1239cb1221d72c617ab964734848c0e commit 8262bb3cc1239cb1221d72c617ab964734848c0e Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2019-08-10 10:32:32 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2019-08-10 11:16:28 +0000 profiles: Lift the cairo USE mask for app-editors/emacs-vcs:27. According to upstream NEWS: "The configure option '--with-cairo' is no longer experimental." Bug: https://bugs.gentoo.org/691830 Signed-off-by: Ulrich Müller <ulm@gentoo.org> profiles/base/package.use.mask | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a2bcc1d9959a2c8f74fdff375b9c9907b298652d commit a2bcc1d9959a2c8f74fdff375b9c9907b298652d Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2019-08-10 10:02:14 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2019-08-10 11:16:28 +0000 app-editors/emacs-vcs: Add harfbuzz USE flag. Bug: https://bugs.gentoo.org/691830 Reported-by: Simon Reiser <me@sfxr.de> Package-Manager: Portage-2.3.71, Repoman-2.3.17 Signed-off-by: Ulrich Müller <ulm@gentoo.org> app-editors/emacs-vcs/emacs-vcs-27.0.9999.ebuild | 4 +++- app-editors/emacs-vcs/metadata.xml | 2 ++ 2 files changed, 5 insertions(+), 1 deletion(-)
Created attachment 586488 [details] build.log (In reply to simonfxr from comment #2) > > I think the right option to pass is --with-dumping={pdumper,unexec}. > > However, I wonder if we really should make this configurable, or just go > > with pdumper as the upstream default (because supporting unexec was a > > nightmare in the past). > > You are correct, doing it the way I did is wrong (I just tested it). > --with-dumping={pdumper,unexec} works as intended. > > About making it a use flag: I guess there is a reason, upstream still > supports it , maybe it is not yet as tested on some architectures, so I > thought it might be useful for someone to have the option. But there is > probably not much lost if it is not configurable. Have you actually tested --with-dumping=unexec? Because for me it makes the compilation fail in emacs.c, see attached build.log. So, if you really insist on this flag, please file a bug report upstream and ask them to fix this feature. (However, I expect that they won't be enthusiatic about it, and that support will only get worse in the future.)
(In reply to Ulrich Müller from comment #4) Thanks for the updated ebuild and unmasking of cairo! > Created attachment 586488 [details] > build.log > Have you actually tested --with-dumping=unexec? Because for me it makes the > compilation fail in emacs.c, see attached build.log. Sorry I was lazy and only tested the configure step. > So, if you really insist on this flag, please file a bug report upstream and > ask them to fix this feature. (However, I expect that they won't be > enthusiatic about it, and that support will only get worse in the future.) It's not that I care, I just thought it might be useful to *someone*. So I'm okay with not having the flag. Is there any reason you dropped the libotf flag from the patch? AFAICT there is no need to couple it to the m17nlib. Keeping it coupled means, there is no way to disable m17n but link against libotf, since --without-libotf is explicitly passed to configure. ./configure --with-cairo --without-m17n-flt (Yes it builds and runs fine): > Configured for 'x86_64-pc-linux-gnu'. > > Where should the build process find the source code? . > What compiler should emacs be built with? gcc -g3 -O2 > Should Emacs use the GNU version of malloc? no > (The GNU allocators don't work with this system configuration.) > Should Emacs use a relocating allocator for buffers? no > Should Emacs use mmap(2) for buffer allocation? no > What window system should Emacs use? x11 > What toolkit should Emacs use? GTK3 > Where do we find X Windows header files? Standard dirs > Where do we find X Windows libraries? Standard dirs > Does Emacs use -lXaw3d? no > Does Emacs use -lXpm? yes > Does Emacs use -ljpeg? yes > Does Emacs use -ltiff? yes > Does Emacs use a gif library? yes -lgif > Does Emacs use a png library? yes -lpng16 -lz > Does Emacs use -lrsvg-2? yes > Does Emacs use cairo? yes > Does Emacs use -llcms2? yes > Does Emacs use imagemagick? no > Does Emacs support sound? yes > Does Emacs use -lgpm? yes > Does Emacs use -ldbus? yes > Does Emacs use -lgconf? no > Does Emacs use GSettings? yes > Does Emacs use a file notification library? yes -lglibc (inotify) > Does Emacs use access control lists? yes -lacl > Does Emacs use -lselinux? no > Does Emacs use -lgnutls? yes > Does Emacs use -lxml2? yes > Does Emacs use -lfreetype? yes > Does Emacs use HarfBuzz? yes > Does Emacs use -lm17n-flt? no > Does Emacs use -lotf? yes > Does Emacs use -lxft? no > Does Emacs use -lsystemd? yes > Does Emacs use -ljansson? yes > Does Emacs use -lgmp? yes > Does Emacs directly use zlib? yes > Does Emacs have dynamic modules support? no > Does Emacs use toolkit scroll bars? yes > Does Emacs support Xwidgets (requires gtk3)? no > Does Emacs have threading support in lisp? yes > Does Emacs support the portable dumper? yes > Does Emacs support legacy unexec dumping? no > Which dumping strategy does Emacs use? pdumper
(In reply to simonfxr from comment #5) > It's not that I care, I just thought it might be useful to *someone*. So I'm > okay with not having the flag. I am closing this bug then. Thank you for reporting and for testing! > Is there any reason you dropped the libotf flag from the patch? AFAICT there > is no need to couple it to the m17nlib. Keeping it coupled means, there is > no way to disable m17n but link against libotf, since --without-libotf is > explicitly passed to configure. We had a separate libotf flag previously, but we dropped it in 2008: https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/?id=766c54898e1e49748b0160c9c1c0dc1f5d1f97e1 Note the ChangeLog message: 28 Feb 2008; Ulrich Mueller <ulm@gentoo.org> emacs-cvs-23.0.60-r2.ebuild: Drop libotf USE flag; Upstream says that libotf without m17n-flt is useless. This refers to the following message from the emacs-devel mailing list: https://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02770.html AFAICS, there is nothing in etc/NEWS* that would indicate that the above has changed. Therefore, I see no reason for adding that flag again.
