mmadia ([info]mmadia) wrote in [info]bezilla,
@ 2008-04-01 20:00:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Haiku support ...
Even though Haiku is for the most part source and binary compatible with R5,
there are some issues.
Most notably, configure scripts break due to different values for `uname`
In particular, `uname -s` reports "Haiku" and "BeOS" respectively.


Currently mozilla's build system performs conditional testing on $(OS_ARCH), which is equal to `uname -s`

It's possible to pass --host=i586-beos or a similar line to configure to use the BeOS definitions, but this isn't an ideal solution.
Numerous beos-workarounds will no longer be needed.
For example, Haiku has better posix support.

For reference, the other beos-specific build system variables are:
BEOS_PROGRAM_RESOURCE :: for applying the .rsrc file,
defined in (application)/app/Makefile.in
used in http://mxr.mozilla.org/mozilla1.8/source/config/rules.mk#831
BEOS_ADDON_WORKAROUND :: for creating *.so.stub,
defined in http://mxr.mozilla.org/mozilla1.8/source/config/config.mk#114
used in http://mxr.mozilla.org/mozilla1.8/source/config/rules.mk#671 and #681

So how are we going to implement Haiku support?

(Post a new comment)

native support!
[info]umccullough
2008-04-02 05:07 pm UTC (link)
In my ever so humble opinion as an outsider looking in - I would definitely recommend adding Haiku as an additional platform logically independent of BeOS.

Eventually Firefox is going to drop BeOS support (it's inevitable) - and Haiku support will remain. Might as well start planning for that event.

I suggest the approach that Haiku devs are taking - freshly porting of software to Haiku while adding as much POSIX support needed to get there as they go.

Obviously there will be some code that comes directly over from the BeOS port - because it contains all the native bindings - but all BeOS-specific logic should eventually be evaluated and cleaned up for Haiku again I would think.

(Reply to this) (Thread)
Re: native support!
[info]mmadia
2008-04-02 11:42 pm UTC (link)
I'm not exactly sure what the other devs have in mind, but imo i see 3 stages..

First adding OS_ARCH recoginition to configure and related makefiles.
This will enable Haiku to be an actual build target.
At this stage, the current BeOS definitions and C/C++ code are used
eg, ifeq (Haiku, $(OS_ARCH)) and AC_DEFINE(XP_BEOS)

Next, configure+makefiles are updated to create Haiku definitions.
These C/C++ definitions are evaluated on the same line as BeOS.
In otherwords, at this point Haiku and BeOS are still using the same C/C++ code
eg, AC_DEFINE(XP_HAIKU) and #ifdef XP_BEOS or XP_HAKIU

Finally, the C/C++ definitions for XP_HAIKU and XP_BEOS are evaluated seperately.
( though i'm not sure if all evaluations need to be seperated )
This would allow Haiku to fork from BeOS.

Thing is, I'm only familiar with the workings of the build system and my C/C++ ability is sub-par at best :)
So I'm not even certain if this is correct at all.

(Reply to this) (Parent)

[info]nielx
2008-04-06 05:06 pm UTC (link)
Well,

I'd suggest the following route. I would slowly start by porting the packages Firefox 3 depends on. Then I would start porting Firefox 3 to Haiku - and clean out the BeOS cruft.

To start that process, I know someone is already working on porting git (which is used by cairo). Git, as you might know, is a decentralised revision control system. I will try to set up a shared repository in which we could share patches for Cairo.

I will keep this blog posted.

N.

(Reply to this) (Thread)
Git... huh...
[info]umccullough
2008-04-08 02:58 am UTC (link)
Funny, I was just looking at what it might take to port Git over the weekend :)

Glad to hear someone else is already working on it, I am extremely unqualified ;)

(Reply to this) (Parent)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…