[cmake-developers] [CMake 0015176]: typo in Modules/GNUInstallDirs.cmake
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15176 == Reported By:David Coppa Assigned To: == Project:CMake Issue ID: 15176 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-09-29 06:24 EDT Last Modified: 2014-09-29 06:24 EDT == Summary:typo in Modules/GNUInstallDirs.cmake Description: Commit d4fdd9c189f85d659f4294f8ec6da3e7e51215ec (GNUInstallDirs: use the proper default for info and man paths on OpenBSD) introduced a typo: CMAKE_INSTALL_MANDDIR - CMAKE_INSTALL_MANDIR The attached diff fixes the issue. == Issue History Date ModifiedUsername FieldChange == 2014-09-29 06:24 David CoppaNew Issue 2014-09-29 06:24 David CoppaFile Added: 0001-Fix-typo-in-Modules-GNUInstallDirs.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
Re: [cmake-developers] Support of codesign
It should not be an error for 'codesign' to not be available
in the PATH. The user may have set CPACK_COMMAND_CODESIGN
to some other location. The error should only occur if no
value for CPACK_COMMAND_CODESIGN is available when the tool
is actually needed for signing.
I attached another patch that will fix the broken tests. It will check for
defined CPACK_APPLE_CERT_APP before it will search for 'codesign'.
Well, the FindProgram line for codesign looks like the line for Rez,
hdiutil, SetFile and so on. I don't know cmake sources enough... but
shouldn't it be the same here?
André
From 5f2e6a0b2d6253515a5696b283976414dc72eb85 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9=20Klitzing?= aklitz...@gmail.com
Date: Mon, 29 Sep 2014 12:05:59 +0200
Subject: [PATCH] CPack: Add support for code signing of bundles on MacOS
---
Modules/CPackDMG.cmake | 24 +++
Source/CPack/cmCPackBundleGenerator.cxx| 18 -
Source/CPack/cmCPackBundleGenerator.h | 1 +
Source/CPack/cmCPackDragNDropGenerator.cxx | 107 +
Source/CPack/cmCPackDragNDropGenerator.h | 1 +
5 files changed, 150 insertions(+), 1 deletion(-)
diff --git a/Modules/CPackDMG.cmake b/Modules/CPackDMG.cmake
index b7a6ba5..fb9fe39 100644
--- a/Modules/CPackDMG.cmake
+++ b/Modules/CPackDMG.cmake
@@ -36,6 +36,23 @@
# background image is set. The background image is applied after applying the
# custom .DS_Store file.
#
+#
+#
+# .. variable:: CPACK_APPLE_CERT_APP
+# The name of your Apple supplied code signing certificate for the application.
+# The name usually takes the form Developer ID Application: [Name] or
+# 3rd Party Mac Developer Application: [Name]. If this variable is not set
+# the application will not be signed.
+#
+# .. variable:: CPACK_APPLE_ENTITLEMENTS
+# The name of the plist file that contains your apple entitlements for sandboxing
+# your application. This file is required for submission to the Mac App Store.
+#
+# .. variable:: CPACK_APPLE_CODESIGN_FILES
+# A list of additional files that you wish to be signed. You do not need to
+# list the main application folder, or the main executable. You should
+# list any frameworks and plugins that are included in your app bundle.
+#
# .. variable:: CPACK_COMMAND_HDIUTIL
#
# Path to the hdiutil(1) command used to operate on disk image files on Mac
@@ -54,6 +71,13 @@
# Path to the Rez(1) command used to compile resources on Mac OS X. This
# variable can be used to override the automatically detected command (or
# specify its location if the auto-detection fails to find it.)
+#
+# .. variable:: CPACK_COMMAND_CODESIGN
+# Path to the codesign(1) command used to sign applications with an
+# Apple cert. This variable can be used to override the automatically
+# detected command (or specify its location if the auto-detection fails
+# to find it.)
+#
#=
# Copyright 2006-2012 Kitware, Inc.
diff --git a/Source/CPack/cmCPackBundleGenerator.cxx b/Source/CPack/cmCPackBundleGenerator.cxx
index 6c994f1..c5f7139 100644
--- a/Source/CPack/cmCPackBundleGenerator.cxx
+++ b/Source/CPack/cmCPackBundleGenerator.cxx
@@ -53,7 +53,7 @@ const char* cmCPackBundleGenerator::GetPackagingInstallPrefix()
}
//--
-int cmCPackBundleGenerator::PackageFiles()
+int cmCPackBundleGenerator::ConstructAppBundle()
{
// Get required arguments ...
@@ -165,6 +165,22 @@ int cmCPackBundleGenerator::PackageFiles()
cmSystemTools::SetPermissions(command_target.str().c_str(), 0777);
}
+ return 1;
+}
+
+//--
+int cmCPackBundleGenerator::PackageFiles()
+{
+ if(!this-ConstructAppBundle())
+{
+return 0;
+}
+
+ if(!this-SignPackage(toplevel))
+{
+return 0;
+}
+
return this-CreateDMG(toplevel, packageFileNames[0]);
}
diff --git a/Source/CPack/cmCPackBundleGenerator.h b/Source/CPack/cmCPackBundleGenerator.h
index ed0187d..fa9f2fa 100644
--- a/Source/CPack/cmCPackBundleGenerator.h
+++ b/Source/CPack/cmCPackBundleGenerator.h
@@ -31,6 +31,7 @@ public:
protected:
virtual int InitializeInternal();
virtual const char* GetPackagingInstallPrefix();
+ int ConstructAppBundle();
int PackageFiles();
bool SupportsComponentInstallation() const;
diff --git a/Source/CPack/cmCPackDragNDropGenerator.cxx b/Source/CPack/cmCPackDragNDropGenerator.cxx
index 9f0a77e..4e7e9ca 100644
--- a/Source/CPack/cmCPackDragNDropGenerator.cxx
+++ b/Source/CPack/cmCPackDragNDropGenerator.cxx
@@ -103,6 +103,21 @@ int cmCPackDragNDropGenerator::InitializeInternal()
}
this-SetOptionIfNotSet(CPACK_COMMAND_REZ, rez_path.c_str());
+ if(this-GetOption(CPACK_APPLE_CERT_APP))
+{
+const std::string codesign_path = cmSystemTools::FindProgram(codesign,
+ std::vectorstd::string(), false);
+
Re: [cmake-developers] iOS support
On 23-Sep-14 19:42, Florent Castelli wrote: On 23 Sep 2014, at 16:56, Bill Hoffman bill.hoff...@kitware.com wrote: That said it would be really cool to beef up the xcode support enough to be able to create an actual ios app. I have not dug into that enough. Should be able to do most of it with CMAKE_XCODE_ATTRIBUTE. I will look into this try_compile COPY_FILE issue today and get back to the list. It would be great if you could get an example/Test in place that builds an app for a device and works with Xcode and for a stretch goal also works with makefiles or ninja. Couple of more things. Much of the stuff found in these toolchains: https://github.com/Kitware/VTK/blob/master/CMake/ios.toolchain.xcode.cmake https://github.com/Kitware/VTK/blob/master/CMake/ios.simulator.toolchain.cmake https://github.com/Kitware/VTK/blob/master/CMake/ios.device.toolchain.cmake Should be in Platform files. If we created ios platform files we could remove most of the stuff from those toolchain files. This would be a great thing to work on. The problem is that I want a project that is usable by developers directly and you can't really force them to target just the simulator. It should work for targeting both simulator and real device. So having a generic iOS toolchain that can generate both in one project is a requirement for me. Hi, Universal libraries can be built by setting CMAKE_OSX_SYSROOT to iphoneos. This is how it works for me: * https://github.com/ruslo/polly/blob/master/ios-7-1.cmake * https://github.com/ruslo/polly/blob/master/os/iphone.cmake * https://github.com/ruslo/polly/wiki/Toolchain-list#ios real root was found by invoking `xcode-select -print-path`, i.e. you can switch iOS version by providing appropriate DEVELOPER_DIR environment variable. Works for Xcode only (since Xcode 5.0). Ruslo -- 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
- Original Message - It should not be an error for 'codesign' to not be available in the PATH. The user may have set CPACK_COMMAND_CODESIGN to some other location. The error should only occur if no value for CPACK_COMMAND_CODESIGN is available when the tool is actually needed for signing. I attached another patch that will fix the broken tests. It will check for defined CPACK_APPLE_CERT_APP before it will search for 'codesign'. Well, the FindProgram line for codesign looks like the line for Rez, hdiutil, SetFile and so on. I don't know cmake sources enough... but shouldn't it be the same here? Because it appears to only work with the Bundle generator, can you please move the documentation from Modules/CPackDMG.cmake to Modules/CPackBundle.cmake? Or did you intend to make this feature work for both the DragNDrop and Bundle generator? Thanks, 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] Support of codesign
Maybe it shouldn't even be a CPack thing. Maybe it should be an install time step so that all CPack generators will contains signed binaries if codesign is used... D On Mon, Sep 29, 2014 at 9:55 AM, clin...@elemtech.com wrote: It should not be an error for 'codesign' to not be available in the PATH. The user may have set CPACK_COMMAND_CODESIGN to some other location. The error should only occur if no value for CPACK_COMMAND_CODESIGN is available when the tool is actually needed for signing. I attached another patch that will fix the broken tests. It will check for defined CPACK_APPLE_CERT_APP before it will search for 'codesign'. Well, the FindProgram line for codesign looks like the line for Rez, hdiutil, SetFile and so on. I don't know cmake sources enough... but shouldn't it be the same here? Because it appears to only work with the Bundle generator, can you please move the documentation from Modules/CPackDMG.cmake to Modules/CPackBundle.cmake? Or did you intend to make this feature work for both the DragNDrop and Bundle generator? Thanks, 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 -- 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
Maybe it shouldn't even be a CPack thing. Maybe it should be an install time step so that all CPack generators will contains signed binaries if codesign is used... I know this is a bit after the fact and I'm jumping in here pretty late, but... It would be nice to have package signing as a general top level CPack feature. Most supported package formats support some form of signing, rpm and deb with gpg keys, apple bundles, dmgs, nsis installers, etc. Could this be done as a generic CPack variable, CPACK_PACKAGE_SIGNING_KEY, for example, and then if set, then each CPack generator would use it accordingly? Just a thought, not to derail this current patch though. -- 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 Monday, September 29, 2014 01:23:04 PM Chuck Atkins wrote: Maybe it shouldn't even be a CPack thing. Maybe it should be an install time step so that all CPack generators will contains signed binaries if codesign is used... I know this is a bit after the fact and I'm jumping in here pretty late, but... It would be nice to have package signing as a general top level CPack feature. Most supported package formats support some form of signing, rpm and deb with gpg keys, apple bundles, dmgs, nsis installers, etc. Could this be done as a generic CPack variable, CPACK_PACKAGE_SIGNING_KEY, for example, and then if set, then each CPack generator would use it accordingly? Just a thought, not to derail this current patch though. The patch does introduce a SignPackage() function, but what its really doing is signing the application, not the package. There is another suggestion for the patch -- rename the SignPackage() function to be clear that the application is being signed, not the package. At least in the CPack context, the package is the .dmg file, not the .app bundle. The Bundle generator creates an application bundle plus the package. Because the Bundle generator makes the application, a user would want a way to sign it. This is why its Bundle generator specific. With any other generator, the application signing can be done with an install() command. I think application signing is generally not a CPack thing, but there probably isn't much of a choice if the Bundle generator is used. 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
