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 <path to CMakeLists.txt of the project>". > >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 you are wrong: cmake will "see" that the cache has been "transplanted" - and refuse to work with it. (My guess is that a variant of this behaviour is also the reason for the "amnesia" that QtCreator is sometimes showing: if cmake refuses to work - what can QtCreator do?) This is then the moment where you may ask the CMake profis how they are doing - and you will get the answer: we are writing some my_config.cmake modules or scrupts and "feed" them into the cmake - without the GUI! And at that point I am getting the impression, that "cmake culture" is mostly about command line operations, while Qt is first of all the best GUI library that I know, so "Qt culture" is definitely GUI. [...] >Creator *should* detect existing builds, but it only tries directories >close to those it would create itself, so it might just be missing >yours. Could you try to adapt your default build directories in >Tools>Options>Build & Run>Somewhere to match your naming scheme before >opening the project for the first time? Do your build directories get >picked up when you change that? Yes, I also think that the creator *should* do that - at least in the cases where also the cmake-gui is doing it properly! Which means in cases where the CMakeCache was not moved to another folder or other "evil things". The steps I am trying with QtCreator are simple, so no searching needed for QtCreator: - "open" the project, which is the CMakeLists.txt file in the source directory - 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 So I cannot see any reason why the creator should be missing anything! >If Creator does not pick up your build directories: At the very end of >the list of possible Kits there should also be a button labeled >something like "Import build"(?). Could you please try that to import >the two builds of yours? Does that work better? That I have neither seen nor tried yet: I will have to do it tomorrow! [...] >Could you try to upgrade your CMake if you are in that range? I am far beyond that version range - see above! And I have realized the huge progress in cooperation between QtCreator and CMake that happened with increasing version numbers of both QtCreator and CMake during the past few years! [...] >My assumption is that users will just create Kits for things they use >often. Well, so far I did not fiddle a lot with the kits - except to make sure that they are using the right compiler, debugger, Qt version etc. And once I have that ready on either my Linux or my Windows machine, I do not touch it a lot... >If you work a lot with paraview, you could clone one of your existing >kits and add the required settings there: Each has a CMake >Configuration section (among other things;-). You can also check the >other settings while in Tools>Options>Kits>Kit :-) If you do not use >CMake older than 3.7, then you definitely do not need the CodeBlocks >extra generator. If you do not use Qt 4, then you can remove the >QMAKE_PATH(?) setting from CMake's Configuration as well. In these kits sections I have indeed still that CodeBlocks extra generator, together with ninja, and my understanding was that ninja is the "make" tool while CodeBlocks generates some files that finally allow to see my source code in the "projects" section of the main GUI. Of course I can try once without that, but I don't expect this to change a lot regarding my problems!? >Any build configuration will automatically get all the kits' CMake >configuration plus the CMAKE_BUILD_TYPE appropriate for the build >configuration when configuring initially. There is indeed some "magic" going on that I did not understand. My impression is that it is the only area where QtCreator somehow tries to "optimize" the cmake behaviour, like setting the build type properly, thus overwriting a "Release" or "Debug" setting that might be in the cache already. What else it "fiddles around" - no idea! -, but maybe it is the thing where also something fails in such a way that the entire cache is finally dropped as "not invented here"!?? >Would creating kits work for you? Or what would you want to have here? Depends on whether they would do the job ;-) For me the kits is about choosing the right tools, like ninja or Visual Studio or nmake for the make tool, or the compiler and linker version, or the Qt version for a project. In the case of a big project like ParaView, you would typically have settings or options that can be turned on or off, or otherwise configured, like: "use the math module" "use python" "python version 2 or 3" "use the xyz plugin" etc etc - endless! These things you can put into a my_config.cmake script which you can "feed" to the cmake configuration run with the -C option: in that case, the provided settings will first be written into the cache, and only then cmake will start reading CMakeLists.txt - with the initial cache variables already in place. If it would be a good idea to have a page in the "kits" setup that includes such project specific settings!? For me it would not be the logical place - except that it would of course allow to carry the settings not only between build types, but even to other variants of the same project. 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. In the "cmake command line culture", you do such a thing with a config file somehow, while in the "qt gui culture" it is the question in which dialog it would belong... >IIRC there is already a feature request to "mass-export" settings from >one build configuration into another. I am not really sure how a good >UI for functionality like that would look like. 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... >> BOTTOM LINE after this long story: >> >> 1) it would be great if the QtCreator project setup for CMake projects >> would at least be at the comfort level of cmake-gui, like with a >> file/directory dialog and with a display also of unfinished setup >> - with the option to complete it. > >That should work. Could you please open a bug report for this? Well, as far as I can see, this is not really a "bug" but already a feature request! The bug could only be the case that you have an existing and working CMakeCache that is rejected for no obvious reason. Which may not happen in smaller projects, while giving a big project as a "reproducible case" that only makes a bug report "realistic" is a bit difficult. Ideally I would have to spend some time to "melt down" the project so much that I can reproduce the behaviour also with a rather small project... >> 2) it would be great if the QtCreator setup process for CMake would >> allow to "inject" the kind of "my_config.cmake" setup files directly >> into the project setup process, like with the -C option of cmake. >> >> 3) and the most phantastic thing would be to even GENERATE such a >> configuration file - from the steps that a user is doing during an >> initial setup in the "cmake-gui" trial&error way: with that it would >> even overcome a major shortcoming from the "cmake culture"! > >There is no way to know what a user has set explicitly via cmake-gui >or via "cmake -DFOO=bar". There is little I can do about that:-/ No, that would be "magic" indeed! Only if the QtCreator would allow the same kind of "interactive iteration" process like the cmake-gui, then it could of course keep track of what the user changed compared to what the initial setup was - and remember that somehow for further use. However, this is a thing that also the cmake people are not doing yet, so the dream still needs to develop some clearer contours. I am simply thinking about how I am "taking notes" in an editor window that I have open next to the cmake-gui - and where I simply write down all the settings that I am changing. This I can then easily rework into such a my_config.cmake file. >The settings you changed via creator are actually stored in your .user >file in the build directory (for each build configuration). It should >not be too hard to extract those, but considering that you do all the >heavy lifting in cmake-gui, I doubt that will be very useful for you. I would definitely prefer to do it in QtCreator - if it was possible! - because I would not have to change the tool for just this one job - because it would also avoid any reason for the creator to suffer from the "not invented here" syndrome! For me the *.user file is a bit comparable to the CMakeCache file: it is maintained "internally" by the tools, and even if both are plain text files, you better do not fiddle around in them manually. Also both are sometimes simply discarded if the tool "thinks" it cannot recover from certain changes, but QtCreator seems to be less radical. If e.g you update your QtCreator version, or move the *user file from a Linux to a Windows machine, it will only rename and not delete the old version. And I am not sure, but I think it might still try to extract the one or other information that can be adopted even in the new surrounding. Regards, Cornelis
_______________________________________________ Qt-creator mailing list Qt-creator@qt-project.org https://lists.qt-project.org/listinfo/qt-creator
