[haiku-development] Re: GCC 2 x GCC 4.

  • From: Bruno Albuquerque <bga@xxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 13 Aug 2008 11:28:55 -0300

Axel Dörfler wrote:

I don't think this is a good idea.

Who cares? ;)

By keeping the emphasis on GCC2 for Haiku R1 we can do a clean break with R2 - that means full backwards compatibility, and still have all the great API changes for GCC 4 compiled apps.

I am not so sure doing 2 major changes at the same time is wise. Of course it would be better in the sense that we wouldn't have 2 breakages (although being open-source now makes binary compatibility not much of a problem as it was with BeOS) but then it would complicate figuring out what changes actually broke something, for example.

If we switched to GCC4 now, we would just break compatibility for no better reason than the choice of the default compiler.

That's the point, we do *NOT* break compatibility. We still provide GCC 2 libraries and maybe even GCC 2 toolchain as an option. And we gain more time to test the GCC version for real and when we are convinced that it works, we can do the API breakage.

Projects that really need it can use it, but they know that their software will no longer run without a recompilation on future Haiku releases.

This is true for any software that use our C++ API as we will break compatibility anyway. So this is a moot point.

IOW as long as no one forces you to use GCC4, you should use GCC2 for now.

Even using GCC 2 will result in having to recompile at some point. Maybe even twice if we do the transition in 2 steps (as I think we should have). The advantage of what I proposed now is that we can do the first step (switching to GCC 4) without compromissing the R5 binary compatibility goal.

Of course, this is pretty much independent from having Haiku compiled with GCC4, but since it's much better tested with GCC2, and our GCC4 version is not really up-to-date, but has some known problems, as well as some pending bugs (like the Radeon driver Rene mentioned), I don't see good reason to do so shortly before a release.

That's true. The disavantage of doing what I propose is exactly what you described above. The advantage is a smoother transition.

-Bruno


Other related posts: