On Thursday 15 March 2007 02:14 am, Stefan Teleman wrote:
> What it means: with KDE4, Solaris/SunStudio are supported at KDE.

Does that mean that all code going into KDE4 will compile on Solaris using the 
SunStudio? If so, that is significant for our community. Or does this mean 
that 

For Solaris it's key to have c++ code compiled with SunStudio, period.

> The KDE Foundation (KDE e.V.) gave the Green Light for Solaris to
> become one of the supported OS's (supported as opposed to ported).
> However, KDE4 on Solaris will become reality only to the extent
> OpenSolaris folks (us) are willing to invest the time to work on it.

This is what I'm trying to understand, and what we get for the supported OS 
status. If I understand you correctly, they basically gave a green light for 
our community to keep their code compiling on Solaris.

What I want to know is if there is any assurance that we'll get decent code, 
or will be get stuff with Linuxisms plagued throughout it, and it's always 
our job to fix it.

Where do you see the most time being spent in getting the code to compile with 
SunStudio?

> There's 3.4.3 from http://solaris.kde.org/. Blastwave has more recent
> KDE's as well.

Isn't the blastwave version a gcc build?

I used to use mplayer from blastwave, but recently there was some folks in 
Germany for Sun that did a great job at packaging all the mplayer stuff with 
the GUI...works great!

I'll grab your latest stuff, that runs on nevada?

> And i bet it doesn't have anti-aliased fonts. :-)

It has such a crappy video in it, I don't know that would matter much!;-) It 
barely does 1600x1200 and only a single head.

> "Technical preview". Not there yet. It's buildable on Linux.

Then we should aim to get that building on Solaris Express DX.

> IMHO: KDE4 is a longer term project. To get there, we still have to
> build tons of extra libraries on which KDE depends, before we can
> start building KDE. These libraries aren't even in Nevada. I think it
> would be more practical to work in parallel on 3.5.5 and KDE4. It
> might very well be that it will take until KDE 4.0.2 before the
> Solaris version of KDE4 is up to Sun standards. Maybe we should have
> a 3.5.5 build ready before that (3.5.5 is really nice). A lot of the
> work required is common between the two. There is one major feature i
> would like to add in KDE 3 and 4: CORBA bindings to replace DCOP. We
> can use omniORB (http://omniorb.sourceforge.net/). It runs perfectly
> on Solaris 32- and 64- bit. There are technical reason behind this
> pet peeve of mine, and i have the benchmark study done by someone
> else to back me up. :-)

My hesitation in this would be that we deviate from the mainline, and end up 
in a situation where we need to apply patches to the mainline, on a regular 
basis as the sources are updated. I'm all for it if it doesn't cause us to be 
a one-off.

> KDE4 uses CMake (http://www.cmake.org/) for its build system. The auto
> tools are no longer used. This is good and bad. Good because we don't
> have to deal with libtool in KDE4, and CMake is much nicer. Bad
> because we still have to deal with libtool for all the other
> dependencies.

Yeah, libtool is pretty evil, but at least it knows more about Solaris 
recentely.

> A while ago i put together a list of KDE dependencies -- i will dig it
> up and post it here. This list is very long.

Yes, would like to see it.

> QT 3.3.7 and 4.2.2 are here:
>
> http://svn2.cvsdude.com/kdesolaris/trunk/QT/3.3.7
> http://svn2.cvsdude.com/kdesolaris/trunk/QT/4.2.2
>
> svn co --username=anonymous http://svn2.cvsdude.com/kdesolaris/trunk

I need to get svn installed on this machine...but I need to get some 
sleep...;-) later...

-- 

Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group
Advocate of insourcing at Sun - hire people that care about our company!



Reply via email to