[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", find the critical remarks and explanations from CMake
there, then go to that blank properties editor and create a new property
manually, named ThatExternalLib_DIR and also type in the full path
manually (well, copy&paste...), redo the configure run - and in the worst
case you even have to repeat this step until a first "successful run".

PPS: Thanks also for the hint about how to completely avoid conflicts
by telling QtCreator to completely "shut up" and remove the CMake config
from the kit. May be worth a try indeed, but this looks like even more
a step that you would not recommend to people who are not experienced
users of CMake already! And as such I can find also other workarounds
so far...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20191021/0ffb81f9/attachment.html>