[cmake-developers] [CMake 0015441]: Xcode generator does not generate scheme
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15441 == Reported By:Tom Hughes Assigned To: == Project:CMake Issue ID: 15441 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-03-11 16:17 EDT Last Modified: 2015-03-11 16:17 EDT == Summary:Xcode generator does not generate scheme Description: After generating an Xcode project with cmake, an xcode scheme is not created by cmake (https://developer.apple.com/library/ios/featuredarticles/XcodeConcepts/Concept-Schemes.html). When opening the project with Xcode, Xcode seems to automatically generate the scheme, but this makes it hard to use continuous integration to archive an iOS app using xcodebuild (archiving requires a scheme): xcodebuild -project generated_project.xcodeproj -configuration Release -scheme name_of_scheme archive == Issue History Date ModifiedUsername FieldChange == 2015-03-11 16:17 Tom Hughes 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] Generating buildsystem metadata from CMake
On Wednesday, March 11, 2015 11:10:30 Stephen Kelly wrote: Hi, Following from the thread here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focu s=12394 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focu s=12650 I'm starting to gather requirements and make sure the feature is well designed to satisfy the needs we're already aware of, and fits with the features CMake currently has. The aim is to generate a structured file containing metadata relating the buildsystem. To help with completing the design of this feature, I've written documentation (documentation driven design), and a unit test containing a CMakeLists.txt file which exercises many modern CMake features in the generate-metadata branch in my clone. Mostly the design I propose can be read in the documentation I wrote. I'm interested in any feedback. https://gitorious.org/cmake/steveires-cmake/source/generate-metadata:Tests/ Metadata/CMakeLists.txt http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.htm l I expect to require a few iterations to figure out what the metadata files should contain in the end. Note that there are already some differences between my design and Aleix's implementation, such as that my design proposes one metadata file per config. There are also some things missing like location, because it is not yet clear to me whether build or install locations are needed etc. The content of the metadata file is determined by the build properties, and is necessarily similar to the compile-related content created when generating the actual buildsystem. It additionally contains information about the output locations of build artifacts and information relating to the cmake description itself. Goals include: * Make it possible for IDEs to access the compile-related information for autocompletion and code navigation etc purposes. * Remove the need for IDEs to parse generated Makefiles or Ninja files to access compile-related information. The structure of those files is not 'stable', while the content of the metadata file is stable. http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus =11081 * Remove the need for users to create a new build directory and new build in order to use or switch IDEs. QtCreator requires that the C::B 'extra generator is used as it parses compile information from that. Other 'extra generators' such as for eclipse, sublime, kate etc also require fresh/new build directories, although the actual buildsystem they create is identical (assuming using all Makefile based or all Ninja based 'extra generators') From my POV, the json metadata is just another extra generator, but one which can be always enabled additionally to other generators. You say that users don't need new build directories for switching IDEs, but this is only under the assumption that the different IDEs will actually start to use this new file format. See, users can use the C::B format and switch between CodeBlocks and QtCreator. If KDevelop and Kate would get plugins to read the C::B format (which is technically entirely possible) their users also would't have to create a new build directory. So instead of adding generators to cmake which generate what the IDEs expect, this is a change, now cmake will generate a file and the IDEs are expected to follow. My 2 cents Alex -- 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 0015440]: Visual Studio Version Selector launches incorrect version when opening generated UTF-8 solution file.
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15440 == Reported By:Felix Bruns Assigned To: == Project:CMake Issue ID: 15440 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-03-11 07:05 EDT Last Modified: 2015-03-11 07:05 EDT == Summary:Visual Studio Version Selector launches incorrect version when opening generated UTF-8 solution file. Description: Since solution (*.sln) files are encoded as UTF-8 (with signature), Visual Studio Version Selector doesn't detect the file format version correctly. Opening the file with an editor, then saving it as UTF-8 (without signature) fixes the problem. Steps to Reproduce: 1. Install Visual Studio 12 2013 2. Install Visual Studio 14 2015 3. Install CMake 3.2.0-rc2 4. Generate a solution file using the Visual Studio 12 2013 generator. 5. Double-click solution file in Explorer. Actual: 6. Visual Studio 14 2015 is launched. 7. Solution file icon shows no version number in Explorer. Expected: 6. Visual Studio 12 2013 is launched. 7. Solution file icon shows correct version number in Explorer. Workaround: 1. Use Notepad2 to open/save solution file with encoding UTF-8 (_not_ UTF-8 with Signature) 2. Double-click solution file in Explorer. 3. Visual Studio 12 2013 is launched. 4. Solution file icon shows correct version number in Explorer. == Issue History Date ModifiedUsername FieldChange == 2015-03-11 07:05 Felix BrunsNew 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] Generating buildsystem metadata from CMake
Hi,
Following from the thread here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650
I'm starting to gather requirements and make sure the feature is
well designed to satisfy the needs we're already aware of, and fits with
the features CMake currently has.
The aim is to generate a structured file containing metadata relating the
buildsystem.
To help with completing the design of this feature, I've written
documentation (documentation driven design), and a unit test
containing a CMakeLists.txt file which exercises many modern CMake
features in the generate-metadata branch in my clone.
Mostly the design I propose can be read in the documentation I wrote. I'm
interested in any feedback.
https://gitorious.org/cmake/steveires-cmake/source/generate-metadata:Tests/Metadata/CMakeLists.txt
http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.html
I expect to require a few iterations to figure out what the metadata files
should contain in the end. Note that there are already some differences
between my design and Aleix's implementation, such as that my design
proposes one metadata file per config. There are also some things
missing like location, because it is not yet clear to me whether build
or install locations are needed etc.
The content of the metadata file is determined by the build properties, and
is necessarily similar to the compile-related content created when
generating the actual buildsystem. It additionally contains information
about the output locations of build artifacts and information relating to
the cmake description itself.
Goals include:
* Make it possible for IDEs to access the compile-related information for
autocompletion and code navigation etc purposes.
* Remove the need for IDEs to parse generated Makefiles or Ninja files to
access compile-related information. The structure of those files is not
'stable', while the content of the metadata file is stable.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11081
* Remove the need for users to create a new build directory and new build
in order to use or switch IDEs. QtCreator requires that
the C::B 'extra generator is used as it parses compile information from
that. Other 'extra generators' such as for eclipse, sublime, kate etc
also require fresh/new build directories, although the actual buildsystem
they create is identical (assuming using all Makefile based or
all Ninja based 'extra generators')
* Make it possible to write a plugin for the editors/IDEs such as sublime
which consumes the metadata file and invokes the build using whatever
buildsystem the user already has a build directory for, instead of
writing an 'extra generator' and maintaining it in the cmake repo.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9004
* Make it possible for editors/IDEs to allow specifying the configuration
at build-time, where the IDE has that feature, and where a multi-config
generator is available. That is, QtCreator provides user-interface for
choosing debug/release config to build. Currently it can't offer that
when using cmake, because it only allows the use of Makefile or Ninja
generators, in order to make use of the C::B file. QtCreator should be
able to use the Xcode or Visual Studio generators, generate the metadata
file(s), and invoke `cmake --build . --config ${CONFIG}` as
appropriate. Eclipse, Sublime and other editors have similar abilities
to invoke config-specific builds after generation.
* Provide a list of 'build targets', which can be listed and invoked in
IDE/editor user interface. Build targets for all linked binaries
and utilties are provided. The tooling is expected to perform filtering
on the target types to show only executables and utilities for
execution, for example.
* Provide a list of source files per target per type of source file, eg
object sources, header files, generated files, files excluded from the
active configuration/platform/compiler, non-compiled files.
* Make it more easy for an IDE to support actions such as 'remove file
from the project', which requires removing it from the CMakeLists.txt
at the appropriate place, and 'add new file/class to target', which
involves adding code to the CMakeLists.txt file at the appropriate
place. Most likely the easiest way to do the latter is using the
target_sources() command, and to support the former, the location of
the declaration of the target, and all target_sources() calls would
need to be recorded. Even that is not enough because of transitive
consumption of source files through the link interface, but that is
likely irrelevant.
* Provide information about the entire build graph of link-dependencies
for
[cmake-developers] [ANNOUNCE] CMake 3.2.1 Released!
I am proud to announce that CMake 3.2.1 is now available for download at: http://www.cmake.org/download/ Documentation is available at: http://www.cmake.org/cmake/help/v3.2 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.2/release/3.2.html Some of the more significant features of CMake 3.2 are: * CMake learned to support unicode characters *encoded as UTF-8* on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as .h.in files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters. * The Compile Features functionality is now aware of features supported by more compilers, including: * Apple Clang (AppleClang) for Xcode versions 4.4 though 6.1. * GNU compiler versions 4.4 through 5.0 on UNIX and Apple (GNU). * Microsoft Visual Studio (MSVC) for versions 2010 through 2015. * Oracle SolarisStudio (SunPro) version 12.4. * The add_custom_command() and add_custom_target() commands learned a new BYPRODUCTS option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs. * The file(GENERATE) command can now generate files which are used as source files for buildsystem targets. Generated files automatically get their GENERATED property set to TRUE. Deprecated and Removed Features: * Files written in the cmake-language(7), such as CMakeLists.txt or *.cmake files, are now expected to be encoded as UTF-8. If files are already ASCII, they will be compatible. If files were in a different encoding, including Latin 1, they will need to be converted. * The FindOpenGL module no longer explicitly searches for any dependency on X11 libraries with the FindX11 module. Such dependencies should not need to be explicit. Applications using X11 APIs themselves should find and link to X11 libraries explicitly. CMake 3.2 Release Notes *** Changes made since CMake 3.1 include the following. New Features Syntax -- * CMake learned to support unicode characters *encoded as UTF-8* on Windows. This was already supported on platforms whose system APIs accept UTF-8 encoded strings. Unicode characters may now be used in CMake code, paths to source files, configured files such as .h.in files, and other files read and written by CMake. Note that because CMake interoperates with many other tools, there may still be some limitations when using certain unicode characters. Commands * The add_custom_command() and add_custom_target() commands learned a new BYPRODUCTS option to specify files produced as side effects of the custom commands. These are not outputs because they do not always have to be newer than inputs. * The add_custom_command() and add_custom_target() commands learned a new USES_TERMINAL option to request that the command be given direct access to the terminal if possible. The Ninja generator will places such commands in the console pool. Build targets provided by CMake that are meant for individual interactive use, such as install, are now placed in this pool. * A new continue() command was added that can be called inside loop contexts to end the current iteration and start the next one at the top of the loop block. * The file(LOCK) subcommand was created to allow CMake processes to synchronize through file and directory locks. * The file(STRINGS) now supports UTF-16LE, UTF-16BE, UTF-32LE, UTF- 32BE as ENCODING options. * The install(EXPORT) command now works with an absolute DESTINATION even if targets in the export set are installed with a destination or *usage requirements* specified relative to the install prefix. The value of the CMAKE_INSTALL_PREFIX variable is hard-coded into the installed export file as the base for relative references. * The try_compile() command source file signature now honors link flags (e.g. CMAKE_EXE_LINKER_FLAGS) in the generated test project. See policy CMP0056. * The try_run() command learned to honor the LINK_LIBRARIES option just as try_compile() already does. * The file(GENERATE) command now generates the output file with the same permissions as the input file if set. * The file(GENERATE) command can now generate files which are used as source files for buildsystem targets. Generated files automatically get their GENERATED property set to TRUE. Variables - * The CMAKE_MATCH_COUNT variable was introduced to record the number of matches made in the last regular expression matched in an if() command or a string() command. Properties -- * An ANDROID_API_MIN target property was introduced to
Re: [cmake-developers] Support of codesign
Hi there!
I added another improvement to the codesign feature. Sometimes it is
helpful to overwrite or pass additional parameters like --timestamp=none
to codesign.
But this shouldn't be the default for everyone.
So I added the variable CPACK_BUNDLE_APPLE_CODESIGN_PARAMETER.
Hope you like it.
Regards
André
2015-02-20 16:20 GMT+01:00 Clinton Stimpson clin...@elemtech.com:
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
From 6dda0e51c7fb8bf3422e4e208980a5d018910c4a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9=20Klitzing?= aklitz...@gmail.com
Date: Wed, 11 Mar 2015 13:04:15 +0100
Subject: [PATCH] CPack: Add support to overwrite or pass additional parameter
to codesign
---
Modules/CPackBundle.cmake | 5 +
Source/CPack/cmCPackBundleGenerator.cxx | 10 +++---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git x/Modules/CPackBundle.cmake y/Modules/CPackBundle.cmake
index d26a0b3..b412216 100644
--- x/Modules/CPackBundle.cmake
+++ y/Modules/CPackBundle.cmake
@@ -52,6 +52,11 @@
# 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_BUNDLE_APPLE_CODESIGN_PARAMETER
+#
+# Additional parameter that will passed to codesign.
+# Default value: --deep -f
+#
# .. variable:: CPACK_COMMAND_CODESIGN
#
# Path to the codesign(1) command used to sign applications with an
diff --git x/Source/CPack/cmCPackBundleGenerator.cxx y/Source/CPack/cmCPackBundleGenerator.cxx
index 6e7a26b..01c3f8b 100644
--- x/Source/CPack/cmCPackBundleGenerator.cxx
+++ y/Source/CPack/cmCPackBundleGenerator.cxx
@@ -221,6 +221,10 @@ int cmCPackBundleGenerator::SignBundle(const std::string src_dir)
bundle_path += .app;
// A list of additional files to sign, ie. frameworks and plugins.
+const std::string sign_parameter =
+ this-GetOption(CPACK_BUNDLE_APPLE_CODESIGN_PARAMETER)
+ ? this-GetOption(CPACK_BUNDLE_APPLE_CODESIGN_PARAMETER) : --deep -f;
+
const std::string sign_files =
this-GetOption(CPACK_BUNDLE_APPLE_CODESIGN_FILES)
? this-GetOption(CPACK_BUNDLE_APPLE_CODESIGN_FILES) : ;
@@ -234,7 +238,7 @@ int cmCPackBundleGenerator::SignBundle(const std::string src_dir)
{
std::ostringstream temp_sign_file_cmd;
temp_sign_file_cmd this-GetOption(CPACK_COMMAND_CODESIGN);
- temp_sign_file_cmd --deep -f -s \ cpack_apple_cert_app;
+ temp_sign_file_cmd sign_parameter -s \ cpack_apple_cert_app;
temp_sign_file_cmd \ -i ;
temp_sign_file_cmd this-GetOption(CPACK_APPLE_BUNDLE_ID);
temp_sign_file_cmd \;
@@ -254,7 +258,7 @@ int cmCPackBundleGenerator::SignBundle(const std::string src_dir)
// sign main binary
std::ostringstream temp_sign_binary_cmd;
temp_sign_binary_cmd this-GetOption(CPACK_COMMAND_CODESIGN);
-temp_sign_binary_cmd --deep -f -s \ cpack_apple_cert_app;
+temp_sign_binary_cmd sign_parameter -s \ cpack_apple_cert_app;
temp_sign_binary_cmd \ \ bundle_path \;
if(!this-RunCommand(temp_sign_binary_cmd, output))
@@ -269,7 +273,7 @@ int cmCPackBundleGenerator::SignBundle(const std::string src_dir)
// sign app bundle
std::ostringstream temp_codesign_cmd;
temp_codesign_cmd this-GetOption(CPACK_COMMAND_CODESIGN);
-temp_codesign_cmd --deep -f -s \ cpack_apple_cert_app \;
+temp_codesign_cmd sign_parameter -s \ cpack_apple_cert_app \;
if(this-GetOption(CPACK_BUNDLE_APPLE_ENTITLEMENTS))
{
temp_codesign_cmd --entitlements ;
--
2.3.2
--
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] Review request: FindTBB module
Hi, did you manage to improve over the DaxToolkit FindTBB module? Thanks for your time. -- 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] Extracting target metadata, IDE integration
On Tue, Mar 10, 2015 at 01:25:16 +0100, Aleix Pol wrote: output : /home/kde-devel/tmp/llvm/build/lib/libLLVMPowerPCInfo.a, Can this be a list? It's 1 output per target, no? Not on Windows with .dll and .lib splits. sources : [ /list/of/cpp/files, ] Any way to also get the headers? Do you see any option to hint where new sources would need to be added to make them a part of this target? I looked into how the CodeBlocks did it to provide the header files. It's just brute-forcing to see if the file renamed to *.h/*.hpp/*.hxx is present. CMake doesn't have this kind of information, so I think it's better that the IDE's do the hacky parts than cmake. Also we don't really have information about where to put them. You can use the minimum common denominator among the sources I guess. There's the source_group() command which could be changed to affect this as well. Building the project should be fine with the information provided. Explicitly stating the generators used would help a little bit (even better just giving the command necessary to build, e.g. make or ninja or whatnot. Then we would not need to hard-code the mapping of generators-build tools, which makes it much easier for you to support new things:-) Running/Debugging is a bit tricky again: All the information used for linking the binaries is gone. So there is no way to figure out which LD_LIBRARY_PATH needs to be set or anything. There also seems to be no information where files are going to get installed to. Would it be possible to add that information? I ignore it, on the other hand I'm quite a n00b when it comes to cmake codebase and internals. I'm sure if somebody knows where to get that information, he is reading this mailing list. (hello) CMake has options for RPATH for the relevant platforms. By default, binaries have the RPATH set for the build tree. Relevant CMake target properties (there are variables to set default values as well): - BUILD_WITH_INSTALL_RPATH - SKIP_BUILD_RPATH Without SKIP_BUILD_RPATH set, LD_LIBRARY_PATH should not be necessary for running targets. --Ben -- 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
