GNU bug report logs - #34849
Compilation issues with g++ on some files

Previous Next

Package: emacs;

Reported by: Alex <agrambot <at> gmail.com>

Date: Wed, 13 Mar 2019 21:13:01 UTC

Severity: wishlist

Tags: wontfix

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: eggert <at> cs.ucla.edu, 34849 <at> debbugs.gnu.org, agrambot <at> gmail.com
Subject: bug#34849: Compilation issues with g++ on some files
Date: Tue, 19 Mar 2019 09:33:02 +0200
> From: Richard Stallman <rms <at> gnu.org>
> Date: Mon, 18 Mar 2019 22:24:18 -0400
> Cc: eggert <at> cs.ucla.edu, 34849 <at> debbugs.gnu.org
> 
> 1. I don't want C++ code in the Emacs distribution.  This isn't the sort
> of crucial thing that would override that general policy.

I believe the intent was to make the existing code be compilable with
a C++ compiler without introducing any C++ code per se.

My POV on this is that we should make Emacs buildable with as many
modern GUI toolkits as practically possible/reasonable, because it is
not clear which one(s) of them will remain workable and maintained in
the long run.  And since many/most of the toolkits and packages we'd
like to use or be compatible with are written in C++ (HarfBuzz is a
good recent example), we should try making our sources be more
friendly to C++ compilers, as much as possible, because not every such
package has a C glue, like HarfBuzz does.

Therefore, if integration with Qt is reasonably possible, we should
not reject it outright.  I understand the concerns regarding the
license, but we will need to revisit that when GPL's version is
advanced, and not sooner.  Disabling support for a package that no
longer satisfies our requirements is relatively easy.




This bug report was last modified 6 years and 63 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.