Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Moving from 5.6 to 5.10 - qmake yields "Project ERROR: Library 'vulkan' is not defined."
I don't use Vulcan for anything. No changes except moving to using the new mkspec since the old names are no longer valid...
C:\build>C:\Qt\5.10.0\msvc2015_64\bin\qmake -r -spec winrt-x64-msvc2015 "CONFIG+=release"
Info: creating stash file C:\build.qmake.stash
Project ERROR: Library 'vulkan' is not defined.
This ring a bell with anyone?
Winrt ?Are you sure ?
The only mkspecs for vs 2015 that I see are:
What did "win32-msvc2015" become?
Well, I smartened up and used QtCreator to gen a project kit and read what it used.
Apparently there's an all in one win32-msvc now.
I presume that will resolve the issue...
The mkspec is still there, however you have a 64bit version of Qt so it won't do you any good.
Either use the VS2017 pre-built which is 32bit or build Qt for 32bit with VS2015. Note that VS2017 is backward compatible with VS2015 so you can stay with VS2015 while using the VS2017 pre-built Qt.
win32-msvc is it now.
Weird... Builds most of the projects involved, but one project now breaks during complication with a bizarre error:
"c:\qt\5.10.0\msvc2015_64\include\qtcore\qrandom.h(163): warning C4003: not enough actual parameters for macro 'min'"
I recently updated my Visual Studio 2015 to Update 3 with Cumulative Servicing Release (because you MUST use this version of 2015 when building QtWebEngine.)
I'm not using the build of Qt I made in any case, I'm using the 5.10 commercial download to migrate from 5.6 to 5.10. Later, after all the kinks are ironed out, I'll move to the 5.10 that I built from source.
not enough actual parameters for macro 'min'
BTW, it builds just fine with the compiler if I use the 5.6 Qt framework...
Can you try to add
DEFINES += NOMINMAXto your .pro file ?
DEFINES += NOMINMAX
Will do. I'm not sure it's the primary issue as a whole raft of errors follow that one.
Worked... Weird. I would guess that the relative inclusion of "windows.h" somewhere along the way has changed in order to make that an issue.
Thanks for the tip!