which compilers do we want to support with KDE 4 ?

[Kurt Pfeifle]

On Saturday 21 January 2006 10:32, Alexander Neundorf wrote:

> Do we want to support gcc < 3.4 for KDE 4 ?

I think: no!
(KDE 4 can't be "all things to all men")

The reasons:

The "Theory":
* there are 2 major ABI versions, represented by GCC 3.2 (ABI 1) and
  GCC 3.4 (ABI 2). GCC 3.3 is compatible with 3.2, 4.0 is compatible 
  with 3.4). GCC 3.4 can generate GCC 3.2 (ABI 1) compatible binaries 
  (via a compiler switch).
* GCC 4.0 is compatible with GCC 3.4

The Practice:
* there are many subtle differences between binaries compiled even with
  the same major GCC version on different boxes. (This is to a large
  part due to distros having patched their own 3.3.x to support features
  that were available in 3.4 CVS, or whatever).
* also, there are many subtle differences between 3.4 and 4.0 (even if
  they in theory should support the very same ABI version, and implement
  the same Itanium C++ ABI spec), due to lots of "bug fixes".

If you decide now that you will support many different GCC versions
with KDE-4.0, you will for sure also get these many different binaries
built. And you'll have to support them then too. (Even if only 20% will 
be on 3.2, they'll tend to take 80% of your support and development time,
I promise you this).

If you decide for only one (or few) versions, you'll get only these 
versions built. 

It is a sort of "Weichenstellung" (track switching point). 

A decision *now* will determine about a lot of saved, or wasted, time
in the future. All kinds of people (developers writing new code, 
developers fixing bugzilla items, users installing software or upgrading
their systems, packagers who build for their respctive distros....)
will many, many hours on multiple occasions if we decide (and announce) 
now that KDE 4.0 will be supported only for GCC 4.0.

Each GCC version you want to support will have its own family of bugs
and crashes in the future, for many years to come.

A KDE announcment will "force" many more people (even distros) to 
upgrade just because they will not like to miss KDE 4.0. We should not
be too shy about it -- KDE is a "star" amongst users. (Yes, we will also
loose some [users as well as developers], temporary; but very likely 
they'll come back too

> I think we should, otherwise we will loose a lot of developer time (updating 
> g++ means updating all C++ libs on the system, AFAIK), including mine.
> 
> Is gcc 3.3 able to compile kdelibs/kxmlcore ?
> Is gcc 3.3 ABI compatible to gcc 3.2 ?
> What about gcc 3.0 and gcc 3.1 ?
> 
> But I am afraid I am not able to get kxmlcore compiling with gcc 3.2.3, 
> somebody who knows more about this code and about templates should have a 
> look or give me some assistence.

See how it hinders you *now*? You'll repeat that exercise multiple times
over then next few years if you want to stay supporting 3.2 (and you'll 
force a lot of co-developers to also spend time to give their time to 
support users with 3.2 problems).

> Bye
> Alex
> 
> P.S. this is currently the reason why there is no progress with the cmake 
> build of kdelibs

I think it is *much* more easy for a developer to upgrade his compiler,
than it is for a user to fight the many different and subtle problems that
will be occuring if there is code and binaries on systems that was written
for multiple ABI versions and also compiled with multiple compiler versions.

Even if it looks like spending (wasting?) time now to upgrade gcc (or maybe
even one's own distro on the development machine), it will save a *lot* more
time in the future, time that can be spend to write real code instead of
finding workarounds.

So -- wouldnt it be much better to make a clean cut now, and tell everybody
about it?

Cheers,
Kurt

P.S.: Hmmm.... maybe GCC 3.4 will somehow be forced upon us as a version to 
      support, because the upcoming LSB spec may require it. Need to check.