[Cmake-commits] CMake branch, master, updated. v3.15.0-462-g7feece6
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 7feece688d6115601937f4bde7727df70ebea15b (commit) from 579e27ec97101d36d0f42d47bd7aa9c753b15be0 (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=7feece688d6115601937f4bde7727df70ebea15b commit 7feece688d6115601937f4bde7727df70ebea15b Author: Kitware Robot AuthorDate: Fri Jul 26 00:01:24 2019 -0400 Commit: Kitware Robot CommitDate: Fri Jul 26 00:01:24 2019 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 6a1d61f..942ead0 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 15) -set(CMake_VERSION_PATCH 20190725) +set(CMake_VERSION_PATCH 20190726) set(CMake_VERSION_RC 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] Shortcomings with exporting and importing targets
Unfortunately, your approach won't work %( - first of all to write a `*-config.cmake` file the user gonna use `configure_package_config_file` (which is end up w/ `configure_file`). there is no place to use `file(GENERATE...)` since its result appears too late... - Ok, I can imagine that in the middle of `*-config.cmake` one can do `include(genex-expanded-blah-blah.cmake)` which is the result of `file(GENERATE...)` from the CMake run. But, the next problem is to match imported targets (obviously generated as a list variable) to the package names, versions, and components suitable for `find_package`... - The next problem: some finders could be tuned via variables (e.g. `OPENSSL_USE_STATIC_LIBS`, `Boost_USE_MULTITHREADED`, ) or even worse -- finder was given a path hint to load particular build of the third-party dependency (e.g. `XXX_ROOT_DIR`)... So, I'd be happy if CMake could take care of imported targets (loaded via `find_package`) for me and allows me to easily generate an export targets file with required `find_packages` *really used* by my target... On Thu, Jul 25, 2019 at 6:22 PM Robert Maynard wrote: > In general you match every find_package call in your project with one > in your generate config file. If you have complicated conditional > dependencies you might be able to use file(GENERATE to determine which > ones will be used. > > > On Thu, Jul 25, 2019 at 11:02 AM Alex Turbov wrote: > > > > > It is than up to each project to generate an Config module that does > > the required find_package calls to re-locate ZLIB. > > > > Problems begin when mentioned dependencies are wrapped into generator > expressions (e.g. $ or smth even more > complicated) -- how do I know what `find_packages` to include to my > `*-config.cmake`?? > > > > On Thu, Jul 25, 2019 at 5:49 PM Robert Maynard < > robert.mayn...@kitware.com> wrote: > >> > >> target_link_libraries() when given an explicit path+filename as PUBLIC > >> ( not PRIVATE ) will be part of the transitive dependencies. An > >> explicit path+filename is not a target to CMake, nor will CMake > >> compute that it maps to an existing target ( be it imported or a > >> 'normal' target ). > >> > >> > This makes me think that install(TARGETS ...) not supporting imported > targets is likely an oversight by the CMake developers > >> > >> When exporting targets CMake exports what import targets something it > >> depends on. So if you have target_link_libraries(my_target PUBLIC > >> ZLIB::ZLIB) CMake when exporting my_target will export it depends on > >> ZLIB::ZLIB. It does this so that export information is machine > >> relocatable. > >> It is than up to each project to generate an Config module that does > >> the required find_package calls to re-locate ZLIB. > >> > >> On Wed, Jul 24, 2019 at 6:36 PM Benjamin Shadwick < > benshadw...@gmail.com> wrote: > >> > > >> > As a followup to my previous email dated 7/15/19, I learned from a > co-worker this week that if Project A's target_link_libraries() links > against an explicit path+filename of an external library, a subsequent > install(TARGETS ...) command will actually include that dependency in the > exported target for Library A1, such that it will be picked up as a > transitive dependency when later linking Library A1 into a binary in > Project B. > >> > > >> > This makes me think that install(TARGETS ...) not supporting imported > targets is likely an oversight by the CMake developers. This ought to be > fixed, because it effectively discourages people from following the "modern > CMake" approach of using targets wherever possible. > >> > -- > >> > > >> > 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: > >>
Re: [CMake] Shortcomings with exporting and importing targets
In general you match every find_package call in your project with one in your generate config file. If you have complicated conditional dependencies you might be able to use file(GENERATE to determine which ones will be used. On Thu, Jul 25, 2019 at 11:02 AM Alex Turbov wrote: > > > It is than up to each project to generate an Config module that does > the required find_package calls to re-locate ZLIB. > > Problems begin when mentioned dependencies are wrapped into generator > expressions (e.g. $ or smth even more > complicated) -- how do I know what `find_packages` to include to my > `*-config.cmake`?? > > On Thu, Jul 25, 2019 at 5:49 PM Robert Maynard > wrote: >> >> target_link_libraries() when given an explicit path+filename as PUBLIC >> ( not PRIVATE ) will be part of the transitive dependencies. An >> explicit path+filename is not a target to CMake, nor will CMake >> compute that it maps to an existing target ( be it imported or a >> 'normal' target ). >> >> > This makes me think that install(TARGETS ...) not supporting imported >> > targets is likely an oversight by the CMake developers >> >> When exporting targets CMake exports what import targets something it >> depends on. So if you have target_link_libraries(my_target PUBLIC >> ZLIB::ZLIB) CMake when exporting my_target will export it depends on >> ZLIB::ZLIB. It does this so that export information is machine >> relocatable. >> It is than up to each project to generate an Config module that does >> the required find_package calls to re-locate ZLIB. >> >> On Wed, Jul 24, 2019 at 6:36 PM Benjamin Shadwick >> wrote: >> > >> > As a followup to my previous email dated 7/15/19, I learned from a >> > co-worker this week that if Project A's target_link_libraries() links >> > against an explicit path+filename of an external library, a subsequent >> > install(TARGETS ...) command will actually include that dependency in the >> > exported target for Library A1, such that it will be picked up as a >> > transitive dependency when later linking Library A1 into a binary in >> > Project B. >> > >> > This makes me think that install(TARGETS ...) not supporting imported >> > targets is likely an oversight by the CMake developers. This ought to be >> > fixed, because it effectively discourages people from following the >> > "modern CMake" approach of using targets wherever possible. >> > -- >> > >> > 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 -- 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
Re: [CMake] Shortcomings with exporting and importing targets
> It is than up to each project to generate an Config module that does the required find_package calls to re-locate ZLIB. Problems begin when mentioned dependencies are wrapped into generator expressions (e.g. $ or smth even more complicated) -- how do I know what `find_packages` to include to my ` *-config.cmake`?? On Thu, Jul 25, 2019 at 5:49 PM Robert Maynard wrote: > target_link_libraries() when given an explicit path+filename as PUBLIC > ( not PRIVATE ) will be part of the transitive dependencies. An > explicit path+filename is not a target to CMake, nor will CMake > compute that it maps to an existing target ( be it imported or a > 'normal' target ). > > > This makes me think that install(TARGETS ...) not supporting imported > targets is likely an oversight by the CMake developers > > When exporting targets CMake exports what import targets something it > depends on. So if you have target_link_libraries(my_target PUBLIC > ZLIB::ZLIB) CMake when exporting my_target will export it depends on > ZLIB::ZLIB. It does this so that export information is machine > relocatable. > It is than up to each project to generate an Config module that does > the required find_package calls to re-locate ZLIB. > > On Wed, Jul 24, 2019 at 6:36 PM Benjamin Shadwick > wrote: > > > > As a followup to my previous email dated 7/15/19, I learned from a > co-worker this week that if Project A's target_link_libraries() links > against an explicit path+filename of an external library, a subsequent > install(TARGETS ...) command will actually include that dependency in the > exported target for Library A1, such that it will be picked up as a > transitive dependency when later linking Library A1 into a binary in > Project B. > > > > This makes me think that install(TARGETS ...) not supporting imported > targets is likely an oversight by the CMake developers. This ought to be > fixed, because it effectively discourages people from following the "modern > CMake" approach of using targets wherever possible. > > -- > > > > 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 > -- 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
Re: [CMake] Shortcomings with exporting and importing targets
target_link_libraries() when given an explicit path+filename as PUBLIC ( not PRIVATE ) will be part of the transitive dependencies. An explicit path+filename is not a target to CMake, nor will CMake compute that it maps to an existing target ( be it imported or a 'normal' target ). > This makes me think that install(TARGETS ...) not supporting imported targets > is likely an oversight by the CMake developers When exporting targets CMake exports what import targets something it depends on. So if you have target_link_libraries(my_target PUBLIC ZLIB::ZLIB) CMake when exporting my_target will export it depends on ZLIB::ZLIB. It does this so that export information is machine relocatable. It is than up to each project to generate an Config module that does the required find_package calls to re-locate ZLIB. On Wed, Jul 24, 2019 at 6:36 PM Benjamin Shadwick wrote: > > As a followup to my previous email dated 7/15/19, I learned from a co-worker > this week that if Project A's target_link_libraries() links against an > explicit path+filename of an external library, a subsequent install(TARGETS > ...) command will actually include that dependency in the exported target for > Library A1, such that it will be picked up as a transitive dependency when > later linking Library A1 into a binary in Project B. > > This makes me think that install(TARGETS ...) not supporting imported targets > is likely an oversight by the CMake developers. This ought to be fixed, > because it effectively discourages people from following the "modern CMake" > approach of using targets wherever possible. > -- > > 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
[Cmake-commits] CMake branch, master, updated. v3.15.0-461-g579e27e
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 579e27ec97101d36d0f42d47bd7aa9c753b15be0 (commit) via 7b354baad55454e8ef441b0f8e195b93d5caa974 (commit) from a1c6d7e9af5a241b1afa29b3f7459ee9ee4ec77a (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=579e27ec97101d36d0f42d47bd7aa9c753b15be0 commit 579e27ec97101d36d0f42d47bd7aa9c753b15be0 Merge: a1c6d7e 7b354ba Author: Brad King AuthorDate: Thu Jul 25 13:26:45 2019 + Commit: Kitware Robot CommitDate: Thu Jul 25 09:26:55 2019 -0400 Merge topic 'cmake-version-rc' 7b354baad5 CMakeVersion: Set CMake_VERSION_RC to 0 even in non-rc versions Acked-by: Kitware Robot Merge-request: !3603 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7b354baad55454e8ef441b0f8e195b93d5caa974 commit 7b354baad55454e8ef441b0f8e195b93d5caa974 Author: Brad King AuthorDate: Thu Jul 25 08:04:24 2019 -0400 Commit: Brad King CommitDate: Thu Jul 25 09:23:48 2019 -0400 CMakeVersion: Set CMake_VERSION_RC to 0 even in non-rc versions The logic that uses this value already ignores any "false" value, so `0` is just as good as not being set at all. Using `0` for this role makes the version components look more symmetric and reduces the number of edits needed when creating releases. diff --git a/Help/dev/maint.rst b/Help/dev/maint.rst index 1153a09..a1732c8 100644 --- a/Help/dev/maint.rst +++ b/Help/dev/maint.rst @@ -217,7 +217,7 @@ note infrastructure and the version date from ``origin/master``: sed -i $'/^Releases/ i\\\n.. include:: dev.txt\\\n' Help/release/index.rst Update ``Source/CMakeVersion.cmake`` to set the version to -``$major.$minor.$date``: +``$major.$minor.$date`` (and RC ``0`` to disable the suffix): .. code-block:: cmake @@ -225,7 +225,7 @@ Update ``Source/CMakeVersion.cmake`` to set the version to set(CMake_VERSION_MAJOR $major) set(CMake_VERSION_MINOR $minor) set(CMake_VERSION_PATCH $date) - #set(CMake_VERSION_RC 1) + set(CMake_VERSION_RC 0) Commit with a message such as:: diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index f4875fb..6a1d61f 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,4 +2,4 @@ set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 15) set(CMake_VERSION_PATCH 20190725) -#set(CMake_VERSION_RC 1) +set(CMake_VERSION_RC 0) --- Summary of changes: Help/dev/maint.rst| 4 ++-- Source/CMakeVersion.cmake | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
Re: [CMake] add_subdirectory namespaces
Subsequent calls to project() from sub-directories is supported. For calls to project from sub-directories it does everything but set CMAKE_PROJECT_NAME. On Wed, Jul 24, 2019 at 7:29 AM Jason Beach wrote: > > I've been reorganizing / updating our software cmake build. It currently uses > a mixture of Externa Projects and normal target definitions that depend on > the external projects (which has you probably know causes much sorrow and > grief). One of my goals in the reorganization was to replace all the > ExternalProjectAdd statements with FetchContent, however I soon discovered > that some of the external projects declare targets with the same name (i.e. > an uninstall target). These external projects are third party libraries that > are not under our control. > > It appears there's been a suggestion to add namespaces to the > add_subdirectory command: > https://gitlab.kitware.com/cmake/cmake/issues/16414 > > Is that going anywhere? It seems like that would address FetchContent's main > limitation. I guess for the time being I'll use ExternalProject for > thirdparty libraries not under our control and FetchContent for libraries > that are and do a true super build instead of the muddled sort of arrangement > we have now. > > One other kind of not-so-random question-the documentation on the Project > statement is fine if it's in the toplevel CMakeLists.txt (in which case it > defines some project level variables, etc.) but it's silent about what > happens if it's not in the top level CMakeLists.txt. i.e. if I add a library > via add_subdirectory or FetchContent and that library's toplevel > CMakeLists.txt has the project statement, what happens when it's executed? > Is it silently ignored? > > Thanks, > Jason > -- > > 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
[Cmake-commits] CMake branch, master, updated. v3.15.0-459-ga1c6d7e
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 a1c6d7e9af5a241b1afa29b3f7459ee9ee4ec77a (commit) via 070a5e3835b11f76cc8ed8c4a2191295caf8069b (commit) via 420073e53622bd344c9525bce4778ed6aed6276d (commit) from 9111590acadbfa662053c7878ae95efa46bbfb36 (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=a1c6d7e9af5a241b1afa29b3f7459ee9ee4ec77a commit a1c6d7e9af5a241b1afa29b3f7459ee9ee4ec77a Merge: 9111590 070a5e3 Author: Brad King AuthorDate: Thu Jul 25 07:27:14 2019 -0400 Commit: Brad King CommitDate: Thu Jul 25 07:27:14 2019 -0400 Merge branch 'release-3.15' --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, release, updated. v3.15.0-24-g070a5e3
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, release has been updated via 070a5e3835b11f76cc8ed8c4a2191295caf8069b (commit) via d46bac5d38320907cc1f11a223fddd9a11c9b184 (commit) via 420073e53622bd344c9525bce4778ed6aed6276d (commit) via 4f15a6a5c200be8235c3e38390aba438186e7f19 (commit) via d50b31be35ed113a41f3944179f8e4a362018f86 (commit) from 07b93cb1850fa8365c42c4f9e671a423689b3d0a (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 - --- Summary of changes: Modules/Compiler/Clang-CXX.cmake| 7 +++ Source/kwsys/SystemTools.cxx| 7 ++- Source/kwsys/testSystemTools.cxx| 8 ++-- Tests/AliasTarget/CMakeLists.txt| 2 +- Tests/Complex/CMakeLists.txt| 5 - Tests/ComplexOneConfig/CMakeLists.txt | 5 - .../Module/WriteCompilerDetectionHeader/CMakeLists.txt | 4 +--- Tests/Plugin/CMakeLists.txt | 17 ++--- Tests/RunCMake/BuildDepends/BuildUnderSource.c | 5 + Tests/RunCMake/BuildDepends/BuildUnderSource.cmake | 9 + .../RunCMake/BuildDepends/BuildUnderSource.step1.cmake | 3 +++ .../RunCMake/BuildDepends/BuildUnderSource.step2.cmake | 3 +++ Tests/RunCMake/BuildDepends/RunCMakeTest.cmake | 16 +++- Tests/RunCMake/GenerateExportHeader/GEH.cmake | 5 - Tests/Tutorial/Complete/CMakeLists.txt | 3 ++- Tests/Tutorial/Consumer/CMakeLists.txt | 3 ++- Tests/Tutorial/Step10/CMakeLists.txt| 3 ++- Tests/Tutorial/Step11/CMakeLists.txt| 3 ++- Tests/Tutorial/Step2/CMakeLists.txt | 4 +++- Tests/Tutorial/Step2/directions.txt | 3 ++- Tests/Tutorial/Step3/CMakeLists.txt | 3 ++- Tests/Tutorial/Step4/CMakeLists.txt | 3 ++- Tests/Tutorial/Step5/CMakeLists.txt | 3 ++- Tests/Tutorial/Step6/CMakeLists.txt | 3 ++- Tests/Tutorial/Step7/CMakeLists.txt | 3 ++- Tests/Tutorial/Step8/CMakeLists.txt | 3 ++- Tests/Tutorial/Step9/CMakeLists.txt | 3 ++- 27 files changed, 89 insertions(+), 47 deletions(-) create mode 100644 Tests/RunCMake/BuildDepends/BuildUnderSource.c create mode 100644 Tests/RunCMake/BuildDepends/BuildUnderSource.cmake create mode 100644 Tests/RunCMake/BuildDepends/BuildUnderSource.step1.cmake create mode 100644 Tests/RunCMake/BuildDepends/BuildUnderSource.step2.cmake hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.15.0-456-g9111590
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 9111590acadbfa662053c7878ae95efa46bbfb36 (commit)
via c173ed118429a885947907d2e23a9895a60b839a (commit)
via 6e0d92cc53fae3f83cacc8c528ea601562fa1753 (commit)
via d46bac5d38320907cc1f11a223fddd9a11c9b184 (commit)
via a4657ef670962be794d07d1d323c230995ed5593 (commit)
via 161b33f12b9a225607a4ea8339eabd4875bebbfe (commit)
via 4f15a6a5c200be8235c3e38390aba438186e7f19 (commit)
via 5cfc39127e4b9e20d9fdfca885b38272909c5694 (commit)
via d50b31be35ed113a41f3944179f8e4a362018f86 (commit)
via 3391a3eca821ec9e2844af60835e6f2ab722ceed (commit)
from 00be1957da52acac2988e4702f4f8e95fbf170dd (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=9111590acadbfa662053c7878ae95efa46bbfb36
commit 9111590acadbfa662053c7878ae95efa46bbfb36
Merge: c173ed1 3391a3e
Author: Brad King
AuthorDate: Thu Jul 25 11:21:06 2019 +
Commit: Kitware Robot
CommitDate: Thu Jul 25 07:21:18 2019 -0400
Merge topic 'ninja-swift-map-file-path'
3391a3eca8 Ninja: do not normalise swift support file paths
Acked-by: Kitware Robot
Merge-request: !3597
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c173ed118429a885947907d2e23a9895a60b839a
commit c173ed118429a885947907d2e23a9895a60b839a
Merge: 6e0d92c d46bac5
Author: Brad King
AuthorDate: Thu Jul 25 11:20:00 2019 +
Commit: Kitware Robot
CommitDate: Thu Jul 25 07:20:09 2019 -0400
Merge topic 'makefile-depend-relative-include'
d46bac5d38 Makefile: Fix regression in dependencies on relative includes
Acked-by: Kitware Robot
Merge-request: !3599
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e0d92cc53fae3f83cacc8c528ea601562fa1753
commit 6e0d92cc53fae3f83cacc8c528ea601562fa1753
Merge: 00be195 a4657ef
Author: Brad King
AuthorDate: Thu Jul 25 11:17:11 2019 +
Commit: Kitware Robot
CommitDate: Thu Jul 25 07:17:22 2019 -0400
Merge topic 'clang-gnulike-support'
a4657ef670 Merge branch 'backport-clang-gnulike-support' into
clang-gnulike-support
161b33f12b Help/guide/tutorial: Revert "require C++14 for the Tutorial"
4f15a6a5c2 Tests: Revert "require C++14 for the Tutorial"
5cfc39127e Merge branch 'backport-clang-gnulike-support' into
clang-gnulike-support
d50b31be35 Clang: For MSVC ABI do not use modes older than C++14
Acked-by: Kitware Robot
Merge-request: !3592
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d46bac5d38320907cc1f11a223fddd9a11c9b184
commit d46bac5d38320907cc1f11a223fddd9a11c9b184
Author: Brad King
AuthorDate: Wed Jul 24 09:53:53 2019 -0400
Commit: Brad King
CommitDate: Wed Jul 24 11:37:31 2019 -0400
Makefile: Fix regression in dependencies on relative includes
Since commit a13a5c948e (Replace use of CollapseCombinedPath with
CollapseFullPath, 2019-03-19, v3.15.0-rc1~361^2~1), one code path now
calls `CollapseFullPath` with a base path that may be relative.
Backport KWSys commit c6f8e24a3 (SystemTools: Fix CollapseFullPath with
relative base path, 2019-07-24) to handle such base paths.
This case occurs when a build tree is placed in a directory inside a
source tree such that CMake is willing to generate a relative path from
the build tree to the source tree. Add a test covering this case.
Fixes: #19507
diff --git a/Source/kwsys/SystemTools.cxx b/Source/kwsys/SystemTools.cxx
index 2135913..ae7a18a 100644
--- a/Source/kwsys/SystemTools.cxx
+++ b/Source/kwsys/SystemTools.cxx
@@ -3394,8 +3394,13 @@ static void SystemToolsAppendComponents(
static const std::string cur = ".";
for (std::vector::const_iterator i = first; i != last; ++i) {
if (*i == up) {
- if (out_components.size() > 1) {
+ // Remove the previous component if possible. Ignore ../ components
+ // that try to go above the root. Keep ../ components if they are
+ // at the beginning of a relative path (base path is relative).
+ if (out_components.size() > 1 && out_components.back() != up) {
out_components.resize(out_components.size() - 1);
+ } else if (!out_components.empty() && out_components[0].empty()) {
+out_components.emplace_back(std::move(*i));
}
} else if (!i->empty() && *i != cur) {
#if __cplusplus >= 201103L || (defined(_MSVC_LANG) && _MSVC_LANG >= 201103L)
diff --git a/Source/kwsys/testSystemTools.cxx b/Source/kwsys/testSystemTools.cxx
index 9a40b53..ffa6a29 100644
--- a/Source/kwsys/testSystemTools.cxx
+++
