[Cmake-commits] CMake branch, master, updated. v3.4.0-rc1-188-g84c1d4f

_VERSION_MINOR 4) -set(CMake_VERSION_PATCH 20151013) +set(CMake_VERSION_PATCH 20151014) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

[cmake-developers] [CMake 0015785]: Support "generator expressions" in "install(CODE)"

The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15785 == Reported By:SunBlack Assigned To:

Re: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options

Hi, > - If not, what is the best/official way to get exact control over the compiler > and linker options used? I had to do something similar recently where I didn't want ``-DNDEBUG`` to be in any of the configurations. I used ``CMAKE_USER_MAKE_RULES_OVERRIDE `` to set the path to file

Re: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options

Dan Liew wrote: > Hi, > > >> - If not, what is the best/official way to get exact control over the >> compiler and linker options used? > > I had to do something similar recently where I didn't want > ``-DNDEBUG`` to be in any of the configurations. > > I used

Re: [cmake-developers] BUILD_TESTING when cross compiling

On 10/13/2015 01:17 AM, Geoffrey Viola wrote: > Tests/CMakeLists.txt [snip] > run when it won't be able to run the code on the host machine? Many of the tests end with a step that verifies that a built executable can run. Several tests build tools that generate sources. In both cases we expect

Re: [cmake-developers] GHS MULTI generator link with RUNTIME_OUTPUT_DIRECTORY patch

On 10/13/2015 01:06 AM, Geoffrey Viola wrote: > Attached is a patch to allow the GHS MULTI [snip] > + const char* runtimeOutputDir = > +tg->GetProperty("RUNTIME_OUTPUT_DIRECTORY"); The generator should not have to deal with such properties directly. There are internal APIs to get the

[cmake-developers] [CMake 0015787]: Please add note about change to 3.4 release notes

The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=15787 == Reported By:James Crosby Assigned To:

[cmake-developers] [CMake 0015786]: FindMatlab / matlab_add_mex does not work with 64-bit Matlab Version - Version detected as 32-bit Matlab

The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15786 == Reported By:Kerstin Keller Assigned To:

Re: [CMake] FindCUDA discard any previous value of CUDA_USE_STATIC_CUDA_RUNTIME

Maybe we could make the FindCUDA script check if the caller defined that variable prior to any inclusion. If the user did, then FindCUDA should respect the caller choice. Something like that would make the trick: if(NOT DEFINED CUDA_USE_STATIC_CUDA_RUNTIME_FORCED) if(DEFINED

[CMake] C++11 flag not being added

I have the following two lines in my CMakeLists.txt set_property(GLOBAL PROPERTY CXX_STANDARD 11) set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) However when compiling some of my source files, the -std=c++11 flag is not added. Just for good measure I added:

[Cmake-commits] CMake branch, next, updated. v3.4.0-rc1-503-g7db9307

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 7db9307dfdf5f2e6713f6a41d688d09a4dc8bd56 (commit) via

Re: [CMake] FindCUDA discard any previous value of CUDA_USE_STATIC_CUDA_RUNTIME

Yeah, I thought about this method yesterday, but I'm not really excited about this approach. It adds yet another variable for the configuration that doesn't really match the others. Granted the behavior of the other FindCUDA options allow setting it before the first FindCUDA invocation, so there

Re: [cmake-developers] ITK NIfTI broken Oct 6

On 10/12/2015 01:48 PM, Stephen Kelly wrote: > Subdirs: Initialize from parent before configuring. > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7dac31b2 It seems that problem was covering another one: CMake Error: File /.../Modules/ThirdParty/GDCM/src/gdcm/Source/gdcmByteValue.cxx

Re: [CMake] C++11 flag not being added

I would also like to know this, right now I do this and it works, but it produced warnings on MSVC, so I did this nasty patch: if(WIN32) if(MINGW) SET(CMAKE_CXX_FLAGS "-mwindows -std=c++11") endif() else() SET(CMAKE_CXX_FLAGS "-std=c++11") endif() however doing just the

Re: [CMake] C++11 flag not being added

Hi, CXX_STANDARD is a target property, not a global one. You can either set CXX_STANDARD for every target that needs it, or set it globally by changing the default value. You can do the latter by setting the variable CMAKE_CXX_STANDARD before defining any target that depends on it:

