Re: [cmake-developers] Modules/GetPrequisites.cmake issues
On Monday, August 03, 2015 10:22:18 AM Brad King wrote: On 07/30/2015 10:56 AM, Brad King wrote: Thanks! Applied: Those patches exposed a bug in FindMPI, so I fixed that and rebased the other changes on it: FindMPI: Drop unnecessary and incorrect use of GetPrerequisites http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c46b6ae GetPrerequisites: Add error checks for execute_process() calls http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=afb674ab GetPrerequisites: Optionally filter objdump output for speed http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5d0a8b1a -Brad Thanks. I believe that also fixes http://www.cmake.org/Bug/view.php?id=13351 Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Modules/GetPrequisites.cmake issues
On 07/30/2015 10:56 AM, Brad King wrote: Thanks! Applied: Those patches exposed a bug in FindMPI, so I fixed that and rebased the other changes on it: FindMPI: Drop unnecessary and incorrect use of GetPrerequisites http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c46b6ae GetPrerequisites: Add error checks for execute_process() calls http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=afb674ab GetPrerequisites: Optionally filter objdump output for speed http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5d0a8b1a -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Add command line options for deprecation message control
On 08/03/2015 09:43 AM, Domen Vrankar wrote: Since CPack only gets CPACK_* variables from CMake we can't use CMAKE_SUPPRESS_DEVELOPER_ERRORS to revert back to warnings. The mistake is that message() now treats warnings as errors unless explicitly suppressed. While normal CMake runs suppress it by default, script mode and CPack have no such initialization. I've inverted the logic to require the mode to be explicitly enabled: cmake: Do not treat developer warnings as errors by default in scripts http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=975426ce That should fix the test failures. On 08/01/2015 04:03 AM, Stephen Kelly wrote: I still think it's a bit odd that policies and message(DEPRECATED) use a different semantic though (ie, message(DEPRECATED) should issue a warning by default unless -Wno-dev is used). ...or -Wno-deprecated That semantic change may be reasonable but is independent of the command line options change under discussion here. It may require a policy too. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-3.3.0-Linux-x86_64.tar.gz on download page is not gzipped
thank you for the good catch and for fixing this! now the download behaves as expected on my Chrome version. thank you again and keep it up! radovan On Mon, Aug 3, 2015 at 8:05 PM Brad King brad.k...@kitware.com wrote: On 07/31/2015 09:54 AM, Nils Gladitz wrote: The HTTP response for cmake-3.3.0.tar.gz does contain: Content-Encoding: x-gzip Thanks for pointing this out. Which I think does tell clients that they should decompress to get the actual content which is declared to be of Content-Type:application/x-gzip; this is I think incorrect unless the HTTP server compresses the .tar.gz once more with gzip before delivery. Our admins have fixed the configuration on the server so that there is no Content-Encoding header for .Z and .gz files anymore. I think that configuration was there by mistake. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Macro generation for relaxed constexpr
Qt 5 provides a macro for this context which expands to either 'const' or
'constexpr' depending on whether cxx_constexpr is available, and another
macro which expands to either 'const' or 'constexpr' depending on whether
cxx_relaxed_constexpr is available.
Thinking of it, since C++14 constexpr does not imply const anymore, so
isn't this macro ambiguous wrt standard c++ ?
On Wed, Jul 8, 2015 at 10:42 PM, Stephen Kelly steve...@gmail.com wrote:
Jean-Michaël Celerier wrote:
I think there should be a test for the different allowed contexts of the
${prefix_arg}_RELAXED_CONSTEXPR and ${prefix_arg}_CONSTEXPR macros. Could
you extend Tests/Module/WriteCompilerDetectionHeader with a test for
that?
For sure, I'll do this asap.
Great, thanks!
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[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
Re: [cmake-developers] Modules/GetPrequisites.cmake issues
On 03/08/2015 15:22, Brad King wrote: Hi Brad, On 07/30/2015 10:56 AM, Brad King wrote: Thanks! Applied: Those patches exposed a bug in FindMPI, so I fixed that and rebased the other changes on it: Glad my patch flushed out an unrelated defect. OTOH there are many other uses of execute_process() in the Modules that look like they might be suspect through not checking if the process returned a success status. It's not a blanket change as some do seem to be failsafe by checking for error output. Even a very simple command might fail unexpectedly due to access rights or similar. FindMPI: Drop unnecessary and incorrect use of GetPrerequisites http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c46b6ae GetPrerequisites: Add error checks for execute_process() calls http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=afb674ab GetPrerequisites: Optionally filter objdump output for speed http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5d0a8b1a -Brad Regards Bill Somerville. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Add command line options for deprecation message control
Brad King wrote: On 08/01/2015 04:03 AM, Stephen Kelly wrote: I still think it's a bit odd that policies and message(DEPRECATED) use a different semantic though (ie, message(DEPRECATED) should issue a warning by default unless -Wno-dev is used). ...or -Wno-deprecated That semantic change may be reasonable but is independent of the command line options change under discussion here. It may require a policy too. I filed a bug to track this: http://www.cmake.org/Bug/view.php?id=15677 Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Macro generation for relaxed constexpr
Jean-Michaël Celerier wrote: Qt 5 provides a macro for this context which expands to either 'const' or 'constexpr' depending on whether cxx_constexpr is available, and another macro which expands to either 'const' or 'constexpr' depending on whether cxx_relaxed_constexpr is available. Thinking of it, since C++14 constexpr does not imply const anymore, so isn't this macro ambiguous wrt standard c++ ? The 'const' keyword can be used in multiple contexts. Can you clarify which you mean with a reference to some document? Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-3.3.0-Linux-x86_64.tar.gz on download page is not gzipped
On 07/31/2015 09:54 AM, Nils Gladitz wrote: The HTTP response for cmake-3.3.0.tar.gz does contain: Content-Encoding: x-gzip Thanks for pointing this out. Which I think does tell clients that they should decompress to get the actual content which is declared to be of Content-Type:application/x-gzip; this is I think incorrect unless the HTTP server compresses the .tar.gz once more with gzip before delivery. Our admins have fixed the configuration on the server so that there is no Content-Encoding header for .Z and .gz files anymore. I think that configuration was there by mistake. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 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
Re: [cmake-developers] Add command line options for deprecation message control
The branch seems to make the RunCMake.CPack_RPM test fail on my machine. I have not investigated. Missed this thread... I was talking to Brad about this. Failing test is written exactly for testing author warning message (CPackRPM.cmake:560). RPM packages may be relocatable but if relocation paths don't match with any file paths in package an author warning is output but package is still created. Since CPack only gets CPACK_* variables from CMake we can't use CMAKE_SUPPRESS_DEVELOPER_ERRORS to revert back to warnings. If this is the only location where CPack uses developer messages we could change it to normal info message but implementing this fallback mechanism for CPack (and CTest?) would probably be a more complete solution. Regards, Domen -- 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:
Re: [cmake-developers] [PATCH] Macro generation for relaxed constexpr
I'm referring to the const used after methods (struct { int f() const; }).
Here is an example : https://ideone.com/C28SMn
Best regards :)
On Mon, Aug 3, 2015 at 7:20 PM, Stephen Kelly steve...@gmail.com wrote:
Jean-Michaël Celerier wrote:
Qt 5 provides a macro for this context which expands to either 'const'
or
'constexpr' depending on whether cxx_constexpr is available, and another
macro which expands to either 'const' or 'constexpr' depending on whether
cxx_relaxed_constexpr is available.
Thinking of it, since C++14 constexpr does not imply const anymore, so
isn't this macro ambiguous wrt standard c++ ?
The 'const' keyword can be used in multiple contexts. Can you clarify which
you mean with a reference to some document?
Thanks,
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Segfault
On 08/02/2015 01:35 PM, Justin Borodinsky wrote:
I received a segfault during generation with the attached list-file.
Attached is a patch to master which avoids the null pointer access
causing it, but there may be a better fix.
Please try this patch instead.
Thanks,
-Brad
From 33d52a96f7f622f96a3c656babe59795f7cabf8f Mon Sep 17 00:00:00 2001
Message-Id: 33d52a96f7f622f96a3c656babe59795f7cabf8f.1438633052.git.brad.k...@kitware.com
From: Brad King brad.k...@kitware.com
Date: Mon, 3 Aug 2015 15:28:41 -0400
Subject: [PATCH] Reject TARGET_PDB_FILE for imported targets instead of
crashing
Reported-by: Justin Borodinsky justin.borodin...@gmail.com
---
Source/cmGeneratorExpressionNode.cxx | 7 +++
Source/cmTarget.cxx | 1 +
.../GeneratorExpression/ImportedTarget-TARGET_PDB_FILE-result.txt | 1 +
.../GeneratorExpression/ImportedTarget-TARGET_PDB_FILE-stderr.txt | 8
.../GeneratorExpression/ImportedTarget-TARGET_PDB_FILE.cmake | 2 ++
Tests/RunCMake/GeneratorExpression/RunCMakeTest.cmake | 1 +
6 files changed, 20 insertions(+)
create mode 100644 Tests/RunCMake/GeneratorExpression/ImportedTarget-TARGET_PDB_FILE-result.txt
create mode 100644 Tests/RunCMake/GeneratorExpression/ImportedTarget-TARGET_PDB_FILE-stderr.txt
create mode 100644 Tests/RunCMake/GeneratorExpression/ImportedTarget-TARGET_PDB_FILE.cmake
diff --git a/Source/cmGeneratorExpressionNode.cxx b/Source/cmGeneratorExpressionNode.cxx
index f3527ff..140e2e4 100644
--- a/Source/cmGeneratorExpressionNode.cxx
+++ b/Source/cmGeneratorExpressionNode.cxx
@@ -1597,6 +1597,13 @@ struct TargetFilesystemArtifactResultCreatorArtifactPdbTag
cmGeneratorExpressionContext *context,
const GeneratorExpressionContent *content)
{
+if (target-IsImported())
+ {
+ ::reportError(context, content-GetOriginalExpression(),
+TARGET_PDB_FILE not allowed for IMPORTED targets.);
+ return std::string();
+ }
+
std::string language = target-Target-GetLinkerLanguage(context-Config);
std::string pdbSupportVar = CMAKE_ + language + _LINKER_SUPPORTS_PDB;
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index cf33791..3b43e6f 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -3356,6 +3356,7 @@ void cmTarget::ComputeLinkClosure(const std::string config,
// Get languages built in this target.
UNORDERED_SETstd::string languages;
LinkImplementation const* impl = this-GetLinkImplementation(config);
+ assert(impl);
for(std::vectorstd::string::const_iterator li = impl-Languages.begin();
li != impl-Languages.end(); ++li)
{
diff --git a/Tests/RunCMake/GeneratorExpression/ImportedTarget-TARGET_PDB_FILE-result.txt b/Tests/RunCMake/GeneratorExpression/ImportedTarget-TARGET_PDB_FILE-result.txt
new file mode 100644
index 000..d00491f
--- /dev/null
+++ b/Tests/RunCMake/GeneratorExpression/ImportedTarget-TARGET_PDB_FILE-result.txt
@@ -0,0 +1 @@
+1
diff --git a/Tests/RunCMake/GeneratorExpression/ImportedTarget-TARGET_PDB_FILE-stderr.txt b/Tests/RunCMake/GeneratorExpression/ImportedTarget-TARGET_PDB_FILE-stderr.txt
new file mode 100644
index 000..d915ecb
--- /dev/null
+++ b/Tests/RunCMake/GeneratorExpression/ImportedTarget-TARGET_PDB_FILE-stderr.txt
@@ -0,0 +1,8 @@
+CMake Error at ImportedTarget-TARGET_PDB_FILE.cmake:2 \(add_custom_target\):
+ Error evaluating generator expression:
+
+\$TARGET_PDB_FILE:empty
+
+ TARGET_PDB_FILE not allowed for IMPORTED targets.
+Call Stack \(most recent call first\):
+ CMakeLists.txt:3 \(include\)
diff --git a/Tests/RunCMake/GeneratorExpression/ImportedTarget-TARGET_PDB_FILE.cmake b/Tests/RunCMake/GeneratorExpression/ImportedTarget-TARGET_PDB_FILE.cmake
new file mode 100644
index 000..c55c5d5
--- /dev/null
+++ b/Tests/RunCMake/GeneratorExpression/ImportedTarget-TARGET_PDB_FILE.cmake
@@ -0,0 +1,2 @@
+add_library(empty UNKNOWN IMPORTED)
+add_custom_target(custom COMMAND echo $TARGET_PDB_FILE:empty)
diff --git a/Tests/RunCMake/GeneratorExpression/RunCMakeTest.cmake b/Tests/RunCMake/GeneratorExpression/RunCMakeTest.cmake
index 1c8fab5..cba3941 100644
--- a/Tests/RunCMake/GeneratorExpression/RunCMakeTest.cmake
+++ b/Tests/RunCMake/GeneratorExpression/RunCMakeTest.cmake
@@ -26,6 +26,7 @@ run_cmake(COMPILE_LANGUAGE-add_library)
run_cmake(COMPILE_LANGUAGE-add_test)
run_cmake(COMPILE_LANGUAGE-unknown-lang)
+run_cmake(ImportedTarget-TARGET_PDB_FILE)
if(LINKER_SUPPORTS_PDB)
run_cmake(NonValidTarget-TARGET_PDB_FILE)
run_cmake(ValidTarget-TARGET_PDB_FILE)
--
2.4.6
--
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:
Re: [cmake-developers] Java support
On 07/31/2015 04:08 AM, CHEVRIER, Marc wrote: New version of patches. Thanks. I applied the first three with minor tweaks and merged to 'next' for testing: FindJava: Add support for idlj and jarsigner tools http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e499264 UseJava: Teach add_jar to support file syntax for sources http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=244e9364 UseJava: Teach install_jar new DESTINATION and COMPONENT options http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8f8d824d The 0004 patch (create_javah) fails testing for me on Linux: $ ctest -R Java.Javah -V ... 261: Running test command: /usr/lib/jvm/java-7-openjdk-amd64/bin/java -classpath hello3.jar HelloWorld2 261: Test command failed: /usr/lib/jvm/java-7-openjdk-amd64/bin/java 261: Native code library failed to load. 261: java.lang.UnsatisfiedLinkError: no B in java.library.path ... Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
