On Tue, Aug 18, 2009 at 17:36, Pavel Heimlich<tropikhajma at gmail.com> wrote: >> Have the mmx/sse/sse2 detection problems with the >> recent QT4 builds >> been resolved ? These problems did not exist before >> the migration to >> the "other" SCM. > > this is definitely offtopic in this thread, but :
No, actually, this is quite on-topic. > 0. the issues were probably not present after the migration, although I > cannot tell really "probably" and "I cannot tell" do not inspire confidence. > 1. they probably occured after the move to Qt 4.5.* See my comment above. > 2. we had to move to qt 4.5.* since this is what KDE 4.2 requires > 3. few patches may have been dropped if they were not applying cleanly This is not acceptable. It is not acceptable to drop patches just because they no longer apply cleanly. If the old patch no longer applies cleanly, then a new patch should be generated, if it is still needed. It is very clear that, in the mmx/sse/sse2 detection defect, the patch is still needed. > 4. I'd love to check the patch xlucas pointed to in the other thread and > perhaps fix it, but after *your* SCM was migrated recently, I am no longer > able to browse the source tree WORKSFORME. The patches required to make QT4's ./configure allow mmx/sse/sse2 with studio 12 are trivial. A total of three shell script lines need to be modified. > 5. have the patches been submitted upstream a year ago we would probably no > longer need most of them and there would be no such issue. Few weeks ago you > have mentioned that you are in touch with someone from qt team ready to look > at the patches - any news? Actually, I said that a number of months ago. Someone from Nokia/Trolltech looked at the QT4 patches in cvsdude, checked out a copy, and mentioned that they were considering integrating these patches in their main tree. It does not look like this has happened. There could be several reasons: 1. QT is no longer interested in these patches (possible, but very unlikely). 2. Their process for accepting community patches upstream has changed. 3. They are waiting for the QT4 integration in Solaris, and will incorporate the patches published by the Solaris build. In either of these cases, I do know that QT has the patches. Pestering them with questions "did you check in my patch yet" is not going to make anything go faster. Quite the opposite. > KDE4 itself is moving fast. If we keep sitting on our behinds, there'll be > once again a pathetic bunch of bits unsupported by upstream. And the approach used for keeping up with upstream is dropping patches which no longer apply cleanly, or randomly changing compiler flags, in the hope that "this might fix something" ? > Using undocumented flags is IMO just hiding bugs either in SS or in the > packages. The real problem is that ATM we don't even know which bugs and > where. > not sure if I'm the one, but here are my points: > get KDE4 on Open/Solaris and as a side effect improve and promote Sun Studio ? Fine. If you want to submit CR's and supporting test cases for suspected Sun Studio bugs, then you need to create simple compiler test cases reproducing the problem you are reporting. Sometimes these problems are very difficult to reproduce, or track down, because we are dealing with extremely complex code, with a very high number of dependencies. Randomly removing compiler flags, or dropping patches, is not going to help anyone. --Stefan -- Stefan Teleman KDE e.V. stefan.teleman at gmail.com
