[haiku-development] Re: To __BEOS__ or not to __BEOS__?
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 08 May 2008 23:22:48 +0200 CEST
<philippe.houdoin@xxxxxxx> wrote:
> As I said above, I fail to see the point of having binary
> compatibility for R1 if
> we don't have source compatibility too: if Haiku R1 is able to *run*
> a binary as if
> it was running on BeOS, one will expect recompiling the binary source
> will work
> too. If a POSIX code workaround made for BeOS works on Haiku too, why
> should
> we force recompiling this code to fail by default?
That makes no sense to me.
1) There is almost no work to make native apps compile - in that
regard, Haiku is not more different than different BeOS versions.
2) Unmaintained apps, and all those binaries available out there
(that's what people use, we don't download the sources and build
everything ourselves) work on Haiku.
3) Maintained apps can make the small changes with no real effort
4) __BEOS__ only matter foreign ported apps. The old versions for BeOS
still work, so there is no need to recompile them at all. Since Haiku
is, as Ingo mentioned, much more POSIX compatible, it *simplifies*
porting apps to Haiku properly by removing __BEOS__
"Ryan Leavengood" <leavengood@xxxxxxxxx> wrote:
> In my opinion we should simply maintain a compatibility layer for
> older applications in the form of special code in the runtime_loader
> and some GCC2 libraries (libroot.so, libbe.so, etc.)
>
> Otherwise I think we should move forward in the following ways:
>
> - GCC4+ should become the default compiler (and problems related to
> this fixed, as Michael has been investigating.)
That's R2 stuff. If only for the reason that we will want to change the
API in several ways for GCC 4.
So for R1, GCC4 should be a possibility (as Michael demonstrated), but
it shouldn't be the default; it should only be used for stuff that
really needs it.
Otherwise, we'll break binary compatibility, and that's just a bad idea
for any OS that already has an existing software base. Making the real
switch with R2 will allow us to provide a clean upgrade path without
much worries for the end user; in fact, only those apps that will use
GCC4 now will be broken for sure.
Bye,
Axel.
Other related posts:
