On Thursday 15 March 2007 08:54 am, Stefan Teleman wrote: > Yes, it means exactly that. Fixes for Sun Studio will be accepted (and > must be submitted) upstream.
Ok, that is key for us. If we couldn't get he changes upstream we in a bad situation. Now I kinda understand where we are...thanks. I'm ok helping with this, and I think we should be able to get a small team to work on this, and if we can get the changes upstream, this will ensure we can continue to have working KDE Desktops on Solaris/OpenSolaris in the future. > 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. I will caution against deviating from what the mainline project is doing. You need to lobby your rationale to us, the community!<wink> In general I don't want us to create more work for ourselves than is needed. The DCOP/Corba change sounded like it could haunt us. I know that Corba works better for us, and KDE was Corba at one point, but changed to DCOP, at least that is my understanding. Isn't that true? > 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. :-) But do you see ANY? There's a difference between not being able to get the changes upstream and being able to. If they can at least get them upstream, one of the big hurdles is elliminated. > It's up to us to get rid of the Linuxisms and replace them with > portable code. I was more concerned if this would be something that keeps getting thrown at us, like, everything we get a new rev it's full of code that won't compile on Solaris. I think most QT code is platform neutral, isn't that true? > > 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. This sound like one of the more difficult pieces, these libraries. There was some 1394 relates stuff that Alan Perry worked on, and David Bustos wrote a glue layer for some stuff in getting a web cam to work. This could be used for kino possibly, if we had the backend pieces. > 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. This is a big part of modern software, we would need some type of solution. > > Isn't the blastwave version a gcc build? > > Yup, i'm pretty sure it's gcc. That's the whole point of this project, we need a SunStudio compiled version if we want the plugins to work and not crap out on us. At least this is my understanding. When people tell me things like, "I run the blastwave KDE and it works good, only craps out occasionally", I don't consider that to be software I want to run. I don't like when my desktop disappears all of the sudden. > > I'll grab your latest stuff, that runs on nevada? > > No idea if it runs on Nevada. I don't think it does. You need to udpate your system to the latest nevada. This all needs to happen on nevada latest, and continue as we move forward. There's a new DX coming out soon, but I wouldn't mind using DX as a base, that way it would allow other developers to sync up and/or get involved more easily. We need to get a standard development environment, and that means getting things rolling on nevada, IMO. > > 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. As long as we can push upstream we should be ok. > I think the JDS dudes are planning on integrating an "official" > libtool into Nevada. Which will help a lot. I guess that would be John Rice and Co.? Or Glynn Foster's group. I'm not sure who's working on the desktop. KDE is my desktop, and nobody is working on it yet...:-/ -- Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group Advocate of insourcing at Sun - hire people that care about our company!