[cmake-developers] [CMake 0015788]: Error during export target, which has additional defined include directories with target_include_directories

The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15788 == Reported By:SunBlack Assigned To:

[Cmake-commits] CMake branch, next, updated. v3.4.0-rc1-505-g12fcad5

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 12fcad5764d82276a98b5f1b22de34ac5ea77144 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.4.0-rc1-181-gfc04b8f

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 fc04b8f4b8ebb53b19c0430ac992baa46c75d2e9 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.4.0-rc1-177-g242d664

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 242d664f748baad810ae47aef91fc11475647f98 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.4.0-rc1-179-gd75971b

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 d75971b5af8b2e48a14bc1363826a555c77eed2d (commit) via

[Cmake-commits] CMake branch, master, updated. v3.4.0-rc1-183-gd6af556

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 d6af5566e8c07b6b47ac78b1652c29dbe0e31aa2 (commit) via

[cmake-developers] genex-generator-objects topic

Steve, Last night's RunCMake.include test failures bisect to: cmMakefile: Store container of cmExportBuildFileGenerators. https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5925f99c A clang sanitizer build output is below. Please take a look. Thanks, -Brad WRITE of size 8 at

[Cmake-commits] CMake branch, master, updated. v3.4.0-rc1-187-gc4361a2

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 c4361a265b32acaa4a84c1ab14fecee1bfe49d33 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.4.0-rc1-516-g2ee565e

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 2ee565e6f2795a90b7a4821cda7cbf23070efa5a (commit) via

[Cmake-commits] CMake branch, next, updated. v3.4.0-rc1-511-ga177b85

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 a177b8586863744f774579f744afd400404993df (commit) via

Re: [cmake-developers] Generating buildsystem metadata from CMake

Alexander Neundorf wrote: > Maybe this is of interest: the Eclipse CDT developers are currently > working on improved support for cmake: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=350206 > http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg29621.html Yes, I noticed that too a few days ago. My

[Cmake-commits] CMake branch, next, updated. v3.4.0-rc1-523-g6638bfe

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 6638bfeba68c732f5441e00fdcd807957d3b041a (commit) via

[Cmake-commits] CMake branch, next, updated. v3.4.0-rc1-521-gda7ed9b

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 da7ed9b1e766d6cb8e657c1420c07eabd726a34a (commit) via

Re: [CMake] C++11 flag not being added

Thanks, setting the global variable solved my issue. -Matt > On Oct 13, 2015, at 10:46 AM, Johannes Zarl-Zierl > wrote: > > Hi, > > CXX_STANDARD is a target property, not a global one. You can either set > CXX_STANDARD for every target that needs it, or set it

Re: [cmake-developers] genex-generator-objects topic

Brad King wrote: > Steve, > > Last night's RunCMake.include test failures bisect to: > > cmMakefile: Store container of cmExportBuildFileGenerators. > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5925f99c > > A clang sanitizer build output is below. Please take a look. Looks like

[Cmake-commits] CMake branch, next, updated. v3.4.0-rc1-518-g0013c5c

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 0013c5cad94e4e3c61a4f3eceafeb382bdc36969 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.4.0-rc1-525-ge15afa2

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 e15afa23efdaa409f5f809444fa1ceb98f18210b (commit) via

Re: [cmake-developers] ITK NIfTI broken Oct 6

Brad King wrote: > Therefore we see that CMAKE_CURRENT_SOURCE_DIR is incorrectly set. > This CMakeLists.txt file is again entered by the subdirs() command > in the parent directory. What a mess... Thanks for bisecting. I fixed this by pushing part of a branch which I was intending to start to

[CMake] cmake_check_build_system is causing a rebuild at "make install"

For future reference, one can determine what triggered the reconfigure by doing make install VERBOSE=1 It appears not to be enough to have configured with -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE. In our case, for reasons we have not yet figured out, the depend file for a particular .cu.o object

[Cmake-commits] CMake branch, next, updated. v3.4.0-rc1-533-gd2d09ae

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 d2d09aece23f023f3e81586811a31abac0e3292f (commit) via