[haiku-development] Re: UI discussion (was "WebPositive misleading tool tip on new tab")
- From: pulkomandy@xxxxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 27 Feb 2013 20:34:02 +0100
On 2013-02-27 at 19:12:53 [+0100], Justin Stressman <jstressman@xxxxxxxxx>
wrote:
> On Wed, Feb 27, 2013 at 5:00 PM, <pulkomandy@xxxxxxxxxxxxx> wrote:
> > We worked around that in most cases. The official build is a gcc2 hybrid,
> > so
> > it also bundles a gcc4 compiler with libraries. The Mesa we bundle for
> > gcc4
> > is up to date, and if you build an app using gcc4, it will work.
>
> But that only applies to the gcc4 build, right? Not the gcc2 or even
> gcc2h builds?
No, if you build your app using gcc4 on a gcc2-hybrid it will use the new
Mesa. We do the same for Web+ (WebKit is gcc4 only) and we could do it for
more apps. It does not add a significant amount of work to either do that, or
make sure the code works with gcc2. Using both compilers also sometimes helps
detecting more bugs in the code because they do things a bit differently.
While the C part of gcc2 is quite annoying to work with (it lacks most of
C99), the C++ part is fairly ok, until you try to use too much templates.
Since most of Haiku is written in C++, we don't have that many problems with
it. And since 3rd-party apps can use gcc4 when needed, there's no locking
problem here, only a small amount of extra work that will not be lost anyway,
see below.
> I guess my point was that while I know we can use such workarounds,
> they are extra hassle. If/when we can ditch gcc 2.x, it completely
> removes the need for all these distinctions and hybrids and juggling
> etc.
>
> Even if R2 did retain backward compatibility as a gcc4h build as the
> official one, it would be secondary, not the primary concern as it is
> now.
>
The idea is that the gcc2 API is the one we retain compatibility with. For
R2, we will switch to gcc4h and start modifying the gcc4 part to include new
features and likely break compatibility in some places. Applications built
with gcc4 on R1 will not work on R2, but applications built with gcc2 will.
This provides a smooth migration path from R1 to R2. Devs can then update
their apps to the R2 API, and we will provide a similar migration path for
them towards R3, and so on.
This means we will always be running in a kind of hybrid environment, where
the 'previous' and 'current' APIs will each be sandboxed in its own world.
Starting with gcc2/4 now allows us to spot most of the issues with doing that
and think about the solutions. 3rd-party developers should also learn how to
package their apps properly, because that knowledge will be useful for future
versions of Haiku as well. We may also have similar situations with x86 32/64
bit hybrids, and maybe some other processors in the future.
--
Adrien.
Other related posts:
