Re: [cmake-developers] cmake-gui icons
2014-10-27 21:33 GMT+01:00 Ben Boeckel ben.boec...@kitware.com: On Mon, Oct 27, 2014 at 11:59:09 -0600, Orion Poplawski wrote: Trying to bring a bit more attention to this: Fedora is pushing to have higher resolution icons for the applications. There already is CMakeSetup128.png, but these would need to get installed into the proper /usr/share/icons/ hierarchy and named appropriately for the correct size to be automatically found and used. It would be good to have cmake-gui be conformant to the current desktop standards. Related - http://www.cmake.org/Bug/view.php?id=13504 http://www.cmake.org/Bug/view.php?id=14315 Also might want to consider shipping AppData information. http://people.freedesktop.org/~hughsient/appdata/ I think there's a bug about this too (or at least for appdata). My question is: does it really make sense to have appdata for CMake's GUI? It isn't an end user application and I feel that developers know about CMake's Qt UI (or at least wouldn't look for it in the application tool thing). (I'm not against AppData overall; just wondering whether it makes sense for development tools such as cmake-gui.) Others' thoughts? I wouds say: Yes, it makes sense. There is AppData for Anjuta, Eclipse, KDevelop, QtCreator and the like. Those too are tools for developers rather than end users. cmake-gui would perfectly fit into that crowd. -- Daniel -- 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] ExternalProject CMAKE_ARGS and CMAKE_CACHE_ARGS arguments
Hello Brad, Sorry for the delay. On 22/10/14 17:18, Brad King wrote: How about a new option like CMAKE_CACHE_DEFAULT_ARGS for that? I just pushed a new ExternalProject_CMAKE_CACHE_DEFAULT_ARGS topic, can you please review it? Cheers, Daniele -- 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-gui icons
I would say yes, too. On Tue, Oct 28, 2014 at 3:27 AM, Daniel Pfeifer dan...@pfeifer-mail.de wrote: 2014-10-27 21:33 GMT+01:00 Ben Boeckel ben.boec...@kitware.com: On Mon, Oct 27, 2014 at 11:59:09 -0600, Orion Poplawski wrote: Trying to bring a bit more attention to this: Fedora is pushing to have higher resolution icons for the applications. There already is CMakeSetup128.png, but these would need to get installed into the proper /usr/share/icons/ hierarchy and named appropriately for the correct size to be automatically found and used. It would be good to have cmake-gui be conformant to the current desktop standards. Related - http://www.cmake.org/Bug/view.php?id=13504 http://www.cmake.org/Bug/view.php?id=14315 Also might want to consider shipping AppData information. http://people.freedesktop.org/~hughsient/appdata/ I think there's a bug about this too (or at least for appdata). My question is: does it really make sense to have appdata for CMake's GUI? It isn't an end user application and I feel that developers know about CMake's Qt UI (or at least wouldn't look for it in the application tool thing). (I'm not against AppData overall; just wondering whether it makes sense for development tools such as cmake-gui.) Others' thoughts? I wouds say: Yes, it makes sense. There is AppData for Anjuta, Eclipse, KDevelop, QtCreator and the like. Those too are tools for developers rather than end users. cmake-gui would perfectly fit into that crowd. -- Daniel -- 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 0015222]: Need a way to determine when features were introduced into cmake
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15222 == Reported By:Charles Karney Assigned To: == Project:CMake Issue ID: 15222 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2014-10-28 08:08 EDT Last Modified: 2014-10-28 08:08 EDT == Summary:Need a way to determine when features were introduced into cmake Description: Authors of cmake scripts face a challenge ensuring that their scripts are portable. This is exacerbated by * cmake is constantly evolving (which is good!); * their cmake scripts are run by a diverse set of users (also good!); * authors have little control over the version of cmake that end-users have installed; * the relationship with end-users is even more tenuous with the package-config scripts (which are not read by the builder of the package but by a developer using the package). There is cmake_minimum_required, but authors would normally not want to set this to too recent a version. The problem is that it's difficult to know when a particular feature appeared in cmake. There's no single changelog (and the format of the changelog doesn't make it easy to search in). Frequently I'm left doing a binary search in the documentation! Sometimes I need install old versions to check their behavior. For example I just noticed that install (TARGET ...) also an INCLUDES DESTINATION option. This seemed like a feature I should be using until I noticed that it only appeared in 2.8.12 (or thereabouts). Suggestions: * Have a developer mode where cmake behaves as though it were at the version given by cmake_minimum_required. (Probably this is unfeasible?) * In the documentation, specify when each command, command option, variable, etc., was introduced. (Might junk up the documentation.) * Split this information off into a separate document. (My favored solution.) Steps to Reproduce: N/A Additional Information: N/A == Issue History Date ModifiedUsername FieldChange == 2014-10-28 08:08 Charles Karney 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] cmake-gui icons
On 10/27/2014 01:59 PM, Orion Poplawski wrote: Fedora is pushing to have higher resolution icons for the applications. There already is CMakeSetup128.png, but these would need to get installed into the proper /usr/share/icons/ hierarchy and named appropriately for the correct size to be automatically found and used. It would be good to have cmake-gui be conformant to the current desktop standards. Where should it go and what should it be called? http://www.cmake.org/Bug/view.php?id=13504 http://www.cmake.org/Bug/view.php?id=14315 These were fixed in 3.0. I've updated the issue tracker entries. 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
Re: [cmake-developers] [PATCHv2] Tests: Run Tutorial steps 1-4 as tests for Windows CE
On 10/27/2014 09:11 AM, Brad King wrote: Tests: Run Tutorial steps 1-4 as tests for Windows CE http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e690d0db Please take a look at the test failures on your dashboard submission for these tests. 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
Re: [cmake-developers] [PATCHv2] Tests: Run Tutorial steps 1-4 as tests for Windows CE
On 10/27/2014 09:11 AM, Brad King wrote: Tests: Run Tutorial steps 1-4 as tests for Windows CE http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e690d0db Please take a look at the test failures on your dashboard submission for these tests. I'm already on it. I will let you know if I have found the problem. Pascal -- 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 0015223]: Object OUTPUT_EXTENSIONs selection is hard - if ever possible - to manage with cross compilation
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15223 == Reported By:Emmanuel Blot Assigned To: == Project:CMake Issue ID: 15223 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2014-10-28 17:07 CET Last Modified: 2014-10-28 17:07 CET == Summary:Object OUTPUT_EXTENSIONs selection is hard - if ever possible - to manage with cross compilation Description: For some (historical?) reasons, CMake considers the default object extension tas .obj, which is quite unusual but on Windows. CMake Modules files define: IF (UNIX) set(CMAKE_LANG_OUTPUT_EXTENSION .o) ELSE () set(CMAKE_LANG_OUTPUT_EXTENSION .obj) ENDIF () which makes the Unix style the exception, and Windows style the default rule. However, when cmake is used to cross compile, many (if not most) OSes use the Unix style, even if they are not Unix-based. The trouble is that UNIX variable seems to be mostly defined from the host environment, not from the target environment. The net result is that .obj extension is enforced for non-Windows targets, which in turn rapidly becomes a nightmare to manage. Forcing UNIX to 1 from a CMakeLists.txt sometimes helps for C source files - although it is definitely a hack - but does not with ASM files for example. Setting CMAKE_LANG_OUTPUT_EXTENSION from a CMakeLists.txt does not seem to be recommended - from previous CMake ML posts - and does not work anyway. Although I would personally favour .o to be the default extension and Windows the exception, I guess that for at least compatibility with previous CMake version this cannot be changed. However, being able to easily define the extension for a non Unix project, or for a cross compiled one is definitely a real need. Additional Information: I've failed - up to know - to find a way to choose the proper extension, which forced me to write ugly workaround in CMakeLists.txt files. == Issue History Date ModifiedUsername FieldChange == 2014-10-28 17:07 Emmanuel Blot 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] cmake-gui icons
On 10/28/2014 08:18 AM, Brad King wrote: On 10/27/2014 01:59 PM, Orion Poplawski wrote: Fedora is pushing to have higher resolution icons for the applications. There already is CMakeSetup128.png, but these would need to get installed into the proper /usr/share/icons/ hierarchy and named appropriately for the correct size to be automatically found and used. It would be good to have cmake-gui be conformant to the current desktop standards. Where should it go and what should it be called? There should be a series in: /usr/share/icons/hicolor/XxX/apps/CMakeSetup.png Where XxX is the resolution, eg: 32x32, 48x48,... : ls /usr/share/icons/hicolor 128x128 192x192 22x22 256x256 36x36 512x512 72x72 16x1620x2024x24 32x3248x48 64x6496x96 You don't need all of them, but a selection is nice. SVG/svgz is nice too, and that goes in scalable. Then the icon name in the .desktop file is simply CMakeSetup. http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- 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-gui icons
On Tue, Oct 28, 2014 at 11:27 AM, Orion Poplawski or...@cora.nwra.com
wrote:
There should be a series in:
/usr/share/icons/hicolor/XxX/apps/CMakeSetup.png
Where XxX is the resolution, eg: 32x32, 48x48,... :
ls /usr/share/icons/hicolor
128x128 192x192 22x22 256x256 36x36 512x512 72x72
16x1620x2024x24 32x3248x48 64x6496x96
You don't need all of them, but a selection is nice.
SVG/svgz is nice too, and that goes in scalable.
I do this within the RPM spec file for packages I maintain which don't do
this for me but the idea should work the same for CMake, something like:
if(UNIX) # Or any other qualifiers/tests needed...
include(GNUInstallDirs)
set(ICON_INSTALL_PREFIX} ${CMAKE_INSTALL_DATADIR}/icons/hicolor)
set(ICON_SIZES 32x32;64x64;128x128)
foreach(_size ICON_SIZES)
install(FILES CMakeSetup${_size}.png
DESTINATION ${ICON_INSTALL_PREFIX}/${_size}/apps
RENAME CMakeSetup.png)
endforeach()
install(FILES CMakeSetup.svg DESTINATION
${ICON_INSTALL_PREFIX}/scalable/apps)
endif()
This assumes the icon size is appended to the base name.
I haven't tested this and it may well have typos but I would think this
would work.
Thanks,
Richard
--
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] ExternalProject CMAKE_ARGS and CMAKE_CACHE_ARGS arguments
On 10/28/2014 06:48 AM, Daniele E. Domenichelli wrote: I just pushed a new ExternalProject_CMAKE_CACHE_DEFAULT_ARGS topic, can you please review it? Good. After seeing the lack of a clean place to document the differences among these options I decided it is time to revise the documentation layout. I've done that here: ExternalProject: Convert docs to a bracket comment http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=98936ae3 ExternalProject: Use explicit markup and definition lists in docs http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9c2c17b Please rebase on those. You should find it much easier to add more detail to the documentation of each option. 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
[cmake-developers] [CMake 0015225]: Xcode generator ignores the add_compile_options command
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15225 == Reported By:Ilya Assigned To: == Project:CMake Issue ID: 15225 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2014-10-28 13:42 EDT Last Modified: 2014-10-28 13:42 EDT == Summary:Xcode generator ignores the add_compile_options command Description: The flags specified via add_compile_options do not appear anywhere in generated Xcode project (I use Xcode 6) In other hand, options specified via the add_definitions command will be properly placed under the OTHER_CFLAGS Xcode attribute. Moreover, generator seems to categorize these flags and put them under appropriate Xcode attributes. E.g. add_definitions( -DHAVE_PTHREADS -Wduplicate-method-match ) -DHAVE_PTHREADS will be added to the GCC_PREPROCESSOR_DEFINITIONS Xcode attribute while -Wduplicate-method-match will be added to the OTHER_CFLAGS Xcode attribute. == Issue History Date ModifiedUsername FieldChange == 2014-10-28 13:42 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] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!
I am proud to announce that CMake 3.1 has entered the release candidate stage.
Sources and binaries are available at:
http://www.cmake.org/files/v3.1/?C=M;O=D
Documentation is available at:
http://www.cmake.org/cmake/help/v3.1
Release notes appear below and are also published at
http://www.cmake.org/cmake/help/v3.1/release/3.1.0.html
Some of the more significant features of CMake 3.1 are:
* Windows Phone and Windows Store support has been added to Visual Studio 11
(2012) and above Generators.
* NVIDIA Nsight Tegra support has been added to Visual Studio 10 (2010) and
above Generators.
* New target_compile_features command allows populating target based compile
features. CMake uses this information to ensure that the compiler in use is
capable of building the target, and to add any necessary compile flags
such as -std=gnu++11 to support language features.
More information on this is found at:
- http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html
* The syntax for *Variable References* and *Escape Sequences* was simplified in
order to allow a much faster implementation. See policy CMP0053.
* The if command no longer automatically dereferences variables named in
quoted or bracket arguments. See policy CMP0054.
* The target property SOURCES now generally supports Generator Expressions.
The generator expressions may be used in the add_library and
add_executable commands.
* It is now possible to write and append to the target property SOURCES.
The variable CMAKE_DEBUG_TARGET_PROPERTIES can be used to trace the
origin of sources.
* CPack gained 7Z and TXZ generators supporting lzma-compressed archives.
* The ExternalProject module has learned to support lzma-compressed
source tarballs with .7z, .tar.xz, and .txz extensions.
* The ExternalProject module ExternalProject_Add command learned a new
BUILD_ALWAYS option to cause the external project build step to run every
time the host project is built.
* The ctest_coverage command learned to support Intel coverage files with the
codecov tool.
* The ctest_memcheck command learned to support sanitizer modes, including
AddressSanitizer, MemorySanitizer, ThreadSanitizer, and
UndefinedBehaviorSanitizer.
Deprecated and Removed Features:
* In CMake 3.0 the target_link_libraries command accidentally began allowing
unquoted arguments to use Generator Expressions containing a semicolon
separated list within them. For example:
set(libs B C)
target_link_libraries(A PUBLIC $BUILD_INTERFACE:${libs})
This is equivalent to writing:
target_link_libraries(A PUBLIC $BUILD_INTERFACE:B C)
and was never intended to work. It did not work in CMake 2.8.12.
Such generator expressions should be in quoted arguments:
set(libs B C)
target_link_libraries(A PUBLIC $BUILD_INTERFACE:${libs})
CMake 3.1 again requires the quotes for this to work correctly.
CMake 3.1.0 Release Notes
*
Changes made since CMake 3.0.0 include the following.
Documentation Changes
=
* A new cmake-compile-features(7) manual was added.
New Features
Generators
--
* A Visual Studio 14 generator was added.
Windows Phone and Windows Store
~~~
* Generators for Visual Studio 11 (2012) and above learned to
generate projects for Windows Phone and Windows Store. One may set
the CMAKE_SYSTEM_NAME variable to WindowsPhone or WindowsStore
on the cmake(1) command-line or in a CMAKE_TOOLCHAIN_FILE to
activate these platforms. Also set CMAKE_SYSTEM_VERSION to 8.0
or 8.1 to specify the version of Windows to be targeted.
NVIDIA Nsight Tegra
~~~
* Generators for Visual Studio 10 (2010) and above learned to
generate projects for NVIDIA Nsight Tegra Visual Studio Edition.
One may set the CMAKE_SYSTEM_NAME variable to Android on the
cmake(1) command-line or in a CMAKE_TOOLCHAIN_FILE to activate
this platform.
Syntax
--
* The cmake-language(7) syntax for *Variable References* and
*Escape Sequences* was simplified in order to allow a much faster
implementation. See policy CMP0053.
* The if() command no longer automatically dereferences variables
named in quoted or bracket arguments. See policy CMP0054.
Commands
* The add_custom_command() command learned to interpret cmake-
generator-expressions(7) in arguments to DEPENDS.
* The export(PACKAGE) command learned to check the
CMAKE_EXPORT_NO_PACKAGE_REGISTRY variable to skip exporting the
package.
* The file(STRINGS) command gained a new ENCODING option to
enable extraction of UTF-8 strings.
* The find_package() command learned to check the
CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY and
CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY variables to skip
searching the package registries.
* The install() command learned a MESSAGE_NEVER option to avoid
output during installation.
* The string() command
Re: [cmake-developers] Support of codesign
Hi there!
As requested... I renamed the 3 APPLE variables to BUNDLE_APPLE in attached
patch.
Thanks
André Klitzing
Clinton Stimpson clin...@elemtech.com schrieb am Mon Oct 27 2014 at
17:42:50:
Hi André,
I can help you get this patch into the git repo. But before doing that,
Brad
requested one more change.
Can you please rename 3 of the CMake variables to
CPACK_BUNDLE_APPLE_CERT_APP
CPACK_BUNDLE_APPLE_ENTITLEMENTS
CPACK_BUNDLE_APPLE_CODESIGN_FILES
Thanks,
Clint
From ce841285959648f7c16f34b24a71af029f89c976 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9=20Klitzing?= aklitz...@gmail.com
Date: Tue, 28 Oct 2014 19:15:55 +0100
Subject: [PATCH] CPack: Add support for code signing of bundles on MacOS
---
Modules/CPackBundle.cmake | 25 +++
Source/CPack/cmCPackBundleGenerator.cxx | 126 +++-
Source/CPack/cmCPackBundleGenerator.h | 2 +
3 files changed, 152 insertions(+), 1 deletion(-)
diff --git a/Modules/CPackBundle.cmake b/Modules/CPackBundle.cmake
index d8293c0..d26a0b3 100644
--- a/Modules/CPackBundle.cmake
+++ b/Modules/CPackBundle.cmake
@@ -33,6 +33,31 @@
# Path to a startup script. This is a path to an executable or script that
# will be run whenever an end-user double-clicks the generated bundle in the
# OSX Finder. Optional.
+#
+# .. variable:: CPACK_BUNDLE_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_BUNDLE_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_BUNDLE_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_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-2009 Kitware, Inc.
diff --git a/Source/CPack/cmCPackBundleGenerator.cxx b/Source/CPack/cmCPackBundleGenerator.cxx
index 6c994f1..fbd1d21 100644
--- a/Source/CPack/cmCPackBundleGenerator.cxx
+++ b/Source/CPack/cmCPackBundleGenerator.cxx
@@ -39,6 +39,21 @@ int cmCPackBundleGenerator::InitializeInternal()
return 0;
}
+ if(this-GetOption(CPACK_BUNDLE_APPLE_CERT_APP))
+{
+const std::string codesign_path = cmSystemTools::FindProgram(codesign,
+ std::vectorstd::string(), false);
+
+if(codesign_path.empty())
+ {
+ cmCPackLogger(cmCPackLog::LOG_ERROR,
+Cannot locate codesign command
+ std::endl);
+ return 0;
+ }
+this-SetOptionIfNotSet(CPACK_COMMAND_CODESIGN, codesign_path.c_str());
+}
+
return this-Superclass::InitializeInternal();
}
@@ -53,7 +68,7 @@ const char* cmCPackBundleGenerator::GetPackagingInstallPrefix()
}
//--
-int cmCPackBundleGenerator::PackageFiles()
+int cmCPackBundleGenerator::ConstructBundle()
{
// Get required arguments ...
@@ -165,6 +180,22 @@ int cmCPackBundleGenerator::PackageFiles()
cmSystemTools::SetPermissions(command_target.str().c_str(), 0777);
}
+ return 1;
+}
+
+//--
+int cmCPackBundleGenerator::PackageFiles()
+{
+ if(!this-ConstructBundle())
+{
+return 0;
+}
+
+ if(!this-SignBundle(toplevel))
+{
+return 0;
+}
+
return this-CreateDMG(toplevel, packageFileNames[0]);
}
@@ -172,3 +203,96 @@ bool cmCPackBundleGenerator::SupportsComponentInstallation() const
{
return false;
}
+
+
+int cmCPackBundleGenerator::SignBundle(const std::string src_dir)
+{
+ const std::string cpack_apple_cert_app =
+this-GetOption(CPACK_BUNDLE_APPLE_CERT_APP)
+? this-GetOption(CPACK_BUNDLE_APPLE_CERT_APP) : ;
+
+ // codesign the application.
+ if(!cpack_apple_cert_app.empty())
+{
+std::string bundle_path;
+bundle_path = src_dir + /;
+bundle_path += this-GetOption(CPACK_BUNDLE_NAME);
+bundle_path += .app;
+
+// A list of additional files to sign, ie. frameworks and plugins.
+const std::string sign_files =
+ this-GetOption(CPACK_BUNDLE_APPLE_CODESIGN_FILES)
+ ? this-GetOption(CPACK_BUNDLE_APPLE_CODESIGN_FILES) : ;
+
+std::vectorstd::string relFiles;
+cmSystemTools::ExpandListArgument(sign_files,
Re: [cmake-developers] Support of codesign
Thanks for the patch. Its in the repository now. http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=bd3fbf3 Clint On Tuesday, October 28, 2014 06:18:34 PM A. Klitzing wrote: Hi there! As requested... I renamed the 3 APPLE variables to BUNDLE_APPLE in attached patch. Thanks André Klitzing Clinton Stimpson clin...@elemtech.com schrieb am Mon Oct 27 2014 at 17:42:50: Hi André, I can help you get this patch into the git repo. But before doing that, Brad requested one more change. Can you please rename 3 of the CMake variables to CPACK_BUNDLE_APPLE_CERT_APP CPACK_BUNDLE_APPLE_ENTITLEMENTS CPACK_BUNDLE_APPLE_CODESIGN_FILES 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] ExternalProject CMAKE_ARGS and CMAKE_CACHE_ARGS arguments
On 28/10/14 18:01, Brad King wrote: Please rebase on those. You should find it much easier to add more detail to the documentation of each option. Done, thanks. Daniele -- 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] New command 'file(LOCK_DIRECTORY ...)'
On 13-Oct-14 18:39, Brad King wrote: With all the above in mind, please brainstorm and propose a more complete signature set. You can use the keyword/value pairing common in other commands to avoid needing a positional argument for every value. What do you think about this: file( LOCK path [DIRECTORY] # if present locked file will be path/cmake.lock (instead of path) [RELEASE] # do explicit unlock [GUARD FUNCTION|FILE|PROCESS] # if not present - set to `GUARD PROCESS` (not used if RELEASE) [RESULT_VARIABLE variable] # 0 on success, error message otherwise; if not present - any error is FATAL_ERROR [TIMEOUT seconds] # 0 - return immediately if operation failed (try_lock), otherwise timeout (timed_lock); # if not present - lock until success (or error); # not used if RELEASE; ) ? On 13-Oct-14 18:39, Brad King wrote: Also, please post a summary of how the implementation will work on each platform. Boost implementation of file locking mechanism use LockFileEx/UnlockFileEx for windows and fcntl for unix-like platforms. These functions lock file only for current process. When process crashes lock removed by OS automatically. In terms of boost documentation `file(LOCK ...)` locks are exclusive and advisory. boost.interprocess: http://www.boost.org/doc/libs/1_56_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.file_lock LockFileEx: http://msdn.microsoft.com/library/windows/desktop/aa365203%28v=vs.85%29.aspx UnlockFileEx: http://msdn.microsoft.com/library/windows/desktop/aa365716%28v=vs.85%29.aspx fcntl (linux): http://linux.die.net/man/2/fcntl fcntl (mac): https://developer.apple.com/library/Mac/documentation/Darwin/Reference/ManPages/man2/fcntl.2.html I've tried (Un)LockFileEx/fcntl on windows (including mingw and cygwin), linux and mac - works fine for me with one exception: cygwin's lock is not visible by win32's lock. I.e. you can synchronize multiple cygwin processes and multiple windows normal processes, but you can't mix them. On 13-Oct-14 18:34, Ben Boeckel wrote: Maybe we need something like the 'trap' shell builtin which runs code on various triggers rather than something like file/directory locks... Note that you can't set trap for SIGKILL. So if somebody will terminate your CMake instance by `kill -9 pid` probably you will have a problem. -- 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
