HI all,
package is a builtin target unless things have changed you cannot depend on
a builtin target.
https://gitlab.kitware.com/cmake/cmake/issues/8438
https://cmake.org/Bug/view.php?id=8438
Personnally I would explicitely call CPack in my custom target in order to
be sure that the zip is up-to-
> Do you have any special reason why your rename target depends on PACKAGE,
is this the target which cpack is using?
I think so ...
2016-08-26 20:01 GMT+02:00 tonka3...@gmail.com :
> Hey Kristian,
>
> Thx for your answer. Iv've already done this like in your solution. I have
> a seperated target
Hey Kristian,
Thx for your answer. Iv've already done this like in your solution. I have a
seperated target which depends on my create zip target and use ${CMAKE_COMMAND}
-e copy to copy the file to my target directory (so the solution is platform
independent), and leaf the original zip in the
Hey,
you're working on Windows, right?
I think you can do that if you create an additional target and call that
target. So let's say, you have this 'hello.cpp', and you generate with
CMake a solution. This is an example of a CMakeLists.txt
> cmake_minimum_required(VERSION 3.4)
> project(cpack_zi
Hey Karl,
just gave it another shot ... so I can confirm what you saw with cmake
3.3 (btw, what cmake version did you use?). I should try a more recent
one to make sure as well.
anyhow, there 2 global workarounds that you have at your disposal:
1) set(CUDA_NVCC_FLAGS "-Dfoo") needs to be call
Hi Karl,
just a quick question, why not use add_definitions? Did you look into it
or is directory-wide preprocessor defines a nogo in your use case?
Best,
Peter
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitwa
