[Cmake-commits] CMake branch, master, updated. v3.15.3-1044-g8032977
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 80329771fec7c516540e1db29d971f8f28ed593b (commit) from 19bcdca93c3a05db12652677f8d0e310797bb375 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=80329771fec7c516540e1db29d971f8f28ed593b commit 80329771fec7c516540e1db29d971f8f28ed593b Author: Kitware Robot AuthorDate: Sat Sep 14 00:01:05 2019 -0400 Commit: Kitware Robot CommitDate: Sat Sep 14 00:01:05 2019 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index e9cca30..7384954 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,7 +1,7 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 15) -set(CMake_VERSION_PATCH 20190913) +set(CMake_VERSION_PATCH 20190914) #set(CMake_VERSION_RC 0) set(CMake_VERSION_IS_DIRTY 0) --- Summary of changes: Source/CMakeVersion.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
Re: [cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory
I will do that. It's also easier for me to track the changes that way. Regards, Tushar On Sat, Sep 14, 2019 at 12:04 AM Brad King wrote: > > On 9/13/19 1:30 PM, Tushar Maheshwari wrote: > > Thanks for the quick response. > > I have my commits separated by file groups. I'll open small MRs > > collecting the related groups. > > Thanks. Please just keep a couple MRs open at a time so we don't > overwhelm the CI builders. After some are merged you can open more. > > -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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory
On 9/13/19 1:30 PM, Tushar Maheshwari wrote: > Thanks for the quick response. > I have my commits separated by file groups. I'll open small MRs > collecting the related groups. Thanks. Please just keep a couple MRs open at a time so we don't overwhelm the CI builders. After some are merged you can open more. -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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory
Thanks for the quick response. I have my commits separated by file groups. I'll open small MRs collecting the related groups. Please comment if the grouping is incorrect or if a commit/diff needs to be moved to a different branch. Thanks, Tushar On Fri, Sep 13, 2019 at 10:46 PM Brad King wrote: > > On 9/13/19 12:58 PM, Kyle Edwards via cmake-developers wrote: > > On Fri, 2019-09-13 at 22:08 +0530, Tushar Maheshwari wrote: > >> I have pushed some sample commits to > >> https://gitlab.kitware.com/tusharpm/cmake/commits/smart_mem. > >> > >> If this is something I can pursue, I would appreciate a review of my > >> changes to better suit the project. > > > > We have already made lots of progress in replacing manual delete's with > > std::unique_ptr's, and completing this modernization has been a goal of > > ours since we switched to C++11. I would very strongly encourage you to > > open a merge request with any progress you've made in this regard. > > Yes. Your branch changes a lot of areas and there are several other > rounds of refactoring going on so you may have trouble with conflicts. > I suggest grouping the changes (e.g. ExportSet) and opening a MR with > only one area. Once that is merged open a new MR for another area. > > 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory
On 9/13/19 12:58 PM, Kyle Edwards via cmake-developers wrote: > On Fri, 2019-09-13 at 22:08 +0530, Tushar Maheshwari wrote: >> I have pushed some sample commits to >> https://gitlab.kitware.com/tusharpm/cmake/commits/smart_mem. >> >> If this is something I can pursue, I would appreciate a review of my >> changes to better suit the project. > > We have already made lots of progress in replacing manual delete's with > std::unique_ptr's, and completing this modernization has been a goal of > ours since we switched to C++11. I would very strongly encourage you to > open a merge request with any progress you've made in this regard. Yes. Your branch changes a lot of areas and there are several other rounds of refactoring going on so you may have trouble with conflicts. I suggest grouping the changes (e.g. ExportSet) and opening a MR with only one area. Once that is merged open a new MR for another area. 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory
On Fri, 2019-09-13 at 22:08 +0530, Tushar Maheshwari wrote: > Hi, > > I am a C++ developer and a modern-C++ enthusiast. In the interest of > modernizing the codebase, I propose using smart pointers to handle > dynamically allocated memory. I would like to get the feedback from > the developers if this change is planned/attempted/desirable or > inapplicable for CMake. > > Currently, in the master branch (limiting to the Source directory): > - delete expression appears 127 times (2 of those are false > positives). > $ grep -Er 'delete(\[\])? \S+;' Source | wc -l > 127 > - cmDeleteAll function (a helper to delete a Range of objects) is > used 40 times. > $ grep -Er 'cmDeleteAll\(.+\);' Source | wc -l > 40 > - [Skipping the `free` stats. I can investigate that if required.] > > Many of these are great candidates for `std::unique_ptr`. This can > reduce the destructors of many classes to default, and in some cases > achieve the rule of zero. This aligns well with the "Resource > management" section of the CppCoreGuidelines. > However, it might be impractical to replace some occurrences, like > the > interfaces with C libraries. > > I have pushed some sample commits to > https://gitlab.kitware.com/tusharpm/cmake/commits/smart_mem. > > One drawback I noticed while changing some members to use smart > pointers is the boilerplate required to expose them to the callers. > There might be a cleaner way than passing references to smart > pointers. I would like to discuss those options also, if possible. > > If this is something I can pursue, I would appreciate a review of my > changes to better suit the project. We have already made lots of progress in replacing manual delete's with std::unique_ptr's, and completing this modernization has been a goal of ours since we switched to C++11. I would very strongly encourage you to open a merge request with any progress you've made in this regard. Kyle -- 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: https://cmake.org/mailman/listinfo/cmake-developers
[cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory
Hi, I am a C++ developer and a modern-C++ enthusiast. In the interest of modernizing the codebase, I propose using smart pointers to handle dynamically allocated memory. I would like to get the feedback from the developers if this change is planned/attempted/desirable or inapplicable for CMake. Currently, in the master branch (limiting to the Source directory): - delete expression appears 127 times (2 of those are false positives). $ grep -Er 'delete(\[\])? \S+;' Source | wc -l 127 - cmDeleteAll function (a helper to delete a Range of objects) is used 40 times. $ grep -Er 'cmDeleteAll\(.+\);' Source | wc -l 40 - [Skipping the `free` stats. I can investigate that if required.] Many of these are great candidates for `std::unique_ptr`. This can reduce the destructors of many classes to default, and in some cases achieve the rule of zero. This aligns well with the "Resource management" section of the CppCoreGuidelines. However, it might be impractical to replace some occurrences, like the interfaces with C libraries. I have pushed some sample commits to https://gitlab.kitware.com/tusharpm/cmake/commits/smart_mem. One drawback I noticed while changing some members to use smart pointers is the boilerplate required to expose them to the callers. There might be a cleaner way than passing references to smart pointers. I would like to discuss those options also, if possible. If this is something I can pursue, I would appreciate a review of my changes to better suit the project. Thanks, Tushar -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] Preventing multiple definitions of metaObject methods
On Fri, 2019-09-13 at 15:25 +, Stephen Morris wrote: > Suppose I have a class that derives from QObject, and contains the > Q_OBJECT macro in its header file. When I compile it using AUTOMOC > enabled, a "moc_myClass.cpp" file is created; if I manually include > that file at the end of my 'myClass.cpp" file, then the moc file will > be compiled there, otherwise CMake will take matters into its own > hands and compile it anyway. > > Now suppose make my class into a static library. The static library > now contains the object code generated when moc_myClass.cpp was > compiled. > > I now include my static library from an application. Unless I enable > AUTOMOC again, then I get a compilation error when Q_OBJECT is > encountered. If I do enable it, then CMake generates a new > moc_myClass.cpp file and, since it can't see the place where it was > included in myClass.cpp, it goes ahead and recompiles it, placing the > object code alongside the application's other object code. > > Now, when the application links in the static library, it finds two > definitions of moc_myClass.cpp's object code, and gives a multiple > definition error. > > All the ways I've come up with so far to work around this are so > hacky that I'm embarrassed to mention them. There must be a proper > way to handle this situation. Please can someone advise me what it > is? > > (N.B. I've been doing this for years with dynamic libraries are never > encountered a problem, presumably because there the application > doesn't get to see the inner workings of the library's object code. > This issue does seem to be specific to static libraries, of which I > have little prior experience). Stephen, Could you post a minimally reproducible example with CMakeLists.txt and accompanying source code? I am currently working on a Qt-based project with static libraries and have not encountered this issue. Kyle -- 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: https://cmake.org/mailman/listinfo/cmake
[CMake] Preventing multiple definitions of metaObject methods
Suppose I have a class that derives from QObject, and contains the Q_OBJECT macro in its header file. When I compile it using AUTOMOC enabled, a "moc_myClass.cpp" file is created; if I manually include that file at the end of my 'myClass.cpp" file, then the moc file will be compiled there, otherwise CMake will take matters into its own hands and compile it anyway. Now suppose make my class into a static library. The static library now contains the object code generated when moc_myClass.cpp was compiled. I now include my static library from an application. Unless I enable AUTOMOC again, then I get a compilation error when Q_OBJECT is encountered. If I do enable it, then CMake generates a new moc_myClass.cpp file and, since it can't see the place where it was included in myClass.cpp, it goes ahead and recompiles it, placing the object code alongside the application's other object code. Now, when the application links in the static library, it finds two definitions of moc_myClass.cpp's object code, and gives a multiple definition error. All the ways I've come up with so far to work around this are so hacky that I'm embarrassed to mention them. There must be a proper way to handle this situation. Please can someone advise me what it is? (N.B. I've been doing this for years with dynamic libraries are never encountered a problem, presumably because there the application doesn't get to see the inner workings of the library's object code. This issue does seem to be specific to static libraries, of which I have little prior experience). -- 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: https://cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v3.15.3-1043-g19bcdca
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 19bcdca93c3a05db12652677f8d0e310797bb375 (commit) via 0b8c0b26ce076952bfdc0392d2c93c3597974c9f (commit) via bacb50afa9ed7806a8900ab7524f2f4a4cd7d669 (commit) via a81e9a0ced25490d1384316834dff36a55d4e864 (commit) via 573cd4e4b43d8d3b75f6e7c420b5f833cdd2120e (commit) via 95f23ea5d5a07da503f8e2ab9c52c82086cdcae4 (commit) via 706400d417e6435a442af2626a8430016e24aa9d (commit) via 7f8699026211c6a3055e767125021a91da4b1393 (commit) via 56bfb8de5d1ddc3a499b03be8ae75c9832b6f878 (commit) via 83b3f76a3b13ffe2d8bdf3f67c20e36e22a6955f (commit) via b85407ae76951649907e8e5675fe17d65dfd5457 (commit) via d55319c01d5482ff31166750717252e1b49f1e69 (commit) via fb5affe0859ae1bc07d059fc11cee3daca4d8780 (commit) via 242d876d7b919fe6efb3a347dfa35a66e3ef58df (commit) via 06a2e764f0f088a212e20b85e364b5621ef639fe (commit) via b46970cfe9e0c96a9794acb49fc580565bcd6e91 (commit) via 0b95c64e43e5f60ee9c60570f359a40e4e882096 (commit) via e4c67981aca4fd736fd7503d9d105a0a6fb43828 (commit) via 36b939db682a9405790bee76f95673eeaeb445b8 (commit) via 28cf1271ed6051af46ff68f52a8c9c0435ca1234 (commit) via 41b0d60f48c3d8d882ec25b56d638b392121fcc8 (commit) via f717e1fccf2968ffeba36dc84e428abd4f8db5c0 (commit) via f0ecb123981c6b383a55f7d75e023cf4310f2074 (commit) via 482d858500a42a63c97d3dc11ae74d81a10bab3f (commit) via f6574c9a816ffda7d9ff8c3f2e4ce0485cf28894 (commit) via 2edb0b71edd36031f2fcc0b65633c1c16f8e9268 (commit) via 62d59323899330197e795872c13c1d300a97d088 (commit) via d69457077d021b7d4ea10bf2201da61222966c92 (commit) from 729c928c7b59919a9d379891973bda22665c75da (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=19bcdca93c3a05db12652677f8d0e310797bb375 commit 19bcdca93c3a05db12652677f8d0e310797bb375 Merge: 0b8c0b2 482d858 Author: Brad King AuthorDate: Fri Sep 13 13:56:02 2019 + Commit: Kitware Robot CommitDate: Fri Sep 13 09:56:20 2019 -0400 Merge topic 'target-level-dependencies-via-byproducts' 482d858500 Depend: Add test for target-level dependencies via byproducts f6574c9a81 Depend: Hook up automatic target-level dependencies via byproducts 2edb0b71ed cmMakefile: Add lookup from source name to targets via byproducts 62d5932389 Refatoring: Extract AnyOutputMatches utility Acked-by: Kitware Robot Merge-request: !3806 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0b8c0b26ce076952bfdc0392d2c93c3597974c9f commit 0b8c0b26ce076952bfdc0392d2c93c3597974c9f Merge: bacb50a d694570 Author: Brad King AuthorDate: Fri Sep 13 13:53:16 2019 + Commit: Kitware Robot CommitDate: Fri Sep 13 09:53:41 2019 -0400 Merge topic 'cpack-wix-start-menu' d69457077d CPackWIX: Allow omitting program menu folder and uninstall shortcut Acked-by: Kitware Robot Merge-request: !3802 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bacb50afa9ed7806a8900ab7524f2f4a4cd7d669 commit bacb50afa9ed7806a8900ab7524f2f4a4cd7d669 Merge: 729c928 a81e9a0 Author: Brad King AuthorDate: Fri Sep 13 13:52:23 2019 + Commit: Kitware Robot CommitDate: Fri Sep 13 09:52:34 2019 -0400 Merge topic 'free-free-set-them-free' a81e9a0ced cmSubdirCommand: Port away from cmCommand 573cd4e4b4 cmSetTestsPropertiesCommand: Port away from cmCommand 95f23ea5d5 cmSetSourceFilesPropertiesCommand: Port away from cmCommand 706400d417 cmRemoveDefinitionsCommand: Port away from cmCommand 7f86990262 cmQTWrapUICommand: Port away from cmCommand 56bfb8de5d cmQTWrapCPPCommand: Port away from cmCommand 83b3f76a3b cmLinkLibrariesCommand: Port away from cmCommand b85407ae76 cmInstallTargetsCommand: Port away from cmCommand ... Acked-by: Kitware Robot Merge-request: !3807 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a81e9a0ced25490d1384316834dff36a55d4e864 commit a81e9a0ced25490d1384316834dff36a55d4e864 Author: Regina Pfeifer AuthorDate: Thu Sep 12 16:29:52 2019 +0200 Commit: Regina Pfeifer CommitDate: Thu Sep 12 18:16:17 2019 +0200 cmSubdirCommand: Port away from cmCommand Ref: #19499 diff --git a/Source/cmCommands.cxx b/Source/cmCommands.cxx index 9fb07f2..38fcf5b 100644 --- a/Source/cmCommands.cxx +++ b/Source/cmCommands.cxx @@ -247,7 +247,7 @@ void GetProjectCommands(cmState* state) cm::make_unique());
Re: [CMake] set_target_properties ( INTERFACE_INCLUDE_DIRECTORIES ...)
For completeness, there is also OPTION C: set_property(TARGET target PROPERTY INTERFACE_INCLUDE_DIRECTORIES directory1 directory2) set_target_properties() is a shorthand for setting several properties at once, so it assumes its arguments are prop value prop value. If you need finer control, such as appending or easy way to pass multiple values, use the full power of set_property(). Petr On Fri, 13 Sep 2019 at 06:24, Theodore Hall wrote: > On Thu, Sep 12, 2019 at 6:31 PM Craig Scott > wrote: > > OPTION A: Put quotes around a semi-colon separated string if using >> set_target_properties(): >> > > Many thanks. I had tried quotes, and I had tried a semi-colon, and I > thought that I had tried them together, but evidently I missed that > permutation. > > I'm actually sticking with OPTION B anyway -- it seems cleaner. But I was > mystified looking for OPTION A. > > -- > > Ted Hall > > -- > > 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: > https://cmake.org/mailman/listinfo/cmake > -- 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: https://cmake.org/mailman/listinfo/cmake
