[Qt-creator] Setup of CMake based projects

[Tobias Hunger]

Hi Cornelis,

On Thu, Oct 3, 2019 at 11:56 PM Cornelis Bockemühl
<cornelis at bockemuehl.ch> wrote:
> 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.

The CMake version is great, it already has fileapi! Unfortunately your
Creator is too old to make use of it.

For the CMake version you use, the 4.11 snapshots will work best. You
can find binaries over at
https://download.qt.io/snapshots/qtcreator/4.11/ , so no need to build
this yourself.

You really want fileapi, that is way more stable than server-mode,
especially when you run of and just run cmake yourself while creator
is running. CMake does not like that at all:-)

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

Do they match the naming scheme creator has for those directories?

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

... already done for you in Creator ...

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

... generator is already defined for you in creator ...

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

That is a good point: The configuration run output is not visible in
project mode:-/

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

Creator prints the changed values in italics, not in red.

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

Creator will offer a file selector as well -- when the type is set
correctly in CMake. Well, it needs to be able to read the settings for
that to work.

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

As I said before: That should not happen:-) I'll check on Monday when
I am back in the office.

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

Same workflow in Creator;-)

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

Just hit build:-)

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

You have the same problem in creator:-/

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

You will need to adapt it a bit. It has the source and build paths in
there somewhere.

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

It should still retrieve the configuration data. That works for me.

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

I see people having scripts that run "cmake -DFOO=bar -D...".

ToolChain files are apparently also used sometimes.

> Yes, I also think that the creator *should* do that - at least in the
> cases where also the cmake-gui is doing it properly!

"It should" as in "that works for me(TM)".

[...]

> 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

Well, that way it will not try to import, it will assume the directory
is empty and
run cmake with all the configuration option, probably overriding your
configuration.

[...]

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

That is surprising then!

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

"CodeBlocks" is necessary to parse projects with CMake < 3.7. Creator
still sets it, just in case somebody decides to use such a old cmake.

> Of course I can
> try once without that, but I don't expect this to change a lot regarding
> my problems!?

Probably not. It should make it straight forward to set up projects;-)

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

Usually that happens when the compilers auto-detected by CMake and
those defined in the Kit in creator do not match.

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

Most of these do not make too much sense for the kits, true.

But some like the CMAKE_PREFIX_PATH could make sense at the kit level.

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

People around me seem to have shell scripts that call "cmake -DFOO=bar
[...]" to do the initial configuration.

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

I guess it all depends:-)

Some settings are definitely project specific and those make little
sense in the Kit. But if you have lots of Paraview projects, then it
might make sense to have all the settings related to setting that up
in a kit.

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

Good point. We probably need something 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.
>
> 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...

Ok, I'll keep that in the back of my mind. Let's see what can be done here.

Maybe being able to select several entries and export them to a
different build configuration is enough already?

The challenge is that creator does not really know what the user
actually did set, so this needs some user interaction.

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

It is implemented,

> The bug could only be the case that you have an existing and working
> CMakeCache that is rejected for no obvious reason.

If not asked to import a directory, Creator will override CMake
whenever it sees settings that do not match up with its expectations.

Typically the compiler paths mismatch between a project and creator.
Some settings can not be changed once the CMakeCache.txt file is
there, so creator will start from scratch. There can only be one
authoritive source of truth: Should that be creator or CMake? I am not
impartial, so I will always chose creator;-)

You can override the default (Creator is boss) by changing your kits:
Remove the CMake Configuration from there and creator will not even
attempt to tell cmake anything (but the CMAKE_BUILD_TYPE).

You then need to make sure yourself that the compilers used by CMake
match those set up in the Kit. If you ignore this, then the code model
will be less precise as it will take macros and include paths from the
wrong compiler.

[...]

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

Please try a current Creator. Things did improve during the last two years;-)

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

Yes, Creator will keep "old" files around and will read the file
version that is "closest" to its version. It will also upgrade old
files to new syntax automatically.

Best Regards,
Tobias