Dear Kitware,
First of all, thank for such great tools like cmake, really enjoy your
tools.
I’ve saw that you are using GitLab as your sourcecode system. Also I’ve
see that you have used Mantis as bugtracker before. I have made the same
transition to GitLab, but I’ve not transferred the Manits
Thank You both. Now it works!
Am 11.08.2016 um 11:29 schrieb Stuermer, Michael SP/HZA-ZSEP:
-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Patrik
Lehmann
Sent: Thursday, August 11, 2016 11:04 AM
To: cmake@cmake.org
Subject: [CMake] Use GLOB to generate
> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Patrik
> Lehmann
> Sent: Thursday, August 11, 2016 11:04 AM
> To: cmake@cmake.org
> Subject: [CMake] Use GLOB to generate filelist for install package
>
> Hello,
>
> I try to use GLOB to collect the files
I have a few different cmake based projects that depend on each other (as a
tree, no circular dependencies). Mostly this works great, but a few people
have expressed interested in a superbuild which builds everything together for
various purposes. I can make this work with ExternalProject,
I've come across an odd situation where I'm unsure what the most
portable and recommended solution would be.
I'm linking a program against the CURL and ICU libraries. CURL has
traditional variables for the includes and libraries; ICU has imported
targets.
In FindICU:
Well what I was trying to do was to actually have a target inside the
windows build that would trigger the linux build so to build both at the
same time. imagine you have a VS project one of the "projects" would be the
linux build. So as long as the build folder is different I could have both
On 11/08/2016 16:24, rle...@codelibre.net wrote:
I've come across an odd situation where I'm unsure what the most
portable and recommended solution would be.
I'm linking a program against the CURL and ICU libraries. CURL has
traditional variables for the includes and libraries; ICU has
Hi tonka,
We (Ben) wrote a conversion tool that we use to convert mantis issues
over to gitlab. You can find the project at:
https://gitlab.kitware.com/utils/mantis-to-gitlab
It has an Apache 2.0 license.
On Thu, Aug 11, 2016 at 9:31 AM, tonka tonka wrote:
> Dear Kitware,
I am a one man company that needs to get a Library built from C/C++ source
using CMake.
My system is windows 7 Professional. I am running MVS 8 (Microsoft Visual
Studios 8) I need the following library built from the below URL (It's a
DICOM image Library):
+1 for the initiative. Wouldn’t it make more sense however to make it a
CMAKE_SYSTEM_NAME? If I remember correctly that’s how MinGW works, and this
should be something very similar.
Feladó: Tiago Macarios--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
Hello,
I try to use GLOB to collect the files for my install package, but
unfortunately I got the message
'file INSTALL cannot find
"C:/Project/include/test1.h;C:/Project/include/test2.h;...'
My code:
FILE(GLOB MY_INCLUDES_H "${PROJECT_SOURCE_DIR}/include/*.h")
INSTALL(FILES
Remove the quotes around the variable MY_INCLUDES_H in the INSTALL command
because this is a list. Using quotes, you pass it as a single string.
On 11/08/16 11:03, "CMake on behalf of Patrik Lehmann" wrote:
Hello,
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, next has been updated
via 7dbdc8675b1235e2f416c05dbb9b00f07c956ade (commit)
via
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 f203694bb848e7a4bd2c623348053532b1b4e589 (commit)
via
The previous fix uncovered another bug from commit 7229ae7. That commit
dropped librt from the link line when using static linking with CUDA 7.0 or
newer on Linux. However, librt is still required on the link line in newer
CUDA versions, I get linker errors without it.
I've attached a second
Recent changes to FindCUDA.cmake (commit 7229ae7) broke the documented behavior
of the CUDA_USE_STATIC_CUDA_RUNTIME option. Per the documentation, this option
should be enabled by default if libcudart_static is present in the selected
version of CUDA, and silently disabled if it's not. After
_VERSION_MINOR 6)
-set(CMake_VERSION_PATCH 20160811)
+set(CMake_VERSION_PATCH 20160812)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/
17 matches
Mail list logo