<html>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!<br /><br />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:<br /><br />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).<br /><br />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>".<br /><br />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.<br /><br />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.<br /><br />5) Now finish the CMake GUI ("generate" is not required now) and open a new session in QtCreator<br /><br />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.<br /><br />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:<br /><br />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!<br /><br />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!)<br /><br />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!<br /><br />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!<br /><br />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<br /><br />set(ParaView_DIR "C:/dev/pv/rel" CACHE PATH "")<br /><br />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:<br /><br />cmake -G ninja -C my_config.cmake <path-to-CMakeLists.txt><br /><br />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...<br /><br /><strong>BOTTOM LINE after this long story:<br /><br />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.<br /><br />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.<br /><br />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"!</strong><br /><br />With best regards,<br />Cornelis<br /> </html>