[cmake-developers] [CMake 0015690]: ctest doing one more undesirable run
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15690
==
Reported By:Clinton Stimpson
Assigned To:
==
Project:CMake
Issue ID: 15690
Category: CTest
Reproducibility:have not tried
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-08-07 16:41 EDT
Last Modified: 2015-08-07 16:41 EDT
==
Summary:ctest doing one more undesirable run
Description:
I call
ctest -VV -S my.ctest
and it goes through my script, then decides to do one more configure/build/test,
which I don't want.
Steps to Reproduce:
Use this ctest script:
set(CTEST_SOURCE_DIRECTORY ${CMAKE_CURRENT_LIST_DIR}/src)
set(CTEST_BINARY_DIRECTORY ${CMAKE_CURRENT_LIST_DIR}/build)
set(CTEST_CMAKE_GENERATOR Unix Makefiles)
set(CTEST_PROJECT_NAME all)
set(CTEST_CONFIGURATION_TYPE Release)
set(CTEST_COMMAND ctest)
function(doit)
ctest_start(Experimental)
ctest_configure()
ctest_build()
endfunction()
doit()
Additional Information:
Notice how I'm using a function(). If I change to a macro(), then the problem
goes away. But I don't want to do that.
A workaround is to add
set(CTEST_RUN_CURRENT_SCRIPT OFF)
at the bottom of my script (yuck).
==
Issue History
Date ModifiedUsername FieldChange
==
2015-08-07 16:41 Clinton StimpsonNew 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] [CMake 0015687]: target_include_directories(): SYSTEM option does not seem to work when targeting Xcode.
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15687
==
Reported By:Adn
Assigned To:
==
Project:CMake
Issue ID: 15687
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-08-07 04:07 EDT
Last Modified: 2015-08-07 04:07 EDT
==
Summary:target_include_directories(): SYSTEM option does not
seem to work when targeting Xcode.
Description:
Following the documentation for target_include_directories():
http://www.cmake.org/cmake/help/v3.0/command/target_include_directories.html
We tried to provide the SYSTEM argument to target_include_directories(), to
prevent a third party library to issue a lot of warnings. We expected it to put
the library's include path on the C++ flags line, behind -isystem, but it had
actually no effect, still using this path as if SYSTEM was not given.
We attached in Steps To Reproduce the minimal example reproducing this problem
in our environment:
*CMake v3.3.0 (also tested with v3.0.0 for the same results)
*OS X 10.9.5
*Xcode 5.1.1
There is a mailing list thread discussion this issue, that seems to point to the
incriminated code:
http://www.cmake.org/pipermail/cmake/2015-August/061322.html
Steps to Reproduce:
cmake_minimum_required(VERSION 3.0)
find_package(Boost 1.49 COMPONENTS)
project(system_dependencies)
add_executable(${PROJECT_NAME} main.cpp)
target_include_directories(${PROJECT_NAME} SYSTEM PUBLIC ${Boost_INCLUDE_DIRS})
Additional Information:
There is also a Stack Overflow question:
http://stackoverflow.com/q/31722426
==
Issue History
Date ModifiedUsername FieldChange
==
2015-08-07 04:07 AdnNew 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] [CMake 0015686]: Windows phone projects targeting Windows 10 differ from Windows Phone 8.1 projects
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15686 == Reported By:D.E. Goodman-Wilson Assigned To: == Project:CMake Issue ID: 15686 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2015-08-06 10:23 EDT Last Modified: 2015-08-06 10:23 EDT == Summary:Windows phone projects targeting Windows 10 differ from Windows Phone 8.1 projects Description: Basically, some fields in the .vcxproj need to change, and some new ones added (related, but only part of the way there: https://public.kitware.com/Bug/view.php?id=15670). Here is a link to an MSDN article detailing the differences between a Windows Phone 8.1 and Windows Universal 10 project file; it explains how the various fields in the XML file have evolved, and the specific steps that must be take to manually migrate a project. https://msdn.microsoft.com/en-us/library/Mt148501.aspx#MigrateCPlusPlus Steps to Reproduce: Build a project targeting Windows Phone 8.1, using the Visual Studio 2015 generator and the following CMake directives: set(CMAKE_SYSTEM_NAME WindowsPhone) set(CMAKE_SYSTEM_VERSION 8.1) == Issue History Date ModifiedUsername FieldChange == 2015-08-06 10:23 D.E. Goodman-WilsonNew 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] [CMake 0015682]: [biicode] Ninja generator uses relative paths in target description when including parent directory
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15682 == Reported By:Sam Spilsbury Assigned To: == Project:CMake Issue ID: 15682 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-08-05 02:33 EDT Last Modified: 2015-08-05 02:33 EDT == Summary:[biicode] Ninja generator uses relative paths in target description when including parent directory Description: This is the typical directory tree that biicode uses: CMakeLists.txt - bii | - cmake | - biicode.cmake - CMakeLists.txt - build - bin - lib Biicode starts from bii/cmake/CMakeLists.txt which includes bii/cmake/biicode.cmake which then adds the top-level CMakeLists.txt as a subdirectory. bin and lib are set to CMAKE_RUNTIME_OUTPUT_DIRECTORY and CMAKE_ARCHIVE_OUTPUT_DIRECTORY respectively. When using the ninja generator with this layout, relative paths are inserted into the build.ninja file, for example: # # Link the executable ../../bin/main build ../../bin/main: C_EXECUTABLE_LINKER build_dir/CMakeFiles/main.dir/main.c.o POST_BUILD = : PRE_LINK = : TARGET_PDB = main.dbg # = # Target aliases. However, the all target specifies the absolute path to the output file: # # The main all target. build all: phony /Users/smspillaz/Source/polysquare/cmake-ninja-test/bin/main Which causes ninja to fail: ninja: error: '/Users/smspillaz/Source/polysquare/cmake-ninja-test/bin/main', needed by 'all', missing and no known rule to make it Steps to Reproduce: Tarball of reduced testcase included. $ cd bii/ $ mkdir build $ cd build/ $ cmake ../cmake -G $ ninja Additional Information: Granted, this is a strange build configuration, however biicode uses it and it doesn't appear to me that there is any other way of doing what they want to do without breaking their interface. == Issue History Date ModifiedUsername FieldChange == 2015-08-05 02:33 Sam Spilsbury New Issue 2015-08-05 02:33 Sam Spilsbury File Added: cmake-ninja-test.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 0015683]: Extend --trace to --coverage mode for detection of dead cmake code
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15683 == Reported By:j.kreuzberger Assigned To: == Project:CMake Issue ID: 15683 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2015-08-05 03:05 EDT Last Modified: 2015-08-05 03:05 EDT == Summary:Extend --trace to --coverage mode for detection of dead cmake code Description: my intention is to find dead cmake script code in the project for cleanup and maintainance of the scripts. I have adapted the gcovr script to parse the cmake script output in --trace mode to detected code coverage and write text or html output. Results attached below. No i have some issues: - The trace mode does report multi line statements as one line statement. This should be reported as RANGE (e.g. not with just one line number, with start and end line number (e.g. filename(3:5): ) - the commands closing are not considered in trace output. so to each if(), macro() or other commands, the enclosing endif(), endmacro() etc are not covered. This should be also traced or covered For complete finalisation is must reload the file and mark the commented and blank lines as covered. But thats ok for me for the covering issues. So my suggestion would be to extend the trace mode or create an additional coverage mode. Steps to Reproduce: cmake with --trace output activated and multiline statements like set( MY_VAR test.cpp test.h ... ) if( WIN32 ) set( MYVAR2 ) endif() Additional Information: The attached files are sample output from the adapted gcovr script. Script cant be published cause i have to clarify the copyright issues with the original script holders. == Issue History Date ModifiedUsername FieldChange == 2015-08-05 03:05 j.kreuzberger New Issue 2015-08-05 03:05 j.kreuzberger File Added: cmake_coverage.tinyxml2_tinyxml2sources.txt.html == -- 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 0015684]: CMAKE_Fortran_COMPILER_VERSION becomes unset after second configuring
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15684
==
Reported By:Raul Laasner
Assigned To:
==
Project:CMake
Issue ID: 15684
Category: CMake
Reproducibility:always
Severity: minor
Priority: low
Status: new
==
Date Submitted: 2015-08-05 07:33 EDT
Last Modified: 2015-08-05 07:33 EDT
==
Summary:CMAKE_Fortran_COMPILER_VERSION becomes unset after
second configuring
Description:
CMAKE_Fortran_COMPILER_VERSION contains the correct version after the first
configuring (first run of cmake), but becomes undefined after the second
configuring. Is this normal behavior?
Steps to Reproduce:
Try, e.g.,
message(test 1 ${CMAKE_C_COMPILER_VERSION})
message(test 2 ${CMAKE_Fortran_COMPILER_VERSION})
The first time it prints
test 1 5.2.0
test 2 5.2.0
in my system, but after the second run of cmake it prints
test 1 5.2.0
test 2
==
Issue History
Date ModifiedUsername FieldChange
==
2015-08-05 07:33 Raul Laasner 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] [CMake 0015685]: When packaging cmake-gui Qt dlls are resolved from the PATH and not from the Qt installation directory used to build CMake
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15685 == Reported By:Mourad Assigned To: == Project:CMake Issue ID: 15685 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-08-05 13:21 EDT Last Modified: 2015-08-05 13:21 EDT == Summary:When packaging cmake-gui Qt dlls are resolved from the PATH and not from the Qt installation directory used to build CMake Description: Hi, I have two Qt versions installed on my system. The main one (64 bit build) is used for my other projects, and the second one (32bit build) is only used to build CMake. When packaging/installing CMake-gui , the Qt dlls are resolved from my main Qt installation (because its bin folder is in my PATH, I guess), and not from the Qt installation folder that is used to build CMake. IMHO, there is a typo in Source/QtDialog/CMakeLists.txt (see attached patch), which when solved, solves the problem. Please note that there might also be a problem with the QT_LIBRARY_DIR variable (it's not used on Windows, maybe it is on other platforms) Cheers, Mourad == Issue History Date ModifiedUsername FieldChange == 2015-08-05 13:21 Mourad New Issue 2015-08-05 13:21 Mourad File Added: cmake.patch == -- 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 0015681]: add_custom_command(TARGET ...) can't see in scope target
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15681 == Reported By:Dan Liew Assigned To: == Project:CMake Issue ID: 15681 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-08-04 17:18 EDT Last Modified: 2015-08-04 17:18 EDT == Summary:add_custom_command(TARGET ...) can't see in scope target Description: 'm observing a problem with CMake's add_custom_command() when using the TARGET version of the signature. Code demonstrating the issue can be found at [1] In ``test/CMakeLists.txt`` [2] I try using add_custom_command() to build and run an executable every time the ``foolib`` library is rebuilt. The motivation behind doing this is to have some very quick and simple library tests run every time the library is built. This use of add_custom_command() does not seem to work at all. Using CMake 2.8.12.2 the requested command is not invoked when running ``make foolib``. I am aware that the custom command won't run if ``foolib`` has already been made but even if I do a clean build the custom command specified does not run. When using CMake 3.2.3 I get a warning about CMP0040 which complains that the target passed to the TARGET argument in ``add_custom_command()`` doesn't exist. ``` Policy CMP0040 is not set: The target in the TARGET signature of add_custom_command() must exist. Run cmake --help-policy CMP0040 for policy details. Use the cmake_policy command to set the policy and suppress this warning. The target name foolib is unknown in this context. This warning is for project developers. Use -Wno-dev to suppress it ``` This doesn't make sense the target **clearly exists and is in scope** because the ``simple_test`` executable links against it and also it is possible to read properties of the target. Seems like there's some sort of weird scope issue going on here. [1] https://github.com/delcypher/cmake_add_custom_command_bug [2] https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/test/CMakeLists.txt Steps to Reproduce: $ git clone https://github.com/delcypher/cmake_add_custom_command_bug.git $ cd cmake_add_custom_command_bug $ mkdir build $ cd build # Under new versions of CMake a warning is emitted about the foolib target not being known in this context $ cmake ../ $ make foolib VERBOSE=1 you will see that none of the custom commands are executed == Issue History Date ModifiedUsername FieldChange == 2015-08-04 17:18 Dan Liew 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] [CMake 0015679]: ExternalProject with Ninja generator should import sub-project's build.ninja into the parent project
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15679 == Reported By:Chris Assigned To: == Project:CMake Issue ID: 15679 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2015-08-04 12:45 EDT Last Modified: 2015-08-04 12:45 EDT == Summary:ExternalProject with Ninja generator should import sub-project's build.ninja into the parent project Description: Ninja's scheduling works best if it has a full picture of what you're building. Doing that in projects that extensively use ExternalProject can be tricky. To make this work I believe CMake needs to do 3 things that it doesn't do today. (1) ExternalProject needs to prefix all the rules and targets in the ninja file it generates so that they don't conflict with the parent project's rules or targets (2) ExternalProject calls to CMake need to be marked as Generator rules in Ninja so that Ninja will re-exec itself after running CMake (3) ExternalProject needs to generate Ninja includes in the parent project. Additional Information: This request is coming out of the LLVM developer community. As we're moving more actively to CMake we are leveraging ExternalProject more and more for generating cross-compiled targets, bootstrapping the compiler and generating test targets. We believe these improvements to ExternalProject will make for a better developer experience on our end. Thanks, -Chris == Issue History Date ModifiedUsername FieldChange == 2015-08-04 12:45 Chris 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] [CMake 0015680]: The message about a missing CMakeLists.txt in a subdirectory is incorrect [regression]
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15680 == Reported By:Anton Makeev Assigned To: == Project:CMake Issue ID: 15680 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-08-04 16:06 EDT Last Modified: 2015-08-04 16:06 EDT == Summary:The message about a missing CMakeLists.txt in a subdirectory is incorrect [regression] Description: CMake 3.3 reports The source directory ...problems_missing_subdirs_cmakelists/subdir does not contain a CMakeLists.txt file. CMake 3.3 reports The source directory ...problems_missing_subdirs_cmakelists/subdir/CMakeLists.txt does not contain a CMakeLists.txt file. Steps to Reproduce: generate the attached project with Unix Makefiles generator == Issue History Date ModifiedUsername FieldChange == 2015-08-04 16:06 Anton Makeev New Issue 2015-08-04 16:06 Anton Makeev File Added: problems_missing_subdirs_cmakelists.zip == -- 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 0015676]: The red message INSTALL TARGETS - target Xxx has RESOURCE files but no RESOURCE DESTINATION. is misleading on Apple platforms.
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15676
==
Reported By:Adn
Assigned To:
==
Project:CMake
Issue ID: 15676
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-08-03 05:33 EDT
Last Modified: 2015-08-03 05:33 EDT
==
Summary:The red message INSTALL TARGETS - target Xxx has
RESOURCE files but no RESOURCE DESTINATION. is misleading on Apple platforms.
Description:
When building an OS X application, the resource files are listed in the RESOURCE
target property. Following INSTALL(...) documentation
(http://www.cmake.org/cmake/help/v3.3/command/install.html?highlight=install#installing-targets):
The PRIVATE_HEADER, PUBLIC_HEADER, and RESOURCE arguments cause subsequent
properties to be applied to installing a FRAMEWORK shared library target’s
associated files on non-Apple platforms.
Rules defined by these arguments are ignored on Apple platforms because the
associated files are installed into the appropriate locations inside the
framework folder.
From the documentation, one would understand that there is no point in giving a
RESOURCE argument to INSTALL command when targeting Apple platforms: the
argument is ignored, and the resource are copied inside the bundle (the second
statement here being actually true). Yet, if this argument is omitted, a red
message is emitted in the GUI, which seems confusing with regard to the
documentation statement.
Also, if one decides to provide this argument with a dummy location to turn off
the message, the install target will actually copy the RESOURCE files to the
dummy location (So the argument is not ignored: the resources are still copied
in the bundle, but they are also copied in the provided location).
Steps to Reproduce:
##
## This is the skeleton of a CMakeLists.txt that would trigger the red message
when generated on Apple
##
# populate ${${PROJECT_NAME}_RESOURCES} variable with a .xib file and images
add_executable(${PROJECT_NAME} MACOSX_BUNDLE
${${PROJECT_NAME}_HEADERS}
${${PROJECT_NAME}_SOURCES}
${${PROJECT_NAME}_RESOURCES}
main.mm
)
set_target_properties(${PROJECT_NAME} PROPERTIES
VERSION ${VERSION}
SOVERSION ${SOVERSION}
RESOURCE ${${PROJECT_NAME}_RESOURCES}
)
install(TARGETS ${PROJECT_NAME}
BUNDLE DESTINATION ${RUNTIME_OUTPUT_DIRECTORY}
)
Additional Information:
There is a stack overflow question on this topic:
http://stackoverflow.com/q/31723271/1027706
==
Issue History
Date ModifiedUsername FieldChange
==
2015-08-03 05:33 AdnNew 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] [CMake 0015677]: Issue deprecation warnings by default.
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15677 == Reported By:Stephen Kelly Assigned To: == Project:CMake Issue ID: 15677 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-08-03 19:19 CEST Last Modified: 2015-08-03 19:19 CEST == Summary:Issue deprecation warnings by default. Description: message(DEPRECATED) does not issue any warning unless the user adds additional command line flags. Policy warnings are issued by default until the user uses command line flags. message(DEPRECATED) should likely be changed to issue the message by default. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13798/focus=13878 == Issue History Date ModifiedUsername FieldChange == 2015-08-03 19:19 Stephen Kelly 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] [CMake 0015678]: CMakeCache.txt can't be passed into cmake's -C flag
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15678
==
Reported By:Chris
Assigned To:
==
Project:CMake
Issue ID: 15678
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-08-03 17:08 EDT
Last Modified: 2015-08-03 17:08 EDT
==
Summary:CMakeCache.txt can't be passed into cmake's -C flag
Description:
I'm probably trying to be too clever, but I'm trying to setup a cmake build
target for clang to do a bootstrap build where you build clang, then use the
built clang to rebuild clang. I had this genius idea that I could try and pass
through the CMake options used to configure the first clang using the
CMakeCache.txt and the -C flag. It unfortunately doesn't work. I see the
following errors:
[2/5] Performing configure step for 'bootstrap'
FAILED: cd
/Users/cbieneman/dev/open-source/llvm-build-rel/tools/clang/bootstrap/src/bootstrap-build
/Users/cbieneman/dev/open-source/cmake-bins/bin/cmake -C
/Users/cbieneman/dev/open-source/llvm-build-rel/CMakeCache.txt
-DCMAKE_CXX_COMPILER=/Users/cbieneman/dev/open-source/llvm-build-rel/bin/clang++
-DCMAKE_CXX_COMPILER=/Users/cbieneman/dev/open-source/llvm-build-rel/bin/clang
-GSublime Text 2 - Ninja /Users/cbieneman/dev/open-source/llvm
/Users/cbieneman/dev/open-source/cmake-bins/bin/cmake -E touch
/Users/cbieneman/dev/open-source/llvm-build-rel/tools/clang/bootstrap/src/bootstrap-stamp/bootstrap-configure
loading initial cache file
/Users/cbieneman/dev/open-source/llvm-build-rel/CMakeCache.txt
CMake Error: Error in cmake code at
/Users/cbieneman/dev/open-source/llvm-build-rel/CMakeCache.txt:17:
Parse error. Expected a command name, got unquoted argument with text
//Default.
CMake Error: Error processing file:
/Users/cbieneman/dev/open-source/llvm-build-rel/CMakeCache.txt
Steps to Reproduce:
Apply the diffs below to clang, and configure with CMake setting
-DCLANG_ENABLE_BOOTSTRAP=On, and run buildtool bootstrap.
Additional Information:
diff --git a/CMakeLists.txt b/CMakeLists.txt
index ab70f1d..6974b6e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -96,6 +96,7 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR )
option(LLVM_FORCE_USE_OLD_HOST_TOOLCHAIN
Set to ON to force using an old, unsupported host toolchain. OFF)
+ option(CLANG_ENABLE_BOOTSTRAP Generate the clang bootstrap target OFF)
include(AddLLVM)
include(TableGen)
@@ -551,3 +552,31 @@ if (CLANG_BUILT_STANDALONE)
${CLANG_BINARY_DIR}/share/clang/cmake/ClangConfig.cmake
COPYONLY)
endif ()
+
+if (CLANG_ENABLE_BOOTSTRAP)
+ include(ExternalProject)
+
+ ExternalProject_Add(bootstrap
+DEPENDS clang
+PREFIX bootstrap
+SOURCE_DIR ${CMAKE_SOURCE_DIR}
+CMAKE_ARGS -C ${CMAKE_BINARY_DIR}/CMakeCache.txt
+${CLANG_BOOTSTRAP_CMAKE_ARGS}
+-DCMAKE_CXX_COMPILER=${CMAKE_BINARY_DIR}/bin/clang++
+-DCMAKE_CXX_COMPILER=${CMAKE_BINARY_DIR}/bin/clang
+STEP_TARGETS configure build
+)
+
+ ExternalProject_Add_Step(bootstrap force-reconfigure
+DEPENDERS configure
+ALWAYS 1
+)
+
+ ExternalProject_Add_Step(bootstrap clobber
+COMMAND ${CMAKE_COMMAND} -E remove_directory BINARY_DIR
+COMMAND ${CMAKE_COMMAND} -E make_directory BINARY_DIR
+COMMENT Clobberring compiler-rt build directory...
+DEPENDERS configure
+DEPENDS ${LLVM_RUNTIME_OUTPUT_INTDIR}/bootstrap
+ )
+endif()
==
Issue History
Date ModifiedUsername FieldChange
==
2015-08-03 17:08 Chris 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:
[cmake-developers] [CMake 0015675]: RULE_LAUNCH_COMPILE is ignored for non-makefile generators
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15675 == Reported By:andi Assigned To: == Project:CMake Issue ID: 15675 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-08-02 10:47 EDT Last Modified: 2015-08-02 10:47 EDT == Summary:RULE_LAUNCH_COMPILE is ignored for non-makefile generators Description: It would be nice if RULE_LAUNCH_COMPILE and RULE_LAUNCH_LINK would also be considered for the non-makefile generators. == Issue History Date ModifiedUsername FieldChange == 2015-08-02 10:47 andi 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] [CMake 0015672]: XCode project broken since cmake 3.3.0
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15672
==
Reported By:A. Klitzing
Assigned To:
==
Project:CMake
Issue ID: 15672
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2015-07-30 10:59 EDT
Last Modified: 2015-07-30 10:59 EDT
==
Summary:XCode project broken since cmake 3.3.0
Description:
We use cmake to build our application for iOS. If we try the same workflow with
cmake 3.3.0 we get this error:
$ cmakexbuild -target install
2015-07-30 16:41:03.453 xcodebuild[47660:18383918]
CFPropertyListCreateFromXMLData(): Old-style plist parser: missing semicolon in
dictionary on line 1381. Parsing will be abandoned. Break on
_CFPropertyListMissingSemicolon to debug.
2015-07-30 16:41:03.458 xcodebuild[47660:18383918]
CFPropertyListCreateFromXMLData(): Old-style plist parser: missing semicolon in
dictionary on line 1381. Parsing will be abandoned. Break on
_CFPropertyListMissingSemicolon to debug.
2015-07-30 16:41:03.459 xcodebuild[47660:18383918] The data couldn’t be read
because it isn’t in the correct format.
xcodebuild: error: Unable to read project 'XXX.xcodeproj'.
Reason: Project /tmp/build/XXX.xcodeproj cannot be opened because the
project
file cannot be parsed.
The same workflow works with cmake 3.0.x - 3.2.x!
Steps to Reproduce:
1. cmake ../XXX/ -DCMAKE_PREFIX_PATH=/tmp/thirdparty
-DCMAKE_TOOLCHAIN_FILE=../XXX/cmake/iOS.toolchain.cmake -GXcode
2. cmakexbuild -target install
Toolchain file:
https://code.google.com/p/ios-cmake/source/browse/toolchain/iOS.cmake
Additional Information:
Line 1380 - 1382 of project.pbxproj
1380 2525E3626D4B43E89F8019E3 /*
/tmp/XXX/resources/images/iOS/appIcons/icon29...@2x.png */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = image; na me =
icon29...@2x.png; path = resources/images/iOS/appIcons/icon29...@2x.png;
sourceTree = SOURCE_ROOT; };
1381 254B9DCBBC4947269D39ACED /*
/tmp/XXX/resources/images/iOS/appIcons/icon29x29~ipad.png */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = image; name =
icon29x29~ipad.png; path = resources/images/iOS/appIcons/icon29x29~ipad.png;
sourceTree = SOURCE_ROOT; };
1382 268D04D278914C12AE277A44 /*
/tmp/XXX/resources/images/iOS/appIcons/icon40x40@2x~ipad.png */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = imag e; name =
icon40x40@2x~ipad.png; path =
resources/images/iOS/appIcons/icon40x40@2x~ipad.png; sourceTree = SOURCE_ROOT;
};
==
Issue History
Date ModifiedUsername FieldChange
==
2015-07-30 10:59 A. KlitzingNew 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] [CMake 0015673]: CMAKE_C_COMPILER is used to link a CXX shared library on Solaris
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15673 == Reported By:Xan López Assigned To: == Project:CMake Issue ID: 15673 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-07-30 11:58 EDT Last Modified: 2015-07-30 11:58 EDT == Summary:CMAKE_C_COMPILER is used to link a CXX shared library on Solaris Description: The SunOS.cmake file has the following: if(CMAKE_COMPILER_IS_GNUCXX) if(CMAKE_COMPILER_IS_GNUCC) set(CMAKE_CXX_CREATE_SHARED_LIBRARY CMAKE_C_COMPILER CMAKE_SHARED_LIBRARY_CXX_FLAGS LINK_FLAGS CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS SONAME_FLAGTARGET_SONAME -o TARGET OBJECTS LINK_LIBRARIES) The end result is that CMAKE_C_COMPILER (gcc) is used to link C++ shared libraries in Solaris. This results in numerous errors. I assume this is just a typo, and the attached patch just fixes things for me. This can be reproduced 100% of the time trying to compile LLVM/clang from SVN HEAD, LTO and clang libs will fail to compile. == Issue History Date ModifiedUsername FieldChange == 2015-07-30 11:58 Xan López New Issue 2015-07-30 11:58 Xan López File Added: 0001-SunOS-use-CXX-compiler-to-link-CXX-shared-libraries.patch == -- 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 0015671]: cmake does not find _vsnprintf
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15671 == Reported By:beckmi Assigned To: == Project:CMake Issue ID: 15671 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-30 07:01 EDT Last Modified: 2015-07-30 07:01 EDT == Summary:cmake does not find _vsnprintf Description: I am using Visual Studio 2015 cmake 3.3 freetds-0.95.19 running cmake -G NMake Makefiles . does not find vsnprintf nor _vsnprintf Steps to Reproduce: Install Visual Studio 2015 Download freetds run cmake run nmake == Issue History Date ModifiedUsername FieldChange == 2015-07-30 07:01 beckmi 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] [CMake 0015668]: Create debuginfo package
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15668 == Reported By:Egor Assigned To: == Project:CMake Issue ID: 15668 Category: CPack Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2015-07-29 04:26 EDT Last Modified: 2015-07-29 04:26 EDT == Summary:Create debuginfo package Description: CPack allows us to create rpm-packages through CPackRPM module, but there is no chance to ask him for building correspondent debuginfo rpm package. == Issue History Date ModifiedUsername FieldChange == 2015-07-29 04:26 Egor 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] [CMake 0015667]: XCTest CocoaExample crashes Xcode GUI
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15667
==
Reported By:Seppo Tomperi
Assigned To:
==
Project:CMake
Issue ID: 15667
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-07-29 02:47 EDT
Last Modified: 2015-07-29 02:47 EDT
==
Summary:XCTest CocoaExample crashes Xcode GUI
Description:
cmake version 3.3.0 from homebrew
Starting XCTest CocoaExample test from Xcode GUI crashes Xcode 6.4 and 7.
XCTest FrameworkExample test works from Xcode GUI.
However from command line CocoaExample passes.
Steps to Reproduce:
cd Tests/XCTest/
mkdir target
cd target/
cmake -G Xcode ..
open XCTest.xcodeproj
# running CocoaExample from GUI crashes Xcode
#however:
xcodebuild -project XCTest.xcodeproj/ -scheme CocoaExample -destination
'platform=OS X,arch=x86_64' build
xcodebuild -project XCTest.xcodeproj/ -scheme CocoaExample -destination
'platform=OS X,arch=x86_64' test
# passes:
Test Suite 'All tests' started at 2015-07-29 06:41:31 +
Test Suite 'CocoaExampleTests.xctest' started at 2015-07-29 06:41:31 +
Test Suite 'CocoaExampleTests' started at 2015-07-29 06:41:31 +
Test Case '-[CocoaExampleTests testExample]' started.
Test Case '-[CocoaExampleTests testExample]' passed (0.000 seconds).
Test Suite 'CocoaExampleTests' passed at 2015-07-29 06:41:31 +.
Executed 1 test, with 0 failures (0 unexpected) in 0.000 (0.000)
seconds
Test Suite 'CocoaExampleTests.xctest' passed at 2015-07-29 06:41:31 +.
Executed 1 test, with 0 failures (0 unexpected) in 0.000 (0.001)
seconds
Test Suite 'All tests' passed at 2015-07-29 06:41:31 +.
Executed 1 test, with 0 failures (0 unexpected) in 0.000 (0.001)
seconds
** TEST SUCCEEDED **
Additional Information:
Process: Xcode [74137]
Path: /Applications/Xcode.app/Contents/MacOS/Xcode
Identifier:com.apple.dt.Xcode
Version: 6.4 (7720)
Build Info:IDEFrameworks-7720~8
App Item ID: 497799835
App External ID: 812725084
Code Type: X86-64 (Native)
Parent Process:??? [1]
Responsible: Xcode [74137]
User ID: 501
Date/Time: 2015-07-29 09:36:46.399 +0300
OS Version:Mac OS X 10.10.4 (14E46)
Report Version:11
Anonymous UUID:6FE1E47C-AE8D-AA50-F104-3C3169AD118E
Sleep/Wake UUID: E9A90012-D49D-45CD-8E55-F5314FA4C435
Time Awake Since Boot: 55000 seconds
Time Since Wake: 2700 seconds
Crashed Thread:0 Dispatch queue: com.apple.main-thread
Exception Type:EXC_CRASH (SIGABRT)
Exception Codes: 0x, 0x
Application Specific Information:
ProductBuildVersion: 6E35b
ASSERTION FAILURE in
/SourceCache/IDEXcode3ProjectSupport/IDEXcode3ProjectSupport-7709/Xcode3Core/LegacyProjects/Frameworks/DevToolsCore/DevToolsCore/ProjectModel/Xcode3Model/Xcode3TargetBuildable.m:181
Details: string should be a non-empty string, but it's an empty string
Object: Xcode3TargetProduct: 0x7fc577345ae0
Method: -stringByEvaluatingBuildSettingExpressionString:withBuildParameters:
Thread: NSThread: 0x7fc571439800{number = 1, name = main}
Hints: None
Backtrace:
0 0x00010d8a4fda -[IDEAssertionHandler
handleFailureInMethod:object:fileName:lineNumber:assertionSignature:messageFormat:arguments:]
(in IDEKit)
1 0x00010c5fa65f _DVTAssertionHandler (in DVTFoundation)
2 0x00010c5fa94e _DVTAssertionFailureHandler (in DVTFoundation)
3 0x000116fbdbf3 -[Xcode3TargetBuildable
stringByEvaluatingBuildSettingExpressionString:withBuildParameters:] (in
DevToolsCore)
4 0x00010d10 -[IDESchemeAction
bundleIdentifierFromBuildableProduct:withBuildParameters:] (in IDEFoundation)
5 0x00010d1f38bc __192-[IDETestSchemeAction
testOperationWithTestManager:executionEnvironment:withBuildOperation:buildParameters:schemeCommand:actionRecord:overridingTestingSpecifiers:outError:actionCallbackBlock:]_block_invoke
(in IDEFoundation)
6 0x00010d0af6ae -[IDEOCUnitTestRunner
testOperationsForExecutionEnvironment:withBuildOperation:buildParameters:runDestination:workspace:error:launchParametersBlock:]
(in IDEFoundation)
7 0x000116fe24a8 -[Xcode3OCUnitTestRunner
testOperationsForExecutionEnvironment:withBuildOperation:buildParameters:runDestination:workspace:error:launchParametersBlock:]
[cmake-developers] [CMake 0015669]: XCTest for iOS target has incorrect TEST_HOST
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15669 == Reported By:Seppo Tomperi Assigned To: == Project:CMake Issue ID: 15669 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-29 08:07 EDT Last Modified: 2015-07-29 08:07 EDT == Summary:XCTest for iOS target has incorrect TEST_HOST Description: Path to executable in TEST_HOST is not correct when targeting iOS device. Steps to Reproduce: unzip iOSNavAppXCTest.zip cd iOSNavAppXCTest mkdir build cd build cmake -G Xcode .. grep TEST_HOST NavApp3.xcodeproj/project.pbxproj TEST_HOST variable has extra directory: Contents/MacOS, which is not there. Executable is in NavApp3.app-directory. If Contents/MacOS is edited away from project file then project works and XCTests can be run in simulator and on iPhone. == Issue History Date ModifiedUsername FieldChange == 2015-07-29 08:07 Seppo Tomperi New Issue 2015-07-29 08:07 Seppo Tomperi File Added: iOSNavAppXCTest.zip == -- 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 0015666]: Ninja may unnecessarily relink on windows
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15666
==
Reported By:Nils Gladitz
Assigned To:
==
Project:CMake
Issue ID: 15666
Category: (No Category)
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-07-28 05:56 EDT
Last Modified: 2015-07-28 05:56 EDT
==
Summary:Ninja may unnecessarily relink on windows
Description:
I have the following windows specific test case:
cmake_minimum_required(VERSION 3.3)
project(Foo CXX)
if(NOT EXISTS test.cpp)
file(WRITE test.cpp __declspec(dllexport) void foo() {})
endif()
add_custom_target(touch
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_SOURCE_DIR}/test.cpp
)
add_library(foo SHARED test.cpp)
Steps to Reproduce:
I configured the given test project with the Ninja generator from a Visual
Studio 2013 (x64) environment.
1. ninja # builds the project as expected
2. ninja # outputs ninja: no work to do. as expected
3. ninja touch # touches test.cpp
4. ninja # recompiles and relinks as expected
5-n. ninja # unexpectedly relinks; expected is ninja: no work to do.
Additional Information:
It looks like the relink happens because the linker updates foo.dll but does not
touch foo.lib.
Which leads to (ninja -d explain):
ninja explain: output foo.lib older than most recent input
CMakeFiles/foo.dir/test.cpp.obj (459779794 vs 459780205)
ninja explain: foo.dll is dirty
[1/1] Linking CXX shared library foo.dll
==
Issue History
Date ModifiedUsername FieldChange
==
2015-07-28 05:56 Nils Gladitz 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] [CMake 0015665]: CPack and absolute paths
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15665 == Reported By:Lectem Assigned To: == Project:CMake Issue ID: 15665 Category: CPack Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-27 08:34 EDT Last Modified: 2015-07-27 08:34 EDT == Summary:CPack and absolute paths Description: When running make package (or cpack), with a target having an absolute path as its destination, it will try to install it there instead of using the temporary folder. When using this script : add_library(mylib foo.cpp) install(TARGETS mylib DESTINATION /some/custom/dir) include(CPack) cpack will install mylib to /some/custom/dir which is obviously not what we want. Plus, generators such as TGZ will not include those files, while they actually support absolute paths. What I suggest is 1. Do not make the install, or redirect it in a temp directory 2. Trigger a Warning/Error == Issue History Date ModifiedUsername FieldChange == 2015-07-27 08:34 Lectem 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] [CMake 0015664]: CMake detects the wrong version for the C and C++ Cray Compiler
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15664 == Reported By:jcook Assigned To: == Project:CMake Issue ID: 15664 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-26 13:21 EDT Last Modified: 2015-07-26 13:21 EDT == Summary:CMake detects the wrong version for the C and C++ Cray Compiler Description: This is because CMake is using the _RELEASE macro instead of _RELEASE_MAJOR in Modules/Compiler/Cray-DetermineCompiler.cmake. Steps to Reproduce: cmake --system-information | grep CMAKE_C_COMPILER_VERSION Additional Information: None at this time. Please let me know if you need more info. == Issue History Date ModifiedUsername FieldChange == 2015-07-26 13:21 jcook 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] [CMake 0015663]: externalproject cause make -j build failure the first time
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15663 == Reported By:Laurent Demailly Assigned To: == Project:CMake Issue ID: 15663 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-23 13:50 PDT Last Modified: 2015-07-23 13:50 PDT == Summary:externalproject cause make -j build failure the first time Description: the first time someone builds a cmake generated makefile, using -j yields a broken build because somehow the download of the external projects isn't complete the dependencies should be set correctly such as make waits for that target to complete ? https://github.com/facebook/wdt/issues/12 Steps to Reproduce: git clone https://github.com/facebook/wdt.git mkdir build; cd build cmake ../wdt -G Unix Makefiles -DBUILD_TESTING=on make -j this isn't mac specific - same issue with Ubuntu - could be a bug in our cmakelist.txt https://github.com/facebook/wdt/blob/master/CMakeLists.txt#L212 is where we add gmock == Issue History Date ModifiedUsername FieldChange == 2015-07-23 13:50 Laurent DemaillyNew 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] [CMake 0015660]: Isssue while installing cmake-curses-gui
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15660 == Reported By:vijay Assigned To: == Project:CMake Issue ID: 15660 Category: CCMake Reproducibility:N/A Severity: minor Priority: immediate Status: new == Date Submitted: 2015-07-23 02:33 EDT Last Modified: 2015-07-23 02:33 EDT == Summary:Isssue while installing cmake-curses-gui Description: I've installed cmake 3.2.2 but when i install cmake-curses-gui, it changes my cmake version to 2.8. I need cmake 3x versions including cmake-curses-gui. Help me == Issue History Date ModifiedUsername FieldChange == 2015-07-23 02:33 vijay 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] [CMake 0015661]: FindPythonInterp will accept python in the path, even though it is the wrong version
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15661
==
Reported By:Paul TBBle Hampson
Assigned To:
==
Project:CMake
Issue ID: 15661
Category: Modules
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2015-07-24 04:07 AEST
Last Modified: 2015-07-24 04:07 AEST
==
Summary:FindPythonInterp will accept python in the path,
even though it is the wrong version
Description:
The command
FIND_PACKAGE(PythonInterp 2.6 REQUIRED)
will discover a Python 3 installation if that is 'python' in the path, in
preference to a Python 2 installation.
Steps to Reproduce:
Call
FIND_PACKAGE(PythonInterp 2.6 REQUIRED)
in a CMake script, when your PATH contains C:\Python34 but both Python 3.4 and
Python 2.7 are installed locally.
Expected result:
-- Found PythonInterp: C:/Python27/python.exe (found suitable version 2.7.9,
minimum required is 2.6)
Actual result:
-- Found PythonInterp: C:/Python34/python.exe (found suitable version 3.4.3,
minimum required is 2.6)
Additional Information:
I haven't diagnosed this yet, but the problem appears to be the following blocks
in FindPythonInterp.cmake:
=
# Search for the current active python version first
list(APPEND _Python_VERSIONS ;)
list(APPEND _Python_VERSIONS ${_PYTHON_FIND_OTHER_VERSIONS})
# Search for newest python version if python executable isn't found
if(NOT PYTHON_EXECUTABLE)
foreach(_CURRENT_VERSION IN LISTS _Python_VERSIONS)
set(_Python_NAMES python${_CURRENT_VERSION})
if(WIN32)
list(APPEND _Python_NAMES python)
endif()
find_program(PYTHON_EXECUTABLE
NAMES ${_Python_NAMES}
PATHS
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]
)
endforeach()
endif()
=
If I'm reading this correctly, it's possible for _Python_VERSIONS to be empty
before this if neither ADDTIONAL_VERSIONS nor PYTHONLIBS_VERSION_STRING (from
FindPythonLibs.cmake) are set.
This means that when the given loop is hit, the first value of _CURRENT_VERSION
is , so 'python' is searched for by find_program. There's also the
WIN32-specific block that explicitly searches for the executable name 'python',
as that's the name of the executable on Windows installations.
If python.exe is in the Path (a non-default but common installer option) then
the first search attempt will discover it and use it.
It might be simplest to split this search, and on Win32 not search the system
path until the registry walk has completed.
I think there's also a couple of other issues here: A per-user install of Python
sets a different registry key, and we don't fail if Python 2 was requested but
Python 3 is found, or vice-versa.
We also don't support py.exe, which as of Python 3.3 supports running python
scripts with arbitrary versions by processing the #! initial line the same way
an executable .py file is handled on POSIX systems.
==
Issue History
Date ModifiedUsername FieldChange
==
2015-07-24 04:07 Paul TBBle HampsonNew 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] [CMake 0015662]: CMake looks in the wrong locations for Windows/Windows Phone SDKs with Visual Studio 2015
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15662 == Reported By:D.E. Goodman-Wilson Assigned To: == Project:CMake Issue ID: 15662 Category: CMake Reproducibility:always Severity: major Priority: urgent Status: new == Date Submitted: 2015-07-23 14:20 EDT Last Modified: 2015-07-23 14:20 EDT == Summary:CMake looks in the wrong locations for Windows/Windows Phone SDKs with Visual Studio 2015 Description: With Visual Studio 2015, the locations of the registry keys for the Windows SDK and WIndows Phone SDK have changed, and so the VS 2015 generator—which relies on the VS 2013 registry settings—generates errors wrongly. Steps to Reproduce: On a freshly installed system with no prior installation of Visual Studio 2013, and a fresh installation of Visual Studio 2015 with Windows SDK 8.1 and Windows Phone SDK 8.1 installed, attempt to cmake a project with set(CMAKE_SYSTEM_NAME WindowsPhone) set(CMAKE_SYSTEM_VERSION 8.1) The following error is generated: -- Building for: Visual Studio 14 2015 CMake Error at CMakeLists.txt:2 (project): A Windows Phone component with CMake requires both the Windows Desktop SDK as well as the Windows Phone '8.1' SDK. Please make sure that you have both installed Additional Information: I can't find the new Windows Phone SDK registry keys, but they are not where cmake is expecting them for sure. The new WIndows SDK is now located at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.1A\InstallationFolder == Issue History Date ModifiedUsername FieldChange == 2015-07-23 14:20 D.E. Goodman-WilsonNew 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] [CMake 0015659]: Visual Studio 2015: check_function_exists doesn't work for stdio functions
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15659 == Reported By:Alex Lamaison Assigned To: == Project:CMake Issue ID: 15659 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-22 17:34 EDT Last Modified: 2015-07-22 17:34 EDT == Summary:Visual Studio 2015: check_function_exists doesn't work for stdio functions Description: check_function_exists worked with previous versions of VS and correctly detected the absence of presence of stdio functions like the printf/scanf families, but with VS2015, those functions are always 'not found' With Visual Studio 2015, those functions are now defined *inline* in stdio.h. This means that CheckFunctionExists.c, which doesn't included stdio.h, can't find any definition of the function to link with. Previously this would have linked with the symbol in the CRT. Steps to Reproduce: Add check_function_exists(snprintf) to a project. Configure with VS2015 generator. It should say 'Looking for snprintf - found'. Instead it says 'Looking for snprintf - not found'. Additional Information: A workaround is to add legacy_stdio_definitions.lib to CMAKE_REQUIRED_LIBRARIES. However, that is not ideal because it requires knowing that library is available and required in the first place. That defeats the object of feature detection. More info here: https://msdn.microsoft.com/en-us/library/bb531344.aspx == Issue History Date ModifiedUsername FieldChange == 2015-07-22 17:34 Alex Lamaison 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] [CMake 0015658]: Allow generator expressions in add_custom_command (and add_custom_target)
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15658 == Reported By:Ben Boeckel Assigned To: == Project:CMake Issue ID: 15658 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new Target Version: CMake 3.4 == Date Submitted: 2015-07-21 11:19 EDT Last Modified: 2015-07-21 11:19 EDT == Summary:Allow generator expressions in add_custom_command (and add_custom_target) Description: Now that LOCATION is disallowed, using a target path as an argument to a custom command is not possible without warnings (or making CMP0026 OLD). At least OUTPUT, COMMAND, MAIN_DEPENDENCY, DEPENDS, WORKING_DIRECTORY, and SOURCES (for a_c_t) should expand generator expressions. Some may already do so via properties being genex-expanded already (just WORKING_DIRECTORY IIRC). == Issue History Date ModifiedUsername FieldChange == 2015-07-21 11:19 Ben BoeckelNew 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] [CMake 0015657]: cmTarget::GetOutputInfo called for mytarget which has type UTILITY (CMake Internal Error)
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15657 == Reported By:Erik Sjölund Assigned To: == Project:CMake Issue ID: 15657 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-21 07:16 EDT Last Modified: 2015-07-21 07:16 EDT == Summary:cmTarget::GetOutputInfo called for mytarget which has type UTILITY (CMake Internal Error) Description: I was experimenting with exporting. I don't know if the content of the CMakeLists.txt makes sense but CMake told me to report a bug: CMake Internal Error (please report a bug) Here is the content of the CMakeLists.txt file: cmake_minimum_required(VERSION 3.3) add_custom_command(OUTPUT empty.txt COMMAND touch empty.txt) add_custom_target(mytarget DEPENDS empty.txt) export(TARGETS mytarget FILE export.cmake) Steps to Reproduce: The shell terminal session is attached as a file (terminal-output.txt). == Issue History Date ModifiedUsername FieldChange == 2015-07-21 07:16 Erik Sjölund New Issue 2015-07-21 07:16 Erik Sjölund File Added: terminal-output.txt == -- 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 0015656]: pls. add CPACK_RPM_PACKAGE_CONFLICTS
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15656 == Reported By:Frank-Christian Otto Assigned To: == Project:CMake Issue ID: 15656 Category: CPack Reproducibility:N/A Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-16 05:38 EDT Last Modified: 2015-07-16 05:38 EDT == Summary:pls. add CPACK_RPM_PACKAGE_CONFLICTS Description: RPM packaging via cpack allows to set positive dependencies using CPACK_RPM_PACKAGE_REQUIRES RPM also allows negative dependencies (packages that must not be installed). I patched Modules/CPackRPM.cmake to support this. Pls. consider adding this to the code base. patch added as attachment == Issue History Date ModifiedUsername FieldChange == 2015-07-16 05:38 Frank-Christian OttoNew Issue 2015-07-16 05:38 Frank-Christian OttoFile Added: Modules_CPackRPM.cmake_3.2_patch == -- 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 0015655]: file(GENERATE) fails of the destination directory doesn't exist
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15655
==
Reported By:James Bigler
Assigned To:
==
Project:CMake
Issue ID: 15655
Category: (No Category)
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-07-15 13:42 EDT
Last Modified: 2015-07-15 13:42 EDT
==
Summary:file(GENERATE) fails of the destination directory
doesn't exist
Description:
I wanted to use file(GENERATE) to create some files in an output build
directory, but these directories don't exist at the time of configure and build
so the command fails. These directories are created during build, though so
CMake knows about them somehow.
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
file(GENERATE OUTPUT ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$CONFIG/test.out
CONTENT Hello, world)
file(WRITE a.cpp int main() { return 0; })
add_executable(a a.cpp)
==
Issue History
Date ModifiedUsername FieldChange
==
2015-07-15 13:42 James Bigler 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] [CMake 0015652]: get_target_property() called with non-existent target boost_chrono-mt-shared
The following issue has been DELETED. == Reported By:Mathieu Malaterre Assigned To: == Project:CMake Issue ID: 15652 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-15 08:28 EDT Last Modified: 2015-07-15 08:28 EDT == Summary:get_target_property() called with non-existent target boost_chrono-mt-shared Description: I cannot use FindBoost.cmake on CentOS6 (boost 1.41), it fails with: CMake Error at /usr/lib64/boost/BoostConfig.cmake:64 (get_target_property): get_target_property() called with non-existent target boost_chrono-mt-shared. Call Stack (most recent call first): /opt/tools/cmake-3.0.1/share/cmake-3.0/Modules/FindBoost.cmake:206 (find_package) CMakeLists.txt:33 (find_package) CMake Error at /usr/lib64/boost/BoostConfig.cmake:72 (get_target_property): get_target_property() called with non-existent target boost_chrono-mt-shared-debug. Call Stack (most recent call first): /opt/tools/cmake-3.0.1/share/cmake-3.0/Modules/FindBoost.cmake:206 (find_package) CMakeLists.txt:33 (find_package) Boost 1.41 found. == Issue History Date ModifiedUsername FieldChange == 2015-07-15 08:28 Mathieu MalaterreNew Issue 2015-07-15 08:30 Mathieu MalaterreIssue Deleted: 0015652 == -- 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 0015654]: Need generator expression CONFIG that works for both multi-config and single config generators
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15654
==
Reported By:James Bigler
Assigned To:
==
Project:CMake
Issue ID: 15654
Category: CMake
Reproducibility:N/A
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2015-07-15 13:35 EDT
Last Modified: 2015-07-15 13:35 EDT
==
Summary:Need generator expression CONFIG that works for both
multi-config and single config generators
Description:
The value of $CONFIG works just fine for generators like Visual Studio (e.g.
Debug, RelWithDebInfo), but for generators like Makefiles it maps to
CMAKE_BUILD_TYPE, which is less useful for doing stuff like this:
file(GENERATE ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$CONFIG/myfile)
This will do the right thing for VS, but not for Makefile. It would be helpful
to have such a value that could make this work.
==
Issue History
Date ModifiedUsername FieldChange
==
2015-07-15 13:35 James Bigler 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] [CMake 0015652]: get_target_property() called with non-existent target boost_chrono-mt-shared
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15652 == Reported By:Mathieu Malaterre Assigned To: == Project:CMake Issue ID: 15652 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-15 08:28 EDT Last Modified: 2015-07-15 08:28 EDT == Summary:get_target_property() called with non-existent target boost_chrono-mt-shared Description: I cannot use FindBoost.cmake on CentOS6 (boost 1.41), it fails with: CMake Error at /usr/lib64/boost/BoostConfig.cmake:64 (get_target_property): get_target_property() called with non-existent target boost_chrono-mt-shared. Call Stack (most recent call first): /opt/tools/cmake-3.0.1/share/cmake-3.0/Modules/FindBoost.cmake:206 (find_package) CMakeLists.txt:33 (find_package) CMake Error at /usr/lib64/boost/BoostConfig.cmake:72 (get_target_property): get_target_property() called with non-existent target boost_chrono-mt-shared-debug. Call Stack (most recent call first): /opt/tools/cmake-3.0.1/share/cmake-3.0/Modules/FindBoost.cmake:206 (find_package) CMakeLists.txt:33 (find_package) Boost 1.41 found. == Issue History Date ModifiedUsername FieldChange == 2015-07-15 08:28 Mathieu MalaterreNew 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] [CMake 0015649]: Add cmake -E date [format] [UTC] command to output the current date in the same way STRING(TIMESTAMP [format] [UTC]) does.
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15649 == Reported By:dbanet Assigned To: == Project:CMake Issue ID: 15649 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2015-07-14 03:24 EDT Last Modified: 2015-07-14 03:24 EDT == Summary:Add cmake -E date [format] [UTC] command to output the current date in the same way STRING(TIMESTAMP [format] [UTC]) does. Description: It would be extremely useful to have a cross-platform way to obtain the date just like with STRING(TIMESTAMP [format] [UTC]) in CMake command mode. == Issue History Date ModifiedUsername FieldChange == 2015-07-14 03:24 dbanet 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] [CMake 0015650]: Linking large files on OS X can result in linker failing with command line too long error
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15650
==
Reported By:Abigail
Assigned To:
==
Project:CMake
Issue ID: 15650
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2015-07-14 07:07 EDT
Last Modified: 2015-07-14 07:07 EDT
==
Summary:Linking large files on OS X can result in linker
failing with command line too long error
Description:
When a project contains sufficiently many source files - the one I'm compiling
has 1689 .cpp files - the linker will fail, with the message Error running link
command: Argument list too long.
When using response lists (via set(CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS 1)),
the issue still occurs. This is because the response file is specified as a
linker flag with @ResponseFile.rsp syntax, which is expanded by the compiler
driver rather than being passed through and then expanded internally by the
linker.
OS X's linker, ld64, doesn't support the @ResponseFile.rsp syntax, so it's not
possible to work around this with set(CMAKE_CXX_RESPONSE_FILE_LINK_FLAG
-Wl,@). However, it does support -filelist, but this requires the file to be
newline-separated rather than space-separated.
Steps to Reproduce:
In an empty directory:
for i in {..}; echo void f$i() {} $i.c
find . files.txt
cat EOF CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(long_file_test)
file(STRINGS files.txt files)
add_executable(long_file_test ${files})
EOF
cmake . cmake --build . -- -j 24
...This will compile everything correctly, and then at the end emit:
[100%] Linking C executable long_file_test
Error running link command: Argument list too long
make[2]: *** [long_file_test] Error 2
make[1]: *** [CMakeFiles/long_file_test.dir/all] Error 2
make: *** [all] Error 2
==
Issue History
Date ModifiedUsername FieldChange
==
2015-07-14 07:07 AbigailNew 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] [CMake 0015651]: Missing information in documentation about creation OS X/iOS Frameworks
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15651 == Reported By:gang65 Assigned To: == Project:CMake Issue ID: 15651 Category: Documentation Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-07-14 07:22 EDT Last Modified: 2015-07-14 07:22 EDT == Summary:Missing information in documentation about creation OS X/iOS Frameworks Description: The Cmake documentation is not updated with information about how to create OS X Frameworks: http://www.cmake.org/cmake/help/v3.2/command/set_target_properties.html More information about Frameworks: https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html#//apple_ref/doc/uid/20002253-BAJEJJAB It is possible to create OS X and iOS Framework with following CMake code: set_target_properties(ReflectionIOS PROPERTIES OUTPUT_NAME Reflection FRAMEWORK TRUE FRAMEWORK_VERSION A PUBLIC_HEADER REFLECTION_INCLUDE_FILES ) Could you please update documentation: http://www.cmake.org/cmake/help/v3.2/command/set_target_properties.html Thanks. == Issue History Date ModifiedUsername FieldChange == 2015-07-14 07:22 gang65 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] [CMake 0015648]: FindXercesC.cmake does not work on Windows
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15648 == Reported By:Martin Baute Assigned To: == Project:CMake Issue ID: 15648 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-13 04:38 EDT Last Modified: 2015-07-13 04:38 EDT == Summary:FindXercesC.cmake does not work on Windows Description: The FindXercesC module shipping with CMake is rather simple. It looks for the Xerces-C library using this line: find_library( XercesC_LIBRARY xerces-c DOC Xerces-C++ libraries ) This does not work on Windows -- here, the Xerces-C library is named xerces-c_3.lib (or ...-c_3D.lib for the debug build), making FindXercesC.cmake fail with XercesC_LIBRARY-NOTFOUND. Suggested fix would be using this line: find_library( XercesC_LIBRARY NAMES xerces-c xerces-c_3 xerces-c_2 DOC Xerces-C++ libraries ) == Issue History Date ModifiedUsername FieldChange == 2015-07-13 04:38 Martin Baute 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] [CMake 0015647]: automoc is not run on some files with lots of targets in a CMakeLists.txt
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15647
==
Reported By:Friedrich
Assigned To:
==
Project:CMake
Issue ID: 15647
Category: CMake
Reproducibility:have not tried
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2015-07-11 15:59 EDT
Last Modified: 2015-07-11 15:59 EDT
==
Summary:automoc is not run on some files with lots of
targets in a CMakeLists.txt
Description:
CMake at least in the versions 3.1.3-3.2.3 for some not yet known reasons fails
to run automoc on random targets if there are a lot of targets in a file. It's
random as in, changing target names has an effect on with which files of which
target automoc fails to be run (e.g. appending another letter to the name
suddenly makes it work, just to fail on files of another target, and then the
game restarts).
With 3.3.0-rc2 the problem was not seen.
Steps to Reproduce:
(Sorry, had no time to create a small example)
The problem can be seen in the build of the KDE project Calligra in the
frameworks branch. The CMakeLists.txt file where things are screwed up is
krita/image/tests/CMakeLists.txt,
http://quickgit.kde.org/?p=calligra.gita=blobh=c0f2c77373fb1b624296d27e66c2deb3c86b6c07hb=0629fef375cfc5520cab57a3920e88fe84526c94f=krita%2Fimage%2Ftests%2FCMakeLists.txt
It's enough to build the Krita part of Calligra to trigger this:
# get Calligra sources, use frameworks branch
# (sadly no way known to directly get a tarball with a snapshot)
git clone git://anongit.kde.org/calligra.git
cd calligra; git checkout frameworks; cd ..
Use an texteditor of your choice and remove the cmake version check at the
beging of krita/image/tests/CMakeLists.txt. Then go on:
# create build dir and run cmake, reduce to just building krita (+ internal
deps)
mkdir build; cd build
cmake ../calligra -DBUILD_TESTING=ON -DPRODUCTSET=KRITA
If at the end of the configure log you see
-- -- The following product(set)s/features will be built -
-- KRITA: Full Krita
we are good to finally test the problem.
cd krita/image/tests/
make
And now wait for the build to fail, it should be something like
CMakeFiles/KisAsyncMergerTest.dir/kis_async_merger_test.cpp.o: In function
`KisAsyncMergerTest::KisAsyncMergerTest()':
/home/jenkins/builds/calligra/kf5-
qt5/krita/image/tests/kis_async_merger_test.h:24: undefined reference to
`vtable for KisAsyncMergerTest'
CMakeFiles/KisAsyncMergerTest.dir/kis_async_merger_test.cpp.o: In function
`KisAsyncMergerTest::~KisAsyncMergerTest()':
/home/jenkins/builds/calligra/kf5-
qt5/krita/image/tests/kis_async_merger_test.h:24: undefined reference to
`vtable for KisAsyncMergerTest'
collect2: error: ld returned 1 exit status
krita/image/tests/CMakeFiles/KisAsyncMergerTest.dir/build.make:89: recipe for
target 'krita/image/tests/KisAsyncMergerTest' failed
Give kis_async_merger_test.{h,cpp} a good look, but it seems fine, Q_OBJECT
exists and whatever is needed that should trigger automoc (and does for all the
other files around and with other cmake versions).
Now in krita/image/tests/CMakeLists.txt change the target name
KisAsyncMergerTest to e.g. KisAsyncMergerTestA and rerun the build.
Suddenly automoc is run on kis_async_merger_test.h... only to fail on the
next.
Additional Information:
See https://mail.kde.org/pipermail/kde-buildsystem/2015-June/010819.html for
related short discussion.
==
Issue History
Date ModifiedUsername FieldChange
==
2015-07-11 15:59 Friedrich 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] [CMake 0015644]: AUTORCC not generating files
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15644 == Reported By:Lectem Assigned To: == Project:CMake Issue ID: 15644 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-09 08:08 EDT Last Modified: 2015-07-09 08:08 EDT == Summary:AUTORCC not generating files Description: AUTORCC is not generating the qrc_*.cpp files, rcc isn't even called. I suspect the problem coming from the fact that I'm getting an error while configuring the project : /usr/lib/x86_64-linux-gnu/qt5/bin/rcc: Unknown option: '--list' It is coming from this line : https://github.com/Kitware/CMake/blob/master/Source/cmQtAutoGenerators.cxx#L193 I don't understand what the script is trying to do since --list isn't available for qt4 nor qt5. The resources are present, with the correct path. It is working when using QT5_ADD_RESOURCES. Additional Information: CMakeLists.txt : set(CMAKE_INCLUDE_CURRENT_DIR ON) set(CMAKE_AUTOMOC ON) set(CMAKE_AUTORCC ON) set(CMAKE_AUTOUIC ON) find_package(Qt5Core REQUIRED) find_package(Qt5Widgets REQUIRED) find_package(Qt5LinguistTools REQUIRED) find_package(Qt5Multimedia REQUIRED) add_executable(myexe main.cpp resource_file.qrc) resource_file.qrc : !DOCTYPE RCCRCC version=1.0 qresource fileimages/copy.png/file fileimages/cut.png/file fileimages/new.png/file fileimages/open.png/file fileimages/paste.png/file fileimages/save.png/file /qresource /RCC == Issue History Date ModifiedUsername FieldChange == 2015-07-09 08:08 Lectem 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] [CMake 0015642]: ClCompile Include empty if case of drive letter changes
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15642 == Reported By:Martin Sander Assigned To: == Project:CMake Issue ID: 15642 Category: (No Category) Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-07-08 10:13 EDT Last Modified: 2015-07-08 10:13 EDT == Summary:ClCompile Include empty if case of drive letter changes Description: If cmake is used within cmd.exe and a dependency in add_custom_command(...) has an upper case drive letter and this files occurs otherwise with a lower case drive letter, all ClCompile Include tags refererring to the containing directory are empty. The difference is produced with Archive.zip:cmakeBugHunting/build/ttt.bat and visible in Archive.zip:diff.png == Issue History Date ModifiedUsername FieldChange == 2015-07-08 10:13 Martin Sander New Issue 2015-07-08 10:13 Martin Sander File Added: Archive.zip == -- 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 0015641]: In CMake 3.3.0-rc3 macro CHECK_CXX_COMPILER_FLAG is broken on OSX for some flags
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15641 == Reported By:Nikolay Zapolnov Assigned To: == Project:CMake Issue ID: 15641 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-07-08 09:27 EDT Last Modified: 2015-07-08 09:27 EDT == Summary:In CMake 3.3.0-rc3 macro CHECK_CXX_COMPILER_FLAG is broken on OSX for some flags Description: In CMake 3.2.3 the CHECK_CXX_COMPILER_FLAG macro launches compiler and then linker. But tested flag is passed *only* to the compiler and test passes. But in CMake 3.3.0-rc3 argument is passed to *both* the compiler and the linker. This causes an error for some flags, for example for '-x objective-c++'. Passing this flag to the linker makes it recognize .o files as objective-c++ sources and fail. Steps to Reproduce: Use the following CMakeLists.txt INCLUDE(CheckCXXCompilerFlag) CHECK_CXX_COMPILER_FLAG(-x objective-c++ HAVE_OBJC) This will work correctly in CMake 3.2.3 but in CMake 3.3.0-rc3 HAVE_OBJC will be always false. Additional Information: Part of CMakeOutput.log for good case and part of CMakeError.log for broken case are attached to the ticket. == Issue History Date ModifiedUsername FieldChange == 2015-07-08 09:27 Nikolay ZapolnovNew Issue 2015-07-08 09:27 Nikolay ZapolnovFile Added: good-cmake322.log == -- 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 0015640]: CMake converts generator from Visual Studio 9 2008 to Visual Studio 10 2010 if ZERO_CHECK fails
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15640 == Reported By:James Johnston Assigned To: == Project:CMake Issue ID: 15640 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-07-07 11:04 EDT Last Modified: 2015-07-07 11:04 EDT == Summary:CMake converts generator from Visual Studio 9 2008 to Visual Studio 10 2010 if ZERO_CHECK fails Description: When using CMake with the Visual Studio 9 2008 generator, if the ZERO_CHECK project fails (e.g. due to a FATAL_ERROR or whatever in the CMakeLists.txt file), the entire CMake project is converted to Visual Studio 10 2010! Since the build tree is now in who-knows-what corrupted state, I have no choice but to delete the whole build tree and start over. It's quite time-consuming. The issue doesn't seem to be easily reproduced outside of the ZERO_CHECK project - e.g. I couldn't figure out how to reproduce it with cmake-gui.exe or cmake.exe. Steps to Reproduce: 1. Make a new source tree with the following CMakeLists.txt file: cmake_minimum_required(VERSION 3.3.0 FATAL_ERROR) project(TestProject) #message(FATAL_ERROR Error) 2. Create empty build tree directory as normal, cd to it, and run: cmake -GVisual Studio 9 2008 path to source tree 3. Open the generated Visual Studio solution in Visual C++ 2008. (I used Express version). 4. Edit the CMakeLists.txt and remove the comment on message so that the CMake configure will fail now. 5. Build the ZERO_CHECK project; note that it fails as expected. 6. Remark out the message from CMakeLists.txt so that CMake once again will configure ok. 7. Build the ZERO_CHECK project again. This time, ZERO_CHECK will convert everything over to Visual Studio 2010: * The CMake output shown in Visual Studio Output pane says Building for Visual Studio 10 2010. * The CMakeCache.txt holds: CMAKE_GENERATOR:INTERNAL=Visual Studio 10 2010 * Visual Studio 2008 refuses to reload the solution (created by a newer version of this application and cannot be opened) * Examination of the build tree shows a VS2010 solution and VCPROJ/VCXPROJ files side-by-side... Additional Information: The problem has been successfully reproduced with both CMake 3.3.0-rc1 and the nightly cmake-3.3.20150706-g32b76-win32-x86 build. == Issue History Date ModifiedUsername FieldChange == 2015-07-07 11:04 James Johnston 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] [CMake 0015639]: [Feature Request] Generate one VS solution for several toolsets and architectures
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15639 == Reported By:KindDragon Assigned To: == Project:CMake Issue ID: 15639 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-05 11:24 EDT Last Modified: 2015-07-05 11:24 EDT == Summary:[Feature Request] Generate one VS solution for several toolsets and architectures Description: I want generate one Visual Studio 14 2015 solution for several toolsets (VS2012, VS2013, VS2015) and several architectures (Win32, x64) == Issue History Date ModifiedUsername FieldChange == 2015-07-05 11:24 KindDragon 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] [CMake 0015638]: interface libraries and --graphviz
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15638 == Reported By:tim blechmann Assigned To: == Project:CMake Issue ID: 15638 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-04 08:39 EDT Last Modified: 2015-07-04 08:39 EDT == Summary:interface libraries and --graphviz Description: currently interface libraries are not taken into account when visualising the dependencies via --graphviz Steps to Reproduce: consider the following project: --- project(foo) add_library( a STATIC a.cpp ) add_library( b_interface INTERFACE ) target_link_libraries( b_interface INTERFACE a) add_library( b STATIC b.cpp ) target_link_libraries( b PUBLIC b_interface ) --- expected behaviour: edge between a and b actual behaviour: no edge between a and b == Issue History Date ModifiedUsername FieldChange == 2015-07-04 08:39 tim blechmann 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] [CMake 0015637]: Consider escaping all utf8 chars in XML test output
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15637 == Reported By:Zach Mullen Assigned To: == Project:CMake Issue ID: 15637 Category: CTest Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-01 10:32 EDT Last Modified: 2015-07-01 10:32 EDT == Summary:Consider escaping all utf8 chars in XML test output Description: Right now, any characters we deem non-printable are escaped in a non-standard way, e.g.: [NON-XML-CHAR-0x1B] Instead of the standard NCR escaping: #x1B. I propose that we change to using NCR escaping to provide more portable XML and let CDash (or other consumers of the XML) decide how to render those characters. For instance, my personal use case involves terminal control characters -- services like travis render colors and styles in the web UI just as they would appear in a terminal, and it would be nice to enable CDash to do the same thing without having to look for our nonstandard string. == Issue History Date ModifiedUsername FieldChange == 2015-07-01 10:32 Zach MullenNew 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] [CMake 0015634]: Support for pkgconfig --define-variable
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15634 == Reported By:Heinrich Fink Assigned To: == Project:CMake Issue ID: 15634 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-29 09:13 EDT Last Modified: 2015-06-29 09:13 EDT == Summary:Support for pkgconfig --define-variable Description: It is often necessary to re-define the prefix variable of pkgconfig scripts to adapt to different compilation environments. This is usually done via pkg-config --define-variable=prefix=/my/dev/root/libs. Unfortunately this workflow is not support by CMake scripts that use pkgconfig. A simple option to define additional agurments for pkg-config when invoked would be helpful already. Manually redefining the pkg-config executable path, to already contain the additional argument, wouldn't work. == Issue History Date ModifiedUsername FieldChange == 2015-06-29 09:13 Heinrich Fink 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] [CMake 0015636]: alias libraries and and --graphviz
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15636 == Reported By:tim blechmann Assigned To: == Project:CMake Issue ID: 15636 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-30 00:54 EDT Last Modified: 2015-06-30 00:54 EDT == Summary:alias libraries and and --graphviz Description: when alias libraries are used, the dot files treat original and aliased library as different targets. therefore the dependencies are not visualised. this issue is somehow related to http://www.cmake.org/Bug/view.php?id=13809, which is about add_dependency. Steps to Reproduce: add_library(foo) add_library(bar ALIAS foo) add_executable(baz) target_link_libraries(baz bar) expected behaviour: baz should visualise a dependency to foo. instead foo it shows a dependency to bar. == Issue History Date ModifiedUsername FieldChange == 2015-06-30 00:54 tim blechmann 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] [CMake 0015633]: Library not found when invoke find_library again
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15633 == Reported By:Gustavo Melno Assigned To: == Project:CMake Issue ID: 15633 Category: CMake Reproducibility:always Severity: tweak Priority: normal Status: new == Date Submitted: 2015-06-26 16:41 EDT Last Modified: 2015-06-26 16:41 EDT == Summary:Library not found when invoke find_library again Description: I do a library search for my project: find_library( ICU_LIBRARY NAMES icuuc cygicuuc cygicuuc32 DOC Libraries to link against for the common parts of ICU) if(ICU_INCLUDE_DIR AND ICU_LIBRARY) set(ICU_FOUND 1) else() set(ICU_FOUND) endif() This works for the first time but another call to cmake or a change in any CMakeLists.txt file will unset ICU_FOUND. == Issue History Date ModifiedUsername FieldChange == 2015-06-26 16:41 Gustavo Melno 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] [CMake 0015632]: There are 2 modules with the same some: CheckIncludeFile and CheckIncludeFiles
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15632 == Reported By:ycollet Assigned To: == Project:CMake Issue ID: 15632 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-25 08:30 EDT Last Modified: 2015-06-25 08:30 EDT == Summary:There are 2 modules with the same some: CheckIncludeFile and CheckIncludeFiles Description: There are 2 modules with the same some: CheckIncludeFile and CheckIncludeFiles Both have the same come except for the variable names. Should one should be remove ? == Issue History Date ModifiedUsername FieldChange == 2015-06-25 08:30 ycolletNew 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] [CMake 0015631]: CMAKE_PREFIX_PATH missing documentation for multiple paths list separator
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15631 == Reported By:trsystran Assigned To: == Project:CMake Issue ID: 15631 Category: Documentation Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-25 05:34 EDT Last Modified: 2015-06-25 05:34 EDT == Summary:CMAKE_PREFIX_PATH missing documentation for multiple paths list separator Description: http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_PREFIX_PATH.html This doesn't even mention the fact that it accepts multiple paths. In practice it requires a cmake list, ie ; as separator. This is not documented here. Same for CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH, CMAKE_PROGRAM_PATH. http://www.cmake.org/cmake/help/v3.2/command/find_path.html other hints that CMAKE_PREFIX_PATH is a list, but not for the others. http://www.cmake.org/Wiki/CMake_Useful_Variables#Environment_Variables is the only one documenting that they are lists, and that others than PREFIX are platform dependent lists (linux: with :), which hints that CMAKE_PREFIX_PATH is a cmake list with ;. == Issue History Date ModifiedUsername FieldChange == 2015-06-25 05:34 trsystran 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] [CMake 0015630]: ENABLE_EXPORTS value is not used for gcc makefile -rdynamic option
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15630 == Reported By:Nicolas Deherly Assigned To: == Project:CMake Issue ID: 15630 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-24 04:32 EDT Last Modified: 2015-06-24 04:32 EDT == Summary:ENABLE_EXPORTS value is not used for gcc makefile -rdynamic option Description: Whatever is the value of ENABLE_EXPORTS, executable are linked with the -rdynamic option. I have to reset the __linux_compiler_gnu macro to link without -rdynamic parameter. Additional Information: This bug has already been opened (9985). == Issue History Date ModifiedUsername FieldChange == 2015-06-24 04:32 Nicolas DeherlyNew 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] [CMake 0015626]: 3.3-rc2 segfault (regression)
The following issue has been SUBMITTED.
==
https://public.kitware.com/Bug/view.php?id=15626
==
Reported By:Andrew Fuller
Assigned To:
==
Project:CMake
Issue ID: 15626
Category: CMake
Reproducibility:always
Severity: crash
Priority: high
Status: new
==
Date Submitted: 2015-06-23 13:49 EDT
Last Modified: 2015-06-23 13:49 EDT
==
Summary:3.3-rc2 segfault (regression)
Description:
Manipulating a target that was first created in a different directory branch
causes a segfault.
Steps to Reproduce:
1. Create the following CMake files:
$ tree
.
├── CMakeLists.txt
├── dirA
│ └── CMakeLists.txt
└── dirB
└── CMakeLists.txt
$ cat CMakeLists.txt
add_subdirectory( dirA )
add_subdirectory( dirB )
$ cat dirA/CMakeLists.txt
add_library( foo INTERFACE )
$ cat dirB/CMakeLists.txt
target_link_libraries( foo INTERFACE ${CMAKE_DL_LIBS} )
2. Configure
$ mkdir build cd build cmake ..
[...]
[1]6691 segmentation fault (core dumped) cmake ..
Additional Information:
This works fine with CMake 3.2.1.
==
Issue History
Date ModifiedUsername FieldChange
==
2015-06-23 13:49 Andrew Fuller 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] [CMake 0015628]: CMake needs to request root privileges in order to install command-line tools
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15628 == Reported By:Guy Harris Assigned To: == Project:CMake Issue ID: 15628 Category: CMake Reproducibility:N/A Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-23 17:52 EDT Last Modified: 2015-06-23 17:52 EDT == Summary:CMake needs to request root privileges in order to install command-line tools Description: Even if you try to install them in /usr/local/bin (which should be the case in *all* versions of OS X, and really needs to be the case in 10.11, as per the other issue I filed), you need root privileges to do so, and CMake doesn't do anything to install the symlinks as root. Steps to Reproduce: 1. Start CMake. 2. Select Install For Command Line Use from the Tools menu. 3. Fix it to install in /usr/local/bin rather than /usr/bin. 4. Click Install Command Line Links. 5. Notice the lack of any prompt for your password, as would be required if it were requesting root privileges (and you hadn't done so in the last few minutes). 6. Notice the set of Failed create symlink installation may be incomplete: /usr/local/bin/... messages. == Issue History Date ModifiedUsername FieldChange == 2015-06-23 17:52 Guy Harris 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] [CMake 0015629]: A way to install the command-line tool links from the command line would be useful
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15629 == Reported By:Guy Harris Assigned To: == Project:CMake Issue ID: 15629 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2015-06-23 17:56 EDT Last Modified: 2015-06-23 17:56 EDT == Summary:A way to install the command-line tool links from the command line would be useful Description: Now that you no longer have an installer package for OS X, the command-line tools have to be installed by running CMake through the GUI. For Wireshark, we have a script for OS X to install stuff for building Wireshark from source. That script downloads and installs CMake, which isn't *required* yet but is *supported* (and may eventually become the default or only tool for building). It'd be nice if it could run some program to install the command-line tools. (Wireshark also has command-line tools, but that's one of the reasons we *don't* do drag-install. The other is that we also install a launchd launch daemon to make it possible to capture traffic without root privileges.) == Issue History Date ModifiedUsername FieldChange == 2015-06-23 17:56 Guy Harris 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] [CMake 0015625]: Fix a typo in cmake-buildsystem(7) manual : Add missing INTERFACE_INCLUDE_DIRECTORIES
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15625 == Reported By:Erik Sjölund Assigned To: == Project:CMake Issue ID: 15625 Category: Documentation Reproducibility:N/A Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-20 03:00 EDT Last Modified: 2015-06-20 03:00 EDT == Summary:Fix a typo in cmake-buildsystem(7) manual : Add missing INTERFACE_INCLUDE_DIRECTORIES Description: The property name INTERFACE_INCLUDE_DIRECTORIES is missing from a set_property command in the manual http://www.cmake.org/cmake/help/v3.3/manual/cmake-buildsystem.7.html A patch was uploaded together with this bug report. == Issue History Date ModifiedUsername FieldChange == 2015-06-20 03:00 Erik Sjölund New Issue 2015-06-20 03:00 Erik Sjölund File Added: patch.txt == -- 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 0015624]: CMake Error: Could not find cmake module file: CMakeDetermineLANGUAGECompiler.cmake
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15624 == Reported By:Micha Renner Assigned To: == Project:CMake Issue ID: 15624 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-06-19 07:10 EDT Last Modified: 2015-06-19 07:10 EDT == Summary:CMake Error: Could not find cmake module file: CMakeDetermineLANGUAGECompiler.cmake Description: Also CMake 3.3.0.rc1 It seems, that the file does not exists. Steps to Reproduce: PROJECT(tm LANGUAGE C) == Issue History Date ModifiedUsername FieldChange == 2015-06-19 07:10 Micha Renner 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] [CMake 0015623]: Raspbian puts some system libraries in /usr/lib/arm-linux-gnueabihf which CMake doesn't search
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15623 == Reported By:Eric Wing Assigned To: == Project:CMake Issue ID: 15623 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-18 09:04 EDT Last Modified: 2015-06-18 09:04 EDT == Summary:Raspbian puts some system libraries in /usr/lib/arm-linux-gnueabihf which CMake doesn't search Description: Raspbian, which is a streamlined offshoot of Debian for Raspberry Pi, puts a lot of system libraries in /usr/lib/arm-linux-gnueabihf, which CMake doesn't search for by default. Some popular libraries include libpng, libjpeg, libcurl, openal, sdl, avahi, freetype, and a lot more. When trying to build on a Raspberry Pi (not cross-compiling), CMake couldn't find and link a lot of common libraries. Since Raspbian is essentially just another Linux distro and probably shouldn't be an entirely different platform, the easiest fix seems to be to add /usr/lib/arm-linux-gnueabihf to CMAKE_SYSTEM_LIBRARY_PATH CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES in Modules/Platform/UnixPaths.cmake Steps to Reproduce: I think I originally triggered this by trying to FIND_PACKAGE(OpenAL) on Raspbian. == Issue History Date ModifiedUsername FieldChange == 2015-06-18 09:04 Eric Wing 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] [CMake 0015622]: Add support for 64-bit Visual Studio Toolchains
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15622 == Reported By:Paul TBBle Hampson Assigned To: == Project:CMake Issue ID: 15622 Category: CCMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2015-06-17 22:39 EDT Last Modified: 2015-06-17 22:39 EDT == Summary:Add support for 64-bit Visual Studio Toolchains Description: Visual Studio 2013 onwards have added a property to MSBuild PreferredToolArchitecture which can be set to x64 to use the 64-bit compiler toolchain. This toolchain can produce all the same output targets: Win32, x64 and ARM; as the default (32-bit) compiler toolchain can. It'd be great if this was supported somehow in CMake. Now that we have the -A flag for output architecture from the Visual Studio generators, this might be a duplicated set of generators, which only support -A for output architecture support. If there is an appropriate CMAKE property, that'd work too. Ideally, we could flag off CMAKE_SYSTEM_PROCESSOR and CMAKE_HOST_SYSTEM_PROCESSOR to control this sort of cross-compiler behaviour, except that would: (a) introduce a behaviour change for existing projects (hence perhaps a Visual Studio generator-specific policy); and (b) require fixing CMAKE_SYSTEM_PROCESSOR, see issue http://www.cmake.org/Bug/view.php?id=15170 PreferredToolArchitecture is safe to set to x64 on 32-bit platforms, as the VS2013 MSBuild scripts detect when the build is run on a 32-bit host or without the 64-bit toolset installed, and (silently) fall back to the 32-bit toolset. As a workaround, PreferredToolArchitecture can be set as an environment variable, in case anyone finds this feature request and doesn't want to wait for implementation. Additional Information: MSBuild documentation at https://msdn.microsoft.com/en-us/library/dd293607(v=vs.120).aspx shows this flag for VS2013 and VS2015 RC. In VS2010 and VS2012, you could set the property _IsNativeEnvironment to true to use the 64-bit toolchain. This was not formally documented on MSDN, but in various blog posts. Anecdotally, it didn't support cross-compiling 32-bit or ARM targets from the 64-bit toolchain. The _IsNativeEnvironment property is actually an internal property for the MSBuild C++ targets, but you must set it manually in pre-VS2013 because the IDE is always 32-bit and always provides the PROCESSOR_ARCHITECTURE environment variable as x86. The actual intent of the toolchain code was to detect and enable _IsNativeEnvironment when running from a 64-bit environment, as seen in this snippet: _IsNativeEnvironment Condition='$(PROCESSOR_ARCHITECTURE)' == 'AMD64' and '$(Platform)' == 'X64'true/_IsNativeEnvironment _IsNativeEnvironment Condition='$(PROCESSOR_ARCHITECTURE)' == 'IA64' and '$(Platform)' == 'Itanium'true/_IsNativeEnvironment See https://social.msdn.microsoft.com/Forums/en-US/d6b352ea-12b6-4867-b86d-a052fbab1da4/how-can-switch-to-native-x64-compiler-to-compile-x64-program for discussion. This logic is still present in VS2013, but the PreferredToolArchitecture presents the user-selectable interface. VS2013 attempts to honour the _IsNativeEnvironment property and set PreferredToolArchitecture to match, but apparently that doesn't work, see https://connect.microsoft.com/VisualStudio/feedback/details/800059/isnativeenvironment-true-no-longer-works-on-visual-studio-2013-rc A request for this appeared on Stack Overflow at http://stackoverflow.com/questions/23186620/use-native-64bit-toolset-in-visual-studio-2013 and a CMake mailing list request for a workaround at http://www.cmake.org/pipermail/cmake/2014-February/057045.html == Issue History Date ModifiedUsername FieldChange == 2015-06-17 22:39 Paul TBBle HampsonNew 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:
[cmake-developers] [CMake 0015621]: CMAKE_GENERATOR_PLATFORM references toolset instead of platform
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15621 == Reported By:Paul TBBle Hampson Assigned To: == Project:CMake Issue ID: 15621 Category: Documentation Reproducibility:N/A Severity: tweak Priority: low Status: new == Date Submitted: 2015-06-17 21:29 EDT Last Modified: 2015-06-17 21:29 EDT == Summary:CMAKE_GENERATOR_PLATFORM references toolset instead of platform Description: The help for CMAKE_GENERATOR_PLATFORM says: If the user specifies a toolset name (e.g. via the cmake -A option) the value will be available in this variable. which is clearly a cut-and-paste from CMAKE_GENERATOR_TOOLSET: If the user specifies a toolset name (e.g. via the cmake -T option) the value will be available in this variable. It _should_ say: If the user specifies a platform name (e.g. via the cmake -A option) the value will be available in this variable. i.e. replace 'toolset' with 'platform', to match the variable name and the -A command-line parameter help. See http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_GENERATOR_PLATFORM.html#variable:CMAKE_GENERATOR_PLATFORM == Issue History Date ModifiedUsername FieldChange == 2015-06-17 21:29 Paul TBBle HampsonNew 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] [CMake 0015620]: Ninja generator triggers race condition in Borland bcc32 linker causing intermittent build failure
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15620
==
Reported By:James Johnston
Assigned To:
==
Project:CMake
Issue ID: 15620
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2015-06-17 11:37 EDT
Last Modified: 2015-06-17 11:37 EDT
==
Summary:Ninja generator triggers race condition in Borland
bcc32 linker causing intermittent build failure
Description:
Unfortunately, it appears that the Borland linker utilizes temporary files with
a hard-coded name (e.g. turboc.$ln); these temporary files are written to the
linker's current directory. (Determined via Process Monitor). If two or more
concurrent linkers are run with the same current directory, some of them may
fail as shown below because they will both be trying to use the same temporary
filename.
The Ninja generator, unfortunately seems to keep the current directory to
CMAKE_BINARY_DIR. If the CMake project contains multiple libraries (e.g. VTK
5.4.2, which I tested and has dozens), then it is possible that Ninja will
invoke two concurrent linkers with the same current directory of
CMAKE_BINARY_DIR. They may then conflict with each other - both attempting to
write to a file named ${CMAKE_BINARY_DIR}/turboc.$ln, for example.
To compare, the NMake jom generator runs the linker for each target in a unique
target-specific directory, such that this problem never arises. If the Ninja
generator could also do this, it would work around this issue. (In fact, it
would work around any compiler that happens to write temporary files to its
current directory).
Steps to Reproduce:
My configuration:
* Quad-core hyper-threaded Core i7 CPU
* C++ Builder 5 Update 1
* VTK 5.4.2 (this version still builds under C++ Builder, unlike some newer
versions)
* CMake 3.3.0-rc1 (Kitware-provided binary)
* Ninja 1.5.3, built from source using VC++ 2008 Express
* VTK configured: CMAKE_BUILD_TYPE=RelWithDebInfo, VTK_REMOVE_LEGACY=ON,
BUILD_TESTING=OFF, BUILD_SHARED_LIBS=ON
1. Configure VTK with the above settings. (e.g. to C:\VTK-build)
2. Run ninja to start the build.
3. The build *may* fail if two projects happen to link concurrently. Of
course, it will always succeed if you pass -j 1 to Ninja to only use one CPU
core.
4. Even if you don't immediately experience failure, you can use Sysinternals
Process Monitor from Microsoft to monitor the files being written on your
system. Note that you'll see repeated writes to files like
C:\VTK-build\turboc.$ln.
Additional Information:
While I tested this with C++ Builder 5, the error appears to exist even in the
newest C++ Builder versions:
http://docwiki.embarcadero.com/RADStudio/XE8/en/E2216_Unable_to_create_turboc.$ln_(C%2B%2B)
Sample error when building VTK 5.4.2:
=
[214/2008] Linking CXX shared library bin\vtkDICOMParser.dll Borland C++ 5.5.1
for Win32 Copyright (c) 1993, 2000 Borland Turbo Incremental Link 5.66 Copyright
(c) 1997-2002 Borland
Fatal: No object file or .EXE name was given
Borland Implib Version 3.0.22 Copyright (c) 1991, 2000 Inprise Corporation Error
bin\: unable to open file [215/2008] Linking C shared library bin\vtkzlib.dll
FAILED: cmd.exe /C cd . C:\PROGRA~2\Borland\CBUILD~1\Bin\bcc32.exe -tWR
-tW- -tWD -ebin\vtkzlib.dll -tWM -lS:104857
6 -lSc:4098 -lH:1048576 -lHc:8192 -v import32.lib
Utilities\vtkzlib\CMakeFiles\vtkzlib.dir\adler32.obj snip more OBJ files
implib -c -w bin\vtkzlib.lib bin\vtkzlib.dll cd .
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland Turbo Incremental
Link 5.66 Copyright (c) 1997-2002 Borland
Fatal: Unable to open file 'turboc.$ln'
=
Here is the offending snippet from one of the generated ninja files -
build.ninja:
=
build bin\vtkzlib.dll bin\vtkzlib.lib: C_SHARED_LIBRARY_LINKER__vtkzlib
Utilities\vtkzlib\CMakeFiles\vtkzlib.dir\adler32.obj snip more OBJ files
LANGUAGE_COMPILE_FLAGS = -tWM -Od
LINK_FLAGS = -tWM -lS:1048576 -lSc:4098 -lH:1048576 -lHc:8192 -v
LINK_LIBRARIES = import32.lib
POST_BUILD = cd .
PRE_LINK = cd .
TARGET_FILE = bin\vtkzlib.dll
TARGET_IMPLIB = bin\vtkzlib.lib
TARGET_PDB = vtkzlib.dll.dbg
=
And the corresponding ninja rule:
=
rule C_SHARED_LIBRARY_LINKER__vtkzlib
command = cmd.exe /C $PRE_LINK
[cmake-developers] [CMake 0015618]: HDF5 headers have migrated in linux/debian/sid -- FindHDF5.cmake doesn't detect them
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15618 == Reported By:Sebastian Wouters Assigned To: == Project:CMake Issue ID: 15618 Category: Modules Reproducibility:always Severity: crash Priority: normal Status: new == Date Submitted: 2015-06-16 09:30 EDT Last Modified: 2015-06-16 09:30 EDT == Summary:HDF5 headers have migrated in linux/debian/sid -- FindHDF5.cmake doesn't detect them Description: I got the following comment from someone who's helping me package my code for debian: 4. The include for HDF5 in CheMPS2/include/chemps2/MyHDF5.h is not working for me, there's no /usr/include/hdf5.h (anymore?). If I replace that with '#include hdf5/serial/hdf5.h', it builds fine. I have currently used a work-around to make debuild work for sid: https://github.com/SebWouters/CheMPS2/blob/master/CheMPS2/CMakeLists.txt According to HDF5's specifications, one should include hdf5.h, see section 5 on the page http://www.hdfgroup.org/ftp/HDF5/current/src/unpacked/release_docs/INSTALL In sid's packaged hdf5 version, this file is installed in /usr/include/hdf5/serial/: https://packages.debian.org/sid/amd64/libhdf5-dev/filelist Would it be possible to modify the FindHDF5.cmake so that it detects the hdf5 headers on sid and correctly sets the HDF5_INCLUDE_DIRS variable? Steps to Reproduce: Download and install debian/sid Get cmake, libatlas3-base, libgsl0-dev, and libhdf5-dev with the package manager Download chemps2 commit 226b04dfc07589804fbf7bf2b78b409b08d937eb, or earlier Try to build chemps2 with cmake Additional Information: The discussion at debichem's mailing list: http://lists.alioth.debian.org/pipermail/debichem-devel/2015-June/005963.html == Issue History Date ModifiedUsername FieldChange == 2015-06-16 09:30 Sebastian WoutersNew 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] [CMake 0015619]: ctest stderr vs stdout
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15619
==
Reported By:Clinton Stimpson
Assigned To:
==
Project:CMake
Issue ID: 15619
Category: CTest
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-06-16 18:41 EDT
Last Modified: 2015-06-16 18:41 EDT
==
Summary:ctest stderr vs stdout
Description:
I have a ctest script which basically has:
ctest_start()
...
ctest_build()
ctest_test()
I invoke that script with
ctest -V -S my.ctest 1mytest.stdout 2mytest.stderr
And I'm hoping that mytest.stderr will contain only errors in my script, not
build or test errors from within ctest_build() and ctest_test().
However, errors like
Unable to find executable: /path/to/executable
from ctest_test() can leak into the mytest.stderr if there are build errors.
I don't think that is expected behavior.
Steps to Reproduce:
All in the same directory:
=== CMakeLists.txt ===
include (CTest)
add_test(NAME MyTest COMMAND nonexist_executable)
=== my.ctest ===
set(CTEST_SOURCE_DIRECTORY ${CMAKE_CURRENT_LIST_DIR})
set(CTEST_BINARY_DIRECTORY ${CMAKE_CURRENT_LIST_DIR})
ctest_start(Experimental)
ctest_test()
=== CTestConfig.cmake ===
empty
Then run
cmake .
ctest -V -S my.ctest 1 mytest.stdout 2 mytest.stderr
Look at the output of mytest.stdout and mytest.stderr
Also, mytest.stderr contains:
Error in read script: /home/cjstimp/cubit/cdash/test-ctest/my.ctest
However, the script itself did run successfully.
==
Issue History
Date ModifiedUsername FieldChange
==
2015-06-16 18:41 Clinton StimpsonNew 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] [CMake 0015617]: When assembler is enabled TI Compiler might end up with wrong archiver
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15617 == Reported By:Florian Reinhard Assigned To: == Project:CMake Issue ID: 15617 Category: Modules Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-06-15 08:43 EDT Last Modified: 2015-06-15 08:43 EDT == Summary:When assembler is enabled TI Compiler might end up with wrong archiver Description: If ENABLE(ASM) is used in a TI-Toolchain project and something named ar(.exe) is present in your path, this archiver (ar) will be used and not the TI toolchain's ar6x! Here's why: CMakeDetermineCCompiler.cmake (line 153, [1]) and CMakeDetermineCXXCompiler.cmake have some special code/regex to get the toolchain prefix and suffix. CMakeDetermineASMCompiler.cmake does not contain this code. What happeens? - The ASM Compiler is processed, pre- and suffix are empty. - CMakeFindBinUtils.cmake is processed and CMAKE_AR is filled witht he wrong archiver - Subsequent languages (c/cxx) will not overwrite the wrong CMAKE_AR setting. Steps to Reproduce: I managed to reproduce this easily on multiple machines (all windows): 1. Get a regular archiver named ar in your path. On windows something named ar.exe should do the trick 2. setup a project that uses the TI Toolchain 3. use ENABLE(ASM) in yourproject Additional Information: [1] http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineCCompiler.cmake;h=937aa8c3efe6a83acbc751aee527b7409f68b300;hb=refs/heads/master#l153 == Issue History Date ModifiedUsername FieldChange == 2015-06-15 08:43 Florian ReinhardNew 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] [CMake 0015616]: Configuring for Visual Studio 2015 creates Error
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15616 == Reported By:dkuegler Assigned To: == Project:CMake Issue ID: 15616 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-13 11:32 EDT Last Modified: 2015-06-13 11:32 EDT == Summary:Configuring for Visual Studio 2015 creates Error Description: System: Windows 8.1 Pro (up-to-date) x64 Visual Studio (multiple installations: 2012 Ultimate, 2010 Professional, 2015 RC1) CMAKE 3.2.3 After downloading and selecting VTK 6.2.0 folder, klick Configure and select Visual Studio 2015 x64, default native compiler. multiple Errors are raised: MS VC++ Redist Lib minkernel\crts\ucrt\inc\corecrt_internal_stdio_output.h : 761 : Expression (Unexpected length specifier, false) The same happens for ITK 4.7.1 . This issue might have to be escalated to Microsoft, but since it is directly happening from within CMAKE, I thought I'd start here. Steps to Reproduce: Use a Win8.1 machine install Visual Studio 2015 RC download VTK 6.2.0 run CMake 3.2.3 configure from the VTK 6.2.0 source with a blank Build folder as a compiler select MS Visual Studio 2015 x64. Errors should be thrown ... Additional Information: Workaround: Ignoring seems to be sufficient == Issue History Date ModifiedUsername FieldChange == 2015-06-13 11:32 dkuegler New Issue 2015-06-13 11:32 dkuegler File Added: VTK_CMAKE_Build-Error.PNG == -- 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 0015612]: ninja generator: The command line is too long
The following issue has been SUBMITTED. == http://www.itk.org/Bug/view.php?id=15612 == Reported By:tim blechmann Assigned To: == Project:CMake Issue ID: 15612 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-06-12 06:38 EDT Last Modified: 2015-06-12 06:38 EDT == Summary:ninja generator: The command line is too long Description: i'm adding many POST_BUILD steps via add_custom_command. at one point, ninja builds fail with The command line is too long apparently cmLocalNinjaGenerator::BuildCommandLine simply concatenates various commands viawithout checking, whether the command line is too long. == Issue History Date ModifiedUsername FieldChange == 2015-06-12 06:38 tim blechmann 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] [CMake 0015611]: ExternalProject_Add and find_package commands
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15611 == Reported By:Valerii Kanunik Assigned To: == Project:CMake Issue ID: 15611 Category: CMake Reproducibility:have not tried Severity: feature Priority: normal Status: new == Date Submitted: 2015-06-12 06:35 EDT Last Modified: 2015-06-12 06:35 EDT == Summary:ExternalProject_Add and find_package commands Description: The proposal is to add another step to find_package command. If command can't find package or required version of installed package is different allow find_package command look through the list of targets added by ExternalProject_Add command (or new one special command) and if this library is there perform its download, compile, install and others steps on this (configure) step. Actually the main goal is similar to 0015588 CMake issue. == Issue History Date ModifiedUsername FieldChange == 2015-06-12 06:35 Valerii KanunikNew 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] [CMake 0015613]: Package generated by CPack/PackageMaker display incorrect version with pkgutil
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15613 == Reported By:Xiaoming Wang Assigned To: == Project:CMake Issue ID: 15613 Category: CPack Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-12 15:02 EDT Last Modified: 2015-06-12 15:02 EDT == Summary:Package generated by CPack/PackageMaker display incorrect version with pkgutil Description: CPACK_PACKAGE_VERSION is correctly set in CPackConfig.cmake but when the package is installed on OS X 10.10.x and 10.9.x, etc (doesn't matter which version OS X) pkgutil show the package version is 1.0 which is incorrect. Steps to Reproduce: Just normal cmake/cpack configuration, i.e. CPACK_BINARY_PACKAGEMAKER is ON, CPACK_PACKAGE_VERSION is defined. == Issue History Date ModifiedUsername FieldChange == 2015-06-12 15:02 Xiaoming Wang 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] [CMake 0015614]: add_custom_target/command: Can't give Target the same name as one of the Outputs
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15614
==
Reported By:FlorianM
Assigned To:
==
Project:CMake
Issue ID: 15614
Category: CCMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-06-12 16:03 EDT
Last Modified: 2015-06-12 16:03 EDT
==
Summary:add_custom_target/command: Can't give Target the
same name as one of the Outputs
Description:
Let's say you want to transfer the following makefile into a CMake equivalent:
foo_in: foo.c
$(CC) $ -o $@
foo_out: foo_in
post_process $ $@
And you don't want to add the second step as a post-build step. You still want
to be able to build foo_in or foo_out separately.
Steps to Reproduce:
I'm using the MSYS Makefiles generator with the following test script:
---
cmake_minimum_required(VERSION 2.8)
project(MakeTargetTest C)
file(WRITE foo.c #include windows.h\nint main() {})
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/post_process echo Process something)
add_executable(foo_in foo.c)
set_target_properties(foo_in PROPERTIES SUFFIX )
add_custom_command(
OUTPUT foo_out
COMMAND post_process foo_in foo_out
DEPENDS foo_in
)
add_custom_target(foo_out DEPENDS foo_out)
---
$ make foo_out
Built target foo_out
---
[build.make]
...
CMakeFiles/foo_out:
foo_out: CMakeFiles/foo_out
foo_out: CMakeFiles/foo_out.dir/build.make
.PHONY : foo_out
---
If I rename the custom target to something like foo_out_test it works
correctly:
$ make foo_out_test
Scanning dependencies of target foo_in
[ 50%] Building C object CMakeFiles/foo_in.dir/foo.c.obj
Linking C executable foo_in.
[ 50%] Built target foo_in
[100%] Generating foo_out
[100%] Built target foo_out_test
---
[build.make]
...
CMakeFiles/foo_out_test: foo_out
foo_out: foo_in.
$(CMAKE_COMMAND) -E cmake_progress_report CMakeFiles $(CMAKE_PROGRESS_1)
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --blue --bold
Generating foo_out
post_process foo_in foo_out
foo_out_test: CMakeFiles/foo_out_test
foo_out_test: foo_out
foo_out_test: CMakeFiles/foo_out_test.dir/build.make
.PHONY : foo_out_test
Additional Information:
I understand that the Makefile generator could get confused by dependency that
could be a file and a target dependency, but why should this be possible for
executables and not for custom commands? And why could I not at least get a
warning or error by CMake during generation (since the rule generated is just
empty, see Steps to Reproduce)?
I can see 3 possible solutions:
1. The generator detects that there is a file and a target with the same name
and does add a suffix or prefix to its internal build rules for that file.
2. The add_custom_target() command is extended to allow to define its final
output which is then handled the same way a and add_executable() command output
file.
3. Add an GENERIC (linker) language. So you could use files with any extensions
with add_executable() that are directly given to a definable linker.
==
Issue History
Date ModifiedUsername FieldChange
==
2015-06-12 16:03 FlorianM 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] [CMake 0015615]: ctest --output-on-failure doesn't work
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15615 == Reported By:vinipsmaker Assigned To: == Project:CMake Issue ID: 15615 Category: CTest Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-06-12 22:37 EDT Last Modified: 2015-06-12 22:37 EDT == Summary:ctest --output-on-failure doesn't work Description: According to the documentation[1], the --output-on-failure argument will instruct ctest to show the tests output when they fail. A second approach is to set the env var CTEST_OUTPUT_ON_FAILURE. Neither option work for me. As you can see on appveyor[2], some tests fail, but no output is given. On GNU/Linux, setting the CTEST_OUTPUT_ON_FAILURE does work for me. [1] http://www.cmake.org/cmake/help/v3.3/manual/ctest.1.html [2] https://ci.appveyor.com/project/vinipsmaker/boost-http/build/1.0.63/job/71vy3hxrx9clstju#L1028 == Issue History Date ModifiedUsername FieldChange == 2015-06-12 22:37 vinipsmakerNew 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] [CMake 0015610]: ctest_update can fail without returning -1 as RETURN_VALUE
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15610 == Reported By:trsystran Assigned To: == Project:CMake Issue ID: 15610 Category: CTest Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-11 06:10 EDT Last Modified: 2015-06-11 06:10 EDT == Summary:ctest_update can fail without returning -1 as RETURN_VALUE Description: A ctest_update running git fetch failed: Update command failed: git fetch From the LastUpdate*.log: fetch-err fatal: Unable to create 'E:/repo/.git/refs/remotes/origin/master.lock': File exists. But in the CTest script we check for error: ctest_update(RETURN_VALUE res) if(res LESS 0) # stop if update error ctest_submit(PARTS Notes Update) return() endif() According to the documentation (http://www.cmake.org/cmake/help/v3.2/command/ctest_update.html) ctest_update must return -1 in such case. It didn't. The issue is in Sources/CTest/cmCTestUpdateHandler.cxx:292: return numUpdated; numUpdated is always returned, even in case of update error: the bool update should be used to return -1 == Issue History Date ModifiedUsername FieldChange == 2015-06-11 06:10 trsystran 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] [CMake 0015608]: automoc fails when enabling autorcc
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15608
==
Reported By:Hendrik Sattler
Assigned To:
==
Project:CMake
Issue ID: 15608
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2015-06-11 02:14 EDT
Last Modified: 2015-06-11 02:14 EDT
==
Summary:automoc fails when enabling autorcc
Description:
Automoc does not work after initial cmake run when autorcc is enabled.
I created a small example that shows the problem. I created it from
scratch and it instantly fails for me. I get:
error C3861: 'onTst2': identifier not found (moc_main.cpp)
This file is auto-generated and thus was not updated. - Should not
happen.
I also tried to manually run cmake, it won't help. However, commenting mainx.qrc
helps! Or using qt4_add_resources() and disabling CMAKE_AUTORCC!
Suddenly, the bugtest_automoc target is gone in VS and it compiles
again, even after adding/removing Qt slot functions.
BTW, why is this target called bugtest_automoc and not bugtest_autogen?
The whole thing looks strange as bugtest target still has a
qrc_mainx.cpp.rule but bugtest_automoc also has such a rule.
The bugtest.automoc.rule file properties show no real command:
-
setlocal
cd D:\bugtest\cmake-autogen\build
if %errorlevel% neq 0 goto :cmEnd
D:
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal call :cmErrorLevel %errorlevel% goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd
-
Is that supposed to actually do something?
I am using Visual Studio 2010. CMake is 3.2.2 but also I tried 3.3-rc1.
Steps to Reproduce:
You need to create a foo.png to get the qrc to actually create the
source file (actually 2nd bug that CMake doesn't warn about a missing file).
First run, comment out the onTst2 slot function (both h and cpp file),
it should build.
Then comment it before 2nd run.
Additional Information:
CMakeLists.txt:
--
cmake_minimum_required ( VERSION 3.0.2 )
cmake_policy ( VERSION 3.0.2 )
project ( bugtest CXX )
find_package ( Qt4 )
set ( CMAKE_INCLUDE_CURRENT_DIR ON )
set ( CMAKE_AUTOMOC ON )
set ( CMAKE_AUTORCC ON )
add_executable ( bugtest
main.cpp
mainx.qrc
)
target_link_libraries ( bugtest Qt4::QtCore )
--
main.h:
--
#include QObject
class tst1 : public QObject
{
Q_OBJECT
public slots:
void onTst1();
//void onTst2();
};
--
main.cpp:
--
#include main.h
void tst1::onTst1()
{
}
// void tst1::onTst2()
// {
// }
int main( int argc, char **argv)
{
return 0;
}
--
mainx.qrc:
--
!DOCTYPE RCCRCC version=1.0
qresource
filefoo.png/file
/qresource
/RCC
--
==
Issue History
Date ModifiedUsername FieldChange
==
2015-06-11 02:14 Hendrik SattlerNew 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] [CMake 0015609]: cmake --build path fails with MSBuild
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15609 == Reported By:Hendrik Sattler Assigned To: == Project:CMake Issue ID: 15609 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-11 02:18 EDT Last Modified: 2015-06-11 02:18 EDT == Summary:cmake --build path fails with MSBuild Description: The following fails on Windows7 with Visual Studio 2010. cmake --build build/foo --target doc --config Release Microsoft (R) Build Engine version 4.0.30319.18408 [Microsoft .NET Framework, version 4.0.30319.18444] Copyright (C) Microsoft Corporation. All rights reserved. MSBUILD : error MSB1009: Project file does not exist. Switch: doc.vcxproj Needless to say that the target exists because it works when I run cd build/foo cmake --build . --target doc --config Release == Issue History Date ModifiedUsername FieldChange == 2015-06-11 02:18 Hendrik SattlerNew 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] [CMake 0015607]: Lack of 64bit support (AIX / XL compiler)
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15607
==
Reported By:Martin Baute
Assigned To:
==
Project:CMake
Issue ID: 15607
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-06-10 06:35 EDT
Last Modified: 2015-06-10 06:35 EDT
==
Summary:Lack of 64bit support (AIX / XL compiler)
Description:
On AIX using IBM's XL compiler, the default is for various tools (compiler,
linker, ar, ...) to handle and generate 32bit binaries. To get 64bit binaries,
explicit flags are necessary: -q64 for the compiler during compilation and
linkage, -X64 to 'ar', 'CreateExportList' and probably a couple others I have
forgotten.
As of now, setting these has to be done by the client (including a couple of
tweaks, see Steps to Reproduce). This wouldn't be too bad, except for 64bit
shared libraries.
To export symbols from the lib, the XL-supplied tool CreateExportList needs to
be called with -X64 as well. Looking at Modules/Compiler/XL.cmake:
set(CMAKE_${lang}_CREATE_SHARED_LIBRARY
${CMAKE_XL_CreateExportList} OBJECT_DIR/objects.exp OBJECTS
...
There is no flag to be set for CreateExportList (which would require -X64 in
front of OBJECT_DIR/objects.exp). Manually setting the whole of
CMAKE_${lang}_CREATE_SHARED_LIBRARY to something *with* appropriate flags is
very heavy-handed, hardcoding the -X64 into the CMake-owned file even more so.
The only solution I could come up with was to hardcode CMAKE_XL_CreateExportList
before calling project(), which is not a light touch either.
All told, I feel that CMake should provide a mechanics to set 32bit / 64bit /
32/64bit mode on AIX (and other platforms supporting such), which sets the
various flags appropriately without further intervention by client
CMakeLists.txt. Unfortunately I am not competent enough with CMake's inner
workings to provide a patch, or even a suggestion.
Steps to Reproduce:
/* mylib.cpp */
#include iostream
void mylib( void )
{
std::cout Hello world!\n;
return;
}
/* mytest.cpp */
void mylib( void );
int main( void )
{
mylib();
return 0;
}
## CMakeLists.txt ##
cmake_minimum_required( VERSION 3.2.3 FATAL_ERROR )
# This should not be necessary -- CMakeLists.txt is supposed to be
# (mostly) toolchain-agnostic!
find_program( CMAKE_XL_CreateExportList
NAMES CreateExportList
DOC IBM XL CreateExportList tool
)
if ( AIX64 )
set( CMAKE_XL_CreateExportList /usr/vacpp/bin/CreateExportList -X64 )
endif()
# end_rant
project( aixproblems )
option( AIX64 Create 64bit binaries, default: ON. ON )
add_library( mylib mylib.cpp )
add_executable( mytest mytest.cpp )
# This should not be necessary -- CMakeLists.txt is supposed to be
# (mostly) toolchain-agnostic!
if ( AIX64 )
set_property( TARGET mylib mytest APPEND_STRING PROPERTY COMPILE_FLAGS -q64
)
set_property( TARGET mylib mytest APPEND_STRING PROPERTY LINK_FLAGS -q64
)
set_property( TARGET mylib mytest APPEND_STRING PROPERTY
STATIC_LIBRARY_FLAGS -X64 )
# AIX 'ar' requires -X64 *before* cr / r.
set( CMAKE_CXX_ARCHIVE_CREATE CMAKE_AR LINK_FLAGS cr TARGET
OBJECTS )
set( CMAKE_CXX_ARCHIVE_APPEND CMAKE_AR LINK_FLAGS r TARGET
OBJECTS )
# ...and I have probably forgoten half a dozen settings,
# and broken a couple of rules as well.
endif()
# end_rant
target_link_libraries( mytest mylib )
Additional Information:
Mailing list thread of another CMake user with the same problem (which finally
made me find a workaround for the CreateExportList issue):
https://www.mail-archive.com/cmake%40cmake.org/msg51270.html
==
Issue History
Date ModifiedUsername FieldChange
==
2015-06-10 06:35 Martin Baute 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
[cmake-developers] [CMake 0015606]: Having problem with building a C++ file using Cmake from linux to windows
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15606 == Reported By:Arunava Nag Assigned To: == Project:CMake Issue ID: 15606 Category: CMake Reproducibility:always Severity: minor Priority: urgent Status: new == Date Submitted: 2015-06-09 22:05 EDT Last Modified: 2015-06-09 22:05 EDT == Summary:Having problem with building a C++ file using Cmake from linux to windows Description: CMake Warning (dev) at CMakeLists.txt:6 (if): Policy CMP0054 is not set: Only interpret if() arguments as variables or keywords when unquoted. Run cmake --help-policy CMP0054 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Quoted variables like MSVC will no longer be dereferenced when the policy is set to NEW. Since the policy is not set the OLD behavior will be used. This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at CMakeLists.txt:11 (elseif): Policy CMP0054 is not set: Only interpret if() arguments as variables or keywords when unquoted. Run cmake --help-policy CMP0054 for policy details. Use the cmake_policy command to set the policy and suppress this warning. Quoted variables like MSVC will no longer be dereferenced when the policy is set to NEW. Since the policy is not set the OLD behavior will be used. This warning is for project developers. Use -Wno-dev to suppress it. Configuring done == Issue History Date ModifiedUsername FieldChange == 2015-06-09 22:05 Arunava NagNew 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] [CMake 0015605]: Mention TARGET_FILE for COMMAND option of add_custom_command
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15605
==
Reported By:Lekensteyn
Assigned To:
==
Project:CMake
Issue ID: 15605
Category: Documentation
Reproducibility:N/A
Severity: text
Priority: normal
Status: new
==
Date Submitted: 2015-06-07 15:52 EDT
Last Modified: 2015-06-07 15:52 EDT
==
Summary:Mention TARGET_FILE for COMMAND option of
add_custom_command
Description:
While trying to set an environment variable in an add_custom_command target, I
found http://www.cmake.org/pipermail/cmake/2006-March/008522.html which
describes this syntax:
add_custom_command(TARGET foo
COMMAND ${CMAKE_COMMAND} -E env
VAR=VAL somecommand ...)
This works when somecommand is a system command, but in my case it was an
executable which was previously added by add_executable(somecommand ...).
The documentation at
http://www.cmake.org/cmake/help/v3.2/command/add_custom_command.html describes
how this special behavior works:
If COMMAND specifies an executable target (created by the add_executable()
command) it will automatically be replaced by the location of the executable
created at build time.
While the following paragraph mentions generator expressions (thanks again Nils
Gladitz!), it would help if $TARGET_FILE:somecommand was mentioned in the same
sentence for cases like the above (cmake -E env).
==
Issue History
Date ModifiedUsername FieldChange
==
2015-06-07 15:52 Lekensteyn 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] [CMake 0015604]: In tutorial, code is corrupted, probably due to HTML problems with
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15604 == Reported By:Guy Shaw Assigned To: == Project:CMake Issue ID: 15604 Category: Documentation Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-06 03:47 EDT Last Modified: 2015-06-06 03:47 EDT == Summary:In tutorial, code is corrupted, probably due to HTML problems with Description: http://www.cmake.org/cmake-tutorial First two blocks of sample C code has #include statements with the included file completely missing. The rest of the code samples do not have that problem. I would suspect it has something to do with a conversion step that stumbled on the handling of '' and/or '', but then I am not so sure, because another code snippet with '' survives: if (argc 2) -- Guy Shaw == Issue History Date ModifiedUsername FieldChange == 2015-06-06 03:47 Guy Shaw 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] [CMake 0015601]: Add target linker commands
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15601 == Reported By:Valerii Kanunik Assigned To: == Project:CMake Issue ID: 15601 Category: CMake Reproducibility:have not tried Severity: feature Priority: normal Status: new == Date Submitted: 2015-06-03 04:37 EDT Last Modified: 2015-06-03 04:37 EDT == Summary:Add target linker commands Description: Alongside with all target_* commands (target_compile_definitions, target_compile_features, target_compile_options, target_include_directories and target_link_libraries) are missing command to add linker flag to exact target. It would be grate add one or several commands which, for instance, on linux appends to linking command -Xlinker arguments, -T sctripts etc. == Issue History Date ModifiedUsername FieldChange == 2015-06-03 04:37 Valerii KanunikNew 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] [CMake 0015602]: Multiple configure_file calls with same input file cause Ninja to output spurious warning
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15602 == Reported By:arlbranch Assigned To: == Project:CMake Issue ID: 15602 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-03 12:01 EDT Last Modified: 2015-06-03 12:01 EDT == Summary:Multiple configure_file calls with same input file cause Ninja to output spurious warning Description: Multiple calls to configure_file with the same input file but from different CMakeLists.txt files causes ninja to output the following: warning: multiple rules generate builds involving this target will not be correct; continuing anyway Complete Example: = [branch@fortuna on /dev/pts/2] 611 ~/tmp/cftest $ cmake --version cmake version 3.2.3 CMake suite maintained and supported by Kitware (kitware.com/cmake). [branch@fortuna on /dev/pts/2] 612 ~/tmp/cftest $ ls -R .: cftest.json CMakeLists.txt sub/ ./sub: CMakeLists.txt [branch@fortuna on /dev/pts/2] 613 ~/tmp/cftest $ cat CMakeLists.txt cmake_minimum_required(VERSION 3.2) project(cftest) configure_file(cftest.json cftest1.json COPYONLY) add_subdirectory(sub) [branch@fortuna on /dev/pts/2] 614 ~/tmp/cftest $ cat sub/CMakeLists.txt configure_file(../cftest.json cftest2.json COPYONLY) [branch@fortuna on /dev/pts/2] 615 ~/tmp/cftest $ mkdir ../cfbuild cd ../cfbuild [branch@fortuna on /dev/pts/2] 616 ~/tmp/cfbuild $ cmake -G Ninja ../cftest -- The C compiler identification is GNU 5.1.0 -- The CXX compiler identification is GNU 5.1.0 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: /home/branch/tmp/cfbuild [branch@fortuna on /dev/pts/2] 617 ~/tmp/cfbuild $ ninja ninja: warning: multiple rules generate /home/branch/tmp/cftest/cftest.json. builds involving this target will not be correct; continuing anyway ninja: no work to do. Steps to Reproduce: 1) Create the project in the Description 2) Configure with the Ninja generator 3) build with ninja == Issue History Date ModifiedUsername FieldChange == 2015-06-03 12:01 arlbranch 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] [CMake 0015603]: CMake ignores the configured Visual C/C++ compiler
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15603 == Reported By:Jan Ciger Assigned To: == Project:CMake Issue ID: 15603 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-03 13:46 EDT Last Modified: 2015-06-03 13:46 EDT == Summary:CMake ignores the configured Visual C/C++ compiler Description: CMake Visual Studio 2013 generators (probably other versions too, but not tested) will select incorrect architecture, regardless whether or not vcvarsall.bat amd64 was executed beforehand. cmake . (with no generator specified) will configure 32bit build cmake -G Visual Studio 12 2013 will still configure only a 32bit build (the only VS 2013 generator listed in the --help output) On the other hand cmake-gui offers 3 (!) generators: Visual Studio 12 2013 (probably 32bit build?) Visual Studio 12 2013 Win32 (32bit build) Visual Studio 12 2013 Win64 (64bit build) with the 64bit build being the default. This behaviour is rather inconsistent: * Both tools should be offering the same generators * The tools should offer the correct, currently configured toolchain because otherwise all kinds of issues happen due to the Microsoft's tools being misconfigured. The Microsoft batch files set the following env variables that can be used to identify the current setup: 64bit tools targetting 64bit native build @set Platform=X64 @set CommandPromptType=Native 64bit tools cross-compiling for 32bit @set Platform=X86 @set CommandPromptType=Cross @set PreferredToolArchitecture=x64 64bit tools cross-compiling for ARM @set Platform=ARM @set CommandPromptType=Cross @set PreferredToolArchitecture=x64 etc. == Issue History Date ModifiedUsername FieldChange == 2015-06-03 13:46 Jan Ciger 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] [CMake 0015600]: CTest output redirection doesn't respect the order
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15600 == Reported By:Christophe Dumeunier Assigned To: == Project:CMake Issue ID: 15600 Category: CTest Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-02 08:44 EDT Last Modified: 2015-06-02 08:44 EDT == Summary:CTest output redirection doesn't respect the order Description: The output redirection from the terminal (stdout and stderr) to the LastTest.log file doesn't respect the order of the output between stdout and stderr. When a long message is printed (and flushed) on stdout and followed by a message on stderr, the error message is printed inside the message from stdout, even if stdout is flushed. If I run the executable in the terminal or with output.log 21, the error message is printed at the end, as expected. You can see in attachement the result of executing the given C++ test with CTest. Steps to Reproduce: Launch the tests on the project given in attachement and observe the problem in the generated file ./Testing/Temporary/LastTest.log == Issue History Date ModifiedUsername FieldChange == 2015-06-02 08:44 Christophe DumeunierNew Issue 2015-06-02 08:44 Christophe DumeunierFile Added: bug_ctest_stdouterr.zip == -- 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 0015599]: CTest with launchers drops warning generated by early build command failure
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15599 == Reported By:trsystran Assigned To: == Project:CMake Issue ID: 15599 Category: CTest Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-06-01 05:35 EDT Last Modified: 2015-06-01 05:35 EDT == Summary:CTest with launchers drops warning generated by early build command failure Description: When the build command fails (returns a non-zero return code), CTest creates a ~fake warning in cmCTestBuildHandler::RunMakeCommand: this-ErrorsAndWarnings.push_back(errorwarning);. (Sub-question: Why is it a Warning and not an Error? all non-zero return code should be errors) Then, normally the ErrorsAndWarnings object is parsed and converted to Build.xml in cmCTestBuildHandler::GenerateXMLLogScraped. However, when CTest is run with Launchers enabled, then GenerateXMLLogScraped is never called: cmCTestBuildHandler::GenerateXMLLaunched is called instead, using a different source of information for errors and warnings: the xml files generated by ctest in launcher mode. This means that the build return code value is ignored. Why is it an issue when we have launchers? Because launchers only catch build errors as they wrap the compiler command. If the generator fails early (ie before executing any build command), then the ctest launchers won't catch anything here. It happens with the Ninja generator, when we import an external lib, but forcing an invalid path to the lib. Steps to Reproduce: $ cmake . -G Ninja -DCTEST_USE_LAUNCHERS=ON $ ninja ninja: error: '/invalid/path/to/libmissingLib.so', needed by 'executableFailed', missing and no known rule to make it No call to ctest in launcher mode confirmed with strace -f ninja | grep ctest. When launched via a real ctest flow: Build project MakeCommand:ninja -k0 -l34 all Run command: ninja -k0 -l34 all Each symbol represents 1024 bytes of output. .ninja: error: '/invalid/path/to/libmissingLib.so', needed by 'executableFailed', missing and no known rule to make it Size of output: 0K Command exited with the value: 1 MakeCommand:ninja -k0 -l34 all Error(s) when building project 0 Compiler errors 1 Compiler warnings But the Build.xml has no error nor warning: no issue is pushed to cdash. Additional Information: There are probably many other cases of early generator failure (for example if a source file goes missing between cmake configuration and build), at least with Ninja. == Issue History Date ModifiedUsername FieldChange == 2015-06-01 05:35 trsystran New Issue 2015-06-01 05:35 trsystran File Added: CMakeLists.txt == -- 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 0015598]: CMAKE_Fortran_COMPILER_ID unset even though gfortran installed
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15598 == Reported By:Paul Durack Assigned To: == Project:CMake Issue ID: 15598 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-05-31 17:07 EDT Last Modified: 2015-05-31 17:07 EDT == Summary:CMAKE_Fortran_COMPILER_ID unset even though gfortran installed Description: duro@duro-vm:~/uvcdat-build$ cmake ../uvcdat -DCMAKE_INSTALL_PREFIX=/usr/local/uvcdat/2.2.0 -DQT_QMAKE_EXECUTABLE=/usr/bin/qmake -DCDAT_BUILD_CMOR=ON -DCDAT_BUILD_GUI=ON -DCDAT_BUILD_MODE=ALL [INFO] We reset your path to: /usr/local/uvcdat/2.2.0/Externals/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games -- CMAKE_Fortran_COMPILER_ID = ''. CMake Warning at contrib/sciMake/sciFuncsMacros.cmake:23 (message): Variable CONFIG_SUMMARY is not defined, sciPrintString is unable to write to the summary file. Call Stack (most recent call first): contrib/sciMake/sciFortranFindVersion.cmake:12 (sciPrintString) contrib/sciMake/sciFortranChecks.cmake:14 (include) CMake/cdat_modules/esmf_pkg.cmake:26 (include) CMakeLists.txt:468 (include) CMake Error at contrib/sciMake/sciFortranFindVersion.cmake:160 (message): Unknown compiler ID, . Call Stack (most recent call first): contrib/sciMake/sciFortranChecks.cmake:14 (include) CMake/cdat_modules/esmf_pkg.cmake:26 (include) CMakeLists.txt:468 (include) -- Configuring incomplete, errors occurred! See also /home/duro/uvcdat-build/CMakeFiles/CMakeOutput.log. See also /home/duro/uvcdat-build/CMakeFiles/CMakeError.log. duro@duro-vm:~/uvcdat-build$ which gfortran /usr/bin/gfortran duro@duro-vm:~/uvcdat-build$ gfortran --version GNU Fortran (Ubuntu 4.9.2-10ubuntu13) 4.9.2 duro@duro-vm:~/uvcdat-build$ cmake --version cmake version 3.0.2 Steps to Reproduce: As above == Issue History Date ModifiedUsername FieldChange == 2015-05-31 17:07 Paul DurackNew 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] [CMake 0015593]: Overriding the project configuration (CMAKE_C_SOURCE_FILE_EXTENSIONS)
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15593 == Reported By:Art Assigned To: == Project:CMake Issue ID: 15593 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-05-29 07:31 EDT Last Modified: 2015-05-29 07:31 EDT == Summary:Overriding the project configuration (CMAKE_C_SOURCE_FILE_EXTENSIONS) Description: During the operation of the module CMakeCCompiler.cmake.in comes to overwrite the user's configuration parameter CMAKE_C_SOURCE_FILE_EXTENSIONS Proposed solution: https://github.com/Kitware/CMake/blob/master/Modules/CMakeCCompiler.cmake.in#L34 set(CMAKE_C_SOURCE_FILE_EXTENSIONS c;m) Can be replaced on IF(NOT CMAKE_C_SOURCE_FILE_EXTENSIONS) set(CMAKE_C_SOURCE_FILE_EXTENSIONS c;m) ENDIF() == Issue History Date ModifiedUsername FieldChange == 2015-05-29 07:31 ArtNew 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] [CMake 0015594]: Fix a bug in cmake-compile-features(7) manual : Replace target_link_libraries() with target_include_directories()
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15594 == Reported By:Erik Sjölund Assigned To: == Project:CMake Issue ID: 15594 Category: Documentation Reproducibility:N/A Severity: minor Priority: normal Status: new == Date Submitted: 2015-05-29 10:13 EDT Last Modified: 2015-05-29 10:13 EDT == Summary:Fix a bug in cmake-compile-features(7) manual : Replace target_link_libraries() with target_include_directories() Description: target_link_libraries() is being used in the example code in the cmake-compile-features(7) manual http://www.cmake.org/cmake/help/v3.2/manual/cmake-compile-features.7.html#manual:cmake-compile-features(7) but target_include_directories() was probably meant to be used. The sentence that starts with Consuming code then indicates that the example is about using the appropriate include directory. A patch was uploaded together with this bug report. == Issue History Date ModifiedUsername FieldChange == 2015-05-29 10:13 Erik Sjölund New Issue 2015-05-29 10:13 Erik Sjölund File Added: patch.txt == -- 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 0015595]: FindPkgConfig does not use the CMAKE_FRAMEWORK_PATH and CMAKE_APPBUNDLE_PATH cache variables
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15595
==
Reported By:Daniele E. Domenichelli
Assigned To:Daniele E. Domenichelli
==
Project:CMake
Issue ID: 15595
Category: Modules
Reproducibility:have not tried
Severity: minor
Priority: normal
Status: assigned
==
Date Submitted: 2015-05-29 19:28 CEST
Last Modified: 2015-05-29 19:28 CEST
==
Summary:FindPkgConfig does not use the CMAKE_FRAMEWORK_PATH
and CMAKE_APPBUNDLE_PATH cache variables
Description:
The CMAKE_FRAMEWORK_PATH and CMAKE_APPBUNDLE_PATH cache variables are supposed
to be used to generate the extra paths passed to pkg-config, but instead the
CMAKE_PREFIX_PATH variable is used.
I wrote a patch and added a couple of unit tests
topic: FindPkgConfig_fix_extra_path
FindPkgConfig: Fix extra paths for CMAKE_{FRAMEWORK,APPBUNDLE}_PATH vars
http://www.cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=d4c6531
Let me know if I can merge this and to which branch (next or release?).
==
Issue History
Date ModifiedUsername FieldChange
==
2015-05-29 19:28 Daniele E. DomenichelliNew Issue
2015-05-29 19:28 Daniele E. DomenichelliStatus new = assigned
2015-05-29 19:28 Daniele E. DomenichelliAssigned To = Daniele E.
Domenichelli
==
--
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 0015596]: CMakeClDeps.cmake doesn't work if CC contains arguments
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15596 == Reported By:Reid Kleckner Assigned To: == Project:CMake Issue ID: 15596 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-05-29 13:47 EDT Last Modified: 2015-05-29 13:47 EDT == Summary:CMakeClDeps.cmake doesn't work if CC contains arguments Description: I am attempting to do a 32-bit self-host of clang on Windows with a 64-bit clang-cl binary. By default, the 64-bit binary generates 64-bit code, so I need to pass the -m32 flag to override that. I figured the most robust way to do this is something like setting CC=clang-cl -m32 and running cmake. This *almost* worked, but CMakeCLDeps.cmake runs CMAKE_C_COMPILER without the flags present in CC, and the link failed. It's regex then matched the error message from LINK, and I got this in rules.ninja: msvc_deps_prefix = LINK : error LNK2001: CMakeClDeps.cmake doesn't actually need to do a link, so one easy workaround would be to add /c to command line there. That's probably a good tweak in general, since it saves an invocation of link.exe, and cuts down on moving parts. :) Aside from the workaround, is there a more canonical way that CMakeClDeps should be invoking the compiler that includes flags from the CC env var? == Issue History Date ModifiedUsername FieldChange == 2015-05-29 13:47 Reid Kleckner 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] [CMake 0015597]: Issues with the 'Eclipse CDT4 - NMake Makefiles' Generator
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15597 == Reported By:Anthony Ette Assigned To: == Project:CMake Issue ID: 15597 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-05-29 14:56 EDT Last Modified: 2015-05-29 14:56 EDT == Summary:Issues with the 'Eclipse CDT4 - NMake Makefiles' Generator Description: The project compiles and links in Eclipse but the preprocessor symbols are not defined by the .cproject file. As a result, sections with #ifdef _WIN32 #endif appear grayed out in the IDE and any included files can't be opened. Note that I'm using Eclipse 4 (Luna). Is there any way I can ensure that the Eclipse project has knowledge of my toolchain's preprocessor symbols without having to redefine them all in my CMakeLists.txt file(s)? Steps to Reproduce: 1) setup project with in source build for better eclipse support (see http://www.cmake.org/Wiki/Eclipse_CDT4_Generator) 2) run cmake with the following (please see attached toolchain file for reference): C:\Users\bzpl46\sim\sandbox\AE3007\C2cmake -DCMAKE_TOOLCHAIN_FILE=toolchains\to olchain_windows_vsc.cmake -G Eclipse CDT4 - NMake Makefiles -- The C compiler identification is MSVC 15.0.30729.1 -- The CXX compiler identification is MSVC 15.0.30729.1 -- Eclipse version is set to 4.4 (Luna). Adjust CMAKE_ECLIPSE_VERSION if this is wrong. -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studi o 9.0/VC/bin/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studi o 9.0/VC/bin/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- CMAKE_BINARY_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2 -- CMAKE_CURRENT_BINARY_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2 -- CMAKE_SOURCE_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2 -- CMAKE_CURRENT_SOURCE_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2 -- PROJECT_BINARY_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2 -- PROJECT_SOURCE_DIR: C:/Users/bzpl46/sim/sandbox/AE3007/C2 -- EXECUTABLE_OUTPUT_PATH: C:/Users/bzpl46/sim/sandbox/AE3007/C2 -- LIBRARY_OUTPUT_PATH: -- CMAKE_MODULE_PATH: -- CMAKE_COMMAND: I:/PortableApps/cmake-3.2.2-win32-x86/bin/cmake.exe -- CMAKE_ROOT: I:/PortableApps/cmake-3.2.2-win32-x86/share/cmake-3.2 -- CMAKE_CURRENT_LIST_FILE: C:/Users/bzpl46/sim/sandbox/AE3007/C2/CMakeLists.txt -- CMAKE_CURRENT_LIST_LINE: 90 -- CMAKE_INCLUDE_PATH: -- CMAKE_LIBRARY_PATH: -- CMAKE_SYSTEM: Windows -- CMAKE_SYSTEM_NAME: Windows -- CMAKE_SYSTEM_VERSION: -- CMAKE_SYSTEM_PROCESSOR: -- UNIX: -- CMAKE_SKIP_RULE_DEPENDENCY: -- CMAKE_SKIP_INSTALL_ALL_DEPENDENCY: -- CMAKE_SKIP_RPATH: NO -- CMAKE_VERBOSE_MAKEFILE: FALSE -- CMAKE_SUPPRESS_REGENERATION: -- CMAKE_C_FLAGS: /DWIN32 /D_WINDOWS /W3 -- CMAKE_C_FLAGS_DEBUG: /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -- CMAKE_C_FLAGS_RELEASE: /MD /O2 /Ob2 /D NDEBUG -- CMAKE_CXX_FLAGS: /DWIN32 /D_WINDOWS /W3 /GR /EHsc -- CMAKE_BUILD_TYPE: Debug -- BUILD_SHARED_LIBS: -- CMAKE_C_COMPILER: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/c l.exe -- CMAKE_CXX_COMPILER: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin /cl.exe -- CMAKE_COMPILER_IS_GNUCC: -- CMAKE_COMPILER_IS_GNUCXX : -- CMAKE_AR: -- CMAKE_RANLIB: -- Configuring done -- Generating done -- Build files have been written to: C:/Users/bzpl46/sim/sandbox/AE3007/C2 3) import the project into Eclipse, right click on the project, go to Properties - C/C++ General - Paths and Symbols and notice that there are no symbols defined. There is not even a Symbols tab which is typically the case for a valid CDT project. == Issue History Date ModifiedUsername FieldChange == 2015-05-29 14:56 Anthony Ette New Issue 2015-05-29 14:56 Anthony Ette File Added: toolchain_windows_vsc.cmake
[cmake-developers] [CMake 0015592]: ExternalProject does not allow NOT to init all the submodules
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15592 == Reported By:Daniele E. Domenichelli Assigned To: == Project:CMake Issue ID: 15592 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-05-28 20:03 CEST Last Modified: 2015-05-28 20:03 CEST == Summary:ExternalProject does not allow NOT to init all the submodules Description: Using the GIT_SUBMODULES argument, it is possible to initialize and update only a subset of modules, but it is not possible to skip all of them Passing GIT_SUBMODULES or not passing GIT_SUBMODULE at all is the same, and the behaviour is to initialize and update ALL the submodules. == Issue History Date ModifiedUsername FieldChange == 2015-05-28 20:03 Daniele E. DomenichelliNew 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] [CMake 0015590]: ExternalProject inits all submodules
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15590 == Reported By:Daniele E. Domenichelli Assigned To:Daniele E. Domenichelli == Project:CMake Issue ID: 15590 Category: Modules Reproducibility:always Severity: tweak Priority: low Status: assigned == Date Submitted: 2015-05-28 16:27 CEST Last Modified: 2015-05-28 16:27 CEST == Summary:ExternalProject inits all submodules Description: At the moment ExternalProject is initializing all the submodules of a git repository, even if the user only wants to checkout a subset of submodules. With this patch, it initializes only the selected submodules, reducing the waiting time for repositories with many submodules (such as https://github.com/boostorg/boost). Topic: ExternalProject_init_selected_submodules ExternalProject: Init only selected git submodules http://www.cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=6d5aded I'm not the author of the patch (as you can see from git commit author). It looks good to me, since the git submodule update already downloads only the selected submodules. == Issue History Date ModifiedUsername FieldChange == 2015-05-28 16:27 Daniele E. DomenichelliNew Issue 2015-05-28 16:27 Daniele E. DomenichelliStatus new = assigned 2015-05-28 16:27 Daniele E. DomenichelliAssigned To = Daniele E. Domenichelli == -- 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 0015591]: CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES variables are actually clang-specific not osx-specific
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15591 == Reported By:Chris Bieneman Assigned To: == Project:CMake Issue ID: 15591 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2015-05-28 10:56 EDT Last Modified: 2015-05-28 10:56 EDT == Summary:CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES variables are actually clang-specific not osx-specific Description: The CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES flags are currently the best supported way to set the -isysroot and -arch flags used by clang for cross-compiling, but they only function fully if you are on Darwin. Clang supports these flags on all platforms, so they should really be CMAKE_CLANG_SYSROOT and CMAKE_CLANG_ARCHITECTURES. Having platform-agnostic CMAKE_CLANG_ARCHITECTURES and CMAKE_CLANG_SYSROOT flags would significantly improve cross-compiling support with clang. It would also greatly help the LLVM project in our efforts to replace our autoconf build system with CMake. == Issue History Date ModifiedUsername FieldChange == 2015-05-28 10:56 Chris Bieneman 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] [CMake 0015588]: New behavior of ExternalProject_Add command
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15588 == Reported By:Valerii Kanunik Assigned To: == Project:CMake Issue ID: 15588 Category: CMake Reproducibility:have not tried Severity: feature Priority: normal Status: new == Date Submitted: 2015-05-27 09:19 EDT Last Modified: 2015-05-27 09:19 EDT == Summary:New behavior of ExternalProject_Add command Description: ExternalProject_Add provides great functionality but IMO very uncomfortable. The problem is that command perform all actions on build step and clean command removes all results. Is it possible change command behavior (or provide new one for instance add_subproject) which: 1) Preforms download and configure steps along with configure step of main project 2) Does not add to clean target all unziped or downloaded files, but adds additional command (for inctance make clean-all or dist-clean) which does that. == Issue History Date ModifiedUsername FieldChange == 2015-05-27 09:19 Valerii KanunikNew 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] [CMake 0015589]: Crash when fetching larger data file with External Data on Windows
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15589 == Reported By:Martyn Gigg Assigned To: == Project:CMake Issue ID: 15589 Category: CMake Reproducibility:always Severity: crash Priority: normal Status: new == Date Submitted: 2015-05-27 16:26 EDT Last Modified: 2015-05-27 16:26 EDT == Summary:Crash when fetching larger data file with External Data on Windows Description: We have been using the external data mechanism with great success for several months. Recently, an 800Mb file was added to our test data and on Windows cmake crashes with a std::bad_alloc during a curl callback. The download works fine on Linux and Mac OS X. The full stack trace from Visual Studio is: msvcr110d.dll!_CxxThrowException(void * pExceptionObject, const _s__ThrowInfo * pThrowInfo) Line 152 C++ msvcr110d.dll!operator new(unsigned int size) Line 63 C++ cmake.exe!std::_Allocatechar(unsigned int _Count, char * __formal) Line 28 C++ cmake.exe!std::allocatorchar::allocate(unsigned int _Count) Line 591 C++ cmake.exe!std::_Wrap_allocstd::allocatorchar ::allocate(unsigned int _Count) Line 877C++ cmake.exe!std::vectorchar,std::allocatorchar ::_Insertchar *(std::_Vector_const_iteratorstd::_Vector_valstd::_Simple_typeschar _Where, char * _First, char * _Last, std::forward_iterator_tag __formal) Line 1316C++ cmake.exe!std::vectorchar,std::allocatorchar ::insertchar *(std::_Vector_const_iteratorstd::_Vector_valstd::_Simple_typeschar _Where, char * _First, char * _Last) Line 1262 C++ cmake.exe!`anonymous namespace'::cmFileCommandCurlDebugCallback(void * __formal, curl_infotype __formal, char * chPtr, unsigned int size, void * data) Line 2519 C++ cmake.exe!showit(SessionHandle * data, curl_infotype type, char * ptr, unsigned int size) Line 608 C cmake.exe!Curl_debug(SessionHandle * data, curl_infotype type, char * ptr, unsigned int size, connectdata * conn) Line 661 C cmake.exe!Curl_readwrite(connectdata * conn, unsigned char * done) Line 1208C cmake.exe!Transfer(connectdata * conn) Line 1819C cmake.exe!Curl_perform(SessionHandle * data) Line 2378 C cmake.exe!curl_easy_perform(void * curl) Line 480 C cmake.exe!cmFileCommand::HandleDownloadCommand(const std::vectorstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar args) Line 2946 C++ cmake.exe!cmFileCommand::InitialPass(const std::vectorstd::basic_stringchar,std::char_traitschar,std::allocatorchar ,std::allocatorstd::basic_stringchar,std::char_traitschar,std::allocatorchar args, cmExecutionStatus __formal) Line 83 C++ cmake.exe!cmCommand::InvokeInitialPass(const std::vectorcmListFileArgument,std::allocatorcmListFileArgument args, cmExecutionStatus status) Line 68 C++ cmake.exe!cmMakefile::ExecuteCommand(const cmListFileFunction lff, cmExecutionStatus status) Line 418C++ cmake.exe!cmWhileFunctionBlocker::IsFunctionBlocked(const cmListFileFunction lff, cmMakefile mf, cmExecutionStatus inStatus) Line 73 C++ cmake.exe!cmMakefile::IsFunctionBlocked(const cmListFileFunction lff, cmExecutionStatus status) Line 2833 C++ cmake.exe!cmMakefile::ExecuteCommand(const cmListFileFunction lff, cmExecutionStatus status) Line 386C++ cmake.exe!cmFunctionHelperCommand::InvokeInitialPass(const std::vectorcmListFileArgument,std::allocatorcmListFileArgument args, cmExecutionStatus inStatus) Line 179 C++ cmake.exe!cmMakefile::ExecuteCommand(const cmListFileFunction lff, cmExecutionStatus status) Line 418C++ cmake.exe!cmForEachFunctionBlocker::IsFunctionBlocked(const cmListFileFunction lff, cmMakefile mf, cmExecutionStatus inStatus) Line 57 C++ cmake.exe!cmMakefile::IsFunctionBlocked(const cmListFileFunction lff, cmExecutionStatus status) Line 2833 C++ cmake.exe!cmMakefile::ExecuteCommand(const cmListFileFunction lff, cmExecutionStatus status) Line 386C++ cmake.exe!cmFunctionHelperCommand::InvokeInitialPass(const std::vectorcmListFileArgument,std::allocatorcmListFileArgument args, cmExecutionStatus inStatus) Line 179 C++ cmake.exe!cmMakefile::ExecuteCommand(const cmListFileFunction lff,
[cmake-developers] [CMake 0015587]: Add more RST markup to documentation
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15587 == Reported By:Stephen Kelly Assigned To: == Project:CMake Issue ID: 15587 Category: (No Category) Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-05-26 23:26 CEST Last Modified: 2015-05-26 23:26 CEST == Summary:Add more RST markup to documentation Description: There are lots of places in the CMake documentation which have suboptimal reStructuredText formatting. Fixing up some of that would be great. There is information about writing help files here: http://www.cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#help For example on this page, the CMAKE_PARENT_LIST_FILE could be a link, but is currently not: http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_CURRENT_LIST_FILE.html There are many other examples and it would make a huge improvement to the documentation to systematically improve documentation pages like that. == Issue History Date ModifiedUsername FieldChange == 2015-05-26 23:26 Stephen Kelly 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] [CMake 0015586]: Add support for lists inside generator expressions
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15586 == Reported By:Ilya Assigned To: == Project:CMake Issue ID: 15586 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2015-05-26 10:52 EDT Last Modified: 2015-05-26 10:52 EDT == Summary:Add support for lists inside generator expressions Description: Right now it's not possible to specify lists inside generator expressions. E.g. both $$CONFIG:Debug:-O0 -g and $$CONFIG:Debug:-O0;-g break code. == Issue History Date ModifiedUsername FieldChange == 2015-05-26 10:52 Ilya 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] [CMake 0015585]: Add support for the if / else construct to generator expressions
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15585 == Reported By:Ilya Assigned To: == Project:CMake Issue ID: 15585 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2015-05-26 10:49 EDT Last Modified: 2015-05-26 10:49 EDT == Summary:Add support for the if / else construct to generator expressions Description: It's often desirable to provide content for both branches, e.g.: $CONFIG:Debug:-O0?-O2 Right now code should like this: $CONFIG:Debug:-O0$$NOT:$CONFIG:Debug:-O2 Which is beyond being readable. == Issue History Date ModifiedUsername FieldChange == 2015-05-26 10:49 Ilya 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] [CMake 0015584]: cmake -E does not allow to create zip files
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15584 == Reported By:Ghislain MARY Assigned To: == Project:CMake Issue ID: 15584 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2015-05-25 04:34 EDT Last Modified: 2015-05-25 04:34 EDT == Summary:cmake -E does not allow to create zip files Description: Using the cmake -E tar command a user can currently create a tar archive (eventually compressed) but not a zip file. But CMake is able to generate zip files for the CPack zip archives so it should be possible to add a cmake -E command to generate a zip file. == Issue History Date ModifiedUsername FieldChange == 2015-05-25 04:34 Ghislain MARY 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] [CMake 0015583]: Windows-Intel-Fortran.cmake does not disable optimization in CMAKE_Fortran_FLAGS_DEBUG_INIT
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15583 == Reported By:ovz Assigned To: == Project:CMake Issue ID: 15583 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-05-23 20:38 EDT Last Modified: 2015-05-23 20:38 EDT == Summary:Windows-Intel-Fortran.cmake does not disable optimization in CMAKE_Fortran_FLAGS_DEBUG_INIT Description: In C:\Program Files (x86)\CMake\share\cmake-3.2\Modules\Platform\Windows-Intel-Fortran.cmake I see set (CMAKE_Fortran_FLAGS_DEBUG_INIT /debug:full /dbglibs) set (CMAKE_Fortran_FLAGS_MINSIZEREL_INIT /O1 /D NDEBUG) set (CMAKE_Fortran_FLAGS_RELEASE_INIT /O2 /D NDEBUG) As a result in my .vfproj I get /O2 in Debug mode. I believe it should be set (CMAKE_Fortran_FLAGS_DEBUG_INIT /Od /debug:full /dbglibs) == Issue History Date ModifiedUsername FieldChange == 2015-05-23 20:38 ovzNew 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] [CMake 0015582]: FindLLVM
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15582 == Reported By:Bo Zhou Assigned To: == Project:CMake Issue ID: 15582 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2015-05-23 03:06 EDT Last Modified: 2015-05-23 03:06 EDT == Summary:FindLLVM Description: Hi If CMake has the built-in routines for locating LLVM libraries that would be great. Some people have already done this but still not the official support. Thanks https://github.com/ldc-developers/ldc/blob/master/cmake/Modules/FindLLVM.cmake == Issue History Date ModifiedUsername FieldChange == 2015-05-23 03:06 Bo ZhouNew 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
