Re: [cmake-developers] Support of codesign
Hi Clint,
I have another patch to tweak the error output a little bit. If codesign
fails it won't be possible to get the error message of codesign itself.
That is a little bit confusing because it just fails without an
understandable reason.
This patch will print the output of codesign if it fails.
Best regards
André Klitzing
2014-10-28 19:22 GMT+01:00 Clinton Stimpson clin...@elemtech.com:
Thanks for the patch.
Its in the repository now.
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=bd3fbf3
Clint
From ad4671b3c469f3f3eb89e227b54c40cb09b25474 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9=20Klitzing?= aklitz...@gmail.com
Date: Fri, 20 Feb 2015 10:45:14 +0100
Subject: [PATCH] CPack: Print output from codesign if signing fails
---
Source/CPack/cmCPackBundleGenerator.cxx | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git x/Source/CPack/cmCPackBundleGenerator.cxx y/Source/CPack/cmCPackBundleGenerator.cxx
index e751568..6e7a26b 100644
--- x/Source/CPack/cmCPackBundleGenerator.cxx
+++ y/Source/CPack/cmCPackBundleGenerator.cxx
@@ -214,6 +214,7 @@ int cmCPackBundleGenerator::SignBundle(const std::string src_dir)
// codesign the application.
if(!cpack_apple_cert_app.empty())
{
+std::string output;
std::string bundle_path;
bundle_path = src_dir + /;
bundle_path += this-GetOption(CPACK_BUNDLE_NAME);
@@ -240,11 +241,11 @@ int cmCPackBundleGenerator::SignBundle(const std::string src_dir)
temp_sign_file_cmd bundle_path;
temp_sign_file_cmd it-c_str() \;
- if(!this-RunCommand(temp_sign_file_cmd))
+ if(!this-RunCommand(temp_sign_file_cmd, output))
{
cmCPackLogger(cmCPackLog::LOG_ERROR,
Error signing file:
- bundle_path it-c_str() std::endl);
+ bundle_path it-c_str() std::endl output std::endl);
return 0;
}
@@ -256,11 +257,11 @@ int cmCPackBundleGenerator::SignBundle(const std::string src_dir)
temp_sign_binary_cmd --deep -f -s \ cpack_apple_cert_app;
temp_sign_binary_cmd \ \ bundle_path \;
-if(!this-RunCommand(temp_sign_binary_cmd))
+if(!this-RunCommand(temp_sign_binary_cmd, output))
{
cmCPackLogger(cmCPackLog::LOG_ERROR,
Error signing the application binary.
- std::endl);
+ std::endl output std::endl);
return 0;
}
@@ -276,11 +277,11 @@ int cmCPackBundleGenerator::SignBundle(const std::string src_dir)
}
temp_codesign_cmd \ bundle_path \;
-if(!this-RunCommand(temp_codesign_cmd))
+if(!this-RunCommand(temp_codesign_cmd, output))
{
cmCPackLogger(cmCPackLog::LOG_ERROR,
Error signing the application package.
- std::endl);
+ std::endl output std::endl);
return 0;
}
--
2.3.0
--
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 0015412]: find_dependency macro does not check for UPPERCASED_NAME_FOUND
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15412
==
Reported By:Kiron
Assigned To:
==
Project:CMake
Issue ID: 15412
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-02-20 07:53 EST
Last Modified: 2015-02-20 07:53 EST
==
Summary:find_dependency macro does not check for
UPPERCASED_NAME_FOUND
Description:
The find_dependency macro only checks for ${dep}_FOUND and not for the
alternative form UPPERCASED_NAME_FOUND.
Not UPPERCASED_NAME_FOUND considering means, that the find_dependency macro
will not work with FindModules which use FIND_PACKAGE_HANDLE_STANDARD_ARGS and
do not set FOUND_VAR to ${CMAKE_FIND_PACKAGE_NAME}, since by default it will set
UPPERCASED_NAME_FOUND. Or other FindModules which just set
UPPERCASED_NAME_FOUND.
I also think in line 80 till 83 it should use unset instead of set.
[1]
http://www.cmake.org/gitweb?p=stage/cmake.git;a=blob;f=Modules/CMakeFindDependencyMacro.cmake;h=73efaae7cddc5915fb5e273decd7b703883b929d;hb=HEAD#l78
==
Issue History
Date ModifiedUsername FieldChange
==
2015-02-20 07:53 Kiron 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] Introduction and volunteering for the Matlab package
On 02/19/2015 04:58 PM, Raffi Enficiaud wrote: I just unset this variable before the call to the find_program, and now it works good. Yes, this is expected. If find_program sees that the variable is already set then it assumes the value is correct. The idea is that projects can prevent the find from actually running by doing their own thing to set the variable first. -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] Initial Attempt at Green Hill MULTI IDE Generator Support
But I still get the CMake.GetPrerequisites test timing out.
I don't see that in:
https://open.cdash.org/buildSummary.php?buildid=3701966
You're right. For some reason it is not timing out. It just takes a really long
time. I wonder if my path is long. That test takes an order of magnitude longer
on my machine than the rest:
https://open.cdash.org/testSummary.php?project=1name=CMake.GetPrerequisitesdate=2015-02-19.
Please add to your dashboard scripts a line like:
set(ENV{PATH} ...)
to set a path without python in it for running this dashboard.
...
Also, I haven't debugged the warnings in the Build row yet.
That may be due to the lack of a fresh build tree:
#CTEST_EMPTY_BINARY_DIRECTORY(${CTEST_BINARY_DIRECTORY})
I'll give it a try this weekend.
Geoffrey Viola
SOFTWARE ENGINEER
asirobots.com
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Friday, February 20, 2015 8:35 AM
To: Geoffrey Viola
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] Initial Attempt at Green Hill MULTI IDE
Generator Support
On 02/19/2015 07:44 PM, Geoffrey Viola wrote:
The nightly build that I use does use the cmake_common.cmake script
to grab the latest code, build, test it, etc. Here's what my nightly
build results look like:
https://open.cdash.org/buildSummary.php?buildid=3701008.
Sorry, I mixed up your nightly build and the experimental build you linked.
I made that small change in the attached patch.
I ran another experimental build in debug. Here are those results:
https://open.cdash.org/buildSummary.php?buildid=3701457.
Thanks.
I expected the CMakeOnly.MajorVersionSelection-PythonInterp_2 to
fail because I have the Python 3.3 executable in my path.
Please add to your dashboard scripts a line like:
set(ENV{PATH} ...)
to set a path without python in it for running this dashboard.
That will avoid the problem, which is a separate discussion to address. (The
test is covering that the requested major version is preferred if executables
called python2 and python3 are both in the path, but if just python is
available then it is
used.)
But I still get the CMake.GetPrerequisites test timing out.
I don't see that in:
https://open.cdash.org/buildSummary.php?buildid=3701966
Also, I haven't debugged the warnings in the Build row yet.
That may be due to the lack of a fresh build tree:
#CTEST_EMPTY_BINARY_DIRECTORY(${CTEST_BINARY_DIRECTORY})
This suit of tests was done using a script based on the autogenerated
CTestScript.cmake script.
I don't think CDash has been configured to generate those for CMake properly.
Once you have the nightly dashboard submission running cleanly then we can look
at merging your generator for testing in 'next' to have it covered there.
-Brad
This message contains confidential information and is intended only for the
recipient. If you are not the named addressee you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately if you
have received this e-mail by mistake and delete this e-mail from your system.
Finally, the recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage caused by
any virus transmitted by this email.
--
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] Support of codesign
On Friday, February 20, 2015 12:07:55 PM A. Klitzing wrote: Hi Clint, I have another patch to tweak the error output a little bit. If codesign fails it won't be possible to get the error message of codesign itself. That is a little bit confusing because it just fails without an understandable reason. This patch will print the output of codesign if it fails. Thanks. http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=7b582d1 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] Initial Attempt at Green Hill MULTI IDE Generator Support
On 02/19/2015 07:44 PM, Geoffrey Viola wrote:
The nightly build that I use does use the cmake_common.cmake script
to grab the latest code, build, test it, etc. Here's what my nightly
build results look like:
https://open.cdash.org/buildSummary.php?buildid=3701008.
Sorry, I mixed up your nightly build and the experimental build you linked.
I made that small change in the attached patch.
I ran another experimental build in debug. Here are those results:
https://open.cdash.org/buildSummary.php?buildid=3701457.
Thanks.
I expected the CMakeOnly.MajorVersionSelection-PythonInterp_2 to fail
because I have the Python 3.3 executable in my path.
Please add to your dashboard scripts a line like:
set(ENV{PATH} ...)
to set a path without python in it for running this dashboard.
That will avoid the problem, which is a separate discussion to
address. (The test is covering that the requested major version
is preferred if executables called python2 and python3 are
both in the path, but if just python is available then it is
used.)
But I still get the CMake.GetPrerequisites test timing out.
I don't see that in:
https://open.cdash.org/buildSummary.php?buildid=3701966
Also, I haven't debugged the warnings in the Build row yet.
That may be due to the lack of a fresh build tree:
#CTEST_EMPTY_BINARY_DIRECTORY(${CTEST_BINARY_DIRECTORY})
This suit of tests was done using a script based on the
autogenerated CTestScript.cmake script.
I don't think CDash has been configured to generate those for
CMake properly. Once you have the nightly dashboard submission
running cleanly then we can look at merging your generator for
testing in 'next' to have it covered there.
-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 0015413]: CheckStructHasMember generates an uninitialized variable warning
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15413 == Reported By:Lekensteyn Assigned To: == Project:CMake Issue ID: 15413 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-02-20 11:09 EST Last Modified: 2015-02-20 11:09 EST == Summary:CheckStructHasMember generates an uninitialized variable warning Description: Related to bug 15203 (which is fixed in CMake 3.2). The current check_struct_has_member macro (as can be found in CMake 3.2) generates an uninitialized variable warning (noticeable via Clangs static code analyzer). A patch was proposed in http://www.cmake.org/Bug/view.php?id=15203#c37979, but a valid concern was raised about invoking C++ constructors. Here is a new minimal patch which uses sizeof instead. == Issue History Date ModifiedUsername FieldChange == 2015-02-20 11:09 Lekensteyn New Issue 2015-02-20 11:09 Lekensteyn File Added: 0001-CheckStructHasMember-fix-null-deref-warning.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
