[haiku-development] Re: To __BEOS__ or not to __BEOS__?
- From: <philippe.houdoin@xxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 8 May 2008 19:58:45 +0200
François said:
> I thought we wanted to be source and binary compatible with BeOS
> for R1...
I thought the same too.
> 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!?
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. If a POSIX code workaround made for BeOS works on Haiku
too, why should we force recompiling this code to fail by default?
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)"?
Until we drop BeOS binary compatibility, I suggest we keep __BEOS__ and
__HAIKU__ both builtin defined.
Philippe.
Other related posts:
