bug#34849: Compilation issues with g++ on some files

[Eli Zaretskii]

> Cc: agrambot@gmail.com, 34849@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 19 Mar 2019 19:12:24 -0700
> 
> Especially since there is a disciplined way of using the code that (at least 
> for 
> Alex's need) appears to work well enough; see:
> 
> https://lists.gnu.org/r/bug-gnulib/2019-03/msg00064.html

If this takes care of Alex's needs, it's fine with me.  But it isn't
always so, see, for example this:

  https://www.sourceware.org/ml/gdb-patches/2019-03/msg00143.html

where the GDB folks intend to solve this differently:

  https://www.sourceware.org/ml/gdb-patches/2019-03/msg00163.html

> > 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)
> 
> Sure, but as you mentioned HarfBuzz has a C API

That's just sheer luck, and is not indicative of other toolkits.  Qt
is a counter example of a widely used toolkit that AFAIK doesn't have
a C glue.

> In my experiences toolkits with a C++ API but without a C API tend
> to be less flexible and more of a hassle for C code to interface to,
> and it's not clear we should spend much time catering to them.

We are in the same situation with GTK (though not because of C++), and
experience teaches us that there's nothing we can do when upstream
developers decide to change their APIs in ways that adversely affect
us.

My point is that long-term Emacs survival strategy should favor
changes that make it easier to build with external toolkits.  E.g.,
even HarfBuzz needed non-trivial changes in how we handle character
composition.  Of course, such efforts might be infeasible, so there's
a judgment call that needs to be involved.  What I'm saying is that we
should favor such changes, unless they are prohibitively expensive,
not reject them unless they have negligible costs.  Gnulib's
perspective on this is different, and therefore what Gnulib decides is
not necessarily good policy for us.