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