Future of KDE Development

[Hans Meine]

On Friday 18 February 2005 09:06, Stefan Teleman wrote:
> it's very big. it's almost impractical at this point -- noone sane
> will want to go through the hassle of applying them one by one.
>
> if you really want to take a look, they are in
> stable/3.3.1/contrib/Solaris/FORTE/9/PATCHES-3.3.1
@AdGroot: I had to figure that one out, too, but did the following lucky try: 
ftp://ftp.kde.org/pub/kde/stable/3.3.1/contrib/Solaris/FORTE/9/PATCHES-3.3.1

I am starting to look through them.  (I am compiling with GCC, obviously Sun's 
Forte makes more problems.)  The first patches I inspected contain just too 
many unnecessary changes to say anything about whether there are useful 
changes in there, too.  Quoting stuff I saw so far:

arts/flow/gsl/gslglib.h/cpp:
  internal GSL stuff replaced with #include <glib.h> - unnecessary
arts/mcop/trader_impl.cc:
  "using namespace std" replaced with std:: prefixes - unnecessary
arts/soundserver/artsd.cc:
  this is interesting signal/syslimits stuff, should obviously be integrated
  with #ifdef's
arts/soundserver/samplestorage_impl.cc:
  even better - this could be compatible changes (c vs. c++ headers, direntry
  handling), I am not sure
arts/soundserver/soundserver_impl.cc.diff:
  "No differences encountered" ;-)
arts/soundserver/soundserverv2_impl.cc:
  similar to samplestorage_impl.cc, plus some strange patch replacing a simple
  trader call by lots of code hardcoding different mimetypes. wow - wondering
  who hacked this together and why??

Note that I use to compile arts *without any patches*, and just did it again.
I have successfully compiled the latest 3.2 branch here at our university with 
GCC, and I am currently compiling 3_3_BRANCH, too.  I have so far not used 
any of the above-mentioned packages/patches.  However, I disabled compilation 
of the following stuff, which I did not need anyhow: 
kdebase/{kdm,kxkb,kcontrol/kdm} kdenetwork/{kppp,lanbrowsing}

The only problem I had to work around was that with AC_SYS_LARGEFILE - this 
makes standard headers #define truncate to truncate64, which renders e.g. 
QString::truncate() unusable.  I simply hacked kdenetwork/configure.in.in 
accordingly, which is the only configure.in.in which still had this problem 
(this was worse before).

-- 
Ciao, /  /
     /--/
    /  / ANS