FreeLists / openbeos / [openbeos] Re: I know I'll get flamed for this but....

[Erik Jakowatz <erik@xxxxxxxxxxxxxx>]

I know there's mail I haven't seen, so apologies in advance if I'm
saying something that's already been said.

I think I just figured out the misperception that's behind all the fuss
about BC and breaking it, so let me throw a couple of thoughts out that
may clear the air.

First, our goal -- as we all know -- is to maintain BC for R1.  If,
during the development of R1, we find we are unable to meet that goal,
then we will have a big debate on how bad the breaking situation is.  If
it's bad enough, that might be the time to go directly to GCC3.x.  An
example of this would be some horrible BC break in libbe.so which is
going to affect a large number of apps.  If the break isn't too bad, we
may just forge ahead, knowing that some apps will be broken.  I would
think the list would become quite an exciting place should any kind of
break be necessary. =)

Second, folks are running under the assumption that if we maintain BC
now, we either

* never break BC moving forward, thereby denying ourselves GCC3.x and
all sorts of expansion opportunities or
* at some point in the future have some system-wide BC break in which
the whole apple cart gets turned over.

This is a rather black and white set of scenarios.  There *is* a middle
ground.  Let us assume OBOS successfully maintains BC for R1.  Heading
into R2 work, we decide that we'd really like to move to GCC3.x, or add
BC-breaking extensions to the API, or both.  Rather than just rebuild
the entire system with broken BC, we can simply version the libs.  Using
libbe.so as our example, the original BC version would simply be called
libbe.so.  The new, BC-breaking version might be called libbe.r2.so. 
Those apps which want to move to GCC3.x and/or use any new features can
simply change which lib they link to.  Very simple, low hassle, no
trauma.  We don't jump from one binary standard to another, we
*migrate*.  When a sufficient amount of time has passed, the original
libbe.so can go the way of the Dodo.  Doesn't have to, but can.

Something else I'd like to point out for those who are concerned about
missing out on the performance improvements that GCC3.x offers, there's
absolutely no reason that certain portions of the OS can't be built
using it *right now*.  app_server, for instance, is basically
free-standing in the binary sense; I don't think anything is linking
against is (not C++ linkage, anyway).  All use of the server happens via
messages, which don't give a fig about what binary standard is being
used.  So app_server could potentially get built with GCC3.x for R1.  As
Michael has mentioned, this may be possible for the kernel as well,
since -- unless I am horribly uninformed -- the C ABI is not changed in
GCC3.x.  Mind you, I'm not saying any of this *will* happen, just that
it is possible.

So, you see, there is *no* BC crisis.  We will have to exercise care
when we migrate, but not any more than we must to achieve BC in R1.

Hopefully, I haven't had some intellectual misfire here and we can just
leave this issue alone for now.  I'm sure folks won't hesitate to feed
me my hat if I've missed the boat. =)

e

PS: For those who are inclined to moan about "all those libs on my
system!", I can only say that if you can't manage the space for the
system libs to be duplicated, you either need to get a bigger drive or
get rid of some pr0n. ;)

Helmar Rudolph wrote:
> 
> > that is, we all know that if, down the road, the project
> > hits the wall and finds BC simply unattainable, it'll be
> > dropped.
> 
> At the risk of stirring a hornest's nest, I would like you
> all to think about one particular but not insignificant
> aspect: do you think it makes more sense to break BC when
> there is low or no momentum or if there is a renaissance in
> BeOS development, including commercial-grade projects? Or do
> you think it doesn't matter?
> 
> My take is that BC should be broken with the least amount of
> hassle and upset, and that is when things are slow and low,
> which is right now. I don't think developers, who have
> joined the OpenBeOS R1 / BeOS R6 bandwagon, will appreciate
> if -say- 12 months down the line into their projects, you or
> anyone hits the wall and it's decided BC will be broken.
> 
> Wouldn't it make much more sense to break it now, with
> perhaps 150-190 active projects (extrapolated from the
> BeUnited Developer Survey) than later, when you perhaps have
> 400-600 active projects, among them - and that at least is
> our goal - commercial grade software? These, I guess, would
> at least require a roadmap so that they can plan (whatever
> that means) for the break in BC, because the last thing they
> would want to see is a sudden "hitting of the wall".
> 
> Or is it really only a matter of recompiling the app, IOW am
> I overcomplicating the breaking of BC?
> 
> Would love your input on this,
> 
> Helmar