[cmake-developers] [CMake 0015364]: FindBoost.cmake does not find debug libraries if they are located in a different directory than the release libraries
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15364
==
Reported By:Gunther Laure
Assigned To:
==
Project:CMake
Issue ID: 15364
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2015-01-22 07:55 EST
Last Modified: 2015-01-22 07:55 EST
==
Summary:FindBoost.cmake does not find debug libraries if
they are located in a different directory than the release libraries
Description:
FindBoost.cmake does not find debug libraries if they are located in a different
directory than the release libraries.
Assume following boost lib dir layout:
lib/shared/Debug
lib/shared/Release
lib/static/Debug
lib/static/Release
lib64/shared/Debug
lib64/shared/Release
lib64/static/Debug
lib64/static/Release
For previous cmake version we changed changed the CMAKE_LIBRARY_PATH (depending
on x86,x64,Release,Debug) so that FindBoost did find the correct libraries.
The current version of FindBoost.cmake assumes that Debug and Release have to be
in the same directoy.
This is done in the macro _Boost_FIND_LIBRARY (line 323-325):
# If Boost_LIBRARY_DIR is known then search only there.
if(Boost_LIBRARY_DIR)
set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
endif()
Commenting/Removing these lines restores the previous behaviour and Release and
Debug libraries are found again.
Steps to Reproduce:
create a directory structure like that:
lib/Debug
lib/Release
and put valid boost libs in there:
lib/Debug/boost_system-vc120-mt-gd-1_55.lib
lib/Release/boost_system-vc120-mt-1_55.lib
With CMAKE_LIBRARY_PATH set to both directories and the current version of cmake
(3.1)
find_package(Boost REQUIRED COMPONENTS
system
)
will result in:
Boost_SYSTEM_LIBRARY = lib/Release/boost_system-vc120-mt-1_55.lib
with the lines 323 to 325 commented in FindBoost.cmake it will find both libs:
Boost_SYSTEM_LIBRARY =
optimized;lib/Release/boost_system-vc120-mt-1_55.lib;debug;lib/Debug/boost_system-vc120-mt-gd-1_55.lib
(absolute path removed manually)
Additional Information:
If this is only an issue for us, we could workaround the problem with a
customized FindBoost.cmake file in our environment.
==
Issue History
Date ModifiedUsername FieldChange
==
2015-01-22 07:55 Gunther Laure New Issue
==
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Adding an option for relative compiler invocations
Hi, this issue has been discussed here in 2011, but not to my satisfaction (http://www.cmake.org/pipermail/cmake/2011-December/thread.html#48266). My logging code uses __FILE__ to print the name of the relevant source file; cmake's absolute-path compiler invocations, combined with gcc's implementation of __FILE__, cause two issues: (0.0) The build path ends up being part of the binary (0.1) The build path is printed for every log message I've identified several solutions, all of which are unsatisfactory: (1.0) At the top of every single source and header file, writing '#line 2 subdir/my_file.cpp'. (1.1) Using run-time string manipulations to sanitize the filename. Doesn't solve (0.0) and comes with a run-time cost. (1.2) Using compile-time string manipulations to sanitize the filename. Due to limitations of C++, this requires template metaprogramming, leading to unreasonable complexity and compile times. (1.3) Storing CMAKE_SOURCE_DIR as an constexpr in configure.h, and using that to calculate constexpr offsets into the __FILE__ literals. This does not solve (0.0), but it's the solution I've decided to use for now. (1.4) Replacing gcc by a wrapper script that sanitizes all filename arguments and changes the working directory. The following are not solutions at all: (2.0) Using '-DFILENAME=subdir/my_file.cpp'. This fails for included headers. (2.1) Ignoring the issue. I care about such minor details. Over the last several decades, at least on the POSIX platform, it has become common practice to invoke compilers with relative file paths, and compilers have adopted to act accordingly. While the true culprit is the C standard's lax definition of __FILE__, I'm blaming cmake's unusual, absolute-path invocation behavior. Even in the unlikely event that gcc (and clang) decided to introduce flags that would modify the behavior of __FILE__, all they could do would be stripping the entire basename, so 'project_dir/my_file.cpp' and 'project_dir/subdir/my_file.cpp' would have the same value for __FILE__. I suggest adding an additional, optional parameter to add_executable that would allow switching on relative gcc invocations from a directory of the user's choosing. Thanks for considering this proposal. ~ Michael signature.asc Description: OpenPGP digital signature -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015365]: Provide per-target CXX/C flags
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15365 == Reported By:Kevin Wojniak Assigned To: == Project:CMake Issue ID: 15365 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2015-01-22 10:57 EST Last Modified: 2015-01-22 10:57 EST == Summary:Provide per-target CXX/C flags Description: CMake provides CMAKE_CXX_FLAGS, but this is global. It'd be good to have a per-target CXX flags ability. Possibly a macro such as target_compile_options_cxx() and target_compile_options_c(), or a way to do this with generator expressions (doesn't seem to have a LANG property for sources). == Issue History Date ModifiedUsername FieldChange == 2015-01-22 10:57 Kevin Wojniak New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduce 'Unix Ninja' generator
On 01/22/2015 10:34 AM, Daniel Levin wrote: finally came with solution that works for me with standard Ninja generator for QNX SDK. Great! 2. In custom build rules instead of launching .sh scripts directly shell should be specified explicitly. This is expected for any Windows platform that wants to run scripts. Windows does not support shebang lines so the interpreter must always be specified explicitly. 1. In my toolchain file...I will generate .bat wrapper around compiler instead of .sh. I predict that answer about (1) will be the same: load environment before launching build. I would want to start another thread to discuss this issue, because it sounds critical to me. As I said in earlier responses this is simply a requirement and is not likely to change. I understand your desire to automate the environment, but I do not think CMake is the right level to achieve that. About Unix Ninja. I believe the main reason for the Unix Makefiles was the fact that some make tools can handle Unix syntax only. The Unix Makefiles generator refers exactly to unix-style make tools, and on POSIX systems is the only generator besides Ninja (excluding the extra generators that use makefiles+project files). It is available on Windows because there are make tools on Windows that work with such paths/shells natively. Unless ninja were to have a variant that does so too, then it does not need a distinct generator. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] make more CUDA cache variables advanced
Hi, FindCUDA.cmake creates a number of option variables that are not set to be advanced cache variables. I think that those that do not seem to relate to normal usage of CUDA should be made advanced. That way, non-developer end users of ccmake get to see among the non-advanced options for their project the ones that really make sense for them to change. Developers and power users can switch to the advanced display, of course, just like they do now for a range of other CUDA variables. Patch on cmake master attached. Mark From 8fbbc4d3cbcaf28a8a6939137d8c6b3be638ae02 Mon Sep 17 00:00:00 2001 From: Mark Abraham mark.j.abra...@gmail.com Date: Thu, 22 Jan 2015 16:29:22 +0100 Subject: [PATCH] Mark more CUDA variables as advanced These variables all pertain to specific situations relevant to CUDA compilation. If all find_package modules would make all their cache variables non-advanced, then (e.g.) ccmake becomes rather unusable for non-developer end users of complex software that uses multiple such modules. Making these variables advanced seems to be a compromise that is in the spirit of other work on this module (e.g. in commit d468145f). --- Modules/FindCUDA.cmake | 4 1 file changed, 4 insertions(+) diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake index cae9214..81e1cad 100644 --- a/Modules/FindCUDA.cmake +++ b/Modules/FindCUDA.cmake @@ -483,6 +483,10 @@ mark_as_advanced( CUDA_HOST_COMPILATION_CPP CUDA_NVCC_FLAGS CUDA_PROPAGATE_HOST_FLAGS + CUDA_BUILD_CUBIN + CUDA_BUILD_EMULATION + CUDA_VERBOSE_BUILD + CUDA_SEPARABLE_COMPILATION ) # Makefile and similar generators don't define CMAKE_CONFIGURATION_TYPES, so we -- 1.9.1 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [ANNOUNCE] CMake 3.1.1 Released
We are pleased to announce that CMake 3.1.1 is now available for download. Please use the latest release from our download page: http://www.cmake.org/download/ Thanks for your support! - Changes in 3.1.1 since 3.1.0: André Klitzing (1): Eclipse: Add org.eclipse.cdt.core.cnature to CXX projects (#15068) Ben Boeckel (4): get_test_property: clarify the documentation set_tests_properties: fix documentation tests: add tests for querying properties Xcode: Sort targets deterministically and with ALL_BUILD first (#15346) Brad King (14): bootstrap: Fix syntax for Solaris 10 shell (#15317) Help: Clarify MinGW v. MSYS Makefiles generators (#15319) Ninja: Do not crash when CMAKE_LANG_COMPILE_OBJECT is empty (#15325) Ninja: Generate rules only for languages compiled in a target (#15325) Tests: Test using objects from a language enabled in a subdirectory (#15325) Help: Add 3.1 release note about '#' escaping in Makefiles (#15322) Help: Clarify if(variable) documentation (#15335) Help: Document CMAKE_FIND_PACKAGE_NAME variable Xcode: Do not require code signing for compiler id (#15214) Copyright.txt: Update year range to end in 2015 XL: Fix link flags for executables on Linux with XL compilers QNX: Fix detection of QCC compiler id (#15349) Xcode: Fix early termination on per-config source file error CMake 3.1.1 Calin Cascaval (1): CPack: Fix PackageMaker internal versioning for OS X 10.10 Chuck Atkins (1): Fix compilation with the Oracle / Sun compiler (#15318) Daniele E. Domenichelli (1): Help: Small fixes in CPackComponent documentation David Coppa (1): FindRuby: fix selection of version x.0 (#15345) Domen Vrankar (1): CPack: Avoid crash on invalid CMake generator name (#15308) Evangelos Foutras (1): FindRuby: Fix output check in _RUBY_CONFIG_VAR Gregor Jasny (1): find_package: Document CMAKE_FIND_PACKAGE_NAME variable Justin Borodinsky (1): QtAutoUic: Restore source file AUTOUIC_OPTIONS settings Mark Abraham (1): FindCUDA: Do not assume CMAKE_SYSTEM_PROCESSOR is set Peter Vasil (2): cmake-mode.el: Fix extracting keyword at point in cmake-help cmake-mode.el: Re-add explicit call to require thingatpt Rolf Eike Beer (5): FindIce: Port to work with CMP0054 NEW behavior FindSDL: Allow if() to dereference SDL_INCLUDE_DIR for matching FindQt: fix setting DESIRED_QT_VERSION if find_package(Qt VVV) was called FindQt: fix variable name in error message FindQt: explicitely mention that it cannot Qt5 or later Sergey Nikulov (1): FindBoost: Add latest Boost version 1.57.0 and next milestone 1.58.0 Simon Gomizelj (1): KWSys Terminal: Add xterm-termite to VT100 color support whitelist Stephen Kelly (7): Help: Document valid 14 value for CXX_STANDARD. (#15339) get_target_property: discern empty from undefined properties (#15333) QtAutoUic: Add a test for the regression in the parent commit. cmMakefile: Rename a method to what it really does. Features: Fix the COMPILE_FEATURES genex for unavailable features. cmTarget: Compute link language of TARGET_OBJECTS with CMP0026 OLD (#15338) Help: Link relevant documents for virtual override features (#15311) Tim Blechmann (1): Help: Add INTERFACE_LIBRARY to TYPE target property documentation William Lynch (1): Help: Update cmake.org links to avoid redirects -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Cmake 2.8.8 -- can't find curses.h
Thank you David. That helped and fixed it. I was missing libraries to run the 32bit exes. On Wed, Jan 21, 2015 at 11:32 AM, David Cole dlrd...@aol.com wrote: This is a pre-built Linux binary that should work on that system, and should include ccmake: http://www.cmake.org/files/v2.8/cmake-2.8.8-Linux-i386.tar.gz If you can't run it, it's probably because you're on an x64 box, and you need the run the 32-bit exes and libs library -- hopefully somebody else can chime in with the package to install, because I can never remember the name of it. HTH, David C. On Wed, Jan 21, 2015 at 10:57 AM, Sharath Prasad prasad.shar...@gmail.com wrote: Hello. I am trying to use a specific version of cmake (v2.8.8). I also need ccmake (v2.8.8). I located the folders uploaded for this release. I plan to use it on ubuntu. I downloaded cmake folders and extracted all the folders related to Linux. However, only one folder has options to build from scratch. Other folders have binaries that do not run on my machine. The folder that compiles from scratch cannot locate CURSES or NCURSES and has trouble locating curses.h So ccmake does not work. If I install ccmake, it updates to the latest version 2.8.12 or so. I need v2.8.8 specifically, Can you help? Thanks, Sharath -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduce 'Unix Ninja' generator
I played a bit more and finally came with solution that works for me with
standard Ninja generator for QNX SDK.
1. In my toolchain file if ( CMAKE_HOST_WIN32 AND NOT ${CMAKE_GENERATOR}
STREQUAL Unix Makefiles ) then I will generate .bat wrapper around
compiler instead of .sh.
2. In custom build rules instead of launching .sh scripts directly shell
should be specified explicitly.
I predict that answer about (1) will be the same: load environment before
launching build. I would want to start another thread to discuss this
issue, because it sounds critical to me.
About Unix Ninja. I believe the main reason for the Unix Makefiles was
the fact that some make tools can handle Unix syntax only. From my point of
view it also means Unix environment. That is why I still think even if
Ninja tool has single syntax, when running it under Unix environment it
still make sense to force Ninja to use sh as shell.
On Tue, Jan 20, 2015 at 1:18 PM, Brad King brad.k...@kitware.com wrote:
On 01/20/2015 01:04 PM, Daniel Levin wrote:
Brad King wrote:
We expect that environment variables required by the toolchain
in use are already loaded.
configure everything once, save into cache, build with single
invocation of build tool
Use of a developer-provided environment was a very early and quite
fundamental design decision, and is unlikely to be changed.
I'd rather this discussion focus on how to get a sh-based ninja
working for your environment. Unfortunately without access to
such an environment myself I do not understand it well enough to
suggest the best approach.
Can you provide sample ninja build files (perhaps hand written)
that demonstrate invocations of the compiler and other tools,
assuming it runs with the proper environment already defined?
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Hi, I added a section known problems in the documentation and removed the REDUCE_VISIBILITY option. I am keeping the hidden symbols of the compiled MEX file as it appears to be something properly supported. This behaviour is also documented. I moved the test for bad configuration under RunCMake with appropriate error message and return code. How do we proceed next? Best, Raffi Enficiaud On 21 Jan 2015, at 22:30, Brad King brad.k...@kitware.com wrote: On 01/21/2015 12:01 PM, Raffi Enficiaud wrote: Ok. What do you think about mimicking the mex compiler in terms of options set to the compiler? The -Wl,--exclude-libs,ALL is in fact set by the mex compiler for compiling the mex extensions under Linux. Then I will just drop the REDUCE_VISIBILITY from the interface and add some doc about the best practices that work better. I think suggesting it in the documentation is fine. If some common cross-platform solutions evolve then we can revisit adding official support. But I have a quick question about the proper way of adding a test: [snip] should fail because of a component lacking the the find_package option The best place to put tests covering bad CMake code and error cases is under the Tests/RunCMake infrastructure. That allows explicit matching of return codes and error messages. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015367]: cmake crash in GetNumberOfFilesInDirectory
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15367 == Reported By:Thomas Klausner Assigned To: == Project:CMake Issue ID: 15367 Category: CMake Reproducibility:sometimes Severity: crash Priority: high Status: new == Date Submitted: 2015-01-22 23:04 EST Last Modified: 2015-01-22 23:04 EST == Summary:cmake crash in GetNumberOfFilesInDirectory Description: In Source/kwsys/Directory.cxx, the result value of opendir() is not checked, which can lead to readdir being called with a NULL pointer as first argument, which, at least on NetBSD, leads to a segfault. Steps to Reproduce: I don't know how to cause this, but it happened to me in parallel builds on a tmpfs e.g. when building wesnoth. Additional Information: The attached patch returns '0' as count for directories when opendir fails, which makes wesnoth build for me. Perhaps dirp==NULL should be reported, but I don't know how to best do that, so I'll leave that up to you. == Issue History Date ModifiedUsername FieldChange == 2015-01-22 23:04 Thomas KlausnerNew Issue 2015-01-22 23:04 Thomas KlausnerFile Added: patch-Source_kwsys_Directory.cxx == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] FeatureSummary: Fix wrong bracket
Hi CMake developers, please find attached a small patch to change a ] to a ). Bye Christoph -- When you die, that does not mean that you lose to cancer, you beat cancer by how you live, why you live, and in the manner in which you live. -- Stuart Scott, 1965-2015 From b4d09cabf9d2c1fd71c1102d9c23b79fe777afb0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christoph=20Gr=C3=BCninger?= f...@grueninger.de Date: Thu, 22 Jan 2015 23:48:38 +0100 Subject: [PATCH] FeatureSummary: Fix bracket in documentation. --- Modules/FeatureSummary.cmake | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Modules/FeatureSummary.cmake b/Modules/FeatureSummary.cmake index 9016db8..3eea9db 100644 --- a/Modules/FeatureSummary.cmake +++ b/Modules/FeatureSummary.cmake @@ -40,7 +40,7 @@ # [FATAL_ON_MISSING_REQUIRED_PACKAGES] # [DESCRIPTION Found packages:] # WHAT (ALL | PACKAGES_FOUND | PACKAGES_NOT_FOUND -# | ENABLED_FEATURES | DISABLED_FEATURES] +# | ENABLED_FEATURES | DISABLED_FEATURES) #) # # @@ -265,7 +265,7 @@ # Does the same as SET_PACKAGE_INFO(name description url ) #= -# Copyright 2007-2009 Kitware, Inc. +# Copyright 2007-2015 Kitware, Inc. # # Distributed under the OSI-approved BSD License (the License); # see accompanying file Copyright.txt for details. -- 2.1.2 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015366]: set_source_files_properties OBJECT_DEPENDS broken after normalization
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15366 == Reported By:Daniel v. Gerpen Assigned To: == Project:CMake Issue ID: 15366 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-01-22 19:09 EST Last Modified: 2015-01-22 19:09 EST == Summary:set_source_files_properties OBJECT_DEPENDS broken after normalization Description: With cmake 2.8.9 (ubuntu repos) and cmake 3.0.2 (build locally) the attached project can be build. [ 50%] Generating ../bla/stuff.h Scanning dependencies of target app [100%] Building CXX object blubb/CMakeFiles/app.dir/__/bla/a.cpp.o Linking CXX executable app [100%] Built target app With 3.1 and 3.1.1 it fails because a custom command is not run: Scanning dependencies of target app make[2]: *** No rule to make target `blubb/../bla/stuff.h', needed by `blubb/CMakeFiles/app.dir/__/bla/a.cpp.o'. Stop. make[1]: *** [blubb/CMakeFiles/app.dir/all] Error 2 make: *** [all] Error 2 Steps to Reproduce: tar zxf object_depends.tar.gz cd object_depends cmake . make Additional Information: https://github.com/Kitware/CMake/commit/c4af46 is the first commit with this behavior, it introduced normalization of OUTPUT and DEPENDS in add_custom_command. From what I can see OBJECT_DEPENDS in set_source_file_properties is not normalized. == Issue History Date ModifiedUsername FieldChange == 2015-01-22 19:09 Daniel v. GerpenNew Issue 2015-01-22 19:09 Daniel v. GerpenFile Added: object_depends.tar.gz == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015368]: ExternalProject's BUILD_ALWAYS flag doesn't clear any existing build stamp file
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15368 == Reported By:peitschie Assigned To: == Project:CMake Issue ID: 15368 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-01-23 01:18 EST Last Modified: 2015-01-23 01:18 EST == Summary:ExternalProject's BUILD_ALWAYS flag doesn't clear any existing build stamp file Description: Setting the BUILD_ALWAYS flag on an external project should cause the build step to always trigger. This was new in 3.1 from what I can see. Unfortunately, it appears to do this by making the *next* stamp file created symbolic (see https://github.com/Kitware/CMake/blob/master/Modules/ExternalProject.cmake#L1457). This means that until the existing stamp file is deleted, or something else causes a rebuild to occur, BUILD_ALWAYS has no effect Steps to Reproduce: 1. Create a CMake file with an external project, with BUILD_ALWAYS set to 0 2. Build the external project 3. Change the BUILD_ALWAYS flag to 1 4. Attempt to rebuild the external project, and note how the build step is never executed. == Issue History Date ModifiedUsername FieldChange == 2015-01-23 01:18 peitschie New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] make more CUDA cache variables advanced
On 01/22/2015 10:41 AM, Mark Abraham wrote: FindCUDA.cmake creates a number of option variables that are not set to be advanced cache variables. I think that those that do not seem to relate to normal usage of CUDA should be made advanced. That way, non-developer end users of ccmake get to see among the non-advanced options for their project Applied with a simpler commit message, thanks: FindCUDA: Mark more cache variables as advanced http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=005b409d -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduce 'Unix Ninja' generator
This is expected for any Windows platform that wants to run scripts. Windows does not support shebang lines so the interpreter must always be specified explicitly. At the same CMakeLists.txt is supposed to be portable. I assume any time build rule is added shell should be always specified explicitly unless executable file can be executed natively on all platforms. As I said in earlier responses this is simply a requirement and is not likely to change. I would want to understand origins of this requirement. Let me describe my thoughts in separate thread to avoid offtopic. On Thu, Jan 22, 2015 at 11:27 AM, Brad King brad.k...@kitware.com wrote: On 01/22/2015 10:34 AM, Daniel Levin wrote: finally came with solution that works for me with standard Ninja generator for QNX SDK. Great! 2. In custom build rules instead of launching .sh scripts directly shell should be specified explicitly. This is expected for any Windows platform that wants to run scripts. Windows does not support shebang lines so the interpreter must always be specified explicitly. 1. In my toolchain file...I will generate .bat wrapper around compiler instead of .sh. I predict that answer about (1) will be the same: load environment before launching build. I would want to start another thread to discuss this issue, because it sounds critical to me. As I said in earlier responses this is simply a requirement and is not likely to change. I understand your desire to automate the environment, but I do not think CMake is the right level to achieve that. About Unix Ninja. I believe the main reason for the Unix Makefiles was the fact that some make tools can handle Unix syntax only. The Unix Makefiles generator refers exactly to unix-style make tools, and on POSIX systems is the only generator besides Ninja (excluding the extra generators that use makefiles+project files). It is available on Windows because there are make tools on Windows that work with such paths/shells natively. Unless ninja were to have a variant that does so too, then it does not need a distinct generator. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Attached to this email. I can also do a pull request if you prefer, Best, Raffi Enficiaud FindMatlab.cmake Description: Binary data MatlabTestsRedirect.cmake Description: Binary data On 22 Jan 2015, at 17:48, Brad King brad.k...@kitware.com wrote: On 01/22/2015 10:13 AM, Raffi Enficiaud wrote: How do we proceed next? Please attach a copy of the patch with the latest revisions. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
