emacs-devel
[Top][All Lists]
Advanced

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

Re: Haiku port


From: Eli Zaretskii
Subject: Re: Haiku port
Date: Thu, 26 Aug 2021 15:40:42 +0300

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 26 Aug 2021 17:50:06 +0800
> 
> > What kind of documentation are we talking about here?  Is that
> > user-level documentation, such as some Haiku-specific settings?  If
> > so, a Haiku-specific Appendix, like we already have for some other
> > systems, would be a good place.
> 
> There are currently no user-specific settings, but I was referring to
> the general changes with a new terminal driver.

I don't think we document the terminal drivers, but if you see such
documentation for other terminal types, please point to it: I might be
misunderstanding what you have in mind.

> >> I also think the BFont font driver needs work -- it has artifacting with
> >> RTL text and when drawing condensed characters, but font rendering is
> >> quite certainly outside my field of expertise, and I would appreciate
> >> help from an expert.  (Though, ideally, we would have a FreeType-based
> >> font driver, but I think FreeType is not easily usable within Haiku
> >> applications).
> 
> > Can't you just use HarfBuzz?  Can HarfBuzz be built for Haiku?  We
> > generally are migrating to HarfBuzz as our main text-shaping engine,
> > so it would be good if Haiku supported that as well.
> 
> A port of fthbfont would be well appreciated, but that's beyond my
> abilities at present.  Help welcome :)

Is haikufont so different from the other font infrastructures that you
couldn't do it?  Supporting HarfBuzz usually needs just a small number
of functions, as the basics are already in hbfont.c.

Or maybe you have specific questions about this, in which case please
ask them.

> > I don't see your assignment on file, but maybe I'm not using the same
> > name and email address you used then?
> 
> I think it's the same mail.  Anyhow no worries, I'd be happy to sign
> again.

Form sent off-list, thanks.

> >> -    if test $opsys = mingw32; then
> >> +    if test $opsys = mingw32 || test $opsys = haiku; then
> >>        CFLAGS="$CFLAGS -gdwarf-2"
> 
> > Why did you need this?  Isn't DWARF debug info the default on Haiku?
> > And if it isn't the default, do all the compilers you want to be able
> > to use support the -gdwarf-2 switch?
> 
> Haiku's outdated version of the GNU Debugger only supports dwarf-2 debug
> information, and not the default dwarf-4 format their version of GCC
> builds programs with.

OK, but then please add a comment there with this information, so this
isn't forgotten if and when we change what we do for w32.

> As for compilers, I think only GCC is currently
> supported on Haiku.

Hmm... then why do you tell configure to look for others?  Here:

> >> +if test "${opsys}" = "haiku" && test "${with_be_app}" = "yes"; then
> >> +   AC_PROG_CXX([gcc cl KCC CC cxx cc++ xlC aCC c++ g++])

AFAIU, cl, KCC, xlC, and aCC aren't GCC, right?

> > This seems to say you want to compile Emacs as a C++ program.  Does
> > that really work?  We don't require our C code to be C++-compatible.
> 
> It does.  The C++ code is entirely specific to Haiku windowing and is
> exposed to the rest of Emacs through extern "C" subroutines.

I was talking about C source files and headers not specific to Haiku:
those don't have 'extern "C"' guards anywhere.  They could fail to
compile with a C++ compiler.

> >> +The configuration process should automatically detect and build for Haiku.
> >> +There is also an optional window-system port to Haiku, which can be 
> >> enabled
> >> +by configuring Emacs with the option '--with-be-app', which will require
> >> +the Haiku Application Kit development headers and a C++ compiler to be 
> >> present
> >> +on your system.
> 
> > Can you please make this description more detailed wrt the difference
> > between using '--with-be-app' and not using it?  How will the built
> > Emacs be different in these two cases?
> 
> Should I add something to the likes of "Without --with-be-app, Emacs
> will not have any code specific to Haiku windowing." to the NEWS entry?

Hmm... maybe.  But then I guess I'm confused: what does the automatic
detection of Haiku do, if one needs --with-be-app to have the
windowing code?  IOW, why don't you assume --with-be-app if the
automatic detection of Haiku succeeds?

> >> +(unless (featurep 'haiku)
> >> +  (error "%s: Loading ext-win without having Haiku"
> >> +         invocation-name))
> >
> > Is this error really needed?
> 
> It seems to be present in the rest of the FOO-win backends.

Not all of them.

> I have attached a patch with some of the mistakes rectified, and will
> rectify the rest ASAP.

Thanks.  I'll let others chime in if they want, and then we must wait
for your legal paperwork to complete.



reply via email to

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