Using a custom_command (not custom_target) and a looping over the output
file names, I was able to get cmake to properly track the m4 output
files and create them when necessary; see
https://cmake.org/pipermail/cmake/2009-June/029909.html
This seems to me like a good solution.
On
Hello,
Am 08.01.2017 um 07:22 schrieb Saad Khattak:
Hello,
When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio
2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES}
variables both point to the "Bin" folder for the Vulkan installation
instead of the "Bin32"
Hello,
on Linux cmake treats system directorys specially, i.e. those libraries
are linked without any path.
Furthermore there are environment variables, whose content is added to
the set of system directories.
I do not work on Windows, but your problem looks like a smiliar problem.
Does some
The way to solve this is to use a superbuild project layout - you use
ExternalProject_Add to build your dependencies AND your own project, using
the DEPENDS option to control build order. Thus by the time it gets around
to configuring your project, the dependencies have already been built and
Hello,
I have an external project glfw that I added to my project like this:
==
include(ExternalProject)
ExternalProject_Add(glfw
GIT_REPOSITORY "https://github.com/glfw/glfw.git;
GIT_TAG "master"
SOURCE_DIR "${CMAKE_SOURCE_DIR}/dep/glfw"
CMAKE_ARGS -DGLFW_BUILD_DOCS=OFF
One possibility is the often mentioned superbuild, another is not using
find_library() but setting the variables with the library file paths manually
(that's static info anyway).
Am 8. Januar 2017 22:49:52 MEZ schrieb Saad Khattak :
>Hello,
>
>I have an external project
_VERSION_MINOR 7)
-set(CMake_VERSION_PATCH 20170108)
+set(CMake_VERSION_PATCH 20170109)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/