discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Objective-C bugs and GCC releases


From: Adrian Robert
Subject: Re: Objective-C bugs and GCC releases
Date: Tue, 25 Jan 2005 06:14:03 -0800 (PST)

> In fairness, the Steering Committe did however make a conscious
> decision not to designate Objective-C a release-critical language.
> That is because there are more features in GCC (support for
> languages, chips, optimizations, etc.)  than there are people to
> maintain them all -- especially to keep them all working all the
> time in all possible cross products.

Thank you for taking the time to clarify the situation.  But..

Regardless of how you sugar-coat it, designating a language as not
release critical means in practice you can't rely on GCC going
forward for that language.  And when there are manpower shortages,
the situation is not likely to improve -- rather, the gaps that need
to be filled for support to return will increase.  The direction
things are going for GCC is to try to make it a cutting edge C/C++
compiler as you say.  But is closing that 10% or 20% gap separating
GCC from the IBM and Intel compilers really worth jettisoning entire
languages along the way?  Could there be a middle ground to holding
up releases for too long waiting for non-market-majority development
(a practice which led to the splintering of egcs in the past) on one
side and gradually but surely becoming a specialist C/C++ solution
on the other?

It might seem like that's the middle ground the SC is trying to
steer with designation of "release critical" and non-critical
languages, but I wonder if there's a better way to do it.

What about splitting gcc into two branches, a "high performance"
branch, where heavy optimization takes place, and a "completeness"
branch, where the priority is on platform and language support.
Releases come off both branches: C, C++, maybe Fortran support on
the performance branch, and all languages on the other.
Periodically, both branches are merged together for a unified
release:

   /___/      _/__
  /     \    /    \
_/       \__/      \__ ...
 \       /  \      /   ...
  \     /    \    /
   -\---      -\--
     \          \

Well, I don't know, maybe this wouldn't work in practice.. sometimes
it's only by considering the alternatives that one can become
reconciled to a situation.. ;-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]