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...
_______________________________________________ Qt-creator mailing list Qt-creator@qt-project.org https://lists.qt-project.org/listinfo/qt-creator