Re: [cmake-developers] CMake daemon-mode
Hi Brad, Am 17.06.2016 22:09 schrieb "Brad King": > Then I applied the patches with some revisions: > > cmGeneratorTarget: Adopt Fortran module directory generation > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49f10f0d > > cmLocalGenerator: Add method to get Fortran-specific compiler flags > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5467e794 > > cmLocalGenerator: Adopt target compile flag generation > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c488ce8 > > cmExtraSublimeTextGenerator: Use GetTargetCompileFlags > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=802b36fb > > These have been merged to `next` for testing. Wonderful! Thanks for improving the patches I'll rebase my branch on top of these as soon as they hit master. Best Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
On 06/10/2016 12:31 PM, Tobias Hunger wrote: > I did try to do the changes you requested. The branch is here: > https://github.com/hunger/CMake/commits/compileflags Thanks. I did some refactoring to help address the path conversion problem: Refactor Makefile/Ninja tool working directory storage https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0392f72b Then I applied the patches with some revisions: cmGeneratorTarget: Adopt Fortran module directory generation https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49f10f0d cmLocalGenerator: Add method to get Fortran-specific compiler flags https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5467e794 cmLocalGenerator: Adopt target compile flag generation https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c488ce8 cmExtraSublimeTextGenerator: Use GetTargetCompileFlags https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=802b36fb These have been merged to `next` for testing. > Next patch moves the AddFortranFlags code. This will need some careful > review, as it removes a path conversion that were present in the > original code (in two places). I could just not figure out how > to convert in the new place. I replaced that commit with a different one that preserves the path conversion. The implementation needs to be in cmLocalCommonGenerator in order to have access to the needed information to do the conversion. I used virtual dispatch to achieve this. On other generators we do not need these flags anyway. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
Hi Brad, I just rebased this branch on top of current master and pushed it. There were some conflicts. Best Regards, Tobias On Mon, Jun 13, 2016 at 4:16 PM, Brad Kingwrote: > On 06/10/2016 12:31 PM, Tobias Hunger wrote: >> I did try to do the changes you requested. The branch is here: >> >> https://github.com/hunger/CMake/commits/compileflags > > Thanks. I'm about to go on travel but should hopefully be able to > look at that again when I return. > > -Brad > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
On 06/10/2016 12:31 PM, Tobias Hunger wrote: > I did try to do the changes you requested. The branch is here: > > https://github.com/hunger/CMake/commits/compileflags Thanks. I'm about to go on travel but should hopefully be able to look at that again when I return. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
Hi Brad, On Thu, Jun 9, 2016 at 7:57 PM, Brad Kingwrote: > On 06/09/2016 09:27 AM, Brad King wrote: >>> https://github.com/hunger/CMake/commit/bc060a44b6b2c2281ffe99815163ba02ec835dd6 >> Good. I need to review that one more deeply but should be able to integrate >> it. > > I split out some incremental commits toward that: > > cmCommonTargetGenerator: De-duplicate CMAKE_BUILD_TYPE lookup > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=de4ee088 > > cmLocalGenerator: Adopt GetFrameworkFlags method > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70d3bf85 > > cmLocalGenerator: Move GetFrameworkFlags implementation to private helper > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9613b96 > > Please rebase on that (at least once it is in master). > > For the main change, please also move over AddFortranFlags, perhaps > becoming cmLocalGenerator::GetFortranFlags. The result should be > that cmCommonTargetGenerator::GetFlags moves into the new > cmLocalGenerator::GetTargetCompileFlags method except for the caching. > That will preserve flag order for GetFlags. > > For the Xcode part of the changes, we cannot use the full > GetTargetCompileFlags. The reason is that for Xcode some of the > flags, like the architecture settings, become .pbxproj file properties > instead of raw flags. It may be simplest to just drop that part of > the change for now. Or, we need to factor out an intermediate helper > that can be shared by GetTargetCompileFlags and Xcode. I did try to do the changes you requested. The branch is here: https://github.com/hunger/CMake/commits/compileflags Some comments on the individual commits (and a direct link): This moves the fortran module directory creation: https://github.com/hunger/CMake/commit/eb417fef8bd1c91041a211899a2a7984aa75774d Next patch moves the AddFortranFlags code. This will need some careful review, as it removes a path conversion that were present in the original code (in two places). I could just not figure out how to convert in the new place. https://github.com/hunger/CMake/commit/2d5f6c673cc8a39f8590acfc23d4a6d5af8900a7 Then I add the cmLocalGenerator::GetTargetCompileFlags method I want. https://github.com/hunger/CMake/commit/9be6beddfe2c2eac6b61d572ee3e5131b0f0b30e Finally I convert the Sublime generator over to the new code: https://github.com/hunger/CMake/commit/deb0793a243c266aee00d4f6e07685a5268f3dae As I said, the second one will need some special care during the review. I did run all unit tests with all patches applied, and all pass on my system. Best Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
On 06/09/2016 04:24 PM, Tobias Hunger wrote: >> Please rebase on that (at least once it is in master). > > How long does it usually take to get something into master? Typically a (business) day or two, but sometimes longer depending on trouble with testing in 'next' on our dashboards. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
Hi Brad, Am 09.06.2016 19:57 schrieb "Brad King": > > On 06/09/2016 09:27 AM, Brad King wrote: > >> https://github.com/hunger/CMake/commit/bc060a44b6b2c2281ffe99815163ba02ec835dd6 > > Good. I need to review that one more deeply but should be able to integrate it. > > I split out some incremental commits toward that: > > cmCommonTargetGenerator: De-duplicate CMAKE_BUILD_TYPE lookup > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=de4ee088 > > cmLocalGenerator: Adopt GetFrameworkFlags method > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70d3bf85 > > cmLocalGenerator: Move GetFrameworkFlags implementation to private helper > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9613b96 > > Please rebase on that (at least once it is in master). How long does it usually take to get something into master? I do rebase rather often on top of master right anyway. I do want to stay current as I hate running into merge conflicts after weeksof solitary work in my little ivory tower of code:) > For the main change, please also move over AddFortranFlags, perhaps > becoming cmLocalGenerator::GetFortranFlags. The result should be > that cmCommonTargetGenerator::GetFlags moves into the new > cmLocalGenerator::GetTargetCompileFlags method except for the caching. > That will preserve flag order for GetFlags. I will give that a try. > For the Xcode part of the changes, we cannot use the full > GetTargetCompileFlags. The reason is that for Xcode some of the > flags, like the architecture settings, become .pbxproj file properties > instead of raw flags. It may be simplest to just drop that part of > the change for now. Or, we need to factor out an intermediate helper > that can be shared by GetTargetCompileFlags and Xcode. I think I will just drop that part then. I do not have a Mac handy to test anyway. > Thanks, > -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
On 06/08/2016 10:11 AM, Brad King wrote: > I had to revert it from 'next' because it caused several LinkFlags > test failures. [snip] On 06/08/2016 12:02 PM, Tobias Hunger wrote: > https://github.com/hunger/CMake/commit/66acf05bc1737211f88b6ad13781c791f1a7bce4 > > has an update. None of the tests fail for me with that. Thanks. I applied that one and merged to 'next' yesterday for testing. It passed this time: cmLocalGenerator: Pass configuration to GetTargetFlags https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b0d3e693 > https://github.com/hunger/CMake/commit/bc060a44b6b2c2281ffe99815163ba02ec835dd6 > > Adds a method to retrieve compile flags from cmLocalGenerator. Good. I need to review that one more deeply but should be able to integrate it. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
On 06/08/2016 01:24 AM, Tobias Hunger wrote: >> cmLocalGenerator: Pass configuration to GetTargetFlags >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe0d2241 > > Great, thanks! I had to revert it from 'next' because it caused several LinkFlags test failures. The reason is that it dropped UpperCase() on the config name when called from the Ninja generator. Please revise accordingly in combination with the refactoring discussed in the thread you started dedicated to that method. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
On 06/08/2016 04:05 AM, Stephen Kelly wrote: > I have rebased it and force pushed my github branch (there are a few > rebasing mistakes which I'll remove later). Thanks. > We hit issues at work that different clang-format versions have > different behavior. There we have the luxury of providing particular > binaries that every developer uses to get identical results and no diff > confusion. > > I don't know how to solve that in CMake though. It could become an issue > in the future when some contributors use clang-3.9 and others 3.8. Maybe > clang-format binaries should be in the repo. Right now we're using clang-format 3.8. We'll worry about such differences when they become a problem. > Also, it seems that clang-format is not run by CI. The ProductBuild > stuff doesn't seem to be clang formatted. Yeah, we haven't gotten that set up yet. Yesterday I added a topic to 'next' to fix that formatting. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
On 06/07/2016 11:42 AM, Daniel Pfeifer wrote: > On Mon, Jun 6, 2016 at 7:24 PM, Brad Kingwrote: >> On 06/06/2016 11:39 AM, Tobias Hunger wrote: >> >>> A big chunk of Stephen's work has not even landed in my branch yet. Since >>> cmake >>> reformated all the source in the meantime it is a bit tedious to apply >>> patches >>> from his tree and I have simply not yet needed the changes as I did not >>> venture >>> where he went yet. >> See commit v3.6.0-rc1~54^2~2 (82df6deaaf). Its commit message explains >> how to rebase across the style transition. If you rebase the original >> "cmake-daemon" branch on that then we can rewrite the style to make >> cherry-picking later easier. > When I rebased my own branches across the style transiton, I found the > process quite straight forward. > I can help with the style transition if someone rebases to 82df6deaaf. > > When I tried to rebase steve's work, it was not the style transition > but changes like the following that I struggled with: > https://github.com/Kitware/CMake/commit/563bf9dd8a207e04697a92d8bcd239f52400b355 I have rebased it and force pushed my github branch (there are a few rebasing mistakes which I'll remove later). We hit issues at work that different clang-format versions have different behavior. There we have the luxury of providing particular binaries that every developer uses to get identical results and no diff confusion. I don't know how to solve that in CMake though. It could become an issue in the future when some contributors use clang-3.9 and others 3.8. Maybe clang-format binaries should be in the repo. Also, it seems that clang-format is not run by CI. The ProductBuild stuff doesn't seem to be clang formatted. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
Hi Brad, Am 07.06.2016 19:23 schrieb "Brad King": > If it doesn't conflict with 'master' too much I can take it directly. It should not. I regularly rebase my branch on top of master. > I've cherry-picked 124f8295bee0c228b79a5cf38f0b2581be308118 and merged > to 'next' for testing: > > cmLocalGenerator: Pass configuration to GetTargetFlags > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe0d2241 Great, thanks! I would love to keep my patch set as small as possible:) Best Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
On 06/07/2016 12:18 PM, Tobias Hunger wrote: >> When you have a few such independent refactoring changes done >> we can look at integrating them immediately to avoid holding >> them externally in your daemon topic for too long. > > Can you take that patch from github or do you want them sent here? If it doesn't conflict with 'master' too much I can take it directly. I've cherry-picked 124f8295bee0c228b79a5cf38f0b2581be308118 and merged to 'next' for testing: cmLocalGenerator: Pass configuration to GetTargetFlags https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe0d2241 Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
Hi Brad, sorry for the empty mail, my phone acted up:-) Am 07.06.2016 16:48 schrieb "Brad King": > > On 06/07/2016 10:42 AM, Tobias Hunger wrote: > > On Mo, 2016-06-06 at 13:24 -0400, Brad King wrote: > >> We should be able to refactor things to share the flags computation. > >> Methods like > >> > >> cmLocalGenerator::GetTargetFlags > > > > Does this patch here make sense: > > > > https://github.com/hunger/CMake/commit/124f8295bee0c228b79a5cf38f0b2581be308118 > > > > It passes the configuration to GetTargetFlags instead of forcing it to the build > > type. Since I may end up with different configurations in the project structure, > > I think this is necessary. > > Yes. Previously that method was only called in single-configuration > generators so it could look up the CMAKE_BUILD_TYPE directly. In > multi-config generators that variable is meaningless and instead they > iterate over CMAKE_CONFIGURATION_TYPES. > > When you have a few such independent refactoring changes done > we can look at integrating them immediately to avoid holding > them externally in your daemon topic for too long. Can you take that patch from github or do you want them sent here? Best Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
Hi Am 07.06.2016 16:48 schrieb "Brad King": > On 06/07/2016 10:42 AM, Tobias Hunger wrote: > > On Mo, 2016-06-06 at 13:24 -0400, Brad King wrote: > >> We should be able to refactor things to share the flags computation. > >> Methods like > >> > >> cmLocalGenerator::GetTargetFlags > > > > Does this patch here make sense: > > > > > https://github.com/hunger/CMake/commit/124f8295bee0c228b79a5cf38f0b2581be308118 > > > > It passes the configuration to GetTargetFlags instead of forcing it to > the build > > type. Since I may end up with different configurations in the project > structure, > > I think this is necessary. > > Yes. Previously that method was only called in single-configuration > generators so it could look up the CMAKE_BUILD_TYPE directly. In > multi-config generators that variable is meaningless and instead they > iterate over CMAKE_CONFIGURATION_TYPES. > > When you have a few such independent refactoring changes done > we can look at integrating them immediately to avoid holding > them externally in your daemon topic for too long. > > Thanks, > -Brad > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
On 06/07/2016 10:42 AM, Tobias Hunger wrote: > On Mo, 2016-06-06 at 13:24 -0400, Brad King wrote: >> We should be able to refactor things to share the flags computation. >> Methods like >> >> cmLocalGenerator::GetTargetFlags > > Does this patch here make sense: > > https://github.com/hunger/CMake/commit/124f8295bee0c228b79a5cf38f0b2581be308118 > > It passes the configuration to GetTargetFlags instead of forcing it to the > build > type. Since I may end up with different configurations in the project > structure, > I think this is necessary. Yes. Previously that method was only called in single-configuration generators so it could look up the CMAKE_BUILD_TYPE directly. In multi-config generators that variable is meaningless and instead they iterate over CMAKE_CONFIGURATION_TYPES. When you have a few such independent refactoring changes done we can look at integrating them immediately to avoid holding them externally in your daemon topic for too long. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
On Mo, 2016-06-06 at 13:24 -0400, Brad King wrote: > We should be able to refactor things to share the flags computation. > Methods like > > cmLocalGenerator::GetTargetFlags Does this patch here make sense: https://github.com/hunger/CMake/commit/124f8295bee0c228b79a5cf38f0b2581be308118 It passes the configuration to GetTargetFlags instead of forcing it to the build type. Since I may end up with different configurations in the project structure, I think this is necessary. Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
On 06/07/2016 09:07 AM, Tobias Hunger wrote: >> We should be able to refactor things to share the flags computation. >> Methods like >> >> cmLocalGenerator::GetTargetFlags >> cmLocalGenerator::GetIncludeDirectories >> >> are meant to be used across multiple generators. > > So is that the complete picture? No, just a starting point. Note that we have no API to get all the flags for a source because all the generators collect target-wide and per-source flags separately. They are not combined until the native build tool constructs the final command line. The implementation of CMAKE_EXPORT_COMPILE_COMMANDS may already have some code to combine flags within CMake directly though. > You can override compile time flags on a per-file basis, based on the > code I ran across in the ninja generator:-) Do I still need to add > those per-source-file flags somehow? Yes. It looks like each generator currently does its own call to source->GetProperty("COMPILE_FLAGS") to get the per-source flags. The daemon would have to do something similar, possibly by factoring the logic out of the generators into a common helper. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
On 06/07/2016 05:27 AM, Daniel Pfeifer wrote: > If we have a daemon mode that provides this information (as your > implementation already does), we could let ccmake and cmake-gui use > the daemon instead of linking against CMakeLib. That would be really nice. A lot of the state space in CMake's internal representation is muddled by historical evolution of the different ways we have to invoke it (command line, ccmake, cmake-gui, ctest internals, etc.). Separating the interactive modes would be a nice cleanup. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
Hi Brad! On Mon, Jun 6, 2016 at 7:24 PM, Brad Kingwrote: >> A big chunk of Stephen's work has not even landed in my branch yet. Since >> cmake >> reformated all the source in the meantime it is a bit tedious to apply >> patches >> from his tree and I have simply not yet needed the changes as I did not >> venture >> where he went yet. > > See commit v3.6.0-rc1~54^2~2 (82df6deaaf). Its commit message explains > how to rebase across the style transition. If you rebase the original > "cmake-daemon" branch on that then we can rewrite the style to make > cherry-picking later easier. Thanks, that might prove helpful. So far i basically picked the same sha, that worked surprisingly well. >> At this time I think I will need to duplicate a chunk of code from one of the >> generators to find the flags. Is that really necessary? If so: Which >> generator >> should I copy the code from? > > We should be able to refactor things to share the flags computation. > Methods like > > cmLocalGenerator::GetTargetFlags > cmLocalGenerator::GetIncludeDirectories > > are meant to be used across multiple generators. Due to historical > evolution in generator design not everything has been refactored to > cleanly share such infrastructure across all generators. Stephen made > a lot of progress on that front, but there is still a way to go IIRC. So is that the complete picture? You can override compile time flags on a per-file basis, based on the code I ran across in the ninja generator:-) Do I still need to add those per-source-file flags somehow? Best Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
Hi Daniel, On Tue, Jun 7, 2016 at 11:27 AM, Daniel Pfeiferwrote: > On Mon, Jun 6, 2016 at 5:39 PM, Tobias Hunger wrote: >> Please help to support your use-cases. > > A while ago I wrote a graphical cache editor in GTK: > https://github.com/purpleKarrot/cmake-gtk > The tool reads the cache and provides a graphical view to modify it. > It can then write the cache, run cmake, and read it back. > > I wanted to see how close we can get to ccmake or cmake-gui without > linking against CMakeLib. > > Here is what I was *unable* to achieve: > * Separating Configure from Generate (two buttons). > * Progress bar. > > Quite a short list, right? > If we have a daemon mode that provides this information (as your > implementation already does), we could let ccmake and cmake-gui use > the daemon instead of linking against CMakeLib. If the daemon can expose the right information, then you could even be able to write a generator in e.g. python;-) Best Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
On Mon, Jun 6, 2016 at 7:24 PM, Brad Kingwrote: > On 06/06/2016 11:39 AM, Tobias Hunger wrote: > >> A big chunk of Stephen's work has not even landed in my branch yet. Since >> cmake >> reformated all the source in the meantime it is a bit tedious to apply >> patches >> from his tree and I have simply not yet needed the changes as I did not >> venture >> where he went yet. > > See commit v3.6.0-rc1~54^2~2 (82df6deaaf). Its commit message explains > how to rebase across the style transition. If you rebase the original > "cmake-daemon" branch on that then we can rewrite the style to make > cherry-picking later easier. When I rebased my own branches across the style transiton, I found the process quite straight forward. I can help with the style transition if someone rebases to 82df6deaaf. When I tried to rebase steve's work, it was not the style transition but changes like the following that I struggled with: https://github.com/Kitware/CMake/commit/563bf9dd8a207e04697a92d8bcd239f52400b355 cheers, Daniel -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
On Mon, Jun 6, 2016 at 5:39 PM, Tobias Hungerwrote: > Please help to support your use-cases. A while ago I wrote a graphical cache editor in GTK: https://github.com/purpleKarrot/cmake-gtk The tool reads the cache and provides a graphical view to modify it. It can then write the cache, run cmake, and read it back. I wanted to see how close we can get to ccmake or cmake-gui without linking against CMakeLib. Here is what I was *unable* to achieve: * Separating Configure from Generate (two buttons). * Progress bar. Quite a short list, right? If we have a daemon mode that provides this information (as your implementation already does), we could let ccmake and cmake-gui use the daemon instead of linking against CMakeLib. cheers, Daniel > Please report what information you would like to have available from your > cmake > projects via daemon-mode. > > Patches are of course welcome at any time! > > Any help in getting any interesting information out of cmake is highly > appreciated, too. > > At this time I think I will need to duplicate a chunk of code from one of the > generators to find the flags. Is that really necessary? If so: Which generator > should I copy the code from? > > Best Regards, > Tobias > > -- > Tobias Hunger, Senior Software Engineer | The Qt Company > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 > B > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon-mode
On 06/06/2016 11:39 AM, Tobias Hunger wrote: > This is why I started working on making Stephen's code merge-able and more > robust. I will also volunteer to help maintain this code going forward. Great, thanks! Hopefully I will have time to look at this in more detail soon. For now here are a few responses. > So far I copied over the daemon itself from Stephen. On top of that I added > some > nicer request/respond handling code (you get pretty similar messages from > everything, you can set a cookie in a request, which will be handed back on > response/error, there is a defined way to report a response or an error > condition), progress reporting (directly hooked up to cmake), and a couple of > basic commands to get started (reset, etc.), and some future-proofing by being > able to support several versions of the daemon protocol. Good. I like the use of libuv. I've been meaning to add the infrastructure to make libuv available as something we can use in CMake upstream so that we can port process execution away from KWSys and to libuv. The daemon mode will be a great client for libuv too. > A big chunk of Stephen's work has not even landed in my branch yet. Since > cmake > reformated all the source in the meantime it is a bit tedious to apply patches > from his tree and I have simply not yet needed the changes as I did not > venture > where he went yet. See commit v3.6.0-rc1~54^2~2 (82df6deaaf). Its commit message explains how to rebase across the style transition. If you rebase the original "cmake-daemon" branch on that then we can rewrite the style to make cherry-picking later easier. > At this time I think I will need to duplicate a chunk of code from one of the > generators to find the flags. Is that really necessary? If so: Which generator > should I copy the code from? We should be able to refactor things to share the flags computation. Methods like cmLocalGenerator::GetTargetFlags cmLocalGenerator::GetIncludeDirectories are meant to be used across multiple generators. Due to historical evolution in generator design not everything has been refactored to cleanly share such infrastructure across all generators. Stephen made a lot of progress on that front, but there is still a way to go IIRC. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] CMake daemon-mode
Hi everybody, I want the cmake daemon mode Stephen Kelly proposed a while back. In my opinion this could become a game changer. Unfortunately Stephen told me that he did not have the resources to push this forward at this time. This is why I started working on making Stephen's code merge-able and more robust. I will also volunteer to help maintain this code going forward. My main interest is getting project structure reported out of cmake. So this is what I did start out with. The cool features Stephen demo-ed in his blog https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ are definitely on my wish list though, but I need first class cmake project support first -- with all the information Qt Creator can currently not get its hands on. So I set up a branch over on github and did some hacking: https://github.com/hunger/CMake/commits/daemon-mode Status: === So far I copied over the daemon itself from Stephen. On top of that I added some nicer request/respond handling code (you get pretty similar messages from everything, you can set a cookie in a request, which will be handed back on response/error, there is a defined way to report a response or an error condition), progress reporting (directly hooked up to cmake), and a couple of basic commands to get started (reset, etc.), and some future-proofing by being able to support several versions of the daemon protocol. This infrastructure part is pretty solid by now, and has documentation and tests. On top of that I started to work towards loading a project and extracting the project structure from it. This part is still pretty much in flux as I learn where all the bits and pieces of data are stored in cmake. This part is without proper documentation and tests at this time. I do not consider this branch merge-worthy yet, but I would appreciate feedback on the patch set *A LOT*, ranging from coding style issues up to hints about things I should add to enable more use-cases, or hints on how to get to information currently missing from the output. A big chunk of Stephen's work has not even landed in my branch yet. Since cmake reformated all the source in the meantime it is a bit tedious to apply patches from his tree and I have simply not yet needed the changes as I did not venture where he went yet. It also leaves daemon-mode as a rather separate set of patches that is not changing core cmake components. I also hope this helps with review at this time. Run through: === Start "cmake -E daemon" (no additional parameters required). This will enable daemon-mode and allow you to send magic text via stdin to the daemon, who will respond with magic text on stdout. We will probably want to change that later to a channel that does not get interleaved with cmake output, but for now it works well enough and is really easy to test. A typical session will currently include the following messages sent to the cmake daemon: [== CMake MetaMagic ==[ {"protocolVersion":{"major":0,"minor":1},"type":"handshake"} ]== CMake MetaMagic ==] This needs to be the first thing sent as it establishes the protocol version, right after the daemon reports the available protocol versions on start-up. [== CMake MetaMagic ==[ {"type":"setGlobalSettings", "currentGenerator":"Ninja", "sourceDirectory":"/home/code/src/cmake", "buildDirectory":"/tmp/cmake-build- test"} ]== CMake MetaMagic ==] This sets up a new build directory /tmp/cmake-build-test for the sources found in /home/code/src/cmake, using the Ninja generator. You should be able to leave out the currentGenerator and the sourceDirectory if the buildDirectory already exists. [== CMake MetaMagic ==[ {"type":"configure"} ]== CMake MetaMagic ==] Configures the project. You can also try: [== CMake MetaMagic ==[ {"type":"configure", "cacheArguments":["-Dsomething=else"]} ]== CMake MetaMagic ==] to pass configure arguments along to cmake. Next step is: [== CMake MetaMagic ==[ {"type":"generate"} ]== CMake MetaMagic ==] which will generate the build system in the build directory. This and configure will produce progress output along the way. At this point you can query the project structure: [== CMake MetaMagic ==[ {"type":"project"} ]== CMake MetaMagic ==] This will dump a lot of output:-) You can trim down on that a bit by limiting target types, etc. Additional commands supported at this time: [== CMake MetaMagic ==[ {"type":"globalSettings"} ]== CMake MetaMagic ==] which lists the things you can set via "setGlobalSettings". [== CMake MetaMagic ==[ {"type":"reset"} ]== CMake MetaMagic ==] which will reset the daemon to its default state. Todo: === * Handle toolsets for generators * Get CMakeCache via the daemon (after configure?) * Get build system files from the daemon (after configure?) * Get missing information on the project: * Defines * Compiler flags * Information on linkage of targets * Group similar sources to shorten the output *
Re: [cmake-developers] cmake daemon mode protocol
Hi Stephen, I think what I suggested so far is covered by the first way of interaction covered in http://thread.gmane.org/gmane.comp.lib.qt.creator/11794/focus=15411 . I am just proposing something that is convenient for me to use. On Sat, Jan 16, 2016 at 12:26 PM, Stephen Kellywrote: >>> For this case, I suggest that if the user tries to 'open the source >>> directory', you would use QTemporaryDir to build in a temporary location >> and >>> run the daemon there. I believe clion does something equivalent to that. >>> Is that viable? I suppose you are suggesting that cmake do that instead >>> of leaving it for clients to do? >> >> It is doable. I just do not see why this should be necessary. > > I'm aiming to first design as much as possible of a 'minimal viable > protocol' as a first step. Given the above I think your ideas of running the > daemon with no build dir are not 'minimal' and I'm convinced they're not > viable. I am thinking about the simplest possible use-case I can think of right now: User gets sources from a project somewhere and wants to build those. What is entirely unclear to me with your current implementation is how do I get from "sources are checked out in $DIR" to "I have a $BUILD that I can use to start the daemon"? Then I also do not see how I can support a user switching between two build directories. Do I need to close down one daemon and start another? > Someone would have to prototype the ideas, but I don't think that's a good > use of time or energy right now (mostly because I think they're not viable). > > I recommend focussing on the tasks in my OP: > > http://thread.gmane.org/gmane.comp.lib.qt.creator/11794 That list is so full of cmake internals that it is basically meaningless to me. Sorry. >>> Richer information about some semantics like 'task' and 'busy state' >>> could also be provided in a similar way I expect, assuming those could be >> defined. >> >> This is some basic functionality that we should get right soon, as this >> can influence how long-running tasks need to be designed. > > Yes. Perhaps you can expand on what 'tasks' and 'busy state' you have in > mind. Particularly if you can relate them to what is already in my github > branch. "task" is just some Id to identify what the daemon is currently doing. "state" is just some indication of whether the daemon thinks it is busy with something or not. In "idle" state it should accept more requests, in "busy" state it will just queue them or maybe even ignore them. >> So "cmake --build" is out of scope for the daemon? > > I listed three ways cmake and an IDE could interface here: > > http://thread.gmane.org/gmane.comp.lib.qt.creator/11794/focus=15411 > > 'triggering the build' would be a fourth. I don't think it needs to be part > of the initial discussion of the design. > > Let's try to keep scope small so that we can get on common ground. So let's forget about all the interactive stuff for now. That is IMHO step 2, after the basic protocol is validated by implementing bare bones project information:-) >> That is why I brought up progress information so early: They make things >> complicated by there suddenly being several responses to a request and you >> need a way to identify those. At that point simpler solutions tend to blow >> up:-) > > Yes. > > BTW: I don't expect to get any part of the design of the protocol 'right' on > the first iteration. I think we need to start everything that will need to > be in the protocol, then iterate. Start high level ignoring details, and > fill in the details as we iterate and can encode needs in unit tests. I agree and do not expect anything different. Basic protocol functionality from my point of view needs to include: * Being able to detect the daemon or IDE becoming unresponsive * Being able to find which responses are the result of which requests * Being able to reliably find what kind of object I got as request or response >From the point of view of an IDE: Being able to have progress information is not a high level detail to be filled in later. Best Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake daemon mode protocol
Hi Stephen, Am 15.01.2016 00:38 schrieb "Stephen Kelly": > > * Start daemon-mode without any additional parameters > > > > * Daemon responds with " > > { > > "type": "handShake", > > "version": "3.5.x", > > "supportedProtocols": "3.5" > > } > > As you discovered, the cmake binary might not even support the daemon mode > at all. That is really straight forward to detect: It will send malformed JSON on stdout if daemon-mode is unsupported:-) The error message you get is not JSON and definitely on of type handShake. > I think what you are really asking for is 'the capabilities of the cmake > binary'. In that sense, you might also want to know what generators are > available, whether daemon mode is available (and with which protocol > versions) etc. > > The issue at > > http://public.kitware.com/Bug/view.php?id=15462 > > proposes to dump that information to stdout with a different -E command. I do not really see the need for that. Daemon-mode is easy to detect by the reply to the attempt to start it. Everything else I expect to extract from within daemon mode. > > > > * Client Handshake: > > { > > "type": "handshake", > > "requestProtocolVersion": "3.5" > > } > > > > * Daemon: > > { > > "type:"handshake", > > "protocolVersion": "3.5" > > } > > Something like this is possible too. It's not far off what is already done > in the branch. I know, that is what this is based on after all. All I want is to be able to start daemon-mode without having a builddir that is already associated with a sourcedir. > > At this point the normal operation should be possible. > > > > * Client: > > { > > "type": "setProjectInformation", > > "sourceDirectory": "/some/path", > > "cookie": "1" > > } > > > > Being able to set the source directory is important so that a fresh > > checkout can be configured. There is no build directory available at > > that time... > > I understand the desire to inspect a cmake project without asking the user > to specify a build dir, You can safely read the CMakelists at this point, give syntax errors, maybe even extract basic information like project name at this point. > but cmake has to write build files somewhere in > order to test the compiler etc. If this works with a temporary build directory, then these files probably do not need to litter the build directory in the first place:-) > For this case, I suggest that if the user tries to 'open the source > directory', you would use QTemporaryDir to build in a temporary location and > run the daemon there. I believe clion does something equivalent to that. Hey, the idea is to improve on the current situation, not to perpetuate the workarounds. And how do I associate an empty directory as a builddir to a sourcedir? How can I switch between builds when the daemon-mode is set up to work with one builddir? Do I have to close it down and start a new daemon for the next build? That would be suboptimal, as all the built-in dependent state of the project would need to get regenerated by the new daemon. Associating a daemon with a sourcedir and being able to switch builddir would be nicer. > Is that viable? I suppose you are suggesting that cmake do that instead of > leaving it for clients to do? It is doable. I just do not see why this should be necessary. The daemon is not need to persist its state to disk all the time like command-based cmake currently needs to. > > * Daemon should do progress handling while reading the CMakeLists.txt > > or whatever it does: > > { "type": "progress", "state": "busy", "task": "someId", > > "taskDescription": "Reading CMakeLists.txt files", "cookie": "1" } > > > > * Daemon sends occasional: > > { "type": "progress", "task": "someId", progressTotal: 25, > > progressCurrent: 12, "cookie": "1" } > > Yes. CMake can provide approximate values of how complete the configure step > is. See cmGlobalGenerator::AddMakefile. That could be exposed to the daemon > 'somehow', such as by defining some virtual callback interface. > > Richer information about some semantics like 'task' and 'busy state' could > also be provided in a similar way I expect, assuming those could be defined. This is some basic functionality that we should get right soon, as this can influence how long-running tasks need to be designed. > > * Finally Daemon responds sends data as that is available now. > > { > > "type": "projectInformation", > > "sourceDirectory": "/some/path", > > "buildDirectory": "", > > "projectName": "SomeProject", > > "cookie": "1" > > } > > At this point in your proposal, cmake has run the configure step in a > temporary directory, right? I am currently arguing with complete ignorance of how cmake works internally:-) This is just what I think makes the most sense from an IDE perspective. > So it would be > > "buildDirectory": "/tmp/foo/bar" > > right? No. The daemon should be associated with a sourcedir,
Re: [cmake-developers] cmake daemon mode protocol
Stephen Kelly wrote: > I recommend focussing on the tasks in my OP: > > http://thread.gmane.org/gmane.comp.lib.qt.creator/11794 To be more clear: The goal I have is to enable debugging, introspection of the buildsystem and the state during execution, code completion etc. Your goal seems to be completely orthogonal to that and requires an entirely different set of steps to achieve (perhaps the first being 'demonstrate viability'). I don't think I can help with your goal. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake daemon mode protocol
Tobias Hunger wrote: >> For this case, I suggest that if the user tries to 'open the source >> directory', you would use QTemporaryDir to build in a temporary location > and >> run the daemon there. I believe clion does something equivalent to that. >> Is that viable? I suppose you are suggesting that cmake do that instead >> of leaving it for clients to do? > > It is doable. I just do not see why this should be necessary. I'm aiming to first design as much as possible of a 'minimal viable protocol' as a first step. Given the above I think your ideas of running the daemon with no build dir are not 'minimal' and I'm convinced they're not viable. Someone would have to prototype the ideas, but I don't think that's a good use of time or energy right now (mostly because I think they're not viable). I recommend focussing on the tasks in my OP: http://thread.gmane.org/gmane.comp.lib.qt.creator/11794 >> Richer information about some semantics like 'task' and 'busy state' >> could also be provided in a similar way I expect, assuming those could be > defined. > > This is some basic functionality that we should get right soon, as this > can influence how long-running tasks need to be designed. Yes. Perhaps you can expand on what 'tasks' and 'busy state' you have in mind. Particularly if you can relate them to what is already in my github branch. > So "cmake --build" is out of scope for the daemon? I listed three ways cmake and an IDE could interface here: http://thread.gmane.org/gmane.comp.lib.qt.creator/11794/focus=15411 'triggering the build' would be a fourth. I don't think it needs to be part of the initial discussion of the design. Let's try to keep scope small so that we can get on common ground. > That is why I brought up progress information so early: They make things > complicated by there suddenly being several responses to a request and you > need a way to identify those. At that point simpler solutions tend to blow > up:-) Yes. BTW: I don't expect to get any part of the design of the protocol 'right' on the first iteration. I think we need to start everything that will need to be in the protocol, then iterate. Start high level ignoring details, and fill in the details as we iterate and can encode needs in unit tests. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake daemon mode protocol
Tobias Hunger wrote: > Hi Stephen, > > I have successfully build and run your cmake server mode changes and > the python client script does work as advertised. Thanks for doing that! > I do have a couple of remarks about it. This is more intended as a > starting point for discussion as a real proposal. Would something > along these lines be possible: > * Start daemon-mode without any additional parameters > > * Daemon responds with " > { > "type": "handShake", > "version": "3.5.x", > "supportedProtocols": "3.5" > } As you discovered, the cmake binary might not even support the daemon mode at all. I think what you are really asking for is 'the capabilities of the cmake binary'. In that sense, you might also want to know what generators are available, whether daemon mode is available (and with which protocol versions) etc. The issue at http://public.kitware.com/Bug/view.php?id=15462 proposes to dump that information to stdout with a different -E command. > > * Client Handshake: > { > "type": "handshake", > "requestProtocolVersion": "3.5" > } > > * Daemon: > { > "type:"handshake", > "protocolVersion": "3.5" > } Something like this is possible too. It's not far off what is already done in the branch. > > At this point the normal operation should be possible. > > * Client: > { > "type": "setProjectInformation", > "sourceDirectory": "/some/path", > "cookie": "1" > } > > Being able to set the source directory is important so that a fresh > checkout can be configured. There is no build directory available at > that time... I understand the desire to inspect a cmake project without asking the user to specify a build dir, but cmake has to write build files somewhere in order to test the compiler etc. For this case, I suggest that if the user tries to 'open the source directory', you would use QTemporaryDir to build in a temporary location and run the daemon there. I believe clion does something equivalent to that. Is that viable? I suppose you are suggesting that cmake do that instead of leaving it for clients to do? > * Daemon should do progress handling while reading the CMakeLists.txt > or whatever it does: > { "type": "progress", "state": "busy", "task": "someId", > "taskDescription": "Reading CMakeLists.txt files", "cookie": "1" } > > * Daemon sends occasional: > { "type": "progress", "task": "someId", progressTotal: 25, > progressCurrent: 12, "cookie": "1" } Yes. CMake can provide approximate values of how complete the configure step is. See cmGlobalGenerator::AddMakefile. That could be exposed to the daemon 'somehow', such as by defining some virtual callback interface. Richer information about some semantics like 'task' and 'busy state' could also be provided in a similar way I expect, assuming those could be defined. > * Finally Daemon responds sends data as that is available now. > { > "type": "projectInformation", > "sourceDirectory": "/some/path", > "buildDirectory": "", > "projectName": "SomeProject", > "cookie": "1" > } At this point in your proposal, cmake has run the configure step in a temporary directory, right? So it would be "buildDirectory": "/tmp/foo/bar" right? > * Client: > { > "type": "setProjectInformation", > "buildDirectory": "/some/other/path", > "cookie": "2" > } As this sets a new build directory, cmake will have to run the configure step from scratch in this new location. > * Daemon does progress indication as above... > > * Daemon responds with project info: > { > "type": "progressInformation", > "sourceDirectory": "/some/path", > "buildDirectory": "/some/other/path", > "projectName": "SomeProject", > "cookie": "2" > } I must admit I'm not seduced by this idea as it seems to be that it should be easy for an IDE to build in a temporary dir itself. However, I think it makes sense to design the protocol to handle specifying either a sourceDir or a buildDir (or both if from scratch). Starting daemon mode without arguments as you suggest could work (though we would have to see how that affects the protocol). Or with a different argument (eg cmake -E daemon buildDir cmake -E daemon_source sourceDir ) could work. I am also just brainstorming ideas, not proscribing anything. > We might also want a "ping"/"pong" to detect if the daemon is still > responding. Yes, I had the same thought. I also considered self-terminating the daemon if there is no message on the wire for N seconds, effectively requiring the IDE to ping every N seconds if it is not doing anything else. I considered this because otherwise the IDE might crash and leave zombie cmake daemons running, but I didn't investigate that possibility. > That would require the daemon to be able to handle > multiple requests to be in flight... not sure that this is worth it. Yes, adding a multi-threading requirement to the daemon might
[cmake-developers] cmake daemon mode protocol
Hi Stephen, I have successfully build and run your cmake server mode changes and the python client script does work as advertised. I do have a couple of remarks about it. This is more intended as a starting point for discussion as a real proposal. Would something along these lines be possible: * Start daemon-mode without any additional parameters * Daemon responds with " { "type": "handShake", "version": "3.5.x", "supportedProtocols": "3.5" } * Client Handshake: { "type": "handshake", "requestProtocolVersion": "3.5" } * Daemon: { "type:"handshake", "protocolVersion": "3.5" } At this point the normal operation should be possible. * Client: { "type": "setProjectInformation", "sourceDirectory": "/some/path", "cookie": "1" } Being able to set the source directory is important so that a fresh checkout can be configured. There is no build directory available at that time... * Daemon should do progress handling while reading the CMakeLists.txt or whatever it does: { "type": "progress", "state": "busy", "task": "someId", "taskDescription": "Reading CMakeLists.txt files", "cookie": "1" } * Daemon sends occasional: { "type": "progress", "task": "someId", progressTotal: 25, progressCurrent: 12, "cookie": "1" } * Daemon sends (probably optional...): { "type": "progress", "task": "someId", "state": "done", "cookie": "1" } * Finally Daemon responds sends data as that is available now. { "type": "projectInformation", "sourceDirectory": "/some/path", "buildDirectory": "", "projectName": "SomeProject", "cookie": "1" } * Client: { "type": "setProjectInformation", "buildDirectory": "/some/other/path", "cookie": "2" } * Daemon does progress indication as above... * Daemon responds with project info: { "type": "progressInformation", "sourceDirectory": "/some/path", "buildDirectory": "/some/other/path", "projectName": "SomeProject", "cookie": "2" } We might also want a "ping"/"pong" to detect if the daemon is still responding. That would require the daemon to be able to handle multiple requests to be in flight... not sure that this is worth it. But if we can not do that, then we need to provide constant progress information, which is also not great:-) Not sure about the need for cookies (text set by the client and repeated by the server in all its replies to that request). I do think having them makes sense, even when only one request can be active at any time: They make it so much easier to sanity-check communication. Consistently having a "type" in all messages going back and forth is probably a good idea for the same reason as having cookies. A final, remark unrelated to the protocol: Ideally the daemon should delay writing into (and even creating!) the build directory for as long as possible (or till instructed to actually persist the configuration). We do have many users that use Qt Creator to browse foreign code and those tend to get upset when we write stuff to disk. Best Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers