[cmake-developers] [CMake 0014320]: FindLAPACK doesn't work if BLA_STATIC is set to ON
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14320 == Reported By:ycollet Assigned To: == Project:CMake Issue ID: 14320 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-07-30 03:41 EDT Last Modified: 2013-07-30 03:41 EDT == Summary:FindLAPACK doesn't work if BLA_STATIC is set to ON Description: FindLAPACK doesn't work if BLA_STATIC is set to ON. Steps to Reproduce: Start the attached CMakefiles.txt and change the line set(BLA_STATIC OFF) to ON. == Issue History Date ModifiedUsername FieldChange == 2013-07-30 03:41 ycolletNew Issue 2013-07-30 03:41 ycolletFile Added: CMakeLists.txt == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] cmake --deprecated-warnings and cmake --deprecated-errors
Hi, It's now possible to invoke cmake with -DCMAKE_WARN_DEPRECATED=1 and also with -DCMAKE_ERROR_DEPRECATED=1 to get deprecation warnings or errors. I wonder if we should add --deprecated-warnings and --deprecated-errors and document them in cmake --help, as --warn-uninitialized etc? I think it's something we can do after 2.8.12, but I want to make sure it doesn't change anything in how the deprecation stuff works or is used currently. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014321]: create_javadoc does not work on Windows if doctitle or windowtitle are specified
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14321 == Reported By:Graham Markall Assigned To: == Project:CMake Issue ID: 14321 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-07-30 08:02 EDT Last Modified: 2013-07-30 08:02 EDT == Summary:create_javadoc does not work on Windows if doctitle or windowtitle are specified Description: create_javadoc encloses doctitle and windowtitle in single quotes, which causes the error: The system cannot find the file specified. on Windows. I have a patch to propose, which I shall upload shortly. Steps to Reproduce: Use create_javadoc in a CmakeLists.txt file with a DOCTITLE or WINDOWTITLE argument. == Issue History Date ModifiedUsername FieldChange == 2013-07-30 08:02 Graham Markall New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --deprecated-warnings and cmake --deprecated-errors
On 07/30/2013 06:30 AM, Stephen Kelly wrote: It's now possible to invoke cmake with -DCMAKE_WARN_DEPRECATED=1 and also with -DCMAKE_ERROR_DEPRECATED=1 to get deprecation warnings or errors. I wonder if we should add --deprecated-warnings and --deprecated-errors and document them in cmake --help, as --warn-uninitialized etc? I think it's something we can do after 2.8.12, but I want to make sure it doesn't change anything in how the deprecation stuff works or is used currently. The first warning option ever added was -Wdev and the intention at the time was to use -W... for all warning options. That was forgotten by the time --warn-uninitialized was created. Perhaps that can be cleaned up now: -Wdeprecated -Wdeprecated=error -Wuninitialized ... -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
On 07/29/2013 06:57 PM, Stephen Kelly wrote: Yes, $CONFIGURATION should work both before and after export. So the question is how to know whether to evaluate it during export or write it literally in the file. In this case we want to expand it during export because we want $CONFIGURATION to refer to the build configuration being installed. INCLUDES DESTINATION include/$TARGET_PROPERTY:NAME [snip] The problem (apart from NAME not being currently a target property) is that the $TARGET_PROPERTY:NAME is reproduced verbatim in theTargetsExport.cmake. There the target names are TP1::foo etc, and include/TP1::foo does not exist. Again the problem is when evaluation occurs. The $INSTALL_PREFIX works in the INCLUDES DESTINATION because it is replaced by preprocessing during export. Does anything else get replaced by preprocessing? For $CONFIGURATION it should be fine, but probably also involves replacing (IMPORTED_)?LOCATION(_CONFIG)? with a genex-capable LOCATION. The history of the LOCATION property is complicated enough already. If we do add genex support we should create a new name to distinguish it. However, why would allowing $CONFIGURATION in the destination require a genex location? We generate an install rule for a given configuration with $CONFIGURATION replaced and then put the corresponding result in IMPORTED_LOCATION_CONFIG. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --deprecated-warnings and cmake --deprecated-errors
Brad King wrote: -Wdeprecated -Wdeprecated=error -Wuninitialized Ok, I'll come back to that after 2.8.12. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
Brad King wrote: On 07/29/2013 06:57 PM, Stephen Kelly wrote: Yes, $CONFIGURATION should work both before and after export. So the question is how to know whether to evaluate it during export or write it literally in the file. In this case we want to expand it during export because we want $CONFIGURATION to refer to the build configuration being installed. Right. I had thought that $CONFIGURATION would be evaluated by the reader of the IMPORTED_LOCATION property on the IMPORTED target. I think you are right that it makes more sense to replace it at generate- time. The $INSTALL_PREFIX works in the INCLUDES DESTINATION because it is replaced by preprocessing during export. Does anything else get replaced by preprocessing? Target names get replaced by namespaced target names, and the INSTALL_INTERFACE or BUILD_INTERFACE gets stripped. For $CONFIGURATION it should be fine, but probably also involves replacing (IMPORTED_)?LOCATION(_CONFIG)? with a genex-capable LOCATION. The history of the LOCATION property is complicated enough already. If we do add genex support we should create a new name to distinguish it. However, why would allowing $CONFIGURATION in the destination require a genex location? We generate an install rule for a given configuration with $CONFIGURATION replaced and then put the corresponding result in IMPORTED_LOCATION_CONFIG. Yes, that makes more sense. So, the remaining question is when to evaluate the generator expressions. I agree that evaluating them at export time is a better idea. That means that I should patch the INCLUDES DESTINATION feature to do a complete evaluation, not just a preprocessing. I think that makes sense for all DESTINATION components. So, install(TARGETS foo INCLUDES DESTINATION include/$TARGET_PROPERTY:NAME) will result in include/foo in the INTERFACE_INCLUDE_DIRECTORIES of the IMPORTED target. However, set_property(TARGET foo APPEND PROPERTY INTERFACE_INCLUDE_DIRECTORIES include/$TARGET_PROPERTY:NAME ) will result in include/$TARGET_PROPERTY:NAME in the INTERFACE_INCLUDE_DIRECTORIES of the IMPORTED target. That is, parameters to install(TARGETS) are evaluated at export time, and otherwise the contents of the property are reproduced verbatim. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
On 07/30/2013 09:46 AM, Stephen Kelly wrote: That is, parameters to install(TARGETS) are evaluated at export time, and otherwise the contents of the property are reproduced verbatim. Yes, I think this makes sense. The install rules run as part of the current project's build just like custom commands, so it makes sense to evaluate generator expressions immediately. However, the implementation may be a bit complicated because now cmake_install.cmake script code will have to branch on BUILD_TYPE to pick which install rule to run. There is already infrastructure for this to support the CONFIGURATIONS option of install(TARGETS) so maybe it is okay. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014322]: FindMPI.cmake does not produce a complete list of compile and link flags (-pthread missing)
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14322
==
Reported By:higgins
Assigned To:
==
Project:CMake
Issue ID: 14322
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2013-07-30 11:08 EDT
Last Modified: 2013-07-30 11:08 EDT
==
Summary:FindMPI.cmake does not produce a complete list of
compile and link flags (-pthread missing)
Description:
Openmpi produces the following
mpic++ --showme:compile
-I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi -pthread
mpic++ --showme:link
-pthread -L/usr/lib/openmpi/lib -lmpi_cxx -lmpi -lopen-rte -lopen-pal -ldl
-Wl,--export-dynamic -lnsl -lutil -lm -ldl
However, the regex code in FindMPI.cmake fails to pick-up flags that start with
p.
Additional Information:
To pick up flags starting with p I changed the following lines in FindMPI.cmake.
# Extract include paths from compile command line
#ORIGINAL string(REGEX MATCHALL (^| )-[Df]([^\ ]+|\[^\]+\)
MPI_ALL_COMPILE_FLAGS ${MPI_COMPILE_CMDLINE})
string(REGEX MATCHALL (^| )-[Dfp]([^\ ]+|\[^\]+\)
MPI_ALL_COMPILE_FLAGS ${MPI_COMPILE_CMDLINE})
# Extract linker flags from the link command line
#ORIGINAL string(REGEX MATCHALL (^| )-Wl,([^\ ]+|\[^\]+\)
MPI_ALL_LINK_FLAGS ${MPI_LINK_CMDLINE})
string(REGEX MATCHALL (^| )-[pWl]([^\ ]+|\[^\]+\)
MPI_ALL_LINK_FLAGS ${MPI_LINK_CMDLINE})
==
Issue History
Date ModifiedUsername FieldChange
==
2013-07-30 11:08 higginsNew Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --deprecated-warnings and cmake --deprecated-errors
On 2013-07-30 08:45, Brad King wrote: On 07/30/2013 06:30 AM, Stephen Kelly wrote: I wonder if we should add --deprecated-warnings and --deprecated-errors and document them in cmake --help, as --warn-uninitialized etc? I think it's something we can do after 2.8.12, but I want to make sure it doesn't change anything in how the deprecation stuff works or is used currently. The first warning option ever added was -Wdev and the intention at the time was to use -W... for all warning options. That was forgotten by the time --warn-uninitialized was created. Perhaps that can be cleaned up now: -Wdeprecated -Wdeprecated=error -Wuninitialized If you haven't already, please consider -W[no-][error=]name (instead of -Wname[=error]) for consistency with GCC... e.g.: -Wdeprecated -Wno-deprecated -Werror=deprecated -Wno-error=deprecated Note: -Wname = name_level = std::min(name_level, WARN) -Wnoname = name_level = IGNORED -Werror=name = name_level = ERROR -Wno-error=name = name_level = std::max(name_level, WARN) (where IGNORED WARN ERROR) -- Matthew -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014324]: CMAKE_OSX_SYSROOT isn't set with pre-4.3 Xcode
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14324
==
Reported By:John Ralls
Assigned To:
==
Project:CMake
Issue ID: 14324
Category: CMake
Reproducibility:have not tried
Severity: block
Priority: normal
Status: new
==
Date Submitted: 2013-07-30 19:23 EDT
Last Modified: 2013-07-30 19:23 EDT
==
Summary:CMAKE_OSX_SYSROOT isn't set with pre-4.3 Xcode
Description:
When bootstrapping cmake with pre-XCode-4.3 compilers (in this case
Xcode-3.2.2), CMAKE_OSX_SYSROOT isn't set, resulting in this error:
CMake Error at Modules/Platform/Darwin.cmake:196 (message):
CMAKE_OSX_DEPLOYMENT_TARGET is '10.5' but CMAKE_OSX_SYSROOT:
is not set to a MacOSX SDK with a recognized version. Either set
CMAKE_OSX_SYSROOT to a valid SDK or set CMAKE_OSX_DEPLOYMENT_TARGET to
empty.
Steps to Reproduce:
With a pre-Xcode-4.3 Xcode installed and configured with xcode-select, run
bootstrap.
Set $SDKROOT to the path for the appropriate SDK in the environment and try
again. Both attempts fail.
Additional Information:
There are in fact two problems: The first is at Darwin.cmake line 123:
foreach(d Platforms/MacOSX.platform/Developer/SDKs SDKs)
The path 'Platforms/MacOSX.platform/Developer/SDKs' applies only to Xcode-4.3
and later, those where Xcode is a self-contained application bundle. Earlier
versions of Xcode, those distributed as a .mpkg, installed to
$DEVELOPER_DIR/SDKs, where $DEVELOPER_DIR defaults to /Developer.
The second problem is that set(foo bar CACHE baz waldo) seems to not work with
the gcc-4.2.1 provided with Xcode before version 4. This can be observed by
instrumenting Darwin.cmake as follows:
diff --git a/Modules/Platform/Darwin.cmake b/Modules/Platform/Darwin.cmake
index f0652b9..3ccff88 100644
--- a/Modules/Platform/Darwin.cmake
+++ b/Modules/Platform/Darwin.cmake
@@ -150,8 +150,12 @@ foreach(v CMAKE_OSX_SYSROOT _CMAKE_OSX_SYSROOT_DEFAULT)
break()
endif()
endforeach()
+message(STATUS CMAKE_OSX_SYSROOT: ${CMAKE_OSX_SYSROOT})
+message(STATUS _CMAKE_OSX_SYSROOT_DEFAULT: ${_CMAKE_OSX_SYSROOT_DEFAULT})
set(CMAKE_OSX_SYSROOT ${_CMAKE_OSX_SYSROOT_DEFAULT} CACHE
${_CMAKE_OSX_SYSROOT_TYPE}
The product will be built against the headers and libraries located inside
the indicated SDK.)
+message(STATUS CMAKE_OSX_SYSROOT: ${CMAKE_OSX_SYSROOT})
+message(STATUS _CMAKE_OSX_SYSROOT_DEFAULT: ${_CMAKE_OSX_SYSROOT_DEFAULT})
# Transform the cached value to something we can use.
set(_CMAKE_OSX_SYSROOT_ORIG ${CMAKE_OSX_SYSROOT})
Which produces this output with Xcode-3.2.2:
-- CMAKE_OSX_SYSROOT:
-- _CMAKE_OSX_SYSROOT_DEFAULT: /Volumes/Data/XCode3/SDKs/MacOSX10.5.sdk
-- CMAKE_OSX_SYSROOT:
-- _CMAKE_OSX_SYSROOT_DEFAULT: /Volumes/Data/XCode3/SDKs/MacOSX10.5.sdk
and this with Xcode-4.6.3:
-- CMAKE_OSX_SYSROOT:
-- _CMAKE_OSX_SYSROOT_DEFAULT:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
-- CMAKE_OSX_SYSROOT:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
-- _CMAKE_OSX_SYSROOT_DEFAULT:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
==
Issue History
Date ModifiedUsername FieldChange
==
2013-07-30 19:23 John Ralls New Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
