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.
