[haiku-development] Re: To __BEOS__ or not to __BEOS__?

"Ryan Leavengood" <leavengood@xxxxxxxxx> wrote:
> > So for R1, GCC4 should be a possibility (as Michael demonstrated), 
> > but
> > it shouldn't be the default; it should only be used for stuff that
> > really needs it.
> Anything modern will more than likely need a newer GCC.

Maybe - but only *ported* things, anyway.

> > Otherwise, we'll break binary compatibility, and that's just a bad 
> > idea
> > for any OS that already has an existing software base.
> I did suggest a GCC2 compatibility layer which would allow most basic
> applications to run. Things that would probably not work with this
> scheme is add-ons and probably drivers.

It's not the GCC2 layer I'm talking about - this is something we need 
anyway.

> > Making the real switch with R2 will allow us to provide a clean 
> > upgrade path
> > without much worries for the end user;
> Maybe. I am not sure why breaking binary compatibility in a year or
> two would make things much better and smoother than doing it sooner.

Because we mostly won't break it for the average user.

> > in fact, only those apps that will use GCC4 now will be broken for 
> > sure.
> So the newer apps developed specifically for Haiku (my WebKit port 
> and
> browser, the latest Bezilla code) that need GCC4 will be crippled but
> old and crusty abandonware from 1998 (TEN YEARS AGO) will work fine?

Not just ten year old stuff will work, but anything developed for BeOS 
*and* Haiku. There is usually no need to use GCC4 for native apps 
unless you really want to.

> For me that seems silly. Though for the sake of avoiding feature-
> creep
> and getting R1 out the door maybe that is the best idea. But
> considering all this it seems as if R1 will be mostly a tech-demo and
> not actually a system people can use. If that is the goal, great, but
> that has not been my impression. I cannot use a system without a
> modern web browser (I do not think I am alone on this), and for that
> we need GCC4, hence my being adamant about this. I really don't want
> Haiku to be seen as a toy OS from its first release.

I don't really see the connection to GCC2 and a toy OS.
It's much easier to update the five apps that were compiled with GCC4 
(and will likely be part of the distribution) manually, then to throw 
away your whole fine tuned and customized system.
People should know and take into account that everything they build 
using GCC4 will break in a future release, while GCC2 stuff won't.

The only way to make this better would be to have a centralized 
software repository similar to Ubuntu - then, at least if you only use 
stuff from there, we could break compatibility without having to worry 
too much. And still I was more than just a bit annoyed that many things 
I installed afterwards didn't work anymore for me after an update of 
Ubuntu.

Furthermore, Haiku won't be an "all sources available" system. And I 
don't see us creating and maintaining large software repositories 
either in the next few years. That's why we have to take special care 
about maintaining binary compatibility.
The switch to GCC4 is a good chance to get rid of all the legacy that 
we carry around, and also allows us to clean up any API we don't like. 
As Ingo pointed out, the runtime loader can easily differentiate 
between GCC2 and GCC4 binaries - that's like the perfect solution for a 
clean and seamless switch, and I really wouldn't like to throw that 
away just for having GCC4 now.

Plus, everything that is separate (like servers) or has C linkage only 
(like the kernel), should work fine when compiled with GCC4. So if we 
create our distribution, we could even switch to GCC4 for selected 
components if it turns out to be noticeably faster (and we are okay 
with the added overhead for maintaining the distribution).

Bye,
   Axel.


Other related posts: