(gcc 2.95 support) kdeextragear-1/amarok/src

[Gary L. Greene Jr.]

On Thursday 10 March 2005 2:16 pm, Leo Savernik wrote:
> Am Donnerstag, 10. März 2005 19:43 schrieb Thiago Macieira:
> > Adriaan de Groot wrote:
> > >> How much longer do we have to support gcc 2.95 for? I must say I have
> > >> a great deal of distaste that we must make our code more ugly for the
> > >> sake of an old compiler. I do understand that people want to continue
> > >> to use it, but I just wonder how much longer they will do so. Thanks,
> >
> > At least for all 3.x releases, since we promised to.
> >
> > For KDE 4, I'd like to see that revised. gcc 2.95 will be 6 years old by
> > then. I say we move gcc 2.95 support from "required" to "would be nice".
>
> Which effectively means it support becomes terminally broken.
>
> [...]
>
> > >RELENG_4_11  4.11-RELEASE  Extended  January 25, 2005  January 31, 2007
>
> [...]
>
> > Also, take a look at the emails sent just after 3.3.0 was released. We
> > had a bug/crash in our code that was caused by a miscompilation. The gcc
> > developers won't fix it.
>
> As a software writer you can't count on compiler vendors fixing their bugs.
> It's easier and more effective to work around them.
>
> > So, why are we supporting a broken compiler that won't be fixed? I'm not
> > talking about missing features...
>
> Broad portability means broad support of compilers. Hence, making use of
> the latest and greatest C++-standard features will reduce portability for
> KDE.
>
> > >Oh, if you're moaning about having to support gcc 2.95, be glad that KDE
> > >doesn't officially support any of the other C++ compilers out there,
> > > which are even more picky.
> >
> > I'd like to see some more strictness added to our code, yes. Every time a
> > new gcc version is released, we have to do that anyways.
>
> I support that, too. But just as we banned C99 code for KDE development
> because of portability reasons, we should also similarly restrict the use
> of very advanced C++-standard functionality, especially when it can be
> worked around easily.
>
> mfg
> 	Leo

I'm in defense of Thiago here. Working around an absolutely ancient and broken 
compiler isn't high on my list of things to do for development. Additionally, 
not using the more advance C++ _standard_ functionality, is hampering 
development at times. While we committed to having 2.95 as a base-line for 
the 3.x series, I cast my vote for a later 3.x series compiler for KDE 4. 
Especially since the goal of 4 is in many ways a code clean up as we port for 
Qt 4.

-- 
Gary L. Greene, Jr.
Sent from uriel
 14:24:35 up 4 days,  1:34,  7 users,  load average: 1.74, 1.91, 1.65
 
============================================================
Developer and Project Lead for the PhoeNUX OS.
 check out http://www.phoenuxos.com/ for more info.
EMAIL : greeneg at arklinux.com
============================================================
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050310/969e8b4f/attachment.sig>