[Cmake-commits] CMake branch, master, updated. v3.16.0-rc2-87-g0671f71d70
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 0671f71d70db238b35c7cd64296e0b9f3a5e68a9 (commit) from 493c4e781a35a92c5c912b22493b84de750b1fe1 (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=0671f71d70db238b35c7cd64296e0b9f3a5e68a9 commit 0671f71d70db238b35c7cd64296e0b9f3a5e68a9 Author: Kitware Robot AuthorDate: Sat Oct 19 00:01:07 2019 -0400 Commit: Kitware Robot CommitDate: Sat Oct 19 00:01:07 2019 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index beeb0a6dac..f129c3aa18 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 16) -set(CMake_VERSION_PATCH 20191018) +set(CMake_VERSION_PATCH 20191019) #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] CMake link order
Hello,
I have always used all of the libraries at once to the
TARGET_LINK_LIBRARIES command.
In the following example, the link line order appears the same as the
libraries are listed on the line.
TARGET_LINK_LIBRARIES(devsim_tcl ${LIBRARIES} ${TCL_ARCHIVE}
${SUPERLU_ARCHIVE} ${BLAS_ARCHIVE} ${SQLITE3_ARCHIVE}
${SYMDIFF_ARCHIVE} ${OPTIONAL_LIBS} ${PTHREAD_LIB} ${DLOPEN_LIB})
This is important because my LIBRARIES need to all be on the link line
before the other libraries I am using.
Another option is to explicitly us ADD_DEPENDENCY to add dependencies
between the libraries:
https://cmake.org/cmake/help/latest/command/add_dependencies.html
If I had multiple libraries hopelessly intertwined, I would list them
multiple times:
A B A C
or force the linker to do multiple passes:
-Wl,--start-group A B C -Wl,--end-group
This is by using the start-group and end-group flags in your
TARGET_LINK_LIBRARIES line.
https://cmake.org/pipermail/cmake/2011-May/044478.html
Regards,
Juan
On Fri, Oct 18, 2019 at 9:56 AM Bon, William
wrote:
> Hello,
>
> we are facing an issue while using cmake and we have no idea how to solve
> or debug it.
> We have a complex and huge project (about 50 subdirectories and
> dependencies everywhere), and we are facing issue regarding the link order.
> There is a lot of dependencies between those projects, and to summarize,
> we have two libraries A and B
> A is an imported library from headers and shared lib .so declared like this
> ```
> add_library(A SHARED IMPORTED GLOBAL)
> set_target_properties(A PROPERTIES
> IMPORTED_LINK_INTERFACE_LANGUAGES "C"
> IMPORTED_LOCATION ${A_LIBRARY})
> ```
>
> B is a system library part of a package.
>
> We need to link A before B in every case.
>
> In every project, we include A before B using
> ```
> find_package(B)
> target_link_libraries(${library_produced} PUBLIC A)
> target_link_libraries(${library_produced} PUBLIC B)
> ```
>
> but from time to time, we don't know why, the library produced link in the
> wrong order (checked with ldd and make VERBOSE=1).
> it links B before A.
>
> Is there a way to find out what happens and why cmake change the link
> order for some project and not all projects ?
>
> Best regards,
>
> Bill
> --
>
> 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] CMake link order
Hey all,
I face a similar problem when constructing a correct (and predictable)
link order for Linux and Cygwin. It would be of great help, if there is
some documentation.
In particular, I would raise two question
1) when does the link order change?
2) when does a clean up happen and in which way?
I did also some experiments on linux with cmake 3.13.4 and ended up with
the appended (nearly) minimal example. The example consists of:
* two "fake"-libraries A and B, whose paths are stored in two
variables libA and libB respectively. (they serve just for
demonstration, no real linking is required)
* two interface libraries interfaceA and interfaceB. Each links to the
corresponding fake library.
* two imported libraries impA and impB, each has the location to the
corresponding fake library.
Now I construct some combinations:
1. An interface library interfaceA_B_vA, which links against the
interface libraries "interfaceA interfaceB ${libA}" and an
executable, which links only against interfaceA_B_vA. For that
executable, I get the link order "B A"
2. Suppose one tries to correct that and link explicitly against with
the variable. Such an executable which links as "${libA}
interfaceA_B_vA". In that case, I got the link order "A A B". So we
have a changed order compared to the previous experiment.
3. If I use the imported libraries instead of the variables from
experiment 1, I get the link order A B A, as expected.
From these experiments, I got the impression, that
1. linking through variables remains a nightmare. That is nothing new.
2. interface libraries might change their order
3. imported libraries lead to a more stable link order?
I hope somebody could shed some light in this behavior.
Best regards,
Andreas
Am 18.10.19 um 18:24 schrieb Fred Baksik:
On Fri, Oct 18, 2019, at 11:55 AM, Fred Baksik wrote:
In target_link_libraries it states that "The library dependency graph
is normally acyclic (a DAG)". I recall from my own experience that
the DAG is not always created the same way when generating the
project. It has to do with the way with this part of CMake is
implemented (C++ containers and that sort of thing) so while all the
inputs are the same the order is Not the same so it produces a
different DAG which changed the ordering of the components build
order which also altered the link order.
For the GHS Generator to ensure that the exact same project files are
output we sorted the components by name into a vector first (instead
of just using a set) before supplying it to this algorithm. Then the
results were always the same.
Sorry, I wanted to clarify this a bit. The DAG is correct. For
example lets say A depends on B and C and then C on D. This DAG
always comes out the same. But when you try to extract the dependents
of A it sometimes returns something that will give you B then C or C
then B when accessing them in a linear order. So there were
differences if you inspected these items with the debugger.
When I ran across these kinds of things with the GHS Generator we sort
things in lexicographical order to produce the same results every time.
Best regards,
Fred
project(testLinkOrder)
cmake_minimum_required(VERSION 3.5)
file(WRITE "simpleProg.cc" "int main() { return 0; }")
set(libA "${CMAKE_BINARY_DIR}/A.a")
file(WRITE "${libA}" "i am not a library")
set(libB "${CMAKE_BINARY_DIR}/B.a")
file(WRITE "${libB}" "i am not a library")
add_library(impA IMPORTED STATIC)
set_target_properties(impA PROPERTIES IMPORTED_LOCATION ${libA})
add_library(impB IMPORTED STATIC)
set_target_properties(impB PROPERTIES IMPORTED_LOCATION ${libB})
add_library(interfaceA INTERFACE)
target_link_libraries(interfaceA INTERFACE ${libA})
add_library(interfaceB INTERFACE)
target_link_libraries(interfaceB INTERFACE ${libB})
#target_link_libraries(interfaceA INTERFACE ${libB})
add_library(interface_A_B_vA INTERFACE)
target_link_libraries(interface_A_B_vA INTERFACE interfaceA interfaceB ${libA})
add_executable(linkInterface_A_B_vA simpleProg.cc)
target_link_libraries(linkInterface_A_B_vA interface_A_B_vA)
add_executable(linkvA_IABAVA simpleProg.cc)
target_link_libraries(linkvA_IABAVA ${libA} interface_A_B_vA)
add_library(interface_impA_impB_vA INTERFACE)
target_link_libraries(interface_impA_impB_vA INTERFACE impA impB ${libA})
add_executable(linkInterface_impA_impB_vA simpleProg.cc)
target_link_libraries(linkInterface_impA_impB_vA interface_impA_impB_vA)
--
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
Re: [CMake] CMake link order
On Fri, Oct 18, 2019, at 11:55 AM, Fred Baksik wrote: > > In target_link_libraries it states that "The library dependency graph is > normally acyclic (a DAG)". I recall from my own experience that the DAG is > not always created the same way when generating the project. It has to do > with the way with this part of CMake is implemented (C++ containers and that > sort of thing) so while all the inputs are the same the order is Not the same > so it produces a different DAG which changed the ordering of the components > build order which also altered the link order. > > For the GHS Generator to ensure that the exact same project files are output > we sorted the components by name into a vector first (instead of just using a > set) before supplying it to this algorithm. Then the results were always the > same. > Sorry, I wanted to clarify this a bit. The DAG is correct. For example lets say A depends on B and C and then C on D. This DAG always comes out the same. But when you try to extract the dependents of A it sometimes returns something that will give you B then C or C then B when accessing them in a linear order. So there were differences if you inspected these items with the debugger. When I ran across these kinds of things with the GHS Generator we sort things in lexicographical order to produce the same results every time. Best regards, Fred-- 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] CMake link order
On Fri, Oct 18, 2019, at 6:24 AM, Bon, William wrote:
> Hello,
>
> we are facing an issue while using cmake and we have no idea how to solve or
> debug it.
> We have a complex and huge project (about 50 subdirectories and dependencies
> everywhere), and we are facing issue regarding the link order.
> There is a lot of dependencies between those projects, and to summarize, we
> have two libraries A and B
> A is an imported library from headers and shared lib .so declared like this
> ```
> add_library(A SHARED IMPORTED GLOBAL)
> set_target_properties(A PROPERTIES
> IMPORTED_LINK_INTERFACE_LANGUAGES "C"
> IMPORTED_LOCATION ${A_LIBRARY})
> ```
>
> B is a system library part of a package.
>
> We need to link A before B in every case.
>
> In every project, we include A before B using
> ```
> find_package(B)
> target_link_libraries(${library_produced} PUBLIC A)
> target_link_libraries(${library_produced} PUBLIC B)
> ```
>
> but from time to time, we don't know why, the library produced link in the
> wrong order (checked with ldd and make VERBOSE=1).
> it links B before A.
>
> Is there a way to find out what happens and why cmake change the link order
> for some project and not all projects ?
>
> Best regards,
>
> Bill
>
I'm going by memory when I saw something similar when updating the GHS
Generator in CMake.
In target_link_libraries it states that "The library dependency graph is
normally acyclic (a DAG)". I recall from my own experience that the DAG is not
always created the same way when generating the project. It has to do with the
way with this part of CMake is implemented (C++ containers and that sort of
thing) so while all the inputs are the same the order is Not the same so it
produces a different DAG which changed the ordering of the components build
order which also altered the link order.
For the GHS Generator to ensure that the exact same project files are output we
sorted the components by name into a vector first (instead of just using a set)
before supplying it to this algorithm. Then the results were always the same.
But if I remember correctly an "add_dependency( B A )" or otherwise make B
dependent on A does forces a dependency between the two libraries which forces
the DAG to always put A before B.
I would bet that if you just did the project generation over and over again
into different build directories you'll notice these kinds of differences in
the different Makefiles (or whatever output that is expected by the generator).
This is how I noticed the issue with the GHS Generator because the ordering of
some items were just changing in an unexpected fashion and I was always
comparing what it generated against what I was expecting it to generate.
I never asked the main developers about this; and again this is just my own
observations.
Best regards,
Fred--
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] CMake link order
Hello,
we are facing an issue while using cmake and we have no idea how to solve or
debug it.
We have a complex and huge project (about 50 subdirectories and dependencies
everywhere), and we are facing issue regarding the link order.
There is a lot of dependencies between those projects, and to summarize, we
have two libraries A and B
A is an imported library from headers and shared lib .so declared like this
```
add_library(A SHARED IMPORTED GLOBAL)
set_target_properties(A PROPERTIES
IMPORTED_LINK_INTERFACE_LANGUAGES "C"
IMPORTED_LOCATION ${A_LIBRARY})
```
B is a system library part of a package.
We need to link A before B in every case.
In every project, we include A before B using
```
find_package(B)
target_link_libraries(${library_produced} PUBLIC A)
target_link_libraries(${library_produced} PUBLIC B)
```
but from time to time, we don't know why, the library produced link in the
wrong order (checked with ldd and make VERBOSE=1).
it links B before A.
Is there a way to find out what happens and why cmake change the link order for
some project and not all projects ?
Best regards,
Bill
--
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 annotated tag, v3.16.0-rc2, created. v3.16.0-rc2
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 annotated tag, v3.16.0-rc2 has been created at 371dbf3c152a397447bfae8ddff298b64b01b83b (tag) tagging 92780281c2e8a46223b262b152caa9c8329373b1 (commit) replaces v3.16.0-rc1 tagged by Brad King on Fri Oct 18 10:35:38 2019 -0400 - Log - CMake 3.16.0-rc2 -BEGIN PGP SIGNATURE- iQJKBAABCgA0FiEExsJlMku+vcNQtRPQLSzvEDSSFoQFAl2pzboWHGJyYWQua2lu Z0BraXR3YXJlLmNvbQAKCRAtLO8QNJIWhERaD/9OVP0OTe1NQSzV5hE+AemsP6lk TGenQa7XQLAP3i6V4iEoGBjVal/VnwMLqT2VKwVdEyzQCj/rJlormMR18ejS48ug Zq0WWlTa4wgjDQWl6WJNMvciBZgunHq1QgSxWkzuOwDM89+WFQseH2vaDUyIuP4D avAl97+uFyiFkAdRHFZkISkKDY0unnMyGoxN4QdplrsbrOV+DR01eCzSPGma5oyl dc5GawFB2HdWFDC92hU2dvSQZL8kJOyyUGoOHK2Fe1gDszRMJNqtkhrZy9qMklJ6 i4wZc5FMCh4kGMPYtzH7Y2n0Nt5WkOBpeUK4IsK0j8cANRpmOlnYtn+DnI2vpdX0 ubGFJG+sBnsP5SO6KndKHMyWFnGKkgw0Fq/0ytrt5fa752AofY0Mevfj9nP0kKxF yeHN3YMPY0D7ATEuPQ8Ts2nnkhYVYdEOHHgO4N7buRKPp5jlVSxJJJL+T48L3O1N n+TNwRKYmTZ4VmooiGxsK0OWfj8DBszHWtpBFha5E1QrG3/cl/9Frpi370gXc5sH fu5ViCrBvHrnAh3+zsSmz16ezvpHO44hlkGi0AQ6r3/cqnldRNWrMBMe3lXTUJlU qcwWJErQuMUQGhO85L5O2YNJp35YK989+2goBEi93DhiIvnF4dlADcY3I+bHX2cT sB9+D/SZYgrZrlsPFQ== =S0Rj -END PGP SIGNATURE- Ben Boeckel (2): FindPostgreSQL: support version 12 FindPostgreSQL: support macports installation scheme Brad King (36): Intel: Fix default C++ dialect detection on Windows Tests: Update CompileFeatures test for Intel 19 with VS 2015 Help: Document CMAKE_UNITY_BUILD in 3.16 release notes Help: Improve UNITY_BUILD documentation formatting Help: Extend documentation of CMAKE_UNITY_BUILD variable Help: Document CMAKE_UNITY_BUILD/CMAKE_EXPORT_COMPILE_COMMANDS limitation Merge branch 'intel-19-compile-features' into release-3.16 Merge branch 'doc-unity-build' into release-3.16 Merge branch 'objc-c++flags' into release-3.16 Merge branch 'iar-8051-support' into release-3.16 Merge branch 'FindPostgreSQL-macports-and-v12' into release-3.16 VS: Add toolset v142 CSharp flag table Merge branch 'vs-v142-csharp-flags' into release-3.16 IRSL: Prefer MSVC runtime libraries from newest toolset first IRSL: Install vcruntime140_1.dll if available Merge branch 'InstallRequiredSystemLibraries-redist' into release-3.16 CMakeVersion: Prefer Git information provided by 'git archive' exports Merge branch 'no-git-version' into release-3.16 Merge branch 'FindOpenMP-clang-HIP-device' into release-3.16 Merge branch 'cmake-initial-cache-relative' into release-3.16 Help: Clarify documentation of CMAKE_STATIC_LINKER_FLAGS CMakeFindBinUtils: Remove unnecessary variable unset calls Merge branch 'doc-static-lib-flags' into release-3.16 Merge branch 'FindHDF5-cray' into release-3.16 Merge branch 'FindCurses-tinfow' into release-3.16 Merge branch 'CMakeFindBinUtils-cleanup' into release-3.16 Merge branch 'swift-cross-compile' into release-3.16 Merge branch 'doc-add_link_options-typos' into release-3.16 PCH: Document and test COMPILE_LANGUAGE genex for per-language header Merge branch 'doc-pch-compile-language' into release-3.16 install,export: Do not treat language names as target names cmMakefileTargetGenerator: Inline WriteObjectBuildFile in only call site Merge branch 'export-target-lang-name' into release-3.16 PCH: Fix Makefile dependencies to rebuild PCH on header changes Merge branch 'pch-makefile-depends' into release-3.16 CMake 3.16.0-rc2 Cristian Adam (1): Objective-C: Do not treat Objective-C files as C++ files Konstantin Pyzhov (1): FindOpenMP: Add support for HIP clang device pass Kyle Edwards (1): CMakeVersion: Add option to disable Git suffix Manuel Herrmann (1): FindCurses: use tinfow when wide support is requested Micael Borgefeldt (2): IAR: Fix v850 assembler support file extensions IAR: Add 8051 support Peter Waller (1): cmake: Fix relative path regression in -C Saleem Abdulrasool (1): try_compile: support Swift for cross-compilation Tom Lankhorst (1): Help: Fix typos and style in add_link_options documentation Willem Deconinck (2): FindHDF5: Cray HDF5 Fortran module filename is usually capitalized FindHDF5: Append hdf5 to hdf5_hl to avoid undefined references --- 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.16.0-rc1-49-g92780281c2
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 92780281c2e8a46223b262b152caa9c8329373b1 (commit) from 6dedb9742094470196698a5009441e3860e61f2a (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: 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
[Cmake-commits] CMake branch, master, updated. v3.16.0-rc1-135-g493c4e781a
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 493c4e781a35a92c5c912b22493b84de750b1fe1 (commit) via 92780281c2e8a46223b262b152caa9c8329373b1 (commit) from fdb41a5102e1fef50fb918eba5f84cfc19a62734 (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=493c4e781a35a92c5c912b22493b84de750b1fe1 commit 493c4e781a35a92c5c912b22493b84de750b1fe1 Merge: fdb41a5102 92780281c2 Author: Brad King AuthorDate: Fri Oct 18 10:36:40 2019 -0400 Commit: Brad King CommitDate: Fri Oct 18 10:36:40 2019 -0400 Merge branch 'release-3.16' --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[CMake] setting rpath in executable in build directory
Hello, I have the following scenario. I have gcc 9.2.0 and boost 1.71.0 installed in /opt/ZS/deps/... directory, built for both arm and x86_64. I can build programs using them just fine and they run as expected provided -Wl,-rpaht,/opt/ZS/deps... is added to g++ command line. Now I'm trying to build mqtt_cpp library (https://github.com/redboltz/mqtt_cpp) using them. Everything builds just fine using: export CXX=x86_64-linux-gnu-g++-9.2.0 cmake -G'Unix Makefiles' -S. -Bbuild \ -DBOOST_ROOT=/opt/ZS/deps/include/ \ -DBOOST_LIBRARYDIR=/opt/ZS/deps/x86_64-linux-gnu/lib/ This of course does not contain any information regarding RPATH. I assumed this is why binaries (examples in fact) in build directory can't find proper libraries, so I tried installing them (examples). Unfortunately "make install" installs library (it is header-only library) and not examples, so I can't run any of them. Since I *really* want to run these examples, I tried configuring and building using this command: export CXX=x86_64-linux-gnu-g++-9.2.0 cmake -G'Unix Makefiles' -S. -Bbuild \ -DBOOST_ROOT=/opt/ZS/deps/include/ \ -DBOOST_LIBRARYDIR=/opt/ZS/deps/x86_64-linux-gnu/lib/ \ -DCMAKE_SKIP_BUILD_RPATH=FALSE \ -DCMAKE_SKIP_RPATH=OFF \ -DCMAKE_BUILD_WITH_INSTALL_RPATH=TRUE I assumed that -DCMAKE_SKIP_BUILD_RPATH=FALSE means that I want binaries in build directory (not installed ones) to already have RPATH embedded. I also assumed that -DCMAKE_SKIP_RPATH=OFF assures me that RPATH will be used during build and/or installation. I assumed that -DCMAKE_BUILD_WITH_INSTALL_RPATH=TRUE is supposed to add to binaries in build directory RPATH containing paths to libraries found and used by CMake. All of this simply isn't true, binaries generated by "make -j 4" not only don't have proper RPATH, they don't have rpath at all, not even invalid one. I tried with: readelf -a build/example/broker | grep -i rpath and using chrpath: chrpath build/exampl/broker but there is not even a trace of rpath. Greps comes back emptyhanded and `chrpath` util informs me, that: broker: no rpath or runpath tag found Is there some some magical combination of these flags that allows me to build and run (this is paramount) binaries that were not installed? CMake used is 3.15.4, I don't think earlier ones are aware of boost's version 1.71.0. I also tried adding -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=ON , but it changes nothing. Thanks in advance, -- Jędrzej Dudkiewicz I really hate this damn machine, I wish that they would sell it. It never does just what I want, but only what I tell it. -- 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.16.0-rc1-133-gfdb41a5102
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 fdb41a5102e1fef50fb918eba5f84cfc19a62734 (commit)
via b34b4c5eac27bfc4a1e46f2b46ba17f5be6a8565 (commit)
via e7d57bc3c35e7c47746caf91591ef748b9ce3012 (commit)
via 45b4b4b93076e16281ecee628ef8ffb0aae8f3d6 (commit)
via 4bedf6c9fa3f55a19b09d5ab26cfd149ee2e13e6 (commit)
via 548e9051a4f20657d04341107924171ea9d1bcb5 (commit)
via 99e83d423500e11a8e85c2032e8c536bce175ed1 (commit)
from c867981c9d9bc8548d34f726940cd50b8d05d71c (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=fdb41a5102e1fef50fb918eba5f84cfc19a62734
commit fdb41a5102e1fef50fb918eba5f84cfc19a62734
Merge: b34b4c5eac 4bedf6c9fa
Author: Brad King
AuthorDate: Fri Oct 18 13:01:57 2019 +
Commit: Kitware Robot
CommitDate: Fri Oct 18 09:02:29 2019 -0400
Merge topic 'variable_watch-modernize'
4bedf6c9fa Refactor: Modernize `cmVariableWatchCommand` a little
Acked-by: Kitware Robot
Merge-request: !3892
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b34b4c5eac27bfc4a1e46f2b46ba17f5be6a8565
commit b34b4c5eac27bfc4a1e46f2b46ba17f5be6a8565
Merge: c867981c9d e7d57bc3c3
Author: Brad King
AuthorDate: Fri Oct 18 13:01:36 2019 +
Commit: Kitware Robot
CommitDate: Fri Oct 18 09:01:48 2019 -0400
Merge topic 'vs-vctargetspath'
e7d57bc3c3 VS: Propagate CMAKE_VS_GLOBALS into custom targets
45b4b4b930 VS: Propagate CMAKE_VS_GLOBALS into compiler id projects
548e9051a4 VS: Add support to override VCTargetsPath through toolset
99e83d4235 cmake: Teach --build mode to load CMAKE_GENERATOR_TOOLSET
Acked-by: Kitware Robot
Merge-request: !3817
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7d57bc3c35e7c47746caf91591ef748b9ce3012
commit e7d57bc3c35e7c47746caf91591ef748b9ce3012
Author: Alexander Boczar
AuthorDate: Mon Sep 16 16:55:26 2019 -0700
Commit: Brad King
CommitDate: Thu Oct 17 10:19:01 2019 -0400
VS: Propagate CMAKE_VS_GLOBALS into custom targets
Issue: #19708
diff --git a/Help/release/dev/vs-vctargetspath.rst
b/Help/release/dev/vs-vctargetspath.rst
index 462d183b2a..d40af349e4 100644
--- a/Help/release/dev/vs-vctargetspath.rst
+++ b/Help/release/dev/vs-vctargetspath.rst
@@ -6,4 +6,5 @@ vs-vctargetspath
to specify the ``VCTargetsPath`` value for project files.
* The :variable:`CMAKE_VS_GLOBALS` variable value now applies during
- compiler identification.
+ compiler identification and in targets created by the
+ :command:`add_custom_target` command.
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 99c16f2374..a4f904b155 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -511,8 +511,7 @@ cmTarget::cmTarget(std::string const& name,
cmStateEnums::TargetType type,
initProp("DOTNET_TARGET_FRAMEWORK_VERSION");
}
- if (this->GetType() != cmStateEnums::INTERFACE_LIBRARY &&
- this->GetType() != cmStateEnums::UTILITY) {
+ if (this->GetType() != cmStateEnums::INTERFACE_LIBRARY) {
// check for "CMAKE_VS_GLOBALS" variable and set up target properties
// if any
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=45b4b4b93076e16281ecee628ef8ffb0aae8f3d6
commit 45b4b4b93076e16281ecee628ef8ffb0aae8f3d6
Author: Alexander Boczar
AuthorDate: Thu Sep 26 17:37:47 2019 -0700
Commit: Brad King
CommitDate: Thu Oct 17 10:18:52 2019 -0400
VS: Propagate CMAKE_VS_GLOBALS into compiler id projects
Issue: #19708
diff --git a/Help/release/dev/vs-vctargetspath.rst
b/Help/release/dev/vs-vctargetspath.rst
index ff9d148134..462d183b2a 100644
--- a/Help/release/dev/vs-vctargetspath.rst
+++ b/Help/release/dev/vs-vctargetspath.rst
@@ -4,3 +4,6 @@ vs-vctargetspath
* With :ref:`Visual Studio Generators` for VS 2010 and above,
the :variable:`CMAKE_GENERATOR_TOOLSET` setting gained an option
to specify the ``VCTargetsPath`` value for project files.
+
+* The :variable:`CMAKE_VS_GLOBALS` variable value now applies during
+ compiler identification.
diff --git a/Modules/CMakeDetermineCompilerId.cmake
b/Modules/CMakeDetermineCompilerId.cmake
index 976b291220..f7ef755aeb 100644
--- a/Modules/CMakeDetermineCompilerId.cmake
+++ b/Modules/CMakeDetermineCompilerId.cmake
@@ -320,6 +320,12 @@ Id flags: ${testflags}
${CMAKE_${lang}_COMPILER_ID_FLAGS_ALWAYS}
if(CMAKE_VS_PLATFORM_TOOLSET_VCTARGETS_CUSTOM_DIR)
set(id_ToolsetVCTargetsDir
"${CMAKE_VS_PLATFORM_TOOLSET_VCTARGETS_CUSTOM_DIR}")
endif()
+set(id_CustomGlobals "")
+foreach(pair IN LISTS CMAKE_VS_GLOBALS)
+
[Cmake-commits] CMake branch, release, updated. v3.16.0-rc1-48-g6dedb97420
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 6dedb9742094470196698a5009441e3860e61f2a (commit) via 797689ab35c6f1edc37b120804e348b03ce7b161 (commit) via 0b10b3ed6b3ee644a44414d8b5c205d94a967c12 (commit) from 7aab792716bb647aac2b5802e6e21148471a0c79 (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: Source/cmMakefileTargetGenerator.cxx | 27 +-- Source/cmMakefileTargetGenerator.h| 5 - Tests/BuildDepends/CMakeLists.txt | 16 ++-- Tests/BuildDepends/Project/CMakeLists.txt | 6 ++ Tests/BuildDepends/Project/zot.cxx| 5 +++-- Tests/BuildDepends/Project/zot_pch.cxx| 6 ++ 6 files changed, 38 insertions(+), 27 deletions(-) create mode 100644 Tests/BuildDepends/Project/zot_pch.cxx 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.16.0-rc1-126-gc867981c9d
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 c867981c9d9bc8548d34f726940cd50b8d05d71c (commit) via 1c84b5c86f23d3e1998f67d0cd417b317cd9558b (commit) via 6dedb9742094470196698a5009441e3860e61f2a (commit) via 797689ab35c6f1edc37b120804e348b03ce7b161 (commit) via 0b10b3ed6b3ee644a44414d8b5c205d94a967c12 (commit) from 154aa87ca6bd906b6422ad81f51161995c89cc14 (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=c867981c9d9bc8548d34f726940cd50b8d05d71c commit c867981c9d9bc8548d34f726940cd50b8d05d71c Merge: 1c84b5c86f 6dedb97420 Author: Brad King AuthorDate: Fri Oct 18 08:58:01 2019 -0400 Commit: Brad King CommitDate: Fri Oct 18 08:58:01 2019 -0400 Merge branch 'release-3.16' https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c84b5c86f23d3e1998f67d0cd417b317cd9558b commit 1c84b5c86f23d3e1998f67d0cd417b317cd9558b Merge: 154aa87ca6 797689ab35 Author: Brad King AuthorDate: Fri Oct 18 12:57:06 2019 + Commit: Kitware Robot CommitDate: Fri Oct 18 08:57:16 2019 -0400 Merge topic 'pch-makefile-depends' 797689ab35 PCH: Fix Makefile dependencies to rebuild PCH on header changes 0b10b3ed6b cmMakefileTargetGenerator: Inline WriteObjectBuildFile in only call site Acked-by: Kitware Robot Merge-request: !3928 --- Summary of changes: Source/cmMakefileTargetGenerator.cxx | 27 +-- Source/cmMakefileTargetGenerator.h| 5 - Tests/BuildDepends/CMakeLists.txt | 16 ++-- Tests/BuildDepends/Project/CMakeLists.txt | 6 ++ Tests/BuildDepends/Project/zot.cxx| 5 +++-- Tests/BuildDepends/Project/zot_pch.cxx| 6 ++ 6 files changed, 38 insertions(+), 27 deletions(-) create mode 100644 Tests/BuildDepends/Project/zot_pch.cxx hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
Re: [CMake] Help request for hierarchical directory example
Hi Eric
Thanks very much for your answer. I understand now.
David
On Fri, Oct 18, 2019 at 12:57 PM Eric Noulard
wrote:
>
>
> Le ven. 18 oct. 2019 à 12:53, David Aldrich
> a écrit :
>
>> Hi
>>
>>
>>
>> I'm learning how to use hierarchical directories in CMake and am trying
>> to get an example to work that I saw on YouTube. The example isn't doing
>> what I expect so I would be grateful for some help in understanding why.
>>
>>
>>
>> I am running CMake 3.10.2 on Ubuntu 18.04 (Microsoft WSL) and using make.
>>
>>
>>
>> I have a project called 'cmake-good' that should build library
>> 'libsay-hello.a' and executable 'cmake-good'.
>>
>>
>>
>> Here's the directory tree (excluding CMake artifacts which I don't think
>> I need to show):
>>
>>
>>
>> ├── CMakeLists.txt
>>
>> ├── build
>>
>> │ ├── CMakeCache.txt
>>
>> │ ├── CMakeFiles
>>
>> │ ├── Makefile
>>
>> │ ├── cmake_install.cmake
>>
>> │ ├── hello-exe
>>
>> │ │ ├── Makefile
>>
>> │ │ ├── cmake-good
>>
>> │ └── say-hello
>>
>> │ ├── Makefile
>>
>> │ └── libsay-hello.a
>>
>> ├── hello-exe
>>
>> │ ├── CMakeLists.txt
>>
>> │ └── main.cpp
>>
>> ├── say-hello
>>
>> ├── CMakeLists.txt
>>
>> └── src
>>
>> └── say-hello
>>
>> ├── hello.cpp
>>
>> └── hello.hpp
>>
>>
>>
>> Here are the CMakeLists.txt files:
>>
>>
>>
>> 1) Top level CMakeLists.txt:
>>
>>
>>
>> cmake_minimum_required(VERSION 3.10)
>>
>> project(MyProject VERSION 1.0.0)
>>
>> add_subdirectory(say-hello)
>>
>> add_subdirectory(hello-exe)
>>
>>
>>
>> 2) hello_exe/CMakeLists.txt:
>>
>>
>>
>> add_executable(cmake-good main.cpp )
>>
>> target_link_libraries(cmake-good PRIVATE say-hello)
>>
>>
>>
>> 3) say-hello/CMakeLists.txt:
>>
>>
>>
>> add_library(
>>
>> say-hello
>>
>> src/say-hello/hello.hpp
>>
>> src/say-hello/hello.cpp
>>
>> )
>>
>> target_include_directories(say-hello PUBLIC
>> "${CMAKE_CURRENT_SOURCE_DIR}/src")
>>
>>
>>
>> My problem is that I expect to see:
>>
>>
>>
>> hello-exe/cmake-good
>>
>> say-hello/libsay-hello.a
>>
>>
>>
>> but I see:
>>
>>
>>
>> build\hello-exe\cmake-good
>>
>> build\say-hello\libsay-hello.a
>>
>>
>>
>> Why is that?
>>
>
> Because build/ is your build directory and you apparently did an
> out-of-source build (which is good practice)
> see :
> https://gitlab.kitware.com/cmake/community/wikis/FAQ#out-of-source-build-trees
>
> You should have done something like:
>
> cd cmake-good/build
> cmake ..
> make
>
> In this case everything the build is generating (CMake artefact, build
> artefact etc...) gets written build/
> the directory hierarchy in build will have the same structure as your
> source tree.
>
> This is an expected behaviour.
>
>
>
> --
> Eric
>
--
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] Help request for hierarchical directory example
Le ven. 18 oct. 2019 à 12:53, David Aldrich
a écrit :
> Hi
>
>
>
> I'm learning how to use hierarchical directories in CMake and am trying to
> get an example to work that I saw on YouTube. The example isn't doing what
> I expect so I would be grateful for some help in understanding why.
>
>
>
> I am running CMake 3.10.2 on Ubuntu 18.04 (Microsoft WSL) and using make.
>
>
>
> I have a project called 'cmake-good' that should build library
> 'libsay-hello.a' and executable 'cmake-good'.
>
>
>
> Here's the directory tree (excluding CMake artifacts which I don't think I
> need to show):
>
>
>
> ├── CMakeLists.txt
>
> ├── build
>
> │ ├── CMakeCache.txt
>
> │ ├── CMakeFiles
>
> │ ├── Makefile
>
> │ ├── cmake_install.cmake
>
> │ ├── hello-exe
>
> │ │ ├── Makefile
>
> │ │ ├── cmake-good
>
> │ └── say-hello
>
> │ ├── Makefile
>
> │ └── libsay-hello.a
>
> ├── hello-exe
>
> │ ├── CMakeLists.txt
>
> │ └── main.cpp
>
> ├── say-hello
>
> ├── CMakeLists.txt
>
> └── src
>
> └── say-hello
>
> ├── hello.cpp
>
> └── hello.hpp
>
>
>
> Here are the CMakeLists.txt files:
>
>
>
> 1) Top level CMakeLists.txt:
>
>
>
> cmake_minimum_required(VERSION 3.10)
>
> project(MyProject VERSION 1.0.0)
>
> add_subdirectory(say-hello)
>
> add_subdirectory(hello-exe)
>
>
>
> 2) hello_exe/CMakeLists.txt:
>
>
>
> add_executable(cmake-good main.cpp )
>
> target_link_libraries(cmake-good PRIVATE say-hello)
>
>
>
> 3) say-hello/CMakeLists.txt:
>
>
>
> add_library(
>
> say-hello
>
> src/say-hello/hello.hpp
>
> src/say-hello/hello.cpp
>
> )
>
> target_include_directories(say-hello PUBLIC
> "${CMAKE_CURRENT_SOURCE_DIR}/src")
>
>
>
> My problem is that I expect to see:
>
>
>
> hello-exe/cmake-good
>
> say-hello/libsay-hello.a
>
>
>
> but I see:
>
>
>
> build\hello-exe\cmake-good
>
> build\say-hello\libsay-hello.a
>
>
>
> Why is that?
>
Because build/ is your build directory and you apparently did an
out-of-source build (which is good practice)
see :
https://gitlab.kitware.com/cmake/community/wikis/FAQ#out-of-source-build-trees
You should have done something like:
cd cmake-good/build
cmake ..
make
In this case everything the build is generating (CMake artefact, build
artefact etc...) gets written build/
the directory hierarchy in build will have the same structure as your
source tree.
This is an expected behaviour.
--
Eric
--
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] Help request for hierarchical directory example
Hi
I'm learning how to use hierarchical directories in CMake and am trying to
get an example to work that I saw on YouTube. The example isn't doing what
I expect so I would be grateful for some help in understanding why.
I am running CMake 3.10.2 on Ubuntu 18.04 (Microsoft WSL) and using make.
I have a project called 'cmake-good' that should build library
'libsay-hello.a' and executable 'cmake-good'.
Here's the directory tree (excluding CMake artifacts which I don't think I
need to show):
├── CMakeLists.txt
├── build
│ ├── CMakeCache.txt
│ ├── CMakeFiles
│ ├── Makefile
│ ├── cmake_install.cmake
│ ├── hello-exe
│ │ ├── Makefile
│ │ ├── cmake-good
│ └── say-hello
│ ├── Makefile
│ └── libsay-hello.a
├── hello-exe
│ ├── CMakeLists.txt
│ └── main.cpp
├── say-hello
├── CMakeLists.txt
└── src
└── say-hello
├── hello.cpp
└── hello.hpp
Here are the CMakeLists.txt files:
1) Top level CMakeLists.txt:
cmake_minimum_required(VERSION 3.10)
project(MyProject VERSION 1.0.0)
add_subdirectory(say-hello)
add_subdirectory(hello-exe)
2) hello_exe/CMakeLists.txt:
add_executable(cmake-good main.cpp )
target_link_libraries(cmake-good PRIVATE say-hello)
3) say-hello/CMakeLists.txt:
add_library(
say-hello
src/say-hello/hello.hpp
src/say-hello/hello.cpp
)
target_include_directories(say-hello PUBLIC
"${CMAKE_CURRENT_SOURCE_DIR}/src")
My problem is that I expect to see:
hello-exe/cmake-good
say-hello/libsay-hello.a
but I see:
build\hello-exe\cmake-good
build\say-hello\libsay-hello.a
Why is that?
--
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
