[Qt-creator] Setup of CMake based projects

[Cornelis Bockemühl]

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:

1) 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).

2) 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>".

3) 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.

4) 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.

5) Now finish the CMake GUI ("generate" is not required now) and open a new session in QtCreator

6) 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:

7) 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!

8) 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!)

9) 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:

1) 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.

2) 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.

3) 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"!

With best regards,
Cornelis
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20191003/31eb18b5/attachment-0001.html>