[Qt-creator] Setup of CMake based projects
Tobias Hunger
tobias.hunger at gmail.com
Thu Oct 3 21:12:59 CEST 2019
Hi Cornelis,
first of all: Thank you very much for taking the time to provide your
feedback! May I ask which version of CMake and Qt Creator you use?
Creator has three very different ways to interact with CMake, based on
the features that are available there -- which mostly depends on the
version number.
I am currently on a tablet and can not check the exact names of
things! So please grant me some slack if the strings in the UI do not
match my recollection!
On Thu, Oct 3, 2019 at 10:29 AM Cornelis Bockemühl
<cornelis at bockemuehl.ch> wrote:
>
> Currently I am mostly working on CMake based C++ projects (including Qt), and the QtCreator is by far my favorite GUI for development.
Thanks!
> 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!
There is definitely a clash:-/
> 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:
I would argue that it already is the most widely used project type:-)
But then I do hope it will get even more important now that Qt is
probably going to end up being built with CMake. It does help a lot
that we can now build Qt Creator with CMake, so I can actually use the
integration myself. There are still a lot of paper cuts -- and those
are hard to detect when you only ever open some test projects and
never really work with those!
[...]
> 2) Choose and generate target directories for release and debug code.
Where are those (relative to the source directory)?
> 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>".
Why do you chose to use cmake-gui? Is that just due to the filedialog?
I am asking, because I am actually pretty happy with the configuration
dialog in creator nowadays:-)
> 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.
ext 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.
Creator *should* detect existing builds, but it only tries directories
close to those it would create itself, so it might just be missing
yours. Could you try to adapt your default build directories in
Tools>Options>Build & Run>Somewhere to match your naming scheme before
opening the project for the first time? Do your build directories get
picked up when you change that?
If Creator does not pick up your build directories: At the very end of
the list of possible Kits there should also be a button labeled
something like "Import build"(?). Could you please try that to import
the two builds of yours? Does that work better?
> 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:
[... Configuration UI trouble ...]
That should actually only happen with cmake >=3.7.0 and <=3.10.0 IIRC.
Early server-mode versions did not provide the necessary information
to display something, but that was fixed sometime in 3.9.x IIRC.
Could you try to upgrade your CMake if you are in that range?
[... Paraview setup...]
My assumption is that users will just create Kits for things they use often.
If you work a lot with paraview, you could clone one of your existing
kits and add the required settings there: Each has a CMake
Configuration section (among other things;-). You can also check the
other settings while in Tools>Options>Kits>Kit :-) If you do not use
CMake older than 3.7, then you definitely do not need the CodeBlocks
extra generator. If you do not use Qt 4, then you can remove the
QMAKE_PATH(?) setting from CMake's Configuration as well.
Any build configuration will automatically get all the kits' CMake
configuration plus the CMAKE_BUILD_TYPE appropriate for the build
configuration when configuring initially.
Would creating kits work for you? Or what would you want to have here?
IIRC there is already a feature request to "mass-export" settings from
one build configuration into another. I am not really sure how a good
UI for functionality like that would look like.
> 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.
That should work. Could you please open a bug report for this?
> 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"!
There is no way to know what a user has set explicitly via cmake-gui
or via "cmake -DFOO=bar". There is little I can do about that:-/
The settings you changed via creator are actually stored in your .user
file in the build directory (for each build configuration). It should
not be too hard to extract those, but considering that you do all the
heavy lifting in cmake-gui, I doubt that will be very useful for you.
Best Regards,
Tobias
More information about the Qt-creator
mailing list