Unsolved QtCreator constantly "forgetting" CMake property settings
-
QtCreator is for me the tool of choice for C++ programming, and CMake is the build tool that I at least prefer over qmake because it is much more powerful - plus the base of all my projects is done with cmake anyway.
The good thing is that it looks like QtCreator is gradually more and more going into supporting cmake projects directly, so things are growing together that belong together.
Only one thing I will never understand: Why is the QtCreator so completely destructive if it is about cmake properties?
So many times I already had that case, and just now it happened again: for some reason (which I will never find out!), QtCreator has decided to "forget" all my property settings in the project. If this is just one or two it's just a nuisance, but if it is much more it is really a nightmare! Because entering them with the "project settings" in QtCreator is not fun at all - mostly because paths have to be entered manually or with copy and paste. Much better is the cmake-gui tool already - and even better the method of choice of the cmake programmers at Kitware: they write a longer set of properties into a settings file and import it directly through cmake -C <settings file>.
But then you take that nicely prepared project, open it in QtCreator - and in many cases the QtCreator will again KILL EVERYTHING - for no obvious or understandable reason!
Meaning: you HAVE TO use that really bad project setup page and redo the entire properiy input. There seems to be a certain "not-invented-here" attitude in place...
Once this stupid nightmare is over you can start to enjoy the good features of QtCreator!
QUESTION: Are there any plans to do something serious about this situation in the near future?
-
@cobo said in QtCreator constantly "forgetting" CMake property settings:
QUESTION: Are there any plans to do something serious about this situation in the near future?
as far as I know, cmake is going to replace qmake as the default build system with the release of Qt6
My last information was, that Qt6 shall be released sometime in 2020. If I had to take a guess, I would say sometime near the QtWorldSummit. -
@cobo said in QtCreator constantly "forgetting" CMake property settings:
Only one thing I will never understand: Why is the QtCreator so completely destructive if it is about cmake properties?
Are you removing
*.user*file Qt Creator generates? That's where your settings are stored. If you remove that file, Qt Creator will forget your settings. -
@sierdzio no, that I understood already long ago: I have that .user file in the .gitignore of my project and do not touch it.
I think that basically there is some very low "contradiction tolerance": whenever QtCreator does not like something for whatever reason - it simply discards the entire setup. I agree that this is not very specific, and as a developer I would have problems to deal with such an "error report" ;-) However, I cannot easily specify much more.
Maybe just as an example: I am working with ParaView, and if I am doing a full rebuild of the ParaView software (which takes many hours on my system), I tend to first choose many settings in cmake-gui - because in QtCreator it is rather tedious.
<intermediate remark>For example if it has some errors during the first attempt it does not even bother to display ANY properties: You have to do the setup first with another tool, see what are the bugs (like some missing path etc.) and then manually add that property into the empty setup window in QtCreator.</intermediate remark>
But while I do the setup with cmake-gui for ParaView, I write down all the changes to options that I apply - because I am pretty sure I will have to enter them again and again! (Ok, the fact that already for the debug version you have to enter the same options once more cannot be blamed to QtCreator - it is a "feature" of cmake itself...).
After the project is properly set up with cmake-gui and "generated", both release and debug, I try to open it with QtCreator. With some other projects this was already working, and the maximum that happened was some little dialog asking whether "changes" should be accepted or rejected. But in the case of ParaView I tried it already many times throughout the last two years - and it happened really every time: the ENTIRE setup was gone after the project was read into QtCreator!
And this is where my notes on paper are coming out: I redo all the changes that I did with the cmake-gui - and again I do it twice, for both the release and the debug version.
Not sure if this is already good enough for a reproducible error report because of course I am also using specific tools on a specific system etc. etc.
In the case of ParaView, my conclusion is often most of the time: just do NOT use QtCreator at all for the build - just start ninja on the command line after the "generation".
The only disadvantage is then if I want to understand certain functionalities a bit better: then the facilities of navigating through the large code are just first class with QtCreator - and of course also a debug run requires a build that has succeeded from within QtCreator!
This just as a bit more of illustration of the struggle.
-
Try discussing it on Qt Creator mailing list, maybe? Once you pinpoint it better you would then be able to add a proper bug report in Qt bug tracker.
-
@sierdzio Ok, thanks. I have now a case that can be successfully reproduced.
And if the mailing list is the right place to go, I will do it. (However, mailing lists are such a pain in the a** - compared to online forums...)
-
@CoBo said in QtCreator constantly "forgetting" CMake property settings:
@sierdzio Ok, thanks. I have now a case that can be successfully reproduced.
And if the mailing list is the right place to go, I will do it. (However, mailing lists are such a pain in the a** - compared to online forums...)
Indeed. But Qt developers (with a few exceptions) don't use this forum. They do use the mailing list (and IRC) so it's good to rise the issue there - they will notice.
Or you can also report it on Qt bug tracker.
-
@sierdzio I described the case there now!
Actually it's rather a feature request than a "bug".
Just as a reference for those who might want to know also here, this is the rather long mail that I posted on the qt-creator mailing list:
*Currently I am mostly working on CMake based C++ projects (including Qt), and the QtCreator is by far my favorite GUI for development. However, the cooperation between CMake and QtCreator feels in many ways a lot like a "clash of cultures", but I also see a lot of progress during the past years - which I appreciate a lot!
But when I heard that CMake will eventually become the main build manager in QtCreator, I thought I should post here my "favorite culture clash" situation. I found a workaround that seems to be functional, and since I just did it again, I can explain it step by step:
-
Write the first sources with some first CMakeLists.txt outside of QtCreator - somewhere. Can be dummies or more - just some "project starter". In my case it is a "ParaView custom application", so one of the entries in that CMakeLists.txt is find_package(ParaView REQUIRED).
-
Choose and generate target directories for release and debug code. Go to the one and to the other, and in both do a first CMake setup still outside of QtCreator, with from the command line entering "cmake-gui <path to CMakeLists.txt of the project>".
-
Go through the "configure" loop within that CMake GUI. In the given case this means to enter a build type manually (Release or Debug), and you get a complaint about ParaView not found: you need to enter a path in the ParaView_DIR variable. This is easy because you can use a file dialog for that purpose.
-
During that process, take notes in some additional text editor where you put in things like the ParaView_DIR entry, ie the path where the release or debug code of your own ParaView compilate resides - you will need that information later, and copy&paste will be a shortcut.
-
Now finish the CMake GUI ("generate" is not required now) and open a new session in QtCreator
-
Load the CMakeLists.txt of the new project in that QtCreator session. In the project setup, disable all build types except release and debug (ok, that's what I am doing...) and change the target paths to where you already did your initial debug and release setup with the CMake Gui.
Note that here are already CMakeCache files ready that SHOULD normally be used as a starting point for any further configuration efforts - like through the QtCreator project setup. But at this point, QtCreator is suffering from some "not-invented-here syndrome"! Because this is how the story continues:
-
Start the QtCreator based project setup - and see that ALL the previous effort is simply dumped! So the only thing you can do is - start over from scratch, and this with the much worse facilities (in this point!) of the QtCreator. Because "failure" means here: you get a BLANK settings screen, and you have to read through the entire "general messages" output to figure out what COULD be the thing that you should provide - and this can be quite a jungle of log output!
-
Now comes the initial first setup into the game: The CMake GUI was telling you much more precisely what you should do next, shows all the settings that are ok (or at least accepted) so far, and gives you a comfortable way to change what is still missing. And since you already went through that process, you can easily redo the same steps - because there are the "notes" in that separate text file! So you manually generate a ParaView_DIR variable, and with copy&paste you enter the actuall path. (The QtCreator project setup will neither tell you that actually ParaView_DIR is missing, nor will it give you a file dialog to choose the directory!)
-
With this, and if you did not make a mistake during this rebuild of the build setup, you are done - for the one of the build types. Of course you need to repeat the process for the other one, and then you can start working in your project with QtCreator!
I know, it is not all the fault of QtCreator, but like I said: it is a "clash of cultures"! And part of the "CMake culture" is definitely that tendency to "forget everything if one detail is not ok": there is no way to remember the steps that you did in a CMake-gui session and e.g. apply them again later on, like porting from the release to the debug version, or downloading a next version of some external code and trying to build that with the same settings. And if it is more than just 1-2 settings that you have to provide, even the above path gets really out of control!
For that reason, I do not build the ParaView application itself using the QtCreator at all - because doing it with the means of CMake alone is already sufficiently tedious. In that case I also start with a setup in cmake-gui, but then I "take notes" directly into a my_release_config.cmake file with entries like
set(ParaView_DIR "C:/dev/pv/rel" CACHE PATH "")
In the case of building ParaView it will of course not be this line, but rather a large number of other options that have to be set in order to get the build in the required way. And once that *.cmake file is ready, I do not even use the cmake-gui any more, but do the build directly from the command line, like this:
cmake -G ninja -C my_config.cmake <path-to-CMakeLists.txt>
followed by "ninja" to actually do the build - directly from the command line. And this is fine as long as it is about a project that I am not actively developing - like ParaView. I never take the pain (well, I tried in the past...) to bring the entire ParaView project into the QtCreator...
BOTTOM LINE after this long story:
-
it would be great if the QtCreator project setup for CMake projects would at least be at the comfort level of cmake-gui, like with a file/directory dialog and with a display also of unfinished setup - with the option to complete it.
-
it would be great if the QtCreator setup process for CMake would allow to "inject" the kind of "my_config.cmake" setup files directly into the project setup process, like with the -C option of cmake.
-
and the most phantastic thing would be to even GENERATE such a configuration file - from the steps that a user is doing during an initial setup in the "cmake-gui" trial&error way: with that it would even overcome a major shortcoming from the "cmake culture"!
-
-
https://lists.qt-project.org/pipermail/qt-creator/2019-October/008158.html is the mailing list thread continuing this topic.
-
@CoBo so to keep it short: you wish that Creator uses existing CMakeCache files and/or provides means to set up projects like in CMake GUI?
Regards
-
@aha_1980 Well, in simple cases it actually does respect existing CMakeCache files, but it looks like in more complex projects it tends to "give up" - and drops everything! And there is for me no reason why this should be some extra because the entire cmake processing is done in the background by the cmake tool anyway: why reinvent the wheel?
And yes, if CMake would become the standard build system for QtCreator, this is a field where not only the standard of CMake itself should be reached but even at least a bit more, like reading project settings from a file and supporting the interactive project setup that is one of the main strengths of CMake.
Now part of the "culture clash" is that it looks like the CMake people are more or less "command line people", so you can do EVERYTHING with the plain cmake tool, already less with the cmake-gui (like: you cannot import settings files there - but you can first generate a cache with the command line tool and only then open it with cmake-gui - because it respects the existing cache).
On the other hand, Qt is a "GUI culture" - and they definitely know that business much better, so I can also easily imagine that a QtCreator project setup has the potential to be clearly better than cmake-gui. But that is so far just my dreaming!
-
@CoBo said in QtCreator constantly "forgetting" CMake property settings:
I'm no CMake user yet, and I know nothing about the CMake integration in Creator, but nevertheless want to add my two cent before you got other answers - maybe from the developers on the mailing list.
Well, in simple cases it actually does respect existing CMakeCache files, but it looks like in more complex projects it tends to "give up" - and drops everything!
Ok, so best would be you have an example CMakeCache file that exhibits that behavior, so the developers can reproduce it.
And there is for me no reason why this should be some extra because the entire cmake processing is done in the background by the cmake tool anyway: why reinvent the wheel?
Yeah, the build is done by CMake, but Creator needs information about the project: which files are involved, which build targets, which compiler flags etc.
Tradionally, that area was not covered by CMake, it slowly moves in that direction and Qt developers sent patches to CMake to improve the situation.
So as I said above: if you have clear examples of what is not working: tell them. And after all, Creator is an open source project, so adding some GUI to set up CMake parameter can also be done by external contributors (hint, hint, hint!)
so I can also easily imagine that a QtCreator project setup has the potential to be clearly better than cmake-gui. But that is so far just my dreaming!
Let's hope that dream come true. After all, we will have much more CMake users the next years.
Regards
-
@CoBo said in QtCreator constantly "forgetting" CMake property settings:
QtCreator is for me the tool of choice for C++ programming, and CMake is the build tool that I at least prefer over qmake because it is much more powerful - plus the base of all my projects is done with cmake anyway.
Count me as another user with pretty much same use case.
A very common flow: configure CMake project with cmake-gui or even cmake directly -> build it with command-line -> repeat multiple times with multiple projects -> sometime open one of the projects with Qt Creator to write more code/debug/etc.I remember Qt Creator was able to open an existing cmake build folder (with existing CMakeCache.txt) just fine for a while, and I was happy with it, even though I couldn't preset cmake variables from Qt Creator before running the cmake for the first time for a brand-new build configuration (still cannot, and yes, that is a big deal for my project(s)).
Last few versions (4.12.1, 4.12.2 for sure) this became broken again. If I open an existing cmake build folder (by importing a build configuration or by selecting an existing build folder for an existing QtCreator build configuration) - Qt Creator would delete CMakeCache.txt and re-run cmake from scratch, which actually breaks my build configuration completely(
BTW: my cmake version is 3.16 so it does support filesystem API.
