bug#51658: [PATCH] Haiku port (again)

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 51658@debbugs.gnu.org
> Date: Wed, 10 Nov 2021 08:00:25 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thanks.
> >
> > It's a large patch, so let's start with the general, a.k.a. "big"
> > aspects.
> >
> > First, do we really need to use *.cc files and compile with a C++
> > compiler?  Is that a necessity?  AFAICT, the code in those *.cc files
> > is plain C, so why not use a C compiler, as we do on every other
> > platform?
> 
> That isn't C code.  The code in the .cc code is written in C++, in order
> to use the Haiku GUI libraries which require C++.

Too bad.  IMNSHO, that's a ticking time bomb, and it will certainly
bite us at some point, since mixing C and C++ is tricky and requires a
lot of diligence.  It also means that you will probably be unable to
use any compiler but GCC (or whatever is currently supported by
Haiku), since different C++ compilers are generally
binary-incompatible.

> > Next, the font backend stuff: do we really need 5 (five) backends?
> > How about having just one: HarfBuzz+Cairo?  That's the direction we go
> > on other platforms, so how about making the Haiku code smaller and
> > simpler and support just that single backend, and drop all the older
> > ones?  I'd definitely won't want to drag the unmaintained libm17n-flt
> > into this port.
> 
> I'm fine with removing the ftbe backend, but I would prefer to keep the
> haikufont backend working.  The reason is that Haiku users might not
> have Cairo installed, and it likes to break every now and then, as it's
> not considered important for that platform.

Since you later say Cairo is unreliable, why not drop Cairo?

And that still leaves us with 3 backends, IIUC.  Why not just one?

Let me clarify why I insist on those issues: this port's usability
will depend crucially on its support by the developers who are
interested in Haiku, and that's for now just you.  Any decrease in the
level of support will most probably mean the port will bitrot and die,
given the fast pace of Emacs development.  So every feature that
doesn't absolutely have to be there is better removed, because having
too many supported configurations makes the code difficult to
understand and test, and thus fewer people will be able to support it.
Please keep this in mind when you insist on optional non-essential
features.  From experience, a port or a feature that is not supported
well enough bitrots very quickly around here.

So my suggestion is to choose wisely which features you really need to
keep.