Re: [Qt-creator] Refactoring the CMake plugin
> 1) Registering new cmake instances / tools > > The idea is to provide a way for plugins to register their own > cmake installation > and I introduced a class called CMakeManager that will own all > registered installations. > Every registered cmake will be represented by a CMakeTool instance, > that abstracts away > how a specific cmake is invoked. > > To register them I can see 2 ways: > > a) using factories: > Personally I like factories more, maybe the approach used by > the toolchains would fit here too (QList > Factory::autoDetect()). > That would also require a UI in the settings dialog where the user > can manage the > available cmake tools and manually register them. > > b) provide a function called registerCMakeTool() in the I'd like to see more than just a ubuntu sdk specific use case for this. As is, I don't see much value in that. > CMakeManager that can > be called by plugins. > > 2) Associating a cmake tool with a build > > Now that there is a way to have more than one possible cmake, there > needs to > be a way to control which cmake is used when building/creating the > project files. > > a) By linking it to a Kit > -> provide a CMakeKitInformation so the user can control which > Kit uses which > cmake tool > > b) By linking it to a build configuration > -> a CMakeBuildConfiguration would either need to return a > Core::Id specifying the > cmake tool it wants to use, or the CMakeTool instance itself, so > the IDE can use it > to create the build files. The build configurations config > widget then can provide a > way for the user to switch between the cmake installations > available. Like Tobias said, definitely in the kit. > 3) Automatically running cmake in the background (Get rid of the "Run > cmake" dialog) > > It would be nice if the user was not required to handle the cmake > dialog > every time he wants to change the build settings, cmake arguments > or wants to > switch between different build configurations. > > In my MR, a cmake run is automatically started every time the build > settings are changed and when opening a unconfigured project the > project > configuration page is used. At first sight this is very similar to > how qmake behaves and makes it easily > possible to switch between multiple build configurations without > the need for running > the cmake dialog every time. But the difference of course is that > there are files created when running cmake > and the user does probably not know about that. > > --> A possible solution to this would be to open a dialog to change > the build settings, but to > run cmake automatically when switching between build > configurations. This would make the user more aware of what > is happening. Right, that would work. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Refactoring the CMake plugin
Am 18.06.2014 12:38, schrieb Benjamin Zeller:> Hello, > > I'm working on up-streaming the changes I made on the CMake plugin > for the Ubuntu SDK, this all slowed down in the last weeks because > I was really busy with other tasks. Seeing all this negative energy in this thread I figured I should thank you and Canonical for all this work: CMake integration is just getting better and better. It has improved dramatically since I've used it first something like two years ago. Actually using QtCreator with CMake is quite enjoyable those days. Only minor bits are missing to turn CMake into the QtCreator's build system of choice - in my very subjective and personal opinion. "Minor bits" like editing the CMakeList.txt from wizards and the project explorer. Sadly they are not trivial to implement and not really needed in daily usage. Still they seem important for the final polish. So keep on rocking, Mathias ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Refactoring the CMake plugin
On Jun 20, 2014, at 10:10 AM, Hunger Tobias wrote: > On 19.06.2014 23:29, Benjamin Zeller wrote: >> Am 19.06.2014 00:13, schrieb Miller Henry: >>> On question 3: >>> >>> When switching project configurations, if the build is at all out of date >>> the first thing I'm going to do is re-run make anyway. The only other >>> option that makes sense it to completely blow away the build directory and >>> re-run cmake. I would go so far as making it an option to just run a full >>> build anytime I switch my build configuration (default to true as it is >>> what the user wants even though it violates some purists expectation that >>> no files will be written). I find it very annoying to have this cmake >>> dialog pop up when I open an out of date build, as I'm just going to hit >>> run and wait for it to complete. So long as no build option is being >>> changed, I want qt creator to write the files it needs and not bother me. >> Thats almost what my current patch is doing, it runs cmake in the >> background when you change >> configurations, always, without popping up the dialog. >> If you want to change arguments you can do so in the build settings. >> CMake will then >> be run automatically in the background when you leave the lineedit you >> changed your settings in. >> However this does create files without notice which is really a problem >> when for example you change >> the builddir many times, you might end up with n buildfolders on your >> harddisk. > > You could only run cmake if the builddir already exists and have the > user go through the run cmake dialog otherwise. It must exist and already “be a cmake build directory”, at least. But even that might not be sufficient. All this only works if the user currently pretty much knows the correct build dir s/he wants to set, before fiddling around with the build directory setting. Situations where files could be generated at places where they shouldn’t: * User temporarily sets the value to an existing directory (like a common project root), and then uses the browse button or an external file browser to actually find out the right subdirectory. In that case the directory exists, but Qt Creator should not put any files there * User copies the path from an existing project into the line edit, to later change it from there to the correct one. In this case the directory exists and actually might *be* a “cmake build directory”, just for a different project. No files should be generated. In both cases it is perfectly valid for the user to “leave the line edit” before correcting the setting to its actual value. Br, Eike >> I think it would probably be possible to run cmake automatically when >> you finished editing a cmake >> file, because in that case you did not change any builddir settings. You >> can again say that there might >> be cases when new files are created on the harddisk, but only in the >> builddirectory you specified anyway >> so I think that should be acceptable, right? > > I think so, yes. I am not the maintainer though:-) > > My personal opinion is that the builddir is property of the build system > and it is basically free to do in there what it wants. Creator just > should not add random directories (build directories and of course > others as well) without being very explicit about it doing that. > >>> Now if the cmake dialog acted more like ccmake and let me change cached >>> options that might be useful: the only thing valid to do from the cmake >>> dialog in an existing build directory is change options that ccmake could >>> change for you, but since I only have access to the command line of cmake >>> this isn't convenient. I'm not sure if the cmake cache files are in a >>> stable format where it would be valid for qt creator to do this, but it >>> would be ideal. >> Hm i wonder if cmake has some embeddable tool we could use for that. >>> >>> One annoyance I have is once in a while an automated build fails, when I >>> open qt creator it tries to run cmake, which fails because of a syntax >>> error. There is no easy way to open the offending file in qt creator so I >>> can fix the error(s). If you can do something about this I'd be grateful. >>> At least I'd like it if an outdated project configuration could be used >>> because that will have 95% of what I need. >> Also almost what the patch does, but what will not work of course is >> when you open the project for the >> first time and the project file is invalid, then you will only see the >> "root" project file. >> Once the project is open it will not remove the files from the tree when >> you somehow change your >> project file and add a error to it. > > Ideally a cmake error would be listed as a build issue, so that you can > get to the right file/line from there. That is independent of whether > the file is actually in the project tree already. > > Best Regards, > Tobias > ___ > Qt-c
Re: [Qt-creator] Refactoring the CMake plugin
On 19.06.2014 23:29, Benjamin Zeller wrote: > Am 19.06.2014 00:13, schrieb Miller Henry: >> On question 3: >> >> When switching project configurations, if the build is at all out of date >> the first thing I'm going to do is re-run make anyway. The only other >> option that makes sense it to completely blow away the build directory and >> re-run cmake. I would go so far as making it an option to just run a full >> build anytime I switch my build configuration (default to true as it is what >> the user wants even though it violates some purists expectation that no >> files will be written). I find it very annoying to have this cmake dialog >> pop up when I open an out of date build, as I'm just going to hit run and >> wait for it to complete. So long as no build option is being changed, I >> want qt creator to write the files it needs and not bother me. > Thats almost what my current patch is doing, it runs cmake in the > background when you change > configurations, always, without popping up the dialog. > If you want to change arguments you can do so in the build settings. > CMake will then > be run automatically in the background when you leave the lineedit you > changed your settings in. > However this does create files without notice which is really a problem > when for example you change > the builddir many times, you might end up with n buildfolders on your > harddisk. You could only run cmake if the builddir already exists and have the user go through the run cmake dialog otherwise. > I think it would probably be possible to run cmake automatically when > you finished editing a cmake > file, because in that case you did not change any builddir settings. You > can again say that there might > be cases when new files are created on the harddisk, but only in the > builddirectory you specified anyway > so I think that should be acceptable, right? I think so, yes. I am not the maintainer though:-) My personal opinion is that the builddir is property of the build system and it is basically free to do in there what it wants. Creator just should not add random directories (build directories and of course others as well) without being very explicit about it doing that. >> Now if the cmake dialog acted more like ccmake and let me change cached >> options that might be useful: the only thing valid to do from the cmake >> dialog in an existing build directory is change options that ccmake could >> change for you, but since I only have access to the command line of cmake >> this isn't convenient. I'm not sure if the cmake cache files are in a stable >> format where it would be valid for qt creator to do this, but it would be >> ideal. > Hm i wonder if cmake has some embeddable tool we could use for that. >> >> One annoyance I have is once in a while an automated build fails, when I >> open qt creator it tries to run cmake, which fails because of a syntax >> error. There is no easy way to open the offending file in qt creator so I >> can fix the error(s). If you can do something about this I'd be grateful. >> At least I'd like it if an outdated project configuration could be used >> because that will have 95% of what I need. > Also almost what the patch does, but what will not work of course is > when you open the project for the > first time and the project file is invalid, then you will only see the > "root" project file. > Once the project is open it will not remove the files from the tree when > you somehow change your > project file and add a error to it. Ideally a cmake error would be listed as a build issue, so that you can get to the right file/line from there. That is independent of whether the file is actually in the project tree already. Best Regards, Tobias ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Refactoring the CMake plugin
Am 19.06.2014 00:13, schrieb Miller Henry: > On question 3: > > When switching project configurations, if the build is at all out of date the > first thing I'm going to do is re-run make anyway. The only other option > that makes sense it to completely blow away the build directory and re-run > cmake. I would go so far as making it an option to just run a full build > anytime I switch my build configuration (default to true as it is what the > user wants even though it violates some purists expectation that no files > will be written). I find it very annoying to have this cmake dialog pop up > when I open an out of date build, as I'm just going to hit run and wait for > it to complete. So long as no build option is being changed, I want qt > creator to write the files it needs and not bother me. Thats almost what my current patch is doing, it runs cmake in the background when you change configurations, always, without popping up the dialog. If you want to change arguments you can do so in the build settings. CMake will then be run automatically in the background when you leave the lineedit you changed your settings in. However this does create files without notice which is really a problem when for example you change the builddir many times, you might end up with n buildfolders on your harddisk. I think it would probably be possible to run cmake automatically when you finished editing a cmake file, because in that case you did not change any builddir settings. You can again say that there might be cases when new files are created on the harddisk, but only in the builddirectory you specified anyway so I think that should be acceptable, right? > > Now if the cmake dialog acted more like ccmake and let me change cached > options that might be useful: the only thing valid to do from the cmake > dialog in an existing build directory is change options that ccmake could > change for you, but since I only have access to the command line of cmake > this isn't convenient. I'm not sure if the cmake cache files are in a stable > format where it would be valid for qt creator to do this, but it would be > ideal. Hm i wonder if cmake has some embeddable tool we could use for that. > > One annoyance I have is once in a while an automated build fails, when I open > qt creator it tries to run cmake, which fails because of a syntax error. > There is no easy way to open the offending file in qt creator so I can fix > the error(s). If you can do something about this I'd be grateful. At least > I'd like it if an outdated project configuration could be used because that > will have 95% of what I need. Also almost what the patch does, but what will not work of course is when you open the project for the first time and the project file is invalid, then you will only see the "root" project file. Once the project is open it will not remove the files from the tree when you somehow change your project file and add a error to it. > > -Original Message- > From: qt-creator-bounces+millerhenry=johndeere@qt-project.org > [mailto:qt-creator-bounces+millerhenry=johndeere@qt-project.org] On > Behalf Of Benjamin Zeller > Sent: Wednesday, June 18, 2014 5:39 AM > To: qt-creator@qt-project.org > Subject: [Qt-creator] Refactoring the CMake plugin > > Hello, > > I'm working on up-streaming the changes I made on the CMake plugin for the > Ubuntu SDK, this all slowed down in the last weeks because I was really busy > with other tasks. > > https://codereview.qt-project.org/80708 > https://codereview.qt-project.org/80709 > https://codereview.qt-project.org/80710 > > These are the merge requests, but they still have lots of comments about how > things should be done and unrelated changes ,which made me wonder if it would > be better to start over and get a set of clean patches. > > But before I start doing that I would like to discuss how the plugin should > work and how it should be implemented. > > There are 3 features I would like to get into the CMake plugin: > > 1) Registering new cmake instances / tools > > The idea is to provide a way for plugins to register their own cmake > installation > and I introduced a class called CMakeManager that will own all > registered installations. > Every registered cmake will be represented by a CMakeTool instance, that > abstracts away > how a specific cmake is invoked. > > To register them I can see 2 ways: > > a) using factories: > Personally I like factories more, maybe the approach used by > the toolchains would fit here too (QList > Factory::autoDetect()). > That would also require a UI in the settings dialog where the user can > manage t
Re: [Qt-creator] Refactoring the CMake plugin
On Jun 18, 2014, at 11:26 AM, Lorenz Haas wrote: > Hi Benjamin, > > I can't say anything to your questions :( but I have a small side > note/request (as well as to everyone working on the CMake plugin) :) > > If you rework the CMake plugin could add an option that the header and > source files - as well as ui and qrc files -, displayed in the project > view, getting arranged in groups, that would be nice. Similar the view > of a normal qmake based project where you have the virtual folders > "Headers", "Sources"... (Maybe by parsing source_group, which would > provide a maximum of flexibility?) > > > Best regards, > Lorenz > > P.s.: Another issue is how to have an equivalent for OTHER_FILES in > CMake based projects. Currently I use "add_custom_target(Foo ALL SOURCES > myfile.txt)". Good, bad, other suggestions? If there is a good > "official" way of doing that, we should add that to the documentation. Just my 2 Cents on the Cmake Plugin: If I edit a Cmake file, then the next time I build cmake runs and generates the build system files. I would like it if QtCreator would automatically pick up on that and update my project so I do not have to keep manually clicking the "Run CMake" menu. Or at least have this as an option. Also, as far as getting ALL your files into QtCreator I usually have a cmake variable where I gather all the sources, files, UI files, icons, documentation and all the for a give target and then that CMake variable is used in the add_executable() command. Then QtCreator finds and lists all my files in a nice hierarchy very well. Thanks Mike Jackson ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Refactoring the CMake plugin
Hi, > Add_custom_target is how cmake documentation says to do this. thanks for the confirmation that add_custom_target is fine (and right) to use. Lorenz ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Refactoring the CMake plugin
Tobias Hunger wrote: >> Lorenz, if you need information or >> features from CMake, then the CMake mailing list is the place to say what >> you need. > > This is pretty much at the intersection of Qt Creator and cmake, so asking > fellow cmake plugin users send appropriate to me. You mean s/send/seems/ ? If anyone needs anything *from* cmake that it doesn't provide, then the cmake list seems appropriate to me. Thanks, Steve. ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Refactoring the CMake plugin
On Jun 19, 2014 8:53 AM, "Stephen Kelly" wrote: > I have no idea what you are referring to. Readers shouldn't treat it as > truth just because you said it :). That is why I said "from the little I heard". I hope that made it sufficiently clear that I was repeating information I picked up along the way:) I am aware that my filterbubble has quite a few people that are no fans of cmake, so I try to make that clear. Sorry if I failed in this mission here. > Lorenz, if you need information or > features from CMake, then the CMake mailing list is the place to say what > you need. This is pretty much at the intersection of Qt Creator and cmake, so asking fellow cmake plugin users send appropriate to me. Best Regards, Tobias ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Refactoring the CMake plugin
Tobias Hunger wrote: > Yes, they are willing to add new new generators so > that IDEs can consume the results of cmake runs more easily, but from > the little I heard there is little love for adding features that are > not necessary to build files per se. I have no idea what you are referring to. Readers shouldn't treat it as truth just because you said it :). Lorenz, if you need information or features from CMake, then the CMake mailing list is the place to say what you need. At least CMAKE_EXPORT_COMPILE_COMMANDS (designed by clang developers for clang tooling) is a counter example for what you wrote. Thanks, Steve. ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Refactoring the CMake plugin
On question 3: When switching project configurations, if the build is at all out of date the first thing I'm going to do is re-run make anyway. The only other option that makes sense it to completely blow away the build directory and re-run cmake. I would go so far as making it an option to just run a full build anytime I switch my build configuration (default to true as it is what the user wants even though it violates some purists expectation that no files will be written). I find it very annoying to have this cmake dialog pop up when I open an out of date build, as I'm just going to hit run and wait for it to complete. So long as no build option is being changed, I want qt creator to write the files it needs and not bother me. Now if the cmake dialog acted more like ccmake and let me change cached options that might be useful: the only thing valid to do from the cmake dialog in an existing build directory is change options that ccmake could change for you, but since I only have access to the command line of cmake this isn't convenient. I'm not sure if the cmake cache files are in a stable format where it would be valid for qt creator to do this, but it would be ideal. One annoyance I have is once in a while an automated build fails, when I open qt creator it tries to run cmake, which fails because of a syntax error. There is no easy way to open the offending file in qt creator so I can fix the error(s). If you can do something about this I'd be grateful. At least I'd like it if an outdated project configuration could be used because that will have 95% of what I need. -Original Message- From: qt-creator-bounces+millerhenry=johndeere@qt-project.org [mailto:qt-creator-bounces+millerhenry=johndeere@qt-project.org] On Behalf Of Benjamin Zeller Sent: Wednesday, June 18, 2014 5:39 AM To: qt-creator@qt-project.org Subject: [Qt-creator] Refactoring the CMake plugin Hello, I'm working on up-streaming the changes I made on the CMake plugin for the Ubuntu SDK, this all slowed down in the last weeks because I was really busy with other tasks. https://codereview.qt-project.org/80708 https://codereview.qt-project.org/80709 https://codereview.qt-project.org/80710 These are the merge requests, but they still have lots of comments about how things should be done and unrelated changes ,which made me wonder if it would be better to start over and get a set of clean patches. But before I start doing that I would like to discuss how the plugin should work and how it should be implemented. There are 3 features I would like to get into the CMake plugin: 1) Registering new cmake instances / tools The idea is to provide a way for plugins to register their own cmake installation and I introduced a class called CMakeManager that will own all registered installations. Every registered cmake will be represented by a CMakeTool instance, that abstracts away how a specific cmake is invoked. To register them I can see 2 ways: a) using factories: Personally I like factories more, maybe the approach used by the toolchains would fit here too (QList Factory::autoDetect()). That would also require a UI in the settings dialog where the user can manage the available cmake tools and manually register them. b) provide a function called registerCMakeTool() in the CMakeManager that can be called by plugins. 2) Associating a cmake tool with a build Now that there is a way to have more than one possible cmake, there needs to be a way to control which cmake is used when building/creating the project files. a) By linking it to a Kit -> provide a CMakeKitInformation so the user can control which Kit uses which cmake tool b) By linking it to a build configuration -> a CMakeBuildConfiguration would either need to return a Core::Id specifying the cmake tool it wants to use, or the CMakeTool instance itself, so the IDE can use it to create the build files. The build configurations config widget then can provide a way for the user to switch between the cmake installations available. 3) Automatically running cmake in the background (Get rid of the "Run cmake" dialog) It would be nice if the user was not required to handle the cmake dialog every time he wants to change the build settings, cmake arguments or wants to switch between different build configurations. In my MR, a cmake run is automatically started every time the build settings are changed and when opening a unconfigured project the project configuration page is used. At first sight this is very similar to how qmake behaves and makes it easily possible to switch between multiple build configurations without the need for running the cmake dialog every time. But the difference of course
Re: [Qt-creator] Refactoring the CMake plugin
Add_custom_target is how cmake documentation says to do this. http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:add_custom_target The SOURCES option specifies additional source files to be included in the custom target. Specified source files will be added to IDE project files for convenience in editing even if they have not build rules. -Original Message- From: qt-creator-bounces+millerhenry=johndeere@qt-project.org [mailto:qt-creator-bounces+millerhenry=johndeere@qt-project.org] On Behalf Of Lorenz Haas Sent: Wednesday, June 18, 2014 10:27 AM To: qt-creator@qt-project.org Subject: Re: [Qt-creator] Refactoring the CMake plugin Hi Benjamin, I can't say anything to your questions :( but I have a small side note/request (as well as to everyone working on the CMake plugin) :) If you rework the CMake plugin could add an option that the header and source files - as well as ui and qrc files -, displayed in the project view, getting arranged in groups, that would be nice. Similar the view of a normal qmake based project where you have the virtual folders "Headers", "Sources"... (Maybe by parsing source_group, which would provide a maximum of flexibility?) Best regards, Lorenz P.s.: Another issue is how to have an equivalent for OTHER_FILES in CMake based projects. Currently I use "add_custom_target(Foo ALL SOURCES myfile.txt)". Good, bad, other suggestions? If there is a good "official" way of doing that, we should add that to the documentation. ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Refactoring the CMake plugin
Lorenz Haas wrote: > P.s.: Another issue is how to have an equivalent for OTHER_FILES in > CMake based projects. Currently I use "add_custom_target(Foo ALL SOURCES > myfile.txt)". Good, bad, other suggestions? If there is a good > "official" way of doing that, we should add that to the documentation. add_executable(main main.cpp myfile.txt) ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Refactoring the CMake plugin
Hi Lorenz, I doubt that this will be possible: The project view is meant to visualize the structure of the build system, so it tries to stay true to how the things are organized there.it CMake unfortunately has basically one flat list of files that it considers as inputs, so that is what creator displays. For the same reason I doubt that you will get OTHER_FILES in Cmake. But then there is a new cmake 3.0 out that I did not yet look into. Maybe they extended it? I am not optimistic about that: These things are not strictly necessary to build (and are indeed mostly for IDE support) and so far the cmake authors did not show too much interest in supporting IDEs. Yes, they are willing to add new new generators so that IDEs can consume the results of cmake runs more easily, but from the little I heard there is little love for adding features that are not necessary to build files per se. Best Regards, Tobias On Wed, Jun 18, 2014 at 5:26 PM, Lorenz Haas wrote: > Hi Benjamin, > > I can't say anything to your questions :( but I have a small side > note/request (as well as to everyone working on the CMake plugin) :) > > If you rework the CMake plugin could add an option that the header and > source files - as well as ui and qrc files -, displayed in the project > view, getting arranged in groups, that would be nice. Similar the view > of a normal qmake based project where you have the virtual folders > "Headers", "Sources"... (Maybe by parsing source_group, which would > provide a maximum of flexibility?) > > > Best regards, > Lorenz > > P.s.: Another issue is how to have an equivalent for OTHER_FILES in > CMake based projects. Currently I use "add_custom_target(Foo ALL SOURCES > myfile.txt)". Good, bad, other suggestions? If there is a good > "official" way of doing that, we should add that to the documentation. > ___ > Qt-creator mailing list > Qt-creator@qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Refactoring the CMake plugin
Hi Benjamin, I can't say anything to your questions :( but I have a small side note/request (as well as to everyone working on the CMake plugin) :) If you rework the CMake plugin could add an option that the header and source files - as well as ui and qrc files -, displayed in the project view, getting arranged in groups, that would be nice. Similar the view of a normal qmake based project where you have the virtual folders "Headers", "Sources"... (Maybe by parsing source_group, which would provide a maximum of flexibility?) Best regards, Lorenz P.s.: Another issue is how to have an equivalent for OTHER_FILES in CMake based projects. Currently I use "add_custom_target(Foo ALL SOURCES myfile.txt)". Good, bad, other suggestions? If there is a good "official" way of doing that, we should add that to the documentation. ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Refactoring the CMake plugin
On 18.06.2014 16:02, Benjamin Zeller wrote: > Ok, sounds good to me, so how would you want to have the Kit to extend the > environment? > Like having a KitInformation::addToEnvironment when the buildsteps are > executed? Add a EnvironmentKitInformation that can be configured to change the environment and then use the existing addToEnvironment, yes. >> There are different kinds of cmake? That is new to me. I always grabbed >> the one from kitware. > Yeah well, in our case we have build chroots that contain their own cmake > instance and I need to invoke them inside the chroot. Thats probably > why I needed all these things in the first place. So you have host-binaries in a chroot for the target? Why would you do that? You could have a sysroot set and then compare that to the cmake path. If sysroot is a prefix to cmake path, then you need to chroot... or do something similar. >>> For example the >>> ubuntu sdk plugin identifies Ubuntu SDK kits by checking if the cmake >>> tool is of a special type. >> Why would you do that? >> >> Desktop ubuntu (is that even supported?) is a pretty normal desktop >> target, so why have a special type for that in the first place? And why >> bind that type to cmake? Why do you want to limit users to the cmake >> build system? > The binding to that type of cmake just would happen for the special > case I mentioned above, cross compiling in the chroots... ... which is actually pretty easily done with a script;-) >> Why do you need a default cmake? Just use the one from PATH if the user >> has none explicitly set (and there is one in PATH). > Default cmake as in, the one to use when none is set in the Kit. And yes > that would be the one from the PATH :). No, if there is no cmake set in the kit, then this kit is not applicable for cmake-based projects. So you can just skip those kits when asking which ones the user wants to see his cmake project built with. >> In the cmake wizard you then need to have the user select a kit (one >> with a configured cmake) and off she goes. > Ah yeah we can make the cmake wizard just show Kits that actually have > a cmake set, > that would work also but requires more configuration from a user who > just wants to > use cmake without any fancy things. I would like to have the > KitInformation fall back > to the cmake in PATH. Feel free to do that. That is why the KitInformation has methods for default values, for the initial setup and to fix it again in case something breaks:-) Please make sure to only add cmake to kits where that actually makes sense. E.g. if there is no way to deploy cmake built binaries to the device in question, then just leave out the cmake for those kits. A user is still free to configure those kits manually if he knows what he does. Best Regards, Tobias ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Refactoring the CMake plugin
Am 18.06.2014 15:31, schrieb Hunger Tobias: > Hi Benjamin, > > On 18.06.2014 15:12, Benjamin Zeller wrote: > > >>> Why do you need all that? Why doesn't a simple path to the executable >>> suffice? That executable may very well be a script if that is necessary. >> Well the idea here was to be able to , for example, set different >> environment >> variables or add cmake arguments on the fly if the specific cmake >> version needs that. > We need to have a way for the kit to extend the environment anyway, so > the environment variables should be covered by that functionality (to be > written;-). > > CMake arguments, etc. can all be added in a script. I do not see why > that has to go into Qt Creator, especially considering that this is > static configuration that the user will rarely want to change. Ok, sounds good to me, so how would you want to have the Kit to extend the environment? Like having a KitInformation::addToEnvironment when the buildsteps are executed? >> I also heard from other people it would be nice if one could configure a >> cmake installation for example to add a preload cache script. > Yes, we should be flexible and allow users to do whatever they want, but > we do not need to provide an UI for everything anybody may conceivably > come up with. > > This is one of those things IMHO. > >> Also for example if you want to configure a special toolchain file, or >> just for >> identifying a special type of cmake in the sourcecode. > There are different kinds of cmake? That is new to me. I always grabbed > the one from kitware. Yeah well, in our case we have build chroots that contain their own cmake instance and I need to invoke them inside the chroot. Thats probably why I needed all these things in the first place. >> For example the >> ubuntu sdk plugin identifies Ubuntu SDK kits by checking if the cmake >> tool is of a special type. > Why would you do that? > > Desktop ubuntu (is that even supported?) is a pretty normal desktop > target, so why have a special type for that in the first place? And why > bind that type to cmake? Why do you want to limit users to the cmake > build system? The binding to that type of cmake just would happen for the special case I mentioned above, cross compiling in the chroots... > For the phones and other stuff you have to have devices to talk to those > anyway, so why not use the type of device as a identification? You will > need to do different deployment steps based on which device you have anyway. Good point, I can use the device type id. > > >>> I would personally just add a CMakeKitInformation with the path to the >>> cmake binary you need to call. No CMakeManager, no CMakeTool, nothing:-) >> Hm interesting, so we need at least a "default" cmake but that can still be >> the one found in PATH, or specified in the cmake settings dialog. > Why do you need a default cmake? Just use the one from PATH if the user > has none explicitly set (and there is one in PATH). Default cmake as in, the one to use when none is set in the Kit. And yes that would be the one from the PATH :). > In the cmake wizard you then need to have the user select a kit (one > with a configured cmake) and off she goes. Ah yeah we can make the cmake wizard just show Kits that actually have a cmake set, that would work also but requires more configuration from a user who just wants to use cmake without any fancy things. I would like to have the KitInformation fall back to the cmake in PATH. Best Regards, Benjamin > I have nothing further to contribute to the discussion about when to run > cmake, so I will just cut out that part. > Best Regards, > Tobias > ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Refactoring the CMake plugin
Hi Benjamin, On 18.06.2014 15:12, Benjamin Zeller wrote: >> Why do you need all that? Why doesn't a simple path to the executable >> suffice? That executable may very well be a script if that is necessary. > Well the idea here was to be able to , for example, set different > environment > variables or add cmake arguments on the fly if the specific cmake > version needs that. We need to have a way for the kit to extend the environment anyway, so the environment variables should be covered by that functionality (to be written;-). CMake arguments, etc. can all be added in a script. I do not see why that has to go into Qt Creator, especially considering that this is static configuration that the user will rarely want to change. > I also heard from other people it would be nice if one could configure a > cmake installation for example to add a preload cache script. Yes, we should be flexible and allow users to do whatever they want, but we do not need to provide an UI for everything anybody may conceivably come up with. This is one of those things IMHO. > Also for example if you want to configure a special toolchain file, or > just for > identifying a special type of cmake in the sourcecode. There are different kinds of cmake? That is new to me. I always grabbed the one from kitware. > For example the > ubuntu sdk plugin identifies Ubuntu SDK kits by checking if the cmake > tool is of a special type. Why would you do that? Desktop ubuntu (is that even supported?) is a pretty normal desktop target, so why have a special type for that in the first place? And why bind that type to cmake? Why do you want to limit users to the cmake build system? For the phones and other stuff you have to have devices to talk to those anyway, so why not use the type of device as a identification? You will need to do different deployment steps based on which device you have anyway. >> I would personally just add a CMakeKitInformation with the path to the >> cmake binary you need to call. No CMakeManager, no CMakeTool, nothing:-) > Hm interesting, so we need at least a "default" cmake but that can still be > the one found in PATH, or specified in the cmake settings dialog. Why do you need a default cmake? Just use the one from PATH if the user has none explicitly set (and there is one in PATH). In the cmake wizard you then need to have the user select a kit (one with a configured cmake) and off she goes. I have nothing further to contribute to the discussion about when to run cmake, so I will just cut out that part. Best Regards, Tobias ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Refactoring the CMake plugin
Hi Tobias, > Hi Benjamin, > > On 18.06.2014 12:39, Benjamin Zeller wrote: >> I'm working on up-streaming the changes I made on the CMake plugin >> for the Ubuntu SDK, this all slowed down in the last weeks because >> I was really busy with other tasks. >> >> https://codereview.qt-project.org/80708 >> https://codereview.qt-project.org/80709 >> https://codereview.qt-project.org/80710 > I did not read those, so my comments are entirely based on the contents > of this mail. > >> But before I start doing that I would like to discuss how the plugin >> should work >> and how it should be implemented. >> >> There are 3 features I would like to get into the CMake plugin: >> >> 1) Registering new cmake instances / tools >> >> The idea is to provide a way for plugins to register their own >> cmake installation >> and I introduced a class called CMakeManager that will own all >> registered installations. >> Every registered cmake will be represented by a CMakeTool instance, >> that abstracts away >> how a specific cmake is invoked. >> >> To register them I can see 2 ways: >> >> a) using factories: >> Personally I like factories more, maybe the approach used by >> the toolchains would fit here too (QList >> Factory::autoDetect()). >> That would also require a UI in the settings dialog where the user >> can manage the >> available cmake tools and manually register them. >> >> b) provide a function called registerCMakeTool() in the >> CMakeManager that can >> be called by plugins. > Why do you need all that? Why doesn't a simple path to the executable > suffice? That executable may very well be a script if that is necessary. Well the idea here was to be able to , for example, set different environment variables or add cmake arguments on the fly if the specific cmake version needs that. I also heard from other people it would be nice if one could configure a cmake installation for example to add a preload cache script. Also for example if you want to configure a special toolchain file, or just for identifying a special type of cmake in the sourcecode. For example the ubuntu sdk plugin identifies Ubuntu SDK kits by checking if the cmake tool is of a special type. > >> 2) Associating a cmake tool with a build >> >> Now that there is a way to have more than one possible cmake, there >> needs to >> be a way to control which cmake is used when building/creating the >> project files. >> >> a) By linking it to a Kit >> -> provide a CMakeKitInformation so the user can control which >> Kit uses which >> cmake tool >> >> b) By linking it to a build configuration >> -> a CMakeBuildConfiguration would either need to return a >> Core::Id specifying the >> cmake tool it wants to use, or the CMakeTool instance itself, so >> the IDE can use it >> to create the build files. The build configurations config >> widget then can provide a >> way for the user to switch between the cmake installations >> available. > I'd say the kit is the way to go here. We created kits to get this > repetitive configuration out of individual build configurations into one > central place. > > I would personally just add a CMakeKitInformation with the path to the > cmake binary you need to call. No CMakeManager, no CMakeTool, nothing:-) Hm interesting, so we need at least a "default" cmake but that can still be the one found in PATH, or specified in the cmake settings dialog. > >> 3) Automatically running cmake in the background (Get rid of the "Run >> cmake" dialog) > I am not sure I like this. > > The Run CMake dialog makes it clear that we are going to write something > to disk. There is just no way to run cmake that does not write something > somewhere. > > We generally try to avoid writing files in places where that is not > expected. If a user e.g. changes the build dir 100 times in Project mode > between builds, then he should only see the 100th directory that is > selected when he hits build, not the 99 directories before that. Agreed, that would be not so nice. > >> It would be nice if the user was not required to handle the cmake >> dialog >> every time he wants to change the build settings, cmake arguments >> or wants to >> switch between different build configurations. >> >> In my MR, a cmake run is automatically started every time the build >> settings are changed and when opening a unconfigured project the >> project >> configuration page is used. > IMHO that is a no-go: The user does not ever get a chance to change the > build location before you pollute his drive then. Well thats not entirely true for the unconfigured project case, the NoTargetsPanel will pop up and the user can choose his builddirectory, only if he presses "Configure" the builddir for the current buildconfig is created and the project description files are generated. > >> At firs
Re: [Qt-creator] Refactoring the CMake plugin
Hi Benjamin, On 18.06.2014 12:39, Benjamin Zeller wrote: > I'm working on up-streaming the changes I made on the CMake plugin > for the Ubuntu SDK, this all slowed down in the last weeks because > I was really busy with other tasks. > > https://codereview.qt-project.org/80708 > https://codereview.qt-project.org/80709 > https://codereview.qt-project.org/80710 I did not read those, so my comments are entirely based on the contents of this mail. > But before I start doing that I would like to discuss how the plugin > should work > and how it should be implemented. > > There are 3 features I would like to get into the CMake plugin: > > 1) Registering new cmake instances / tools > > The idea is to provide a way for plugins to register their own > cmake installation > and I introduced a class called CMakeManager that will own all > registered installations. > Every registered cmake will be represented by a CMakeTool instance, > that abstracts away > how a specific cmake is invoked. > > To register them I can see 2 ways: > > a) using factories: > Personally I like factories more, maybe the approach used by > the toolchains would fit here too (QList > Factory::autoDetect()). > That would also require a UI in the settings dialog where the user > can manage the > available cmake tools and manually register them. > > b) provide a function called registerCMakeTool() in the > CMakeManager that can > be called by plugins. Why do you need all that? Why doesn't a simple path to the executable suffice? That executable may very well be a script if that is necessary. > 2) Associating a cmake tool with a build > > Now that there is a way to have more than one possible cmake, there > needs to > be a way to control which cmake is used when building/creating the > project files. > > a) By linking it to a Kit > -> provide a CMakeKitInformation so the user can control which > Kit uses which > cmake tool > > b) By linking it to a build configuration > -> a CMakeBuildConfiguration would either need to return a > Core::Id specifying the > cmake tool it wants to use, or the CMakeTool instance itself, so > the IDE can use it > to create the build files. The build configurations config > widget then can provide a > way for the user to switch between the cmake installations > available. I'd say the kit is the way to go here. We created kits to get this repetitive configuration out of individual build configurations into one central place. I would personally just add a CMakeKitInformation with the path to the cmake binary you need to call. No CMakeManager, no CMakeTool, nothing:-) > 3) Automatically running cmake in the background (Get rid of the "Run > cmake" dialog) I am not sure I like this. The Run CMake dialog makes it clear that we are going to write something to disk. There is just no way to run cmake that does not write something somewhere. We generally try to avoid writing files in places where that is not expected. If a user e.g. changes the build dir 100 times in Project mode between builds, then he should only see the 100th directory that is selected when he hits build, not the 99 directories before that. > It would be nice if the user was not required to handle the cmake > dialog > every time he wants to change the build settings, cmake arguments > or wants to > switch between different build configurations. > > In my MR, a cmake run is automatically started every time the build > settings are changed and when opening a unconfigured project the > project > configuration page is used. IMHO that is a no-go: The user does not ever get a chance to change the build location before you pollute his drive then. > At first sight this is very similar to > how qmake behaves and makes it easily > possible to switch between multiple build configurations without > the need for running > the cmake dialog every time. But the difference of course is that > there are files created when running cmake > and the user does probably not know about that. > --> A possible solution to this would be to open a dialog to change > the build settings, but to > run cmake automatically when switching between build > configurations. This would make the user more aware of what > is happening. I personally would not be opposed to not having the cmake dialog when switching back to an already configured build configuration with an already existing build directory. But then I am not the cmake maintainer and am not fully familiar with the code base nor the direction it is supposed to take. Best Regards, Tobias ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
[Qt-creator] Refactoring the CMake plugin
Hello, I'm working on up-streaming the changes I made on the CMake plugin for the Ubuntu SDK, this all slowed down in the last weeks because I was really busy with other tasks. https://codereview.qt-project.org/80708 https://codereview.qt-project.org/80709 https://codereview.qt-project.org/80710 These are the merge requests, but they still have lots of comments about how things should be done and unrelated changes ,which made me wonder if it would be better to start over and get a set of clean patches. But before I start doing that I would like to discuss how the plugin should work and how it should be implemented. There are 3 features I would like to get into the CMake plugin: 1) Registering new cmake instances / tools The idea is to provide a way for plugins to register their own cmake installation and I introduced a class called CMakeManager that will own all registered installations. Every registered cmake will be represented by a CMakeTool instance, that abstracts away how a specific cmake is invoked. To register them I can see 2 ways: a) using factories: Personally I like factories more, maybe the approach used by the toolchains would fit here too (QList Factory::autoDetect()). That would also require a UI in the settings dialog where the user can manage the available cmake tools and manually register them. b) provide a function called registerCMakeTool() in the CMakeManager that can be called by plugins. 2) Associating a cmake tool with a build Now that there is a way to have more than one possible cmake, there needs to be a way to control which cmake is used when building/creating the project files. a) By linking it to a Kit -> provide a CMakeKitInformation so the user can control which Kit uses which cmake tool b) By linking it to a build configuration -> a CMakeBuildConfiguration would either need to return a Core::Id specifying the cmake tool it wants to use, or the CMakeTool instance itself, so the IDE can use it to create the build files. The build configurations config widget then can provide a way for the user to switch between the cmake installations available. 3) Automatically running cmake in the background (Get rid of the "Run cmake" dialog) It would be nice if the user was not required to handle the cmake dialog every time he wants to change the build settings, cmake arguments or wants to switch between different build configurations. In my MR, a cmake run is automatically started every time the build settings are changed and when opening a unconfigured project the project configuration page is used. At first sight this is very similar to how qmake behaves and makes it easily possible to switch between multiple build configurations without the need for running the cmake dialog every time. But the difference of course is that there are files created when running cmake and the user does probably not know about that. --> A possible solution to this would be to open a dialog to change the build settings, but to run cmake automatically when switching between build configurations. This would make the user more aware of what is happening. So if anyone has some thoughts or comments about that, I really would appreciate the help :). Thanks, Benjamin ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
