On Thursday 15 March 2007 06:32, Alan DuBoff wrote: > 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.
Yes, it means exactly that. Fixes for Sun Studio will be accepted (and must be submitted) upstream. The e.V. even gave us a semi-official green light to break binary compatibility, if we come up with better code. If we have a good rationale for breaking BC, then it's ok to break it. As long as we don't do it every two weeks. :-) The only restriction is that it should also compile with a recent GCC. > 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. Supported status means: specific changes for a particular OS/compiler combination will be accepted upstream, as long as they do not break other OS/compiler combinations. For non-supported status, OS/compiler specific changes are not necessarily accepted upstream. For example. you don't see many HP/UX on PA-RISC with aCC specific code blocks in KDE. :-) > 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. It's up to us to get rid of the Linuxisms and replace them with portable code. > Where do you see the most time being spent in getting the code to > compile with SunStudio? The most time consuming parts are: 1. Studio specific C++ strictness (which g++ happily allows). 2. Studio specific C strictness (which gcc happily allows). 3. Solaris specific quirks which can only be worked around by a rewrite. For example: KProcess && friends. The implementation of KProcess needs a rewrite (i started working on that in the copious free time i have at my disposal these days). 4. Solaris specific system stuff -- for example: KSysGuard for which i actually wrote the missing Solaris parts a couple of years ago. Or the SCSI stuff for K3B, which i had to rewrite, because it did not work on Solaris at all. 5. Dependencies external to KDE, but which have not been ported to Solaris (example: libraw1394). We have libusb in Solaris, we should also port libraw1394. Other examples: OpenSC, transcode. 6. Drivers: for example there's no equivalent of video for linux --v4l-- on Solaris) and because of that one can't use webcams or watch tv, or edit video. > Isn't the blastwave version a gcc build? Yup, i'm pretty sure it's gcc. > 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! KDE4's multimedia layer depends on libXine. :-) > I'll grab your latest stuff, that runs on nevada? No idea if it runs on Nevada. I don't think it does. > > 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. +1. > 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. I talked to the e.V. about the CORBA bindings a while ago, and the official reply was: if there is working code, it will be integrated upstream. That's one of the reasons the CORBA vs. DCOP study was done. KDE doesn't handle projects the way a corporation does. If one wants a certain module, or functionality, to be integrated into KDE mainline, one starts with code. If it's good, it will make it upstream. > Yeah, libtool is pretty evil, but at least it knows more about > Solaris recentely. I think the JDS dudes are planning on integrating an "official" libtool into Nevada. Which will help a lot. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V. -Monty Python stefan.teleman at gmail.com
