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

[Cornelis Bockemühl]

Dear Tobias,

Thanks for taking up my suggestions regarding an improvement of the
"conflict dialog"!

One more remark I want to add in a more general way, referring to
the subject of "clash of cultures" between CMake and Qt world and
your following explanations:

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

For me as a user of both CMake and QtCreator, my intuitive decision
regarding "one authoritative source of truth" is very clearly opposite
to what you are stating there! Simply because - if I am working on a
CMake project, no matter with which tool or tool set, I assume that
whatever CMake has written into it's CMakeCache files is "the truth".
And all others, including QtCreator, would have to respect this!

I can understand your point of view as a programmer, dealing with both
my own and "external" logic: there is a huge difference in the amount
of trust I can have in the one and in the other!

Simple example:

i = 33;

vs something like

i = read(something);

In the first case I know exactly that i will be a number - because I
have assigned the value in my own code. In the second case I cannot know
anything, so I have to test a lot in order to make sure that I can
deal with i in the way I want.

And for you the first is everything that is done within QtCreator, while
whatever comes from CMake sources you have to check for consistency
first! Which is tedious and error prone - and best to be avoided. Still -
if "33" is not the thing that you need to handle, but "something" from
"outside"? Then it makes still no sense to go with 33 only because it is
easier to handle!

So in order to avoid all kinds of conflicts, I would try to reduce the
number of things to put into *.user files and work what you find in the
CMakeCache files, so there are no conflicts because only one truth is
available at all! The *.user file should only contain "convenience entries",
like the result of an evaluation of CMakeCache content (and then it has
to be re-evaluated if the CMakeCache is changed), or things that are
not handled by CMake at all.

In practice, one single thing would reduce this conflict a lot for the
user: If the editing of CMake settings would be as good or better than
what you have with the native CMake tools, like cmake-gui and ccmake.

The crucial point is if you download any project from somebody else
and you start by loading it into QtCreator. Then you have two cases:

- The first "configure" run succeeds. Somehow, i.e. the maximum problems
are property values that are not what you need. In that case you can check,
see, adapt and re-run the configuration - and you are fine.

- The first "configure" run fails. Not because there are errors, but it
may be with an imported project (with find_package()) that cannot be
found without specifying the proper path. Then you end up with a completely
blank list of properties and some "dangerous error" on top - and if you
are not an experienced CMake user, this is the end of the story: "does not
work with QtCreator"!

What the experienced CMake user will do is: use the CMake provided
tools, and see directly that he has to provide a value for e.g.
ThatExternalLib_DIR - together with an explanation that this is supposed
to be a path that points to a ThatExternalLibConfig.cmake file (or
similar). And this path can be entered with a nice dialog, and so on,
until the cmake configure run is ok.

But once the result of THIS step is supposed to be imported into
QtCreator, there is that famous conflict - and it makes really no sense
if QtCreator NOW insists in being the "only authoritative source of truth" -
because at this time it has no clue about anything and the user has just
specified everything nicely!

So with this scenario you see that instead of solving the conflict
between CMakeCache and *user file it could simply be avoided with an
improved setup process for existing CMake projects would: The user does
not have to leave the QtCreator world at all, so QtCreator would be and
remain the "master" from the beginning!

Best regards,
Cornelis

PS: Yes I know there is an alternative already now: You can check the
"General Messages", 

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

[Mitch Curtis]

> -Original Message-
> From: Qt-creator  On Behalf Of Andy
> Sent: Wednesday, 9 October 2019 3:42 PM
> To: Cornelis Bockemühl 
> Cc: qt-creator 
> Subject: Re: [Qt-creator] ?==?utf-8?q? Setup of CMake based projects
> 
> Cornelis:
> 
> You aren't the only one! I always have to pause and look hard at this dialog -
> and I'm never sure I chose wisely.
> 
> 
> This has come up at least once or twice on this list and there may be already
> be an issue for it in the system.

https://bugreports.qt.io/browse/QTCREATORBUG-22413
 
> ---
> Andy Maloney  //  https://asmaloney.com
> 
> twitter ~ @asmaloney <https://twitter.com/asmaloney>
> 
> 
> 
> On Wed, Oct 9, 2019 at 9:29 AM Cornelis Bockemühl
> mailto:corne...@bockemuehl.ch> > wrote:
> 
> 
>   Hi Tobias,
> 
>   This is a "side track" of the initial thread about setup problems of
> CMake based projects: I was mentioning the fact that already now the
> QtCreator sometimes asks what to do with certain settings that seem to be
> "changed on disk" - probably meaning: there are differences between *.user
> file and CMakeCache - but I am not really sure. This would be such a dialog
> that I am getting from time to time:
> 
> 
> 
>   And I must admit that so far I had NO CLUE what this dialog really
> wants to ask me! Now I have at least a guess: the expression "changed on
> disk" I interpret now in the way that it refers to the content of the
> CMakeCache file, while "the real project" (compared to which it is
> "changed") must then probably be what comes from the *.user file. Next
> you have that table, with the columns "Key", "CMake" and "Project". After
> our discussion I tend to guess that "CMake" again refers to the CMakeCache,
> while "Project" refers to the *.user file.
> 
>   So far I had no problems if I just press the right one of two buttons,
> but I never had any idea what I am doing with this choice - much less why I
> am asked this question. And I must admit that this kind of "stirring in the 
> fog"
> feels a bit strange...
> 
>   Because: for a "normal human being", ie without being blinded by
> knowing too much internal details of either CMake or QtCreator, both mean
> more or less the same: If you are working with a CMake based project then
> obviously "CMake" is identical with "the project"!
> 
>   In other words: I think this dialog would need a bit of reconsideration
> in terms of wording! Like:
> 
>   - At the top it could be something like "The project has been changed
> outside of QtCreator"
> 
>   - Headers of the table: change the order of columns 2 and 3, then
> replace "Project" by "QtCreator project" and "CMake" by "Changed value"
> 
>   - Finally the buttons should then be "Discard external changes" (left)
> and "Adapt QtCreator project to changes" (right)
> 
>   This assuming that my current understanding which I gained during
> the discussions in this thread is correct!
> 
>   Best regards, Cornelis
> 
>   ___
>   Qt-creator mailing list
>   Qt-creator@qt-project.org <mailto:Qt-creator@qt-project.org>
>   https://lists.qt-project.org/listinfo/qt-creator
> 

