- Qt 5.7 and Xcode 8 no longer mix well - this is a confirmed Qt bug. See (for example) https://bugreports.qt.io/browse/QTBUG-55649?jql=text%20~%20%22xcode%208%22 among many reported issues. - master krita/3rdparty/ext_qt on macOS pulls down opensource 5.7 to patch - configure/build attempt will halt with: Xcode not set up properly. You may need to confirm the license agreement by running /usr/bin/xcodebuild without arguments. - misleading since it's not a licensing or xcode setup issue - In fact, Qt attempts to validate your xcode installation using a now outdated statement: "xcrun -find xcrun". - It should now use "xcrun -find xcodebuild" instead. - I am researching Qt bug reports to surmize whether the fix is publically available yet. Possibly qt 5.7. - Not sure if latest macOS Sierra (Released) is a factor yet, but I register many troublesome warnings which I am discussing with the Qt crew. - meanwhile I have a tested patch ready, just in case... Patrice Reproducible: Always Steps to Reproduce: 1. from 3rdparty extensions build directory 2. cmake --build . --config RelWithDebInfo --target ext_qt 2. 3. Actual Results: Xcode not set up properly. You may need to confirm the license agreement by running /usr/bin/xcodebuild without arguments. make[3]: *** [ext_qt/ext_qt-prefix/src/ext_qt-stamp/ext_qt-configure] Error 2 make[2]: *** [ext_qt/CMakeFiles/ext_qt.dir/all] Error 2 make[1]: *** [ext_qt/CMakeFiles/ext_qt.dir/rule] Error 2 make: *** [ext_qt] Error 2 Expected Results: to build Good news is : after a successfull rebuild, better macOS openGL compatibility 3.0.2 for krita 3.0.2 beta and beyond.
Created attachment 101212 [details] patches defaults_pre.prf in qtbase/mkspecs/features/mac
Created attachment 101213 [details] patches qtbase configure
ALSO : qteginio no longer a valid module ... patch to ext_qt/CMakelists.txt is attached only tweaked and tested the mac portion though...
Created attachment 101214 [details] cmake fix for invalid module qtenginio
Geez hate not being able to edit/correct these (at least haven't found a way how), but I meant 5.7.1 may fix this...still confirming
Okay. If you've got a patch that works, and that also doesn't break building with the with the 10.9 sdk, could you put it on phabricator?
Ok will do. Shouldn't break 10.9sdk and have been running master with it for a while. Actually patched QT5.7 very early on during xcode betas and just forgot about it until now. We'll have to look out for 5.7.1 and its impact (at least on macOS) FYI, got a response from the qt guys about their weird warnings (mostly java related). We can ignore these for the moment. In fact do we even need java script core? I think not. There must a be a -skip for it. Let me check. Hate bloat. Interesting response... >...some of these look genuinely scary. > >everything from 3rdparty/javascriptcore is mostly irrelevant to us. we may resolve this by upgrading jsc at some point (this has been discussed within the >scope of the qbs project, which still uses the (deprecated) qtscript module), but it's not a priority." [QTBUG-56120](https://bugreports.qt.io/browse/QTBUG-56120 "QTBUG-56120")
The qtscript module is used by ki18n, so we need that, but we can and should skip webkit and qtwebengine. We need qtdeclarative to be able to build qttools.
Did we already push this?
Not yet. But since D2899 is accepted, will do so tonight.
Yay!
Closing then.