> >> 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.
No, it is not. It is on-topic there: http://www.opensolaris.org/jive/thread.jspa?threadID=110482&tstart=0 > > > 0. the issues were probably not present after the > migration, although I cannot tell really > > "probably" and "I cannot tell" do not inspire > confidence. guess what, they were not meant to. Quite the contrary, they were meant to express uncertainty, because this is what these words are supposed to say. I have no idea how were things working or not before a move from one scm to another. Even if I had I would have probably forgotten that. > > > 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. This is the best practice if you have either lot of time or a guy who knows the patches and is willing to refresh them. There were none of that and +- 100 completely undocumented patches with several hundred lines of code. Most of them broke since 4.4.1. > > > 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. good for you, but it does not make the scm more public > > 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. five If I were like you, I'd be saying something about confidence now. But I am not, so I am not saying it. > > > 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. As a mental exercise I am imagining a Nokia engineer, overloaded with porting qt to the latest Tesco microwave oven. Few months ago this guy has received a bunch of patches for a bizarre platform he never heard of before. Willing to help he still moved the e-mail it to his 'When I have some time' folder, where it's steadily sinking as new mails are incoming. The day before leaving for vacation he gets sick of the load, marks all messages in that folder as read, muttering to himself: 'If there was something important, they'll remind themselves ...' > > > 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" ? I don't say it's optimal, but under the circumstances it's better than doing nothing at all. For the conservative ones KDE 4.1.3 with qt 4.4.1 is still at http://solaris.bionicmutton.org/hg/kde4-specs > > > 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. so far the Sun Studio team was happy with just the preprocessed files > > Randomly removing compiler flags, or dropping > patches, is not going to > help anyone. neither accumulating cruft noone understands -- This message posted from opensolaris.org
