[haiku-development] Re: Coordinating porting efforts
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 08 Feb 2008 16:58:19 +0100 CET
Andreas Färber <andreas.faerber@xxxxxx> wrote:
> Of course there can be exceptions to this, where a project doesn't
> stick to such best practice rules, but I'm pretty sure most "high
> quality" projects don't want to have new #defines introduced for
> Haiku
> with no evident benefit.
Sure, but for example networking code heavily needed customizations for
BeOS - this will no longer be the case for Haiku; in that case it's
better to specifically check for BeOS, or against Haiku.
> The only tricky thing I've encountered was in apr(-util?) where BEOS
> was used to conditionally define a prototype for strerror_r because
> it
> was implemented in libroot but not present in their headers. There
> I'll have to look into a new define, but I don't see the point in
> replacing BEOS with BEOS || HAIKU, it's much easier to define both
> and
> only use #if defined(BEOS) && !defined(HAIKU) or similar only where
> needed.
Yes, and Haiku's GCC still defines both __BEOS__, and __HAIKU__ for
that reason.
> We can still do a full code review once we have the self-hosting set
> of tools working on Haiku.
If we don't actually port the tools, we could also just use BeOS
binaries, though :-)
Bye,
Axel.
Other related posts:
