[haiku-development] Re: The technical implications of making GCC 4 Hybrid the default?
- From: pulkomandy <pulkomandy@xxxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 21 Nov 2010 11:40:58 +0100
On Sat, Nov 20, 2010 at 11:49:21PM +0000, Matt Madia wrote:
> I'm curious what the technical (dis)advantages would be of switching
> official releases to be GCC 4 Hybrids, and more importantly if it
> would be feasible.
There's nothing technical that can't be solved. The replicant issue is
the biggest one and would need heavy amounts of hacking, however.
The issue is more about introducing a lot of different APIs. For
example, every new version of the Linux kernel seems to break source
compatibility with every driver developped for it. This forces people to
keep an eye on the latest version of Linux to keep their driver and
kernel modules working, and creates a bias towards open-sourced ones,
which are fixed faster.
Haiku tries to create a more fair software ecosystem, where
closed-source apps and driver are allowed to exist in a sane way. The
idea is to have one and only one API for each release, in order to not
add too much compatibility layers.
If we do a gcc4-R1 version, people will just start to use gcc4 compiler
for their apps. It will look like it works well, but when R2 gets
released, their apps will not run on it and they will need significant
changes to their sourcecode to get it on par with the new GCC4 API.
The changes planned for the R2 API are not small ones. Some classes will
be completely rewritten (BTabView and BOutlineListView come to mind, but
there are others); other classes may keep source compatibility but some
'future extension padding' with reserved slots or just new methods will
break binary compatibility for each of them.
In R2, we plan to have two sets of APIs :
* An R1 compatible set, based on gcc2 ;
* A new, shiny, R2 one, with all the new features and running GCC4 (or
maybe it will be llvm/clang)
The R1-compatible one will allow any software released for R1 or for
older BeOS versions to be run directly. The R2-API will be available for
people willing to update their software and get the new features.
The R1-gcc4 ABI, which is an intermediate step between these, is
considered experimental. It is provided as a way for developpers to :
* Try some of the new features (WebView from webkit)
* Prepare their apps for running under gcc4, and spot more warnings in
their code.
As a 3rd-party developper, using gcc4, you _know_ your app will not run
in R2. It may be a risk some people will want to take, knowing they will
update their software for R2. But for commercial apps, this means their
software is unuseable (and unsellable) from the day R2 is released until
they release an update of their application. If they use gcc2, the
transition is done smoothly and they can take all the time they want to
make a new version of the app, using R2 features.
So, it should be possible to do everything with the gcc2 API. This
includes creating replicants, tracker add-ons, and similar stuff. This
is why we can't compile the whole system using gcc4, as it would simply
prevent people from using the official developper kit for some things.
And, these things are the most interesting ones in Haiku : add-ons and
replicants. They both allow to expand the system functionalities in a
way that no other OS provides.
Also note we may be going 64-bit in R2. In this case, we'll have a gcc2
32 bit API and a gcc4 64 bit one. This way, we have only two APIs to
handle. And going R3, we will remove the gcc2 one and the previous
gcc4-R2 API will become the 'legacy' one, while an even newer version
will be introduced. Keeping only 2 APIs means less work for the devs,
and less headache for the users (which are already mixing things up).
Switching to gcc4 now would then be a short-term solution, but bring
more problems in the future.
--
Adrien.
Other related posts:
