We are happy to announce the release of Qt Creator 4.5 RC!
We think that we are pretty close to what we want to release as Qt Creator 4.5.0, so please take this opportunity to give us final feedback through the bug tracker, our mailing list, or on IRC (#qt-creator on chat.freenode.net). For information about the new features and improvements in this version, please have a look at the beta blog post or our change log.
Get Qt Creator 4.5 RC
The opensource version is available on the Qt download page, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.5 RC is also available under Preview > Qt Creator 4.5.0-rc1 in the online installer (as an update to the beta). Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on chat.freenode.net, and on the Qt Creator mailing list.
In my cmake project on windows 7 , I am no longer able to run the exe. Qtc says it crashes, debugger says debug session was terminated. My assumption is that qt dlls can be found. I can see that now the path to qt bin is missing from the Build environment path variable, which is by default the run enviroment. This was still working in the beta1.
Actually it should not be part of the build environment for CMake (Because the CMake build figures it out not by the environment but by the CMake variables. That was a fix/change that came in after beta.), but it should be part of the run configuration environment. Please create a bugreport on https://bugreports.qt.io/pr... for further investigation.
Ok, but it does not figure it out for me. I am using ctest to execute the unit tests during cmake build and these fail too, as the qt dlls cannot be found anymore. It used to work for some years now and suddenly it breaks. That is not the user experience, we as commercial users expect.
"It used to work for some years now and suddenly it breaks."
Something else used to not work for some years and now works. Thanks for testing the RC and informing us about the issue with the run configuration. I have created https://bugreports.qt.io/br... now.
"That is not the user experience, we as commercial users expect."
Commercial users do expect us to fix bugs and implement new features, right? Both of these mean behavior changes.
Sometimes behavior changes have unexpected influence on unexpected usage patterns.
Well, would you be so kind and tell me what unexpected usage pattern I use? I would also be glad to learn, how cmake on windows is supposed to figure out the qt bin directory AND setting it into the path variable, so ctest can run the test executables.
The unexpected usage pattern is that you are running build products from a build configuration environment instead of a run configuration environment.
As far as I can see you would have the same issue that you have now if your tests required other libraries than Qt that are not found in default search paths. You'd tell CMake about the library by setting XYZ_LIBPATH (or set the prefix such that that library's .cmake files are found), but that would not change the PATH to the libraries either.
CMake does know which libraries it linked the tests to, so it could set up an environment accordingly when running make tests/ctest.
The reason to do the change that is now biting you is this: I am trying to keep the magic low, so that Creator will behave similar to building on the command line. This is rather nice since it allows to setup automated CI systems and similar use-cases in a straight forward way and without surprises.
Changing PATH is magic and it did actually hurt cmake users. CMake's FindPackage works based on PATH (and some other things), so changing it did result in Creator picking different libraries to link against than building on the command line did. That is entirely unexpected and non-obvious, while not changing PATH does result in nicely obvious problems like those you reported.
I'll check what I can do to help you in the Qt Creator 4.5 time frame and later.
I see three possible workarounds you can apply to make your tests work again right now:
First you can fix up the project configuration: Change PATH in the build settings to make creator pick up Qt when building your project and when running your programs. This needs to be done for all projects and all users.
Secondly you can set PATH to include the Qt install location in Tools>Options>Build & Run>Kits. This is specific to one developer and will fix both build- and run configurations for that user and will fix all projects that use the fixed kit.
You can also set up the environment to include the Qt path in your CMakeLists.txt file (CMake has the necessary information from the FindPackage you did to pick up Qt) before you run your tests. That will fix your tests -- both when building from Creator and from the command line, but will not fix the run configuration in Creator.
I hope this helps!
It would be nice if CMake would have some kind of RPATH magic on Windows...
Thanks Tobias, that is quite some effort, but I will look into it.
You wrote "FindPackage works based on PATH (and some other things), so changing it did result in Creator picking different libraries to link against than building on the command line did. " I cannot see how adding the qt kit bin directory has such an effect on windows.
The CMAKE documentation says:"Once you have built the project, you can execute all tests via make test with Makefile generators, or by rebuilding the RUN_TESTS target in your IDE. Internally this runs CTest to actually perform the testing"
So according to Eike, saying "The unexpected usage pattern is that you are running build products from a build configuration environment instead of a run configuration environment.", the CMAKE documentation is recommending an unexpected usage pattern. So does QtCreator support CMAKE only , with no support for CTEST?
"Once you have built the project, you can execute all tests via make test"
Well, that is obviously wrong. If you'd run cmake & built your project from a cmd prompt without setting PATH to the Qt library path (which is not needed to run cmake or build your project, "make test" would still fail to run your tests because it wouldn't find the Qt libraries at run time.
Anyhow I think this discussion becomes a bit academic. There was a bug fix in Qt Creator that resulted in a definite bug with run configurations, and additionally a use case of build configurations of yours broke. The former is a definite blocker for the final, for the latter I have added some suggestions to the bug report and we can see what we can do to improve the situation in what time frame, and in the mean time there are multiple ways with multiple degrees of complexity and scope for a workaround.
Thanks for all the CMake fixes/improvements! Keep 'em coming...
You are welcome!
We are not actively using CMake here, so it is hard to find all the rough spots and paper cuts that our users hit. We heavily rely on your feedback, so please keep that coming!
Thanks for the RC!
I instantly installed it, but noticed QTBUG-64152 still hurts me. Seems like Qt 5.10 was not updated since the fix went in.
Can you tell me when I can expect a snapshot containing this fix? Thanks.
Indeed, looks like a newer Qt was only exported this night. From the time stamps it looks like todays nightly snapshot of Qt Creator might have the change https://download.qt.io/snap... (otherwise tomorrow's should)
The snapshot from Nov 25 has working interactive rebase again. Thanks!
Good job, thank you.
Do you want to fix clangbackend that uses 5GB memory?
Compile and run Qt 5.9.2 MinGW 5.3.0 :
qml: list.count= 5
qml: Item 0
qml: Item 1
qml: Item 2
qml: Item 3
qml: Item 4
Compile and run Qt 5.9.3 MinGW 5.3.0 :
qml: list.count= 5
qml: Item 0
qml: undefined
qml: Item 1
qml: Item 2
qml: Item 3
Qt 5.9.3 Item 0 -> undefined -> Item 1 ?
A large step forward in the CMake support! Now it is comfortable and usable - the nasty bugs seem to be solved.
Thanks!
Thanks!
Please report any pain points you have! We need that feedback to polish our CMake support -- and everything else too:-)