[haiku-development] Re: To __BEOS__ or not to __BEOS__?
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 08 May 2008 22:13:01 +0200
On 2008-05-08 at 19:58:45 [+0200], philippe.houdoin@xxxxxxx wrote:
> François said:
> > I thought we wanted to be source and binary compatible with BeOS
> > for R1...
>
> I thought the same too.
I could be mistaken, but I believe the idea was to be almost fully binary
compatible -- only drop stuff that doesn't make much sense for us (e.g. the
FS interface) -- and mostly source compatible -- break compatibility when
there is a good reason.
> > doing so before R1 would break source level compatibility, so I
> > would avoid doing that.
>
> +1
>
> Andreas Färber said:
> > We've already broken source compatibility by removing the libnetwork
> > symlinks then.
>
> Doesn't make breaking source compatibility before R1 more valid.
>
> While these symlinks are still there in /boot/beos/system/lib, for *binary*
> compatibility, one can't anymore recompile (well, link in fact) a working
> BeOS networking apps without modification.
> That's a weird and distasteful situation when a binary works without
> modification on our target but its source can't be recompile on it without
> some change, no!?
IMHO, no.
> Axel wrote:
> > I don't really see a point in staying 100% source compatible - the
> > changes Haiku requires are minimal at most.
>
> One could say the same apply for binary compatibility - most often the
> changes required to run on Haiku are minimal too.
>
> 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 works too.
AFAIC the absolutely *only* reason to be binary compatible is for old
applications that are not available in source form. Why else would we bother
with an ancient compiler that gives us all kinds of trouble?
> If a POSIX code workaround made for BeOS
> works on Haiku too, why should we force recompiling this code to fail by
> default?
The question should be asked the other way around: Why keep (and suffer from)
a BeOS work-around when it's not necessary on Haiku? And from what I've seen
so far a lot of BeOS work-arounds simply are not necessary anymore.
> By dropping source compatibility, we're forcing people to do those minimal
> changes, while they're not mandatory - binary compatibility being the proof.
> Aren't we too shy here, when Haiku ABI behave as BeOS, to *allow* compiler
> to say "Yes, I AM __BEOS__ (too)"?
The point is Haiku is already better than BeOS in many respects, particularly
when it comes to POSIX compliance. Both binary and source compatibility come
with a cost, which can be lessened by breaking them for certain details.
CU, Ingo
Other related posts:
