[Cmake-commits] CMake branch, master, updated. v3.16.0-rc4-407-gadc50529ac
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 adc50529ac163889c0353756706a7ffddb4ed957 (commit) from d8571ccb9c4c7e6eca33779c083bd501b1782030 (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=adc50529ac163889c0353756706a7ffddb4ed957 commit adc50529ac163889c0353756706a7ffddb4ed957 Author: Kitware Robot AuthorDate: Sun Nov 24 00:01:07 2019 -0500 Commit: Kitware Robot CommitDate: Sun Nov 24 00:01:07 2019 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 39cb3369e4..3aff07eb35 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 20191123) +set(CMake_VERSION_PATCH 20191124) #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] Testing an exe with gtest - possible?
Thanks, this pointed me in the right direction. I ended up moving main() to it's own file so nothing depends on it, using a static add_library (project sources minus the main.cpp) and depend on that target from gtest exe project. Works like a charm. I missed the discourse announcement, I'll use it in the future. Best regards, cen On 11/20/19 3:16 PM, Kyle Edwards wrote: On Wed, 2019-11-20 at 00:54 +0100, cen wrote: Hi I have an existing c++ exe project which I want to test with gtest. I have not yet found an easy way to keep the project as is and test it directly since gtest insists (obviously) to link against the code being tested. I found a smart answer on SO to link against object files and that works ok but it's messy and a lot of manual setup after cmake project generation, probably impossible to automate in cmake. The other quick way is to change the VS project output to a static lib. That also works but is a manual step which again not sure can be automated at all. And there is a bigger issue hidden in here.. I can't link to this lib due to dual main() entry point. So unless there is some smart workaround to keep project as an exe and get gtest to work, I guess the only remaining option is to separate the main() into a small bootstrap exe and then link against the rest of the program (which contains the actual testable logic) as a lib. Finally, if I understand correctly, using target_link_libraries will automatically set up the two projects as dependent and lib will always get built before the main is run. Check out the $ generator expression. This will let you link directly against the object files built for the executable. This mailing list is deprecated. Please post further discussion to Discourse: https://discourse.cmake.org/c/code Kyle -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
[CMake] Link options not transitive
Hi, I have recently encountered what I believe might be a bug, where INTERFACE_LINK_OPTIONS are not carried over static libraries. Following is the simplest CMakeLists.txt that demonstrates the problem: cmake_minimum_required(VERSION 3.16) project(LinkOptionsNotTransitive) add_library(A SHARED A.cpp) add_library(B STATIC B.cpp) add_executable(C C.cpp) target_link_options(A INTERFACE "/DELAYLOAD:A.dll") target_link_libraries(B PRIVATE A) target_link_libraries(C PRIVATE B) I tested this with Visual Studio 2017 generator and both cmake 3.15.4 and 3.16.0-rc4, with the same result. When inspecting generated solution, C is linking both A.lib and B.lib (as it should), but /DELAYLOAD flag is not applied to it. If B has PUBLIC dependency on A, then /DELAYLOAD flag is also correctly carried over. I get the impression that target_link_options behaves as eg. target_include_directories, which are not carried over PRIVATE dependencies. Given that these are linker options, I would expect them to follow same rules as target_link_libraries, which will carry over until nearest linker invocation. Is there any reason for this inconsistency, or is it just a bug and if so, what would be the best way to report it? -- Sincerely, Martin Krošlák -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
Re: [CMake] Missing dll on program startup - a way automate it?
Thanks, this is exactly what I need.
Unfortunately constructing the path expansion involves some gymnastics.
If Find* exposes a list of directories it's just a simple list join (->
boost) but if it does not it is more involved..
list(JOIN Boost_LIBRARY_DIRS ";" BOOST_PATH)
set(ZLIB_PATH "")
FOREACH(LIB_NAME ${ZLIB_LIBRARIES})
get_filename_component(LDIR ${LIB_NAME} DIRECTORY)
if (NOT ZLIB_PATH MATCHES "${LDIR}")
set(ZLIB_PATH "${ZLIB_PATH};${LDIR}")
endif()
ENDFOREACH()
set(EXPAND_PATH "${ZLIB_PATH};${BOOST_PATH}")
set_target_properties(${PROJECT_NAME} PROPERTIES VS_DEBUGGER_ENVIRONMENT
"PATH=%PATH%${EXPAND_PATH}")
Is there a way to get a list of all additional library directories? That
would be ideal but I couldn't find anything.
On 11/20/19 9:32 AM, Petr Kmoch wrote:
Hi.
I haven't used it yet, but I believe the target property
https://cmake.org/cmake/help/latest/prop_tgt/VS_DEBUGGER_ENVIRONMENT.html
might help you.
Petr
On Wed, 20 Nov 2019 at 01:02, cen > wrote:
Hi
Perhaps not really a cmake problem but here we go. An exe depends
on a
few DLLs which I ship in the repo so the rest of the devs don't
have to
build them or fetch them somewhere else. Cmake finds the libraries
and
project builds just fine, until you run it from VS.. you are
welcomed by
the "missing dll" windows error. So I have to copy all the dlls to
the
build/run folder to make it work but this is a manual step. Is there
some way in cmake/VS to somehow tell the IDE to append the execution
$PATH with all the specified library dependencies or something along
those lines? Ideally my goal is to just run cmake, open VS, build the
project and run, all automagical.
I would prefer to keep the dynamic linking.
Best regards, cen
--
Powered by kitware.com/cmake
Kitware offers various services to support the CMake community.
For more information on each offering, please visit
https://cmake.org/services
Visit other Kitware open-source projects at
https://www.kitware.com/platforms
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
This mailing list is deprecated in favor of
https://discourse.cmake.org
--
Powered by kitware.com/cmake
Kitware offers various services to support the CMake community. For more
information on each offering, please visit https://cmake.org/services
Visit other Kitware open-source projects at https://www.kitware.com/platforms
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
This mailing list is deprecated in favor of https://discourse.cmake.org
