[haiku-development] Re: To __BEOS__ or not to __BEOS__?
- From: Stephan Assmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 08 May 2008 23:00:06 +0200
Ingo Weinhold wrote:
>
> 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.
I second Ingo's sentiment here, because to be honest, I'd rather have a
clean upgrade path to follow. I'd rather not have all sorts of hidden
details that influence the binary compilation. Oh, I linked against the
wrong stuff and that "secretly" triggers R5 network mode? That's just
messy. I would like a clean upgrade path for moving software to Haiku.
IMHO, even the reasons pro binary compatibility are by now a bit weak
already, although for the moment, there are a few reasons left:
* We commited to doing it and it provokes respect for being able to pull it
off.
* There is still some closed source software that people might want to keep
using. (Anything besides Gobe actually?)
* There are people compiling on ZETA or R5 yet, and it may be uncomfortable
for them to have to switch to GCC4.
* Haiku itself is a moving target as the recent breakage of the Vision
binary demonstrated, so we might not even want to have that much native
Haiku software around just yet.
But for source compatibility, I don't see the good reasons other than
"undeserved" comfort. If you don't plan on doing any changes when compiling
a program for Haiku, then you might as well keep using the BeOS binary. For
native software it shouldn't matter much anyways, since it mostly means
linking to the correct network libs. And for ports, others already
explained that it may be very beneficial to review every occurance of
#ifdef __BEOS__ anyways, and those should be easy to spot with your favored
text search. :-)
Best regards,
-Stephan
Other related posts:
