[Qt-creator] ?==?utf-8?q? Setup of CMake based projects

[Cornelis Bockemühl]

Hello Tobias,

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

QtCreator is version 4.4.1, CMake is version 3.14, on a Linux system
(OpenSuse Leap 15.1). Versions on my Windows 10 system are similar, but
I don't see them here right now.

And thanks also to you for your detailled reply!

[...]
>> 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:-)

Probably not, but since I am working on top of ParaView, which is fully
CMake based (and from the same "kitchen" as CMake itself), my perception
is definitely biased. And the rest is "rumor": somewhere I was reading
that "switching to CMake instead of qmake" might be a medium term
goal for Qt!? Ok, specualations are not important here.

[...]

>> 2) Choose and generate target directories for release and debug code.
>
>Where are those (relative to the source directory)?

They are separate folders, like parallel to the sources folder, and
also debug and release are separate. It's for me the most sensible
setup - and with ParaView I think it's not possible otherwise.

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

Well, if a project is more than just 3 lines of code I would definitely
not say so ;-)

With the cmake-gui you have a very nice "interactive setup" process!

- start the cmake-gui, choose source and target directories

- press "configure" and choose a generator (typically ninja in my case)

- if you start with a brand new target directory, the system will do
  all the typical cmake checks and work it's way through the source
  CMakeLists.txt

- after that, you have in the lower part of the screen the log, and
  in the upper part you see all the now defined cache variables, with
  everything new in red (which is all during the first run). In the
  QtCreator you see NOTHING as long as there was not at least one
  error-free configuration run

- in the log you see critical things also in red, so you can directly
  check what is going on. Like: cannot find ParaView project, with
  some explanations that you see also in the QtCreator log output -
  only not in red, so you have to check much more in detail.

- the missing ParaView_DIR is also already in the list, with a value
  of ParaView_DIR-NOT-DEFINED (or similar). Since that is a folder,
  you press on a little [..] button at the end of the line and get
  a file folder. In QtCreator you have to extract the name of that
  required variable from the log, add explicitly a variable with that
  name, leave the QtCreator to find out the full path of the ParaView
  build you want to refer to, copy the line and paste it in.

- some projects also have variables that are actually "options", with
  a default value, but as long as there was no successful first run,
  you also cannot see these options in QtCreator.

- after this, you press "configure" again, and all the so far "done"
  variables will be black in the upper window, but some new ones
  that may come in because of some settings that you changed are now
  red, so you can review them again, change if something is not yet
  like you need it, and "configure" again - until everything looks
  fine. (You see that I am talking here about large projects, not
  about 3-liner projects with maximum 1 setting!)

- this is actually some kind of interactive iteration loop, until
  the result is ok. Then you press "generate", leave the gui, and
  create your code with "ninja". Or try to switch into the QtCreator...

After this you will definitely be excited how easy this thing was
going - what used to be a tedious configuration process with other
tools earlier! But then comes the disappointment: If you want to
have a separate setup also for the debug version now, there is no
way around doing the entire process once again! And if you see that
there is now a new version of your project sources online, download
and you want to build it "in the same way" - same thing: again you
go through the entire process twice - once for the release, once
for the debug.

If you think you can simply copy the CMakeCache file to the other
folder, start cmake-gui again and just adapt things like changing
"Release" into "Debug" and leave all the options - then you are
wrong: cmake will "see" that the cache has been "transplanted" -
and refuse to work with it.

(My guess is that a variant of this behaviour is also the reason
for the "amnesia" that QtCreator is sometimes showing: if cmake
refuses to work - what can QtCreator do?)

This is then the moment where you may ask the CMake profis how
they are doing - and you will get the answer: we are writing
some my_config.cmake modules or scrupts and "feed" them into
the cmake - without the GUI!

And at that point I am getting the impression, that "cmake culture"
is mostly about command line operations, while Qt is first of all
the best GUI library that I know, so "Qt culture" is definitely 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?

Yes, I also think that the creator *should* do that - at least in the
cases where also the cmake-gui is doing it properly! Which means in
cases where the CMakeCache was not moved to another folder or other
"evil things".

The steps I am trying with QtCreator are simple, so no searching needed
for QtCreator:

- "open" the project, which is the CMakeLists.txt file in the source
  directory

- in the project setup, immediately adapt the target directories to
  match those where I already prepared the CMakeCache with the cmake-gui
  tool, and where at least that same tool would immediately "see" and
  accept it

So I cannot see any reason why the creator should be missing anything!

>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?

That I have neither seen nor tried yet: I will have to do it tomorrow!

[...]

>Could you try to upgrade your CMake if you are in that range?

I am far beyond that version range - see above! And I have realized the
huge progress in cooperation between QtCreator and CMake that happened
with increasing version numbers of both QtCreator and CMake during the
past few years!

[...]

>My assumption is that users will just create Kits for things they use
>often.

Well, so far I did not fiddle a lot with the kits - except to make sure
that they are using the right compiler, debugger, Qt version etc. And
once I have that ready on either my Linux or my Windows machine, I
do not touch it a lot...

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

In these kits sections I have indeed still that CodeBlocks extra generator,
together with ninja, and my understanding was that ninja is the "make"
tool while CodeBlocks generates some files that finally allow to see my
source code in the "projects" section of the main GUI. Of course I can
try once without that, but I don't expect this to change a lot regarding
my problems!?

>Any build configuration will automatically get all the kits' CMake
>configuration plus the CMAKE_BUILD_TYPE appropriate for the build
>configuration when configuring initially.

There is indeed some "magic" going on that I did not understand. My
impression is that it is the only area where QtCreator somehow tries
to "optimize" the cmake behaviour, like setting the build type properly,
thus overwriting a "Release" or "Debug" setting that might be in the
cache already. What else it "fiddles around" - no idea! -, but maybe
it is the thing where also something fails in such a way that the
entire cache is finally dropped as "not invented here"!??

>Would creating kits work for you? Or what would you want to have here?

Depends on whether they would do the job ;-)

For me the kits is about choosing the right tools, like ninja or
Visual Studio or nmake for the make tool, or the compiler and linker
version, or the Qt version for a project.

In the case of a big project like ParaView, you would typically have
settings or options that can be turned on or off, or otherwise
configured, like:

"use the math module"
"use python"
"python version 2 or 3"
"use the xyz plugin"
etc etc - endless!

These things you can put into a my_config.cmake script which you can
"feed" to the cmake configuration run with the -C option: in that case,
the provided settings will first be written into the cache, and only
then cmake will start reading CMakeLists.txt - with the initial
cache variables already in place.

If it would be a good idea to have a page in the "kits" setup that
includes such project specific settings!? For me it would not be the
logical place - except that it would of course allow to carry the
settings not only between build types, but even to other variants
of the same project.

But still, from the type of settings it is rather not tools, but
project related - but then it is not any more portable: if you change
some environment variable for a project in the "Release" build, you
also need to do it once more for the "Debug" build - it is not carried
over and cannot be ported to another project.

In the "cmake command line culture", you do such a thing with a config
file somehow, while in the "qt gui culture" it is the question in which
dialog it would belong...

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

Yes, that is exactly the problem! In some own projects I already just
put a "save" and a "load" button into a dialog, so certain things can
be "saved" to a config file and "loaded" back in another project or
whatever - but indeed this is adopting "command line culture" into
a "gui culture" where it has little to do! QtCreator style is to do
such things not explicitly, but only "behind the back" of the user take
notes in the *.user files...

>> 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?

Well, as far as I can see, this is not really a "bug" but already a
feature request!

The bug could only be the case that you have an existing and working
CMakeCache that is rejected for no obvious reason. Which may not happen
in smaller projects, while giving a big project as a "reproducible case"
that only makes a bug report "realistic" is a bit difficult. Ideally
I would have to spend some time to "melt down" the project so much
that I can reproduce the behaviour also with a rather small project...

>> 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:-/

No, that would be "magic" indeed!

Only if the QtCreator would allow the same kind of "interactive iteration"
process like the cmake-gui, then it could of course keep track of what
the user changed compared to what the initial setup was - and remember
that somehow for further use. However, this is a thing that also the
cmake people are not doing yet, so the dream still needs to develop
some clearer contours.

I am simply thinking about how I am "taking notes" in an editor window
that I have open next to the cmake-gui - and where I simply write down
all the settings that I am changing. This I can then easily rework into
such a my_config.cmake file.

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

I would definitely prefer to do it in QtCreator - if it was possible!

- because I would not have to change the tool for just this one job

- because it would also avoid any reason for the creator to suffer from
  the "not invented here" syndrome!

For me the *.user file is a bit comparable to the CMakeCache file: it
is maintained "internally" by the tools, and even if both are plain text
files, you better do not fiddle around in them manually. Also both are
sometimes simply discarded if the tool "thinks" it cannot recover from
certain changes, but QtCreator seems to be less radical. If e.g you
update your QtCreator version, or move the *user file from a Linux to
a Windows machine, it will only rename and not delete the old version.
And I am not sure, but I think it might still try to extract the one
or other information that can be adopted even in the new surrounding.

Regards, Cornelis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20191003/961f6dc4/attachment-0001.html>