___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

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

[Andy]

Cornelis:

You aren't the only one! I always have to pause and look hard at this
dialog - and I'm never sure I chose wisely.

This has come up at least once or twice on this list and there may be
already be an issue for it in the system.

---
Andy Maloney  //  https://asmaloney.com
twitter ~ @asmaloney 



On Wed, Oct 9, 2019 at 9:29 AM Cornelis Bockemühl 
wrote:

> Hi Tobias,
>
> This is a "side track" of the initial thread about setup problems of CMake
> based projects: I was mentioning the fact that already now the QtCreator
> sometimes asks what to do with certain settings that seem to be "changed on
> disk" - probably meaning: there are differences between *.user file and
> CMakeCache - but I am not really sure. This would be such a dialog that I
> am getting from time to time:
>
>
>
> And I must admit that so far I had NO CLUE what this dialog really wants
> to ask me! Now I have at least a guess: the expression "changed on disk" I
> interpret now in the way that it refers to the content of the CMakeCache
> file, while "the real project" (compared to which it is "changed") must
> then probably be what comes from the *.user file. Next you have that table,
> with the columns "Key", "CMake" and "Project". After our discussion I tend
> to guess that "CMake" again refers to the CMakeCache, while "Project"
> refers to the *.user file.
>
> So far I had no problems if I just press the right one of two buttons, but
> I never had any idea what I am doing with this choice - much less why I am
> asked this question. And I must admit that this kind of "stirring in the
> fog" feels a bit strange...
>
> Because: for a "normal human being", ie without being blinded by knowing
> too much internal details of either CMake or QtCreator, both mean more or
> less the same: If you are working with a CMake based project then obviously
> "CMake" is identical with "the project"!
>
> In other words: I think this dialog would need a bit of reconsideration in
> terms of wording! Like:
>
> - At the top it could be something like "The project has been changed
> outside of QtCreator"
>
> - Headers of the table: change the order of columns 2 and 3, then replace
> "Project" by "QtCreator project" and "CMake" by "Changed value"
>
> - Finally the buttons should then be "Discard external changes" (left) and
> "Adapt QtCreator project to changes" (right)
>
> This assuming that my current understanding which I gained during the
> discussions in this thread is correct!
>
> Best regards, Cornelis
> ___
> Qt-creator mailing list
> Qt-creator@qt-project.org
> https://lists.qt-project.org/listinfo/qt-creator
>
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

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

[Cornelis Bockemühl]

Hi Tobias,

This is a "side track" of the initial thread about setup problems of CMake 
based projects: I was mentioning the fact that already now the QtCreator 
sometimes asks what to do with certain settings that seem to be "changed on 
disk" - probably meaning: there are differences between *.user file and 
CMakeCache - but I am not really sure. This would be such a dialog that I am 
getting from time to time:



And I must admit that so far I had NO CLUE what this dialog really wants to ask 
me! Now I have at least a guess: the expression "changed on disk" I interpret 
now in the way that it refers to the content of the CMakeCache file, while "the 
real project" (compared to which it is "changed") must then probably be what 
comes from the *.user file. Next you have that table, with the columns "Key", 
"CMake" and "Project". After our discussion I tend to guess that "CMake" again 
refers to the CMakeCache, while "Project" refers to the *.user file.

So far I had no problems if I just press the right one of two buttons, but I 
never had any idea what I am doing with this choice - much less why I am asked 
this question. And I must admit that this kind of "stirring in the fog" feels a 
bit strange...

Because: for a "normal human being", ie without being blinded by knowing too 
much internal details of either CMake or QtCreator, both mean more or less the 
same: If you are working with a CMake based project then obviously "CMake" is 
identical with "the project"!

In other words: I think this dialog would need a bit of reconsideration in 
terms of wording! Like:

- At the top it could be something like "The project has been changed outside 
of QtCreator"

- Headers of the table: change the order of columns 2 and 3, then replace 
"Project" by "QtCreator project" and "CMake" by "Changed value"

- Finally the buttons should then be "Discard external changes" (left) and 
"Adapt QtCreator project to changes" (right)

This assuming that my current understanding which I gained during the 
discussions in this thread is correct!

Best regards, Cornelis
___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator

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

[André Hartmann]

Hi all,

Sorry for hijacking this thread, but I instantly created a suggestion
[1] that tangents this topic.

Not only with CMake, also with other build systems there are often
several steps needed after checking out a project and before working on it.

I remember Tobias mentioned the wish to create a wizard for such setup
tasks a long time ago, but I didn't find a Jira task, therefore I
created one.

Please feel free to join the discussion there.

Regards,
André

[1] https://bugreports.qt.io/browse/QTCREATORBUG-23041

On 04.10.19 11:31, Cornelis Bockemühl wrote:

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 

Re: [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 

Re: [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 ".
>
>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