Howdy,Is source compatibility with BeOS still as important now as it may have when the decision was made seven years ago, and therefore worth maintaining it and the baggage (cruft?) that it entails?
Cheers, Koki 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.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 libnetworksymlinks 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.