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

[Cornelis Bockemühl]

Dear Tobias,

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

Regarding the versions, I just see that I am living in a somehow "confused
state"! And of course the story on the Linux computer is different from
that on the Windows system.

Linux:

For quite some time I was working on OpenSuse Leap 42.3. Other than on
Windows, on many Linux systems there is an "official" Qt support on board,
and this was for me some QtCreator (I forgot the version), with Qt 5.6.2.
And it stayed like that as long as the version was there, while my project
urgently needed something more recent, at least Qt 5.9.

It gave me some grey hairs to finally install a completely independent
Qt development system, because there were initially some troubles because
it seems like the OpenSuse people had a special compilation of Qt and all,
with some kind of tags in the binaries that should guarantee that you
only use all the same "official version". Ok, Linux would not be Linux if
you could not change also that, but it took me some effort.

And with that I finally ended up with my "own system", with QtCreator 4.4
and Qt 5.9.2.

Now, a couple of months ago, I updated my OpenSuse system from 42.3 to
version 15.1 (funny numbering system, but who cares...). And now that you
are talking about versions, I am realizing that with my "own system" I am
actually now behind the "official" OpenSuse versions, which are QtCreator
version 4.8.2 and Qt 5.9.7.

But what I am going to do now is simply "stay detached" - once I am there
already! So at the moment I am indeed downloading a very fresh 4.11.beta
release from 1 Oct. I assume that I can install it simply next to the
existing installation, so nothing that I can lose if something really
goes wrong - I assume! Download is running - will take some time on my
rather slow connection here, but that's not a problem...

(Only I think I should take care of my *.user files when testing a brand
new beta of QtCreator - if ever I consider to possibly switch back to
"good old safe terrain"! But I already know that QtCreator does not simply
"kill" it in case it rejects an existing version...)

Windows:

Here things are "easier" in the way that Windows does absolutely nothing
on it's own on that system but you have plenty of other trouble - like
the different "build tool versions" - and it gave me another set of grey
hairs finally finding out what is what - and that it is absolutely
essential to have compatible versions there! And in this case the numbering
is far more weird than the logic of OpenSuse - it is just totally mad.
But what I know now is that my versioning status on Windows is

msvc2015 == version 14.00 == toolset 140 == compiler version 1900

Which looks for me like I could also install that latest QtCreator on
the windows system, because from the naming of the binary I conclude
that you also compiled with toolset 140 (and moving to another one is
a major operation - from tools and tool sets to all the projects...)

On the Windows system, my current "state of the art" is QtCreator 4.9.0,
with also Qt 5.9.2. Basically I mostly cared about the Qt version for
my projects, and with the creator I updated from time to time if the tool
told me that there is something new - but this only happens on Windows.

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

No, they don't! I considered that creator naming too complicated, so my
current directory trees are something like

project
- sources
- release
- debug
- docs
- ...

On the windows system I made it even shorter (like src, rel, deb...)
because still nowadays it happens that certain Windows tools are doing
crazy things if paths are getting long...

[...]

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

Right, that's not a problem. The problem is only that you see NOTHING
if there was not at least one successful run of the configure tool!

This is different with the cmake-gui: there you see always "as much as
possible" at a given point.

Ok, since I learned that I am working indeed with a rather old QtCreator,
I will have to see how things are looking in a more recent environment.
(As I already said, I did not care much about QtCreator versions so far -
as long as it was "somehow working". And like I already said: there are
so many things working nicely for long already!)

So I will have to see how the same thing is going now with the newest
beta version - once it is installed and running!

[...]

>Same workflow in Creator;-)

Well - once I see that happen, there will be nothing holding me back
from doing the same process in the creator! With the additional
advantage that it will hopefully not reject the final setup - because
it has generated it with the own means.

[...]

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

Right - and I would probably go back also to my "take notes in a text
file" method to work around it.

Or I can try the "cmake expert variant": rework that "notes text file"
into a proper *.cmake script, then do an initial cmake -C ... run to
fill the cache - and see if QtCreator accepts the result...

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

I guess that with some "hacking" such a transfer could be feasible,
but I have already seen also that in detail it may become more tricky,
so I decided to treat the cmake cache files (like the creator user
files) like "black boxes" labelled with "none of your business"...

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

Well, "feeding" that initial cmake script in such a way would be
something to try: I have seen that you can pass parameters to the cmake
call - and I already did it if I wanted to turn on some more verbose
tracking or things like that.

[...]

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

But why? This would then really be blind "not-invented-here" syndrome!

And of course, if that is the policy, the thing that I am calling
"amnesia" is already explained...

And also the solution would be simple: Just don't do it! Maybe with some
user interaction: "I found an existing setup - should I drop or try to
use it?".

>From a programmer's point of view I understand of course that the latter
may cause endless other problems - because it is ALWAYS a problem to
deal with input that was generated by other tools - or even worse:
manually by the user! You have to expect - and handle! - just about
EVERYTHING - including the biggest nonsense. But on the other hand -
that's real life! ;-)

By the way, there already seems to be a situation when QtCreator asks
indeed whether it should use this or that variant of the setup. I did not
figure out in which situation it happens, and also I never understood
the two options that were offered: which one drops changes that I explicitly
introduced and which one keeps them? But I found out that if I press the
right button of the two, the result is most of the time ok... ;-)

(In this case it seems to be a wording question in the dialog, and other
people may understand better than I do.)

[...]

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

...meaning thus: If I keep it it does simply nothing for me - right? And
dropping it has no effect as well.

[...]

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

Ok, another thing to keep in mind then. However, I would think that in
my case compilers should match, both on the Linux and the Windows system:

- on the Linux system, I just use the "system compiler" - whatever it
  finds there, nothing special

- on the Windows system, if I am working on the command line, I am using
  a specially "prepared" one that sets all the environment ready for
  using msvc2015 tools by default. And the QtCreator I do not start
  directly with the provided shortcut, but I prepared a special shortcut
  that first opens also a command line with the proper environment, and
  only from there I am starting the QtCreator

Maybe it would make sense to treat CMake variables with CMAKE_... differently
than any others - that may be project settings that are not different on
different systems?

However, also the CMAKE_... stuff is a bit "old style cmake", referring
directly to specific tools and versions, while more "modern" cmake also
allows things like "work with c++11", and then it has to figure out which
options have to be set for the one or other tool.

[...]

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

I did not try it yet, but as stated above already: it might be a thing
to try! Of course the initial cmake script makes only sense the first
time you are doing the configuration, but as far as I can see it would
also not hurt if you "feed it in" as many times as you want - if the user
did not decide to change some of the settings manually within the GUI.

[...]

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

In that respect the Visual Studio has a way to deal with at least different
build modes, allowing to specify either for "all" or for "debug", "release"
or whatever explicitly.

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

In some way it is against what I feel like "QtCreator style": as a user,
you are never asked too much things - the creator "just does it" - and
takes "private notes" in the user file...

But there MAY BE certain things that the user does know and where
he would like to interfere with his own preferences!

It's then a question of "style" how much you want to bother him with
"stupid questions"...

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

Right, along that line I would also think it might be a good idea: Not
to "bother" the user with questions, but if he really wants, he might
have the option to do certain "advanced things".

I mean, the "kits" are already a thing like that: the user can generate
some kind of "work surrounding" according to his preferences and use
it for his projects, but "kits" stands for me for "tool kits", while the
above would rather be "setting sets".

[...]

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

...and I have the strong impression that this is basically the root
cause of my troubles!

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

Hmm - sounds even like something worth considering... Because I
actually know pretty well what I want the cmake tool to do for me and
what not! As I explained already, if I am building an entire ParaView,
I download the sources, first set up the cache with the command line
tool and some cmake script with my preferred settings, then I adapt
if necessary in the cmake-gui, and finally do the build using ninja.

The only disadvantage: if I am actively working on the code, I want
to have a development GUI that allows me to navigate between classes,
check my syntax, find my include files, allows me to debug the code
and all - and this is QtCreator! ;-)

But of course all the rest, like the plain setup and build, I could
do also without...

However, even if I feel able to do it: a large number of QtCreator
users would not! So for the QtCreator development I think it is not
a very good option.

[...]

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