From brad.king at kitware.com Thu Mar 2 15:55:49 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 2 Mar 2017 15:55:49 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake merge process transition Message-ID: Hi Folks, We're moving CMake's process for merging changes to new infrastructure that is managed directly within merge requests on gitlab.kitware.com. Summary ------- The new process for reviewing changes, staging them for nightly testing, and eventually merging to `master` is documented in a new `Help/dev/review.rst` file. This document is drafted here: https://gitlab.kitware.com/cmake/cmake/merge_requests/542 Please take a look at the draft. Once we have actually made the final transition I'll merge the new instructions and post a link here to their final URL. Details ------- The rest of this message is primarily meant for those who had push access to the old staging repository and/or run nightly builds. Our contribution and review process currently works through GitLab merge requests. However, the actual merge to `next` or `master` has still been done by manually pushing topic branches to our old staging repository (cmake.org/stage/cmake.git) and commanding merge scripts via ssh. Our process for staging topics in `next` for the nightly builds has worked well but requires tedious manual steps and makes updating a topic with a fixup commit difficult. We will drop `next` and replace it with an automatically-maintained staging branch. We currently have a bot that listens to GitLab merge request activity and responds to commands like `Do: test` for topic testing. The bot is capable of much more. It will soon be configured to respond to `Do: stage` and `Do: unstage` commands that instruct it to add or remove the branch associated with a MR to/from the staging branch used for nightly testing. The staging branch is always built from `master` plus a set of staged MR topics. When `master` is updated the entire staging branch is rebuilt automatically. When a staged MR is updated it is unstaged automatically awaiting review and a new `Do: stage`. This will hugely simplify the process of staging a MR for nightly testing. Furthermore, the staging branch will not be published as an official branch under refs/heads/ on the gitlab.kitware.com/cmake/cmake repo. Instead it will be in a custom refs/ path that Git does not clone or fetch by default. CTest scripts used to drive nightly testing will need to be adapted for this. I'll post more information for those of you running nightly builds once we are ready to update the clients. The bot will also gain a `Do: merge` command that I'll use to perform the actual merges to `master`. Its merge commit messages will have more information than the current ones, and will refer back to the MRs that created them. -Brad From robert.maynard at kitware.com Fri Mar 3 10:39:20 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 3 Mar 2017 10:39:20 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.8.0-rc2 now ready for testing! Message-ID: I am proud to announce the second CMake 3.8 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.8 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.8/release/3.8.html Some of the more significant changes in CMake 3.8 are: * CMake now supports "CSharp" (C#) as a first-class language. It is currently supported by the Visual Studio Generators for VS 2010 and above. * CMake now supports "CUDA" as a first-class language. It is currently supported by the Makefile Generators and the "Ninja" generator on Linux, macOS, and Windows. Support for the Visual Studio IDE is under development but not included in this release. * The "Compile Features" functionality now offers meta-features that request compiler modes for specific language standard levels (e.g. "cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and "CMAKE_CXX_KNOWN_FEATURES". * The "Compile Features" functionality is now aware of C++ 17. No specific features are yet enumerated besides the "cxx_std_17" meta- feature. * The Visual Studio Generators for VS 2013 and above learned to support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit toolchain on 64-bit hosts. * The Visual Studio Generators learned to treat files passed to "target_link_libraries()" whose names end in ".targets" as MSBuild "targets" files to be imported into generated project files. * The "try_compile()" command source file signature gained new options to specify the language standard to use in the generated test project. * The "try_compile()" command source file signature now honors language standard variables like "CMAKE_CXX_STANDARD". See policy "CMP0067". * A "BUILD_RPATH" target property and corresponding "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH" locations to be added to binaries in the build tree. * The "COMPILE_FLAGS" source file property learned to support "generator expressions". * A new generator expression "$" was added. It resolves to the true-value if the condition is "1" and resolves to the false-value if the condition is "0". * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX and Windows platforms. * The Visual Studio Generators for VS 2010 and above now place per- source file flags after target-wide flags when they are classified as raw flags with no project file setting ("AdditionalOptions"). This behavior is more consistent with the ordering of flags produced by other generators, and allows flags on more-specific properties (per-source) to override those on more general ones (per-target). * The precompiled Windows binary MSI package provided on "cmake.org" now records the installation directory in the Windows Registry under the key "HKLM\Software\Kitware\CMake" with a value named "InstallDir". CMake 3.8 Release Notes *********************** Changes made since CMake 3.7 include the following. New Features ============ Languages --------- C# ~~ * CMake learned to support "CSharp" (C#) as a first-class language that can be enabled via the "project()" and "enable_language()" commands. It is currently supported by the Visual Studio Generators for VS 2010 and above. C# assemblies and programs can be added just like common C++ targets using the "add_library()" and "add_executable()" commands. References between C# targets in the same source tree may be specified by "target_link_libraries()" like for C++. References to system or 3rd-party assemblies may be specified by the target properties "VS_DOTNET_REFERENCE_" and "VS_DOTNET_REFERENCES". * More fine tuning of C# targets may be done using target and source file properties. Specifically the target properties related to Visual Studio ("VS_*") are worth a look (for setting toolset versions, root namespaces, assembly icons, ...). CUDA ~~~~ * CMake learned to support "CUDA" as a first-class language that can be enabled via the "project()" and "enable_language()" commands. * "CUDA" is currently supported by the Makefile Generators and the "Ninja" generator on Linux, macOS, and Windows. Support for the Visual Studio IDE is under development but not included in this release. * The NVIDIA CUDA Toolkit compiler ("nvcc") is supported. C & C++ ~~~~~~~ * The "Compile Features" functionality now offers meta-features that request compiler modes for specific language standard levels (e.g. "cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and "CMAKE_CXX_KNOWN_FEATURES". * The "Compile Features" functionality is now aware of C++ 17. No specific features are yet enumerated besides the "cxx_std_17" meta- feature. * The "Compile Features" functionality is now aware of the availability of C99 in gcc since version 3.4. Platforms --------- * A new minimal platform file for "Fuchsia" was added. Generators ---------- * The "CodeBlocks" extra generator may now be used to generate with "NMake Makefiles JOM". * The Visual Studio Generators for VS 2013 and above learned to support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit toolchain on 64-bit hosts. * The Visual Studio Generators learned to treat files passed to "target_link_libraries()" whose names end in ".targets" as MSBuild "targets" files to be imported into generated project files. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned the option "COMMAND_EXPAND_LISTS" which causes lists in the "COMMAND" argument to be expanded, including lists created by generator expressions. * The "execute_process()" command gained an "ENCODING" option to specify on Windows which encoding is used for output from child process. * The "math(EXPR)" command gained support for unary "+" and "-" operators. * The "source_group()" command gained "TREE" and "PREFIX" options to add groups following source tree directory structure. * The "string(TIMESTAMP)" command learned to treat "%%" as a way to encode plain "%". * The "string(TIMESTAMP)" command will now honor the "SOURCE_DATE_EPOCH" environment variable and use its value instead of the current time. * The "try_compile()" command source file signature gained new options to specify the language standard to use in the generated test project. * The "try_compile()" command source file signature now honors language standard variables like "CMAKE_CXX_STANDARD". See policy "CMP0067". Variables --------- * A "CMAKE_CODELITE_USE_TARGETS" variable was added to tell the "CodeLite" extra generator to change the generated project to have target-centric organization. The "build", "rebuild", and "clean" operations within "CodeLite" then work on a selected target rather than the whole workspace. (Note that the "Ninja" clean operation on a target includes its dependencies, though.) * The "CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS" variable was added to tell the "Sublime Text 2" extra generator to place specified environment variables in the generated ".sublime-project". * The "CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE" variable was added to tell the "Sublime Text 2" extra generator whether to exclude the build tree from the ".sublime-project" when it is inside the source tree. * A "CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD" variable was added to tell Visual Studio Generators for VS 2010 and above to include the "PACKAGE" target in the default build, similar to the existing "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" variable for the "INSTALL" target. Properties ---------- * A "BUILD_RPATH" target property and corresponding "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH" locations to be added to binaries in the build tree. * The "COMPILE_FLAGS" source file property learned to support "generator expressions". * The "FRAMEWORK" target property may now also be applied to static libraries on Apple targets. It will result in a proper Framework but with a static library inside. * Imported Interface Libraries learned new "IMPORTED_LIBNAME" and "IMPORTED_LIBNAME_" target properties to specify a link library name since interface libraries do not build their own library files. * A "_CPPLINT" target property and supporting "CMAKE__CPPLINT" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run the "cpplint" style checker along with the compiler for "C" and "CXX" languages. * A "MANUALLY_ADDED_DEPENDENCIES" target property has been added. It provides a read-only list of dependencies that have been added with the "add_dependencies()" command. * The "MAP_IMPORTED_CONFIG_" target property learned to interpret empty list elements as referring to the configuration-less imported location specified by "IMPORTED_LOCATION". * The "NO_SYSTEM_FROM_IMPORTED" target property is now supported on Imported Interface Libraries. * New source file properties "SKIP_AUTOMOC", "SKIP_AUTOUIC", "SKIP_AUTORCC", and "SKIP_AUTOGEN" were added to allow source files to be excluded from processing by "AUTOMOC", "AUTOUIC", and "AUTORCC" target properties. * A "VS_COPY_TO_OUT_DIR" source file property was added to tell Visual Studio Generators for VS 2010 and above whether or not a file should e copied to the output directory. * A "VS_DEBUGGER_WORKING_DIRECTORY" target property was added to tell Visual Studio Generators for VS 2010 and above what debugger working directory should be set for the target. * A "VS_DOTNET_REFERENCES_COPY_LOCAL" target property was added to specify whether to copy referenced assemblies to the output directory. * A "VS_DOTNET_REFERENCE_" target property was added to tell Visual Studio Generators for VS 2010 and above to add a .NET reference with a given hint path. * A "VS_INCLUDE_IN_VSIX" source file property was added to tell Visual Studio Generators for VS 2010 and above whether to include the file in a Visual Studio extension package. * A "VS_RESOURCE_GENERATOR" source file property was added to give Visual Studio Generators for VS 2010 and above a setting for the resource generator ("C#" only). * A "VS_USER_PROPS" target property was added to tell Visual Studio Generators for VS 2010 and above to use a custom MSBuild user ".props" file. * A "XCODE_EMIT_EFFECTIVE_PLATFORM_NAME" global property was added to tell the "Xcode" generator whether to emit the "EFFECTIVE_PLATFORM_NAME" variable. This is useful when building with multiple SDKs like "macosx" and "iphoneos" in parallel. * New "XCODE_PRODUCT_TYPE" and "XCODE_EXPLICIT_FILE_TYPE" target properties were created to tell the "Xcode" generator to use custom values of the corresponding attributes for a target in the generated Xcode project. Modules ------- * A "CSharpUtilities" module was added to aid parameterization of Visual Studio C# targets. It provides functions to allow automated setting of source file properties to support Windows Forms, WPF/XAML or other technologies as needed. * The "ExternalData" module learned to support multiple content links for one data file using different hashes, e.g. "img.png.sha256" and "img.png.sha1". This allows objects to be fetched from sources indexed by different hash algorithms. * The "ExternalProject" module gained the "GIT_PROGRESS" option to force Git to show progress when cloning repositories. * The "ExternalProject" module gained a "GIT_CONFIG" option to pass " --config" options to Git when cloning repositories. * The "FeatureSummary" module "feature_summary()" command now accepts a new "QUIET_ON_EMPTY" option that suppresses the output when the list of packages that belong to the selected category is empty. * The "FeatureSummary" module "add_feature_info()" command now accepts lists of dependencies for deciding whether a feature is enabled or not. * The package types accepted by the "FeatureSummary" module can now be tweaked by changing the "FeatureSummary_PKG_TYPES", "FeatureSummary_REQUIRED_PKG_TYPES" and "FeatureSummary_DEFAULT_PKG_TYPE" global properties. * The "FindOpenGL" module now provides imported targets "OpenGL::GL" and "OpenGL::GLU" when the libraries are found. * The "UseSWIG" module gained a "swig_add_library" command to give more flexibility over the old "swig_add_module" command. * The "UseSWIG" module "swig_add_source_to_module" command learned a new "SWIG_OUTFILE_DIR" option to control the output file location ("swig -o"). * The "WriteCompilerDetectionHeader" module gained the "ALLOW_UNKNOWN_COMPILERS" and "ALLOW_UNKNOWN_COMPILER_VERSIONS" options that allow creation of headers that will work also with unknown or old compilers by simply assuming they do not support any of the requested features. CTest ----- * The "ctest_memcheck()" command gained a "DEFECT_COUNT " option to capture the number of memory defects detected. * The "ctest_memcheck()" command learned to read the location of suppressions files for sanitizers from the "CTEST_MEMORYCHECK_SUPPRESSIONS_FILE" variable. * The "ctest_memcheck()" command learned to support "LeakSanitizer" independently from "AddressSanitizer". * The "ctest_update()" command "CDASH_UPLOAD" signature was taught to honor the "RETRY_COUNT", "RETRY_DELAY", and "QUIET" options. CPack ----- * The "CPackIFWConfigureFile" module was added to define a new "cpack_ifw_configure_file()" command to configure file templates prepared in QtIFW/SDK/Creator style. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "DEFAULT", "VIRTUAL", "FORCED_INSTALLATION", "REQUIRES_ADMIN_RIGHTS", "DISPLAY_NAME", "UPDATE_TEXT", "DESCRIPTION", "RELEASE_DATE", "AUTO_DEPEND_ON" and "TRANSLATIONS" options to more specific configuration. * The "CPackIFW" module "cpack_ifw_configure_component()" command gained a new "DEPENDENCIES" alias for "DEPENDS" option. * The "CPackIFW" module "cpack_ifw_configure_component_group()" command gained a new "DEPENDS" option. The "DEPENDENCIES" alias also added. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands "PRIORITY" option now is deprecated and will be removed in a future version of CMake. Please use new "SORTING_PRIORITY" option instead. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_WATERMARK", "CPACK_IFW_PACKAGE_BANNER", "CPACK_IFW_PACKAGE_BACKGROUND", "CPACK_IFW_PACKAGE_WIZARD_STYLE", "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH", "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT", and "CPACK_IFW_PACKAGE_TITLE_COLOR" variables to customize a QtIFW installer look. * The "CPackProductBuild" module gained options to sign packages. See the variables "CPACK_PRODUCTBUILD_IDENTITY_NAME", "CPACK_PRODUCTBUILD_KEYCHAIN_PATH", "CPACK_PKGBUILD_IDENTITY_NAME", and "CPACK_PKGBUILD_KEYCHAIN_PATH". * The "CPackRPM" module learned to omit tags that are not supported by provided "rpmbuild" tool. If unsupported tags are set they are ignored and a developer warning is printed out. * The "CPackRPM" module learned to generate main component package which forces generation of a rpm for defined component without component suffix in filename and package name. See "CPACK_RPM_MAIN_COMPONENT" variable. * The "CPackRPM" module learned to generate a single "debuginfo" package on demand even if components packaging is used. See "CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE" variable. * The "CPackRPM" module learned to support multiple directives per file when using "CPACK_RPM_USER_FILELIST" variable. Other ----- * CMake functionality using cryptographic hashes now supports SHA-3 algorithms. * A new generator expression "$" was added. It resolves to the true-value if the condition is "1" and resolves to the false-value if the condition is "0". Deprecated and Removed Features =============================== * The "FeatureSummary" module commands "set_package_info()", "set_feature_info()", "print_enabled_features()", and "print_disabled_features()" are now deprecated. * The "UseSWIG" module "swig_add_module" command is now deprecated in favor of "swig_add_library". Other Changes ============= * If a command specified by the "_CLANG_TIDY" target property returns non-zero at build time this is now treated as an error instead of silently ignored. * The "ctest_memcheck()" command no longer automatically adds "leak_check=1" to the options used by "AddressSanitizer". The default behavior of "AddressSanitizer" is to run *LeakSanitizer* to check leaks unless "leak_check=0". * The "ctest_memcheck()" command was fixed to correctly append extra sanitizer options read from the "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable to the environment variables used internally by the sanitizers. * The "FeatureSummary" module "set_package_properties()" command no longer forces the package type to "OPTIONAL" when the type is not explicitly set. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX and Windows platforms. * Calls to the "FindPkgConfig" module "pkg_check_modules()" command following a successful call learned to re-evaluate the cached values for a given prefix after changes to the parameters to the command for that prefix. * When using "AUTOMOC" or "AUTOUIC", generated "moc_*", "*.moc" and "ui_*" are placed in the "/_autogen/include" directory which is automatically added to the target's "INCLUDE_DIRECTORIES". It is therefore not necessary anymore to have "CMAKE_CURRENT_BINARY_DIR" in the target's "INCLUDE_DIRECTORIES". * The "Sublime Text 2" generator no longer runs the native build command (e.g. "ninja" or "make") with verbose build output enabled. * The "try_compile()" command source file signature now honors the "CMAKE_WARN_DEPRECATED" variable value in the generated test project. * The Visual Studio Generators for VS 2010 and above now place per- source file flags after target-wide flags when they are classified as raw flags with no project file setting ("AdditionalOptions"). This behavior is more consistent with the ordering of flags produced by other generators, and allows flags on more-specific properties (per-source) to override those on more general ones (per-target). * The precompiled Windows binary MSI package provided on "cmake.org" now records the installation directory in the Windows Registry under the key "HKLM\Software\Kitware\CMake" with a value named "InstallDir". ---------------------------------------------------------------------------- Changes made since CMake 3.8.0-rc1: Ben Boeckel (1): FindGTK2: handle old libsigc++ versions Bjoern Thiel (1): FindCUDA: Fix PTX selection with multiple architectures Brad Davis (1): FindVulkan: Update for LunarG SDK import library location on Windows Brad King (32): Utilities/Sphinx: Port qthelp css workaround to Sphinx 1.4 Help: Fix cmake code block warnings produced by Sphinx 1.4 Help: Improve execute_process ENCODING option documentation execute_process: Restore no-decoding default behavior clang-format.bash: Format CUDA source files too Modules: Run clang-format on CUDA code Tests: Run clang-format on CUDA code Tests: Add case for CUDA with C but not C++ CUDA: Link to standard system libraries when linking as CUDA CUDA: Do not use non-existent -Os flag for nvcc CUDA: Fix test cases to not override CUDA flags CUDA: Fix default compiler flags on Windows ctest_update: Fix svn log and external loading FindHDF5: Restore HDF5__INCLUDE_DIR advanced cache entry mark FindHDF5: Fix search for language-specific header file Windows: Fix inconsistent behavior on changes to case of path to cmake CUDA: Fix boolean interpretation of CUDA_SEPARABLE_COMPILATION ExternalProject: Clarify documented role of `INSTALL_DIR` VS2017: If Win 8.1 SDK is not available, use Win 10 SDK Define a custom Git attribute to mark source files as generated Define a custom Git attribute to mark sources using our C style clang-format.bash: Use Git attributes to mark files for formatting VS: Fix .vcxproj indentation Revert "Ninja: Use full path for all source files" Fix COMPILE_PDB_NAME when used on an OBJECT library ExternalProject: Run `git checkout` with `--` to clarify arguments cmFindLibraryCommand: Refactor AddArchitecturePath logic find_library: Skip 'lib => lib' searches if one symlinks the other cmOrderDirectories: Factor out implicit directory check cmOrderDirectories: Consider symlinks when checking implicit directories Tests: Add case for RPATH exclusion of symlinks to implicit directories CMake 3.8.0-rc2 Gregor Jasny (1): Utilities/Sphinx: Port cmake extension to Sphinx 1.4 Kitsu (1): FindJNI: Add jvm paths for Arch Linux Michael Maltese (1): Help: Clarify 'make-style' variable references in cmake-language(7) Michael St?rmer (3): VS: add VS_CSHARP_ sourcefile property VS: add CSharpUtilities module VS: add test for VS_CSHARP_* source file property Orion Poplawski (1): KWIML: Add -Wno-format-security to tolerate -Werror=format-security Robert Maynard (1): CUDA: Detect the toolkit include directories Sebastian Holtermann (1): Autogen: Fix headers not skipped Wilfried Goesgens (1): ExternalProject: Clarify documented role of `INSTALL_COMMAND` From brad.king at kitware.com Fri Mar 3 13:49:50 2017 From: brad.king at kitware.com (Brad King) Date: Fri, 3 Mar 2017 13:49:50 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake merge process transition In-Reply-To: References: Message-ID: <8ea3487a-e0a6-a38c-7222-7a239f03d3e7@kitware.com> On 03/02/2017 03:55 PM, Brad King wrote: > Once we have actually made the final transition I'll merge the new > instructions and post a link here to their final URL. The transition is complete! Documentation of the review process is now rendered directly on the gitlab repo page [1]. The canonical entry point for contributors is still the CONTRIBUTING.rst file [2]. There is also a new place to index developer documentation [3]. [1] https://gitlab.kitware.com/cmake/cmake/blob/master/Help/dev/review.rst [2] https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst [3] https://gitlab.kitware.com/cmake/cmake/blob/master/Help/dev/README.rst CONTRIBUTING.rst now suggests running `Utilities/SetupForDevelopment.sh`. This script has been updated [4] to drop the old configuration of ssh access to cmake.org repositories. It is now suitable for all contributors to run. [4] https://gitlab.kitware.com/cmake/cmake/merge_requests/546 > Furthermore, the staging branch will not be published as an official > branch under refs/heads/ on the gitlab.kitware.com/cmake/cmake repo. > Instead it will be in a custom refs/ path that Git does not clone or > fetch by default. CTest scripts used to drive nightly testing will > need to be adapted for this. I'll post more information for those of > you running nightly builds once we are ready to update the clients. For now the nightly builds will continue to work as before, fetching from the cmake.org repository. The `master`, `nightly-master`, `next`, and `nightly` branches there are now all maintained by a robot that mirrors the equivalent new refs in the gitlab repository. I have some CTest script updates to move clients to following the gitlab repository directly and will work on deploying them soon. -Brad From brad.king at kitware.com Wed Mar 8 09:33:43 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 8 Mar 2017 09:33:43 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake merge process transition In-Reply-To: <8ea3487a-e0a6-a38c-7222-7a239f03d3e7@kitware.com> References: <8ea3487a-e0a6-a38c-7222-7a239f03d3e7@kitware.com> Message-ID: On 03/03/2017 01:49 PM, Brad King wrote: > For now the nightly builds will continue to work as before, fetching > from the cmake.org repository. The `master`, `nightly-master`, `next`, > and `nightly` branches there are now all maintained by a robot that > mirrors the equivalent new refs in the gitlab repository. I have some > CTest script updates to move clients to following the gitlab repository > directly and will work on deploying them soon. I have updated the cmake_common.cmake script to make nightly testing builds follow the gitlab repository branches directly. I've converted Kitware-maintained builds over to them. I'd like to get all testing machines converted away from the cmake.org repository branches. Then we can stop mirroring to the old `nightly-master`, `nightly`, and `next` branches. If you are running a nightly build, please see updated instructions [1]. Basically the old "dashboard" branch is now published in a new repo [2]. The updated cmake_common.cmake script will automatically convert existing source trees to the new repository and branch layout. Thanks, -Brad [1] https://gitlab.kitware.com/cmake/cmake/blob/master/Help/dev/testing.rst [2] https://gitlab.kitware.com/cmake/dashboard-scripts From eike at sf-mail.de Fri Mar 10 06:34:18 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 10 Mar 2017 12:34:18 +0100 Subject: [cmake-developers] Problems with CTestTestParallel Message-ID: <2069405.2jKWzDYVeC@devpool21> My new build machine (castor.sf-tec.de) seems to reliably trigger some sort of error in CTestTestParallel. If I run that test standalone or just "ctest -j 64" in a build tree it seems to work. Running the nightly script gives the error again. I initially suspected some sort of system problem, but other hosts see this problem again, so I now suspect it's a deeper problem. Even if it says "compile errors" the Lockfile binary is produced and can be run successfully. I've attached the complete build dir of that test, maybe anyone has a clue what is going on there. You probably cannot run the executable as this is compiled for a Sparc Niagara 2 processor. Greetings, Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: testparallel.tar.xz Type: application/x-xz-compressed-tar Size: 33224 bytes Desc: not available URL: From brad.king at kitware.com Fri Mar 10 10:32:49 2017 From: brad.king at kitware.com (Brad King) Date: Fri, 10 Mar 2017 10:32:49 -0500 Subject: [cmake-developers] Problems with CTestTestParallel In-Reply-To: <2069405.2jKWzDYVeC@devpool21> References: <2069405.2jKWzDYVeC@devpool21> Message-ID: <3a91004f-80f4-c7a8-5a49-496a81801e35@kitware.com> On 03/10/2017 06:34 AM, Rolf Eike Beer wrote: > I've attached the complete build dir of that test, maybe anyone > has a clue what is going on there The `Testing/Temporary/LastSubmit_20170310-1035.log` shows errors submitting to CDash. However, the `test.cmake` script does not include a `ctest_submit` call. Any idea what happens there? -Brad From renatoutsch at gmail.com Thu Mar 16 21:39:31 2017 From: renatoutsch at gmail.com (Renato Utsch) Date: Fri, 17 Mar 2017 01:39:31 +0000 Subject: [cmake-developers] Adding a new henerator for CMake Message-ID: Hello, Is there documentation somewhere on how to add a new generator to CMake? There's a build system I really want CMake to support, and I'd like to contribute to make that happen. How difficult / how much code is involved in writing a new generator? The build system has nothing to do with makefiles. Thank. -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.huet at gmail.com Fri Mar 17 03:58:43 2017 From: charles.huet at gmail.com (Charles Huet) Date: Fri, 17 Mar 2017 07:58:43 +0000 Subject: [cmake-developers] Adding a new henerator for CMake In-Reply-To: References: Message-ID: Hi, is this buildsystem by any chance FastBuild ? Because if so there is an effort (I'd like to say ongoing, but it's been on hold since the release of 9.7) to implement one here: https://github.com/packadal/CMake/tree/fastbuild-master Otherwise I guess it can serve as another example, as far as I know there is no documentation on how to implement a generator from scratch. Good luck ! Le ven. 17 mars 2017 ? 02:39, Renato Utsch a ?crit : > Hello, > > Is there documentation somewhere on how to add a new generator to CMake? > There's a build system I really want CMake to support, and I'd like to > contribute to make that happen. > > How difficult / how much code is involved in writing a new generator? The > build system has nothing to do with makefiles. > > Thank. > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From renatoutsch at gmail.com Fri Mar 17 06:51:21 2017 From: renatoutsch at gmail.com (Renato Utsch) Date: Fri, 17 Mar 2017 10:51:21 +0000 Subject: [cmake-developers] Adding a new henerator for CMake In-Reply-To: References: Message-ID: Ooh good to know, I'll take a look at how you're doing that. No, the build system is Bazel. On Fri, Mar 17, 2017, 04:58 Charles Huet wrote: > Hi, > > > is this buildsystem by any chance FastBuild ? > Because if so there is an effort (I'd like to say ongoing, but it's been > on hold since the release of 9.7) to implement one here: > https://github.com/packadal/CMake/tree/fastbuild-master > > Otherwise I guess it can serve as another example, as far as I know there > is no documentation on how to implement a generator from scratch. > > Good luck ! > > Le ven. 17 mars 2017 ? 02:39, Renato Utsch a > ?crit : > > Hello, > > Is there documentation somewhere on how to add a new generator to CMake? > There's a build system I really want CMake to support, and I'd like to > contribute to make that happen. > > How difficult / how much code is involved in writing a new generator? The > build system has nothing to do with makefiles. > > Thank. > > -- > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Fri Mar 17 07:29:30 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 17 Mar 2017 12:29:30 +0100 Subject: [cmake-developers] Adding a new henerator for CMake In-Reply-To: References: Message-ID: 2017-03-17 11:51 GMT+01:00 Renato Utsch : > Ooh good to know, I'll take a look at how you're doing that. > > No, the build system is Bazel. > I'd be interested in a Bazel generator as well. I may help or review it depending on my spare time. Eric > On Fri, Mar 17, 2017, 04:58 Charles Huet wrote: > >> Hi, >> >> >> is this buildsystem by any chance FastBuild ? >> Because if so there is an effort (I'd like to say ongoing, but it's been >> on hold since the release of 9.7) to implement one here: >> https://github.com/packadal/CMake/tree/fastbuild-master >> >> Otherwise I guess it can serve as another example, as far as I know there >> is no documentation on how to implement a generator from scratch. >> >> Good luck ! >> >> Le ven. 17 mars 2017 ? 02:39, Renato Utsch a >> ?crit : >> >> Hello, >> >> Is there documentation somewhere on how to add a new generator to CMake? >> There's a build system I really want CMake to support, and I'd like to >> contribute to make that happen. >> >> How difficult / how much code is involved in writing a new generator? The >> build system has nothing to do with makefiles. >> >> Thank. >> >> -- >> >> 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 > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Fri Mar 17 17:38:28 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 17 Mar 2017 16:38:28 -0500 Subject: [cmake-developers] find_program() not using PATH on Windows? Message-ID: So I have Git 2.11.1 installed and it's located in E:\Git\cmd\git.exe. I ticked the option in the installer to add it to path. I tried using the FindGit module via find_package() to find Git, but it's not working. So I tried a simpler case: find_program(GIT_EXECUTABLE git) However it cannot find 'git'. No matter if I specify PATHS either, it won't work. The documentation states it should use PATH at some point to find git.exe, but it doesn't seem that it is doing this. My PATH on Windows is as follows: $ echo %PATH% C:\Program Files\ConEmu\ConEmu\Scripts;C:\Program Files\ConEmu;C:\Program Files\ConEmu\ConEmu;C:\ProgramData\Oracle\Java\javapath;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Beyond Compare 4;E:\ant\bin;E:\android\sdk\tools;E:\android\sdk\platform-tools;E:\code\ziosk-scripts\device-scripts;E:\tools\ninja;E:\Ruby22\bin;E:\Python35;E:\Python35\Scripts;E:\Program Files\CMake\bin;E:\Program Files\CMake\bin;C:\Program Files (x86)\Notepad++;E:\Git\cmd;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\Program Files (x86)\Microsoft Emulator Manager\1.0\;C:\Program Files\TortoiseSVN\bin;C:\Users\robert\AppData\Local\Microsoft\WindowsApps Note that "E:\Git\cmd" is in the list of paths. I'm able to run git.exe commands from CMD as well. Any idea why CMake is not finding git.exe? I'm using CMake v3.8.0-rc2. From brad.king at kitware.com Mon Mar 20 09:40:14 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Mar 2017 09:40:14 -0400 Subject: [cmake-developers] find_program() not using PATH on Windows? In-Reply-To: References: Message-ID: <83c2b0af-f8ae-aa62-2503-d112d8fc87a2@kitware.com> On 03/17/2017 05:38 PM, Robert Dailey wrote: > find_program(GIT_EXECUTABLE git) The steps it follows are documented here: https://cmake.org/cmake/help/v3.8/command/find_program.html It does include PATH, so it is strange that it is not working. Just to be sure the environment is as expected, add message(STATUS "PATH=$ENV{PATH}") just before the find_program call. -Brad From rcdailey.lists at gmail.com Mon Mar 20 10:17:26 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 20 Mar 2017 09:17:26 -0500 Subject: [cmake-developers] find_program() not using PATH on Windows? In-Reply-To: <83c2b0af-f8ae-aa62-2503-d112d8fc87a2@kitware.com> References: <83c2b0af-f8ae-aa62-2503-d112d8fc87a2@kitware.com> Message-ID: On Mon, Mar 20, 2017 at 8:40 AM, Brad King wrote: > On 03/17/2017 05:38 PM, Robert Dailey wrote: >> find_program(GIT_EXECUTABLE git) > > The steps it follows are documented here: > > https://cmake.org/cmake/help/v3.8/command/find_program.html > > It does include PATH, so it is strange that it is not working. > Just to be sure the environment is as expected, add > > message(STATUS "PATH=$ENV{PATH}") > > just before the find_program call. Here is the result: PATH=C:\ProgramData\Oracle\Java\javapath;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Beyond Compare 4;E:\ant\bin;E:\android\sdk\tools;E:\android\sdk\platform-tools;E:\code\ziosk-scripts\device-scripts;E:\tools\ninja;E:\Ruby22\bin;E:\Python35;E:\Python35\Scripts;E:\Program Files\CMake\bin;E:\Program Files\CMake\bin;C:\Program Files (x86)\Notepad++;E:\Git\cmd;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\Program Files (x86)\Microsoft Emulator Manager\1.0\;C:\Program Files\TortoiseSVN\bin;C:\Users\robert\AppData\Local\Microsoft\WindowsApps; Notice that "E:\Git\cmd" is in the list. Trust me I've beat the hell out of this one, I can't figure out what's going on. I even enabled trace logs but it didn't help much. What can I do to help you guys diagnose this problem? I could try getting a reproducible script for you, but this is so dependent on environment I'm not sure if it will serve as a good test case. let me know. From brad.king at kitware.com Mon Mar 20 10:20:13 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Mar 2017 10:20:13 -0400 Subject: [cmake-developers] find_program() not using PATH on Windows? In-Reply-To: References: <83c2b0af-f8ae-aa62-2503-d112d8fc87a2@kitware.com> Message-ID: <975fcc7c-e492-bda5-32f2-a28ffabdc6ad@kitware.com> On 03/20/2017 10:17 AM, Robert Dailey wrote: > What can I do to help you guys diagnose this problem? I could try > getting a reproducible script for you, but this is so dependent on > environment I'm not sure if it will serve as a good test case. Please build CMake from source with debugging enabled. Then you can step through the search process. Thanks, -Brad From rcdailey.lists at gmail.com Mon Mar 20 10:47:22 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 20 Mar 2017 09:47:22 -0500 Subject: [cmake-developers] find_program() not using PATH on Windows? In-Reply-To: <975fcc7c-e492-bda5-32f2-a28ffabdc6ad@kitware.com> References: <83c2b0af-f8ae-aa62-2503-d112d8fc87a2@kitware.com> <975fcc7c-e492-bda5-32f2-a28ffabdc6ad@kitware.com> Message-ID: On Mon, Mar 20, 2017 at 9:20 AM, Brad King wrote: > On 03/20/2017 10:17 AM, Robert Dailey wrote: >> What can I do to help you guys diagnose this problem? I could try >> getting a reproducible script for you, but this is so dependent on >> environment I'm not sure if it will serve as a good test case. > > Please build CMake from source with debugging enabled. Then you > can step through the search process. I was hoping that wouldn't be your answer but looks like it's unavoidable :-) I'm short on time since $DAYJOB keeps me pretty busy. I'll do my best though. Thanks for the guidance. From brad.king at kitware.com Mon Mar 20 11:16:07 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Mar 2017 11:16:07 -0400 Subject: [cmake-developers] Adding a new generator for CMake In-Reply-To: References: Message-ID: <0f617c17-2a96-2825-e4bc-8824e221c952@kitware.com> On 03/17/2017 07:29 AM, Eric Noulard wrote: > 2017-03-17 11:51 GMT+01:00 Renato Utsch: >> No, the build system is Bazel. > > I'd be interested in a Bazel generator as well. > I may help or review it depending on my spare time. [snip] On 03/16/2017 09:39 PM, Renato Utsch wrote: > Is there documentation somewhere on how to add a new generator to CMake? Unfortunately, no. If you look back in the list archives for when a FastBuild generator was proposed I think there were some guidance posts. Before diving into the implementation please post a design here for how the generated build files may be laid out. One will need to map between CMake's abstractions and Bazel's. Thanks, -Brad From s.pankevich at gmail.com Wed Mar 22 03:30:32 2017 From: s.pankevich at gmail.com (Stanislav Pankevich) Date: Wed, 22 Mar 2017 08:30:32 +0100 Subject: [cmake-developers] Is it possible to clone an existing target? Message-ID: Hello, I have a target `MyTarget`. Is there a way I could do something like clone_target(MyTarget MyNewTarget) so that MyNewTarget appears to be the exact clone (deep copy) of original target with the only difference of a target name? P.S. I understand that complex projects may be the edge-cases for a general-purpose cloning routine. I would be fine with a method that does the job in most of the cases. Thanks, Stan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Mar 22 08:06:55 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Mar 2017 08:06:55 -0400 Subject: [cmake-developers] Is it possible to clone an existing target? In-Reply-To: References: Message-ID: <5af192fd-7dfa-6fe7-1175-f43a93837eda@kitware.com> On 03/22/2017 03:30 AM, Stanislav Pankevich wrote: > I have a target `MyTarget`. Is there a way I could do something like > > clone_target(MyTarget MyNewTarget) > > so that MyNewTarget appears to be the exact clone (deep copy) > of original target with the only difference of a target name? There is no builtin way to do that, though you might be able to get close with a macro that reads target properties from the original in order to reproduce them with appropriate commands. What is your use case? -Brad From s.pankevich at gmail.com Wed Mar 22 09:53:48 2017 From: s.pankevich at gmail.com (Stanislav Pankevich) Date: Wed, 22 Mar 2017 14:53:48 +0100 Subject: [cmake-developers] Is it possible to clone an existing target? In-Reply-To: <5af192fd-7dfa-6fe7-1175-f43a93837eda@kitware.com> References: <5af192fd-7dfa-6fe7-1175-f43a93837eda@kitware.com> Message-ID: Hi Brad, Thanks for the answer. Yes, I am going to write my own macro which, I hope, will do the job for the most cases. My use case is to generate the LLVM bitcode artefacts *.bc from existing CMake target instead of a binary that it would produce by default. Cloning existing target and then patching its settings will help me to maintain both original and patched versions of a library targets. I think this feature might be very useful for all R&D projects that do all sorts of analysis or transformations based on LLVM IR: instead of a normal process of compilation of everything then linking, such project just consumes a collection of *.bc files and then does some useful work with it. It is definitely the attempt to use CMake slightly beyond its normal use case. For full background please see my other related question: https://cmake.org/pipermail/cmake-developers/2017-January/029788.html Thanks, Stan On Wed, Mar 22, 2017 at 1:06 PM, Brad King wrote: > On 03/22/2017 03:30 AM, Stanislav Pankevich wrote: > > I have a target `MyTarget`. Is there a way I could do something like > > > > clone_target(MyTarget MyNewTarget) > > > > so that MyNewTarget appears to be the exact clone (deep copy) > > of original target with the only difference of a target name? > > There is no builtin way to do that, though you might be able to > get close with a macro that reads target properties from the > original in order to reproduce them with appropriate commands. > > What is your use case? > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From egor.pugin at gmail.com Wed Mar 22 10:38:25 2017 From: egor.pugin at gmail.com (Egor Pugin) Date: Wed, 22 Mar 2017 17:38:25 +0300 Subject: [cmake-developers] Is it possible to clone an existing target? In-Reply-To: References: <5af192fd-7dfa-6fe7-1175-f43a93837eda@kitware.com> Message-ID: Aliases for imported targets also would be useful. I found some old email threads, but seems they had not been implemented. On 22 March 2017 at 16:53, Stanislav Pankevich wrote: > Hi Brad, > > Thanks for the answer. > > Yes, I am going to write my own macro which, I hope, will do the job for the > most cases. > > My use case is to generate the LLVM bitcode artefacts *.bc from existing > CMake target instead of a binary that it would produce by default. Cloning > existing target and then patching its settings will help me to maintain both > original and patched versions of a library targets. > > I think this feature might be very useful for all R&D projects that do all > sorts of analysis or transformations based on LLVM IR: instead of a normal > process of compilation of everything then linking, such project just > consumes a collection of *.bc files and then does some useful work with it. > It is definitely the attempt to use CMake slightly beyond its normal use > case. > > For full background please see my other related question: > > https://cmake.org/pipermail/cmake-developers/2017-January/029788.html > > Thanks, > > Stan > > On Wed, Mar 22, 2017 at 1:06 PM, Brad King wrote: >> >> On 03/22/2017 03:30 AM, Stanislav Pankevich wrote: >> > I have a target `MyTarget`. Is there a way I could do something like >> > >> > clone_target(MyTarget MyNewTarget) >> > >> > so that MyNewTarget appears to be the exact clone (deep copy) >> > of original target with the only difference of a target name? >> >> There is no builtin way to do that, though you might be able to >> get close with a macro that reads target properties from the >> original in order to reproduce them with appropriate commands. >> >> What is your use case? >> >> -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 -- Egor Pugin From wesley.hoke at gmail.com Wed Mar 22 12:33:31 2017 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed, 22 Mar 2017 09:33:31 -0700 Subject: [cmake-developers] Debugging issues with enable_language(CSHARP) Message-ID: Hi, I'm trying to diagnose why enable_language(CSHARP) isn't working for me in the RC candidate. I've built CMake from source and am trying to step through the code, but am coming up against the fact that this is an enormous project and I don't quite know where to look. The new C# support is something I want to use on an upcoming project, so I'd like to help solve any issues with it Here's where I'm at: * I'm stepping through cmGlobalGenerator.xx in the EnableLanguage function. When the only language is CSHARP, I'm erroring out where it attempts to get the definition of CMAKE_SHARP_COMPILER * In CMakeErrr.log, I see: The CSharp compiler identification could not be found in "C:/Users/wes/Documents/GitHub/add-in/build_/CMakeFiles/3.8.20170317-g45851/CompilerIdCSharp/CompilerIdCSharp.csproj" When I compile and run this project by hand, I'm seeing InfoCompiler "INFO:compiler[Microsoft Visual Studio]" InfoPlatform "INFO:platform[Windows]" InfoArchitecture "INFO:arch[x64]" InfoCompilerVersion "INFO:compiler_version[2017]" printed from this code: static void Main(string[] args) { // we have to print the lines to make sure // the compiler does not optimize them away ... System.Console.WriteLine(InfoCompiler); System.Console.WriteLine(InfoPlatform); System.Console.WriteLine(InfoArchitecture); System.Console.WriteLine(InfoCompilerVersion); } It all looks good to me. What I haven't been able to find is where the project is compiled and run from within CMake and the console stdout read in order to verify the C# compiler settings. thanks, wes -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Mar 22 12:58:46 2017 From: DLRdave at aol.com (David Cole) Date: Wed, 22 Mar 2017 12:58:46 -0400 Subject: [cmake-developers] Debugging issues with enable_language(CSHARP) In-Reply-To: References: Message-ID: Have you looked into https://github.com/Kitware/CMake/blob/master/Modules/CMakeDetermineCSharpCompiler.cmake ? Send steps to reproduce the problem you're seeing... Maybe somebody else here has encountered the same thing and worked through it already. HTH, David C. On Wed, Mar 22, 2017 at 12:33 PM, Wesley Smith wrote: > Hi, > I'm trying to diagnose why enable_language(CSHARP) isn't working for me in > the RC candidate. I've built CMake from source and am trying to step through > the code, but am coming up against the fact that this is an enormous project > and I don't quite know where to look. > > The new C# support is something I want to use on an upcoming project, so I'd > like to help solve any issues with it > > Here's where I'm at: > > > * I'm stepping through cmGlobalGenerator.xx in the EnableLanguage function. > When the only language is CSHARP, I'm erroring out where it attempts to get > the definition of CMAKE_SHARP_COMPILER > > * In CMakeErrr.log, I see: > The CSharp compiler identification could not be found in > "C:/Users/wes/Documents/GitHub/add-in/build_/CMakeFiles/3.8.20170317-g45851/CompilerIdCSharp/CompilerIdCSharp.csproj" > > When I compile and run this project by hand, I'm seeing > > InfoCompiler > "INFO:compiler[Microsoft Visual Studio]" > InfoPlatform > "INFO:platform[Windows]" > InfoArchitecture > "INFO:arch[x64]" > InfoCompilerVersion > "INFO:compiler_version[2017]" > > printed from this code: > > static void Main(string[] args) > { > // we have to print the lines to make sure > // the compiler does not optimize them away ... > System.Console.WriteLine(InfoCompiler); > System.Console.WriteLine(InfoPlatform); > System.Console.WriteLine(InfoArchitecture); > System.Console.WriteLine(InfoCompilerVersion); > } > > > It all looks good to me. What I haven't been able to find is where the > project is compiled and run from within CMake and the console stdout read in > order to verify the C# compiler settings. > > > thanks, > wes > > > -- > > 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 From wesley.hoke at gmail.com Wed Mar 22 13:15:45 2017 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed, 22 Mar 2017 10:15:45 -0700 Subject: [cmake-developers] Debugging issues with enable_language(CSHARP) In-Reply-To: References: Message-ID: Thanks David, I'll have a look at that. Here's my CMake script ``` cmake_minimum_required(VERSION 3.8.0) project(add-in) enable_language(CSHARP) ``` On Wed, Mar 22, 2017 at 9:58 AM, David Cole wrote: > Have you looked into > https://github.com/Kitware/CMake/blob/master/Modules/ > CMakeDetermineCSharpCompiler.cmake > ? > > Send steps to reproduce the problem you're seeing... Maybe somebody > else here has encountered the same thing and worked through it > already. > > > HTH, > David C. > > > > On Wed, Mar 22, 2017 at 12:33 PM, Wesley Smith > wrote: > > Hi, > > I'm trying to diagnose why enable_language(CSHARP) isn't working for me > in > > the RC candidate. I've built CMake from source and am trying to step > through > > the code, but am coming up against the fact that this is an enormous > project > > and I don't quite know where to look. > > > > The new C# support is something I want to use on an upcoming project, so > I'd > > like to help solve any issues with it > > > > Here's where I'm at: > > > > > > * I'm stepping through cmGlobalGenerator.xx in the EnableLanguage > function. > > When the only language is CSHARP, I'm erroring out where it attempts to > get > > the definition of CMAKE_SHARP_COMPILER > > > > * In CMakeErrr.log, I see: > > The CSharp compiler identification could not be found in > > "C:/Users/wes/Documents/GitHub/add-in/build_/CMakeFiles/3.8.20170317- > g45851/CompilerIdCSharp/CompilerIdCSharp.csproj" > > > > When I compile and run this project by hand, I'm seeing > > > > InfoCompiler > > "INFO:compiler[Microsoft Visual Studio]" > > InfoPlatform > > "INFO:platform[Windows]" > > InfoArchitecture > > "INFO:arch[x64]" > > InfoCompilerVersion > > "INFO:compiler_version[2017]" > > > > printed from this code: > > > > static void Main(string[] args) > > { > > // we have to print the lines to make sure > > // the compiler does not optimize them away ... > > System.Console.WriteLine(InfoCompiler); > > System.Console.WriteLine(InfoPlatform); > > System.Console.WriteLine(InfoArchitecture); > > System.Console.WriteLine(InfoCompilerVersion); > > } > > > > > > It all looks good to me. What I haven't been able to find is where the > > project is compiled and run from within CMake and the console stdout > read in > > order to verify the C# compiler settings. > > > > > > thanks, > > wes > > > > > > -- > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wesley.hoke at gmail.com Wed Mar 22 13:32:05 2017 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed, 22 Mar 2017 10:32:05 -0700 Subject: [cmake-developers] Debugging issues with enable_language(CSHARP) In-Reply-To: References: Message-ID: So the answer is enable_language(CSHARP) should be enable_language(CSharp). -------------- next part -------------- An HTML attachment was scrubbed... URL: From wesley.hoke at gmail.com Thu Mar 23 10:41:03 2017 From: wesley.hoke at gmail.com (Wesley Smith) Date: Thu, 23 Mar 2017 07:41:03 -0700 Subject: [cmake-developers] VS Project Settings User Defines Message-ID: Hi, I'm trying to figure out if it's possible to add user defined XML entries to the project config section of a visual studio file. From what I can see it's not, but maybe someone here know of a code path I haven't come across. Specifically, I'm trying to add these tags: ..\..\add-in.ruleset true These are added on a per-config basis. From what I can see, per-config tags are added via Flag arguments, which are hard coded into the source. Basically, I need to get some data into the FlagMap written by void cmVisualStudioGeneratorOptions::OutputFlagMap(std::ostream& fout, const char* indent) The tags written in its calling function (cmVisualStudio10TargetGenerator::WriteMSToolConfigurationValuesManaged) are also hard coded, so I believe this is the only place possible for dynamically generating tags. Any ideas? thanks! wes -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Mar 23 10:51:10 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Mar 2017 10:51:10 -0400 Subject: [cmake-developers] VS Project Settings User Defines In-Reply-To: References: Message-ID: On 03/23/2017 10:41 AM, Wesley Smith wrote: > Specifically, I'm trying to add these tags: > > ..\..\add-in.ruleset > true > > per-config tags are added via Flag arguments, What are the corresponding command-line flags that these add? If they appear in `Source/cmVS*CLFlagTable.h` then adding the flags in `CMAKE_C_FLAGS` or other places we support flags will reverse-map into the vcxproj file settings. -Brad From wesley.hoke at gmail.com Thu Mar 23 11:15:23 2017 From: wesley.hoke at gmail.com (Wesley Smith) Date: Thu, 23 Mar 2017 08:15:23 -0700 Subject: [cmake-developers] VS Project Settings User Defines In-Reply-To: References: Message-ID: The only reference I've been able to find to this property is via the VisualStudio SDK https://msdn.microsoft.com/en-us/library/hh710870.aspx . It doesn't seem to be part of any compiler configuration. The conclusion here being that none of the flags in the VS tables map to this XML tag. I wonder if the solution here is to add something like the VS_GLOBAL_ prefix or somehow attach custom flags to a target config e.g. attach a flag to the Debug|x64 config of target X. CustomValue On Thu, Mar 23, 2017 at 7:51 AM, Brad King wrote: > On 03/23/2017 10:41 AM, Wesley Smith wrote: > > Specifically, I'm trying to add these tags: > > > > ..\..\add-in.ruleset > > true > > > > per-config tags are added via Flag arguments, > > What are the corresponding command-line flags that these add? > If they appear in `Source/cmVS*CLFlagTable.h` then adding the > flags in `CMAKE_C_FLAGS` or other places we support flags will > reverse-map into the vcxproj file settings. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Thu Mar 23 11:16:43 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 23 Mar 2017 10:16:43 -0500 Subject: [cmake-developers] enable_language behavior change Message-ID: I remember around cmake v3.6, the behavior of enable_language() changed so that if you did it too many times, you'd get the error: Language 'C' is currently being enabled. Recursive call not allowed. I need to implement some backward compatibility code to check of CMake version less than 3.6 (or appropriate version), then still call enable_language(), otherwise do not call it. Is 3.6 the correct version in which this behavior was introduced? From brad.king at kitware.com Thu Mar 23 11:32:11 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Mar 2017 11:32:11 -0400 Subject: [cmake-developers] VS Project Settings User Defines In-Reply-To: References: Message-ID: <562eaf35-7829-7194-cea1-1e0fec04c10b@kitware.com> On 03/23/2017 11:15 AM, Wesley Smith wrote: > the solution here is to add something like the VS_GLOBAL_ > prefix or somehow attach custom flags to a target config > e.g. attach a flag to the Debug|x64 config of target X. Once could either try to add a property prefix like that or add dedicated VS_... properties to activate specific features. We have some of the latter already IIRC. -Brad From brad.king at kitware.com Thu Mar 23 11:33:13 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Mar 2017 11:33:13 -0400 Subject: [cmake-developers] enable_language behavior change In-Reply-To: References: Message-ID: On 03/23/2017 11:16 AM, Robert Dailey wrote: > I remember around cmake v3.6, the behavior of enable_language() > changed so that if you did it too many times, you'd get the error: > > Language 'C' is currently being enabled. Recursive call not allowed. > > I need to implement some backward compatibility code to check of CMake > version less than 3.6 (or appropriate version), then still call > enable_language(), otherwise do not call it. > > Is 3.6 the correct version in which this behavior was introduced? Yes. It was commit v3.6.0-rc1~293^2. -Brad From rcdailey.lists at gmail.com Thu Mar 23 11:35:54 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 23 Mar 2017 10:35:54 -0500 Subject: [cmake-developers] enable_language behavior change In-Reply-To: References: Message-ID: On Thu, Mar 23, 2017 at 10:33 AM, Brad King wrote: > On 03/23/2017 11:16 AM, Robert Dailey wrote: >> I remember around cmake v3.6, the behavior of enable_language() >> changed so that if you did it too many times, you'd get the error: >> >> Language 'C' is currently being enabled. Recursive call not allowed. >> >> I need to implement some backward compatibility code to check of CMake >> version less than 3.6 (or appropriate version), then still call >> enable_language(), otherwise do not call it. >> >> Is 3.6 the correct version in which this behavior was introduced? > > Yes. It was commit v3.6.0-rc1~293^2. Thanks Brad. For future reference, are these changes documented anywhere? I searched for "enable_language" in the 3.6 release notes, and there is no 3.6 entry for policy changes. From tobias.hunger at gmail.com Thu Mar 23 11:37:46 2017 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Thu, 23 Mar 2017 16:37:46 +0100 Subject: [cmake-developers] How to get install locations? Message-ID: Hello CMake developers, I got a bug assigned to me about missing information on install locations in cmake server-mode. I wanted to fix that today, but so far I failed to get that information. Does somebody have some hint? What I tried is to just call cmInstallTargetGenerator::GetInstallFilename which is static. That works, but only gives me the filename. I need the full path. cmInstallTargetGenerator has std::string GetDestination(std::string const& config) const, too, which might have what I need. Unfortunately that is not static, so I need to figure out how to get the right instance of cmInstallTargetGenerator. I tried to get the cmMakefile from the localGenerator and then iterate over the list of cmInstallGenerator* I got from the cmMakefile's GetInstallGenerators() method. But that in empty after I am done with configure. Is that expected? Am I on the right track with this? One cmInstallTargetGenerator seems to install one file only and there seems to be one per cmGeneratorTarget. Is that correct? How does the installation of targets with multiple artifacts work? Best Regards, Tobias From brad.king at kitware.com Thu Mar 23 11:50:26 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Mar 2017 11:50:26 -0400 Subject: [cmake-developers] enable_language behavior change In-Reply-To: References: Message-ID: <676c91ab-8d75-7fb4-b1e0-04c65dbcbf56@kitware.com> On 03/23/2017 11:35 AM, Robert Dailey wrote: > Thanks Brad. For future reference, are these changes documented > anywhere? I searched for "enable_language" in the 3.6 release notes, > and there is no 3.6 entry for policy changes. The release notes are for new features, deprecations, and major user-facing changes. We do not cloud them with every bug fix. This enable_language change was a bug fix that prevented a crash in some cases. I was not aware that there were valid projects that trigger the error. -Brad From rcdailey.lists at gmail.com Thu Mar 23 12:08:43 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 23 Mar 2017 11:08:43 -0500 Subject: [cmake-developers] enable_language behavior change In-Reply-To: <676c91ab-8d75-7fb4-b1e0-04c65dbcbf56@kitware.com> References: <676c91ab-8d75-7fb4-b1e0-04c65dbcbf56@kitware.com> Message-ID: On Thu, Mar 23, 2017 at 10:50 AM, Brad King wrote: > On 03/23/2017 11:35 AM, Robert Dailey wrote: >> Thanks Brad. For future reference, are these changes documented >> anywhere? I searched for "enable_language" in the 3.6 release notes, >> and there is no 3.6 entry for policy changes. > > The release notes are for new features, deprecations, and major > user-facing changes. We do not cloud them with every bug fix. > > This enable_language change was a bug fix that prevented a crash > in some cases. I was not aware that there were valid projects > that trigger the error. > > -Brad > Crystax NDK (on master branch) has a toolchain.cmake which invokes enable_language() but it fails. I guess they didn't test with 3.6 or greater. Basically any of the android.toolchain.cmake scripts floating around have this problem, since they're all modifications of the same base change by takanome: https://github.com/taka-no-me/android-cmake I've introduced a PR on the Crystax project to fix the problem, although I do not know if I'm actually addressing the root cause. My assumption is that the C language is already enabled, but they invoke enable_language(C) anyway for some reason. https://github.com/crystax/android-platform-ndk/pull/16 From brad.king at kitware.com Thu Mar 23 13:04:32 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Mar 2017 13:04:32 -0400 Subject: [cmake-developers] enable_language behavior change In-Reply-To: References: <676c91ab-8d75-7fb4-b1e0-04c65dbcbf56@kitware.com> Message-ID: On 03/23/2017 12:08 PM, Robert Dailey wrote: > Crystax NDK (on master branch) has a toolchain.cmake which invokes > enable_language() That is not something we expected to be done or intended to support. A toolchain file should configure information about the toolchain, not inject functionality into project CMake code. > https://github.com/taka-no-me/android-cmake Toolchain files were never meant to have that level of complexity. That was only necessary due to lack of upstream CMake support for Android, and that has now been resolved. -Brad From brad.king at kitware.com Thu Mar 23 13:10:39 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Mar 2017 13:10:39 -0400 Subject: [cmake-developers] How to get install locations? In-Reply-To: References: Message-ID: <0e2e1f0f-6d25-b54d-3043-16ed6aa93c7c@kitware.com> On 03/23/2017 11:37 AM, Tobias Hunger wrote: > cmInstallTargetGenerator has std::string GetDestination(std::string > const& config) const, too, which might have what I need. Unfortunately > that is not static, so I need to figure out how to get the right > instance of cmInstallTargetGenerator. > > I tried to get the cmMakefile from the localGenerator and then iterate > over the list of cmInstallGenerator* I got from the cmMakefile's > GetInstallGenerators() method. But that in empty after I am done with > configure. Is that expected? > > Am I on the right track with this? Yes, but there is a separate list in each cmMakefile for each source directory. You'd have to traverse the entire structure to find all of them. > One cmInstallTargetGenerator seems to install one file only and there > seems to be one per cmGeneratorTarget. Is that correct? How does the > installation of targets with multiple artifacts work? They are created by install() command invocations. See the impl in `Source/cmInstallCommand.cxx`. For each target the artifacts are each given an install generator. Then there is a block that adds all of them: ``` this->Makefile->AddInstallGenerator(archiveGenerator); this->Makefile->AddInstallGenerator(libraryGenerator); this->Makefile->AddInstallGenerator(runtimeGenerator); ... ``` The code model reported by your protocol needs to cover the possibility of more than one install(TARGETS) command for a given target. Each target may be installed to zero or more destinations. You could either try to put this in a list inside each target, or separately model our concept of installation lists that reference targets instead. -Brad From robert.maynard at kitware.com Thu Mar 23 14:33:21 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 23 Mar 2017 14:33:21 -0400 Subject: [cmake-developers] How to get install locations? In-Reply-To: <0e2e1f0f-6d25-b54d-3043-16ed6aa93c7c@kitware.com> References: <0e2e1f0f-6d25-b54d-3043-16ed6aa93c7c@kitware.com> Message-ID: > One cmInstallTargetGenerator seems to install one file only and there > seems to be one per cmGeneratorTarget. Is that correct? How does the > installation of targets with multiple artifacts work? Just to clarify/muddy the waters. Once https://gitlab.kitware.com/cmake/cmake/merge_requests/574 has been merged in cmInstallTargetGenerator will support OBJECT targets which have multiple artifacts to install. On Thu, Mar 23, 2017 at 1:10 PM, Brad King wrote: > On 03/23/2017 11:37 AM, Tobias Hunger wrote: >> cmInstallTargetGenerator has std::string GetDestination(std::string >> const& config) const, too, which might have what I need. Unfortunately >> that is not static, so I need to figure out how to get the right >> instance of cmInstallTargetGenerator. >> >> I tried to get the cmMakefile from the localGenerator and then iterate >> over the list of cmInstallGenerator* I got from the cmMakefile's >> GetInstallGenerators() method. But that in empty after I am done with >> configure. Is that expected? >> >> Am I on the right track with this? > > Yes, but there is a separate list in each cmMakefile for each source > directory. You'd have to traverse the entire structure to find all > of them. > >> One cmInstallTargetGenerator seems to install one file only and there >> seems to be one per cmGeneratorTarget. Is that correct? How does the >> installation of targets with multiple artifacts work? > > They are created by install() command invocations. See the impl in > `Source/cmInstallCommand.cxx`. For each target the artifacts are > each given an install generator. Then there is a block that adds > all of them: > > ``` > this->Makefile->AddInstallGenerator(archiveGenerator); > this->Makefile->AddInstallGenerator(libraryGenerator); > this->Makefile->AddInstallGenerator(runtimeGenerator); > ... > ``` > > The code model reported by your protocol needs to cover the possibility > of more than one install(TARGETS) command for a given target. Each > target may be installed to zero or more destinations. You could either > try to put this in a list inside each target, or separately model our > concept of installation lists that reference targets instead. > > -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 From robert.maynard at kitware.com Fri Mar 24 14:04:48 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 24 Mar 2017 14:04:48 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.8.0-rc3 now ready for testing! Message-ID: I am proud to announce the third CMake 3.8 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.8 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.8/release/3.8.html Some of the more significant changes in CMake 3.8 are: * CMake now supports "CSharp" (C#) as a first-class language. It is currently supported by the Visual Studio Generators for VS 2010 and above. * CMake now supports "CUDA" as a first-class language. It is currently supported by the Makefile Generators and the "Ninja" generator on Linux, macOS, and Windows. Support for the Visual Studio IDE is under development but not included in this release. * The "Compile Features" functionality now offers meta-features that request compiler modes for specific language standard levels (e.g. "cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and "CMAKE_CXX_KNOWN_FEATURES". * The "Compile Features" functionality is now aware of C++ 17. No specific features are yet enumerated besides the "cxx_std_17" meta- feature. * The Visual Studio Generators for VS 2013 and above learned to support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit toolchain on 64-bit hosts. * The Visual Studio Generators learned to treat files passed to "target_link_libraries()" whose names end in ".targets" as MSBuild "targets" files to be imported into generated project files. * The "try_compile()" command source file signature gained new options to specify the language standard to use in the generated test project. * The "try_compile()" command source file signature now honors language standard variables like "CMAKE_CXX_STANDARD". See policy "CMP0067". * A "BUILD_RPATH" target property and corresponding "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH" locations to be added to binaries in the build tree. * The "COMPILE_FLAGS" source file property learned to support "generator expressions". * A new generator expression "$" was added. It resolves to the true-value if the condition is "1" and resolves to the false-value if the condition is "0". * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX and Windows platforms. * The Visual Studio Generators for VS 2010 and above now place per- source file flags after target-wide flags when they are classified as raw flags with no project file setting ("AdditionalOptions"). This behavior is more consistent with the ordering of flags produced by other generators, and allows flags on more-specific properties (per-source) to override those on more general ones (per-target). * The precompiled Windows binary MSI package provided on "cmake.org" now records the installation directory in the Windows Registry under the key "HKLM\Software\Kitware\CMake" with a value named "InstallDir". CMake 3.8 Release Notes *********************** Changes made since CMake 3.7 include the following. New Features ============ Languages --------- C# ~~ * CMake learned to support "CSharp" (C#) as a first-class language that can be enabled via the "project()" and "enable_language()" commands. It is currently supported by the Visual Studio Generators for VS 2010 and above. C# assemblies and programs can be added just like common C++ targets using the "add_library()" and "add_executable()" commands. References between C# targets in the same source tree may be specified by "target_link_libraries()" like for C++. References to system or 3rd-party assemblies may be specified by the target properties "VS_DOTNET_REFERENCE_" and "VS_DOTNET_REFERENCES". * More fine tuning of C# targets may be done using target and source file properties. Specifically the target properties related to Visual Studio ("VS_*") are worth a look (for setting toolset versions, root namespaces, assembly icons, ...). CUDA ~~~~ * CMake learned to support "CUDA" as a first-class language that can be enabled via the "project()" and "enable_language()" commands. * "CUDA" is currently supported by the Makefile Generators and the "Ninja" generator on Linux, macOS, and Windows. Support for the Visual Studio IDE is under development but not included in this release. * The NVIDIA CUDA Toolkit compiler ("nvcc") is supported. C & C++ ~~~~~~~ * The "Compile Features" functionality now offers meta-features that request compiler modes for specific language standard levels (e.g. "cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and "CMAKE_CXX_KNOWN_FEATURES". * The "Compile Features" functionality is now aware of C++ 17. No specific features are yet enumerated besides the "cxx_std_17" meta- feature. * The "Compile Features" functionality is now aware of the availability of C99 in gcc since version 3.4. Platforms --------- * A new minimal platform file for "Fuchsia" was added. Generators ---------- * The "CodeBlocks" extra generator may now be used to generate with "NMake Makefiles JOM". * The Visual Studio Generators for VS 2013 and above learned to support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit toolchain on 64-bit hosts. * The Visual Studio Generators learned to treat files passed to "target_link_libraries()" whose names end in ".targets" as MSBuild "targets" files to be imported into generated project files. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned the option "COMMAND_EXPAND_LISTS" which causes lists in the "COMMAND" argument to be expanded, including lists created by generator expressions. * The "execute_process()" command gained an "ENCODING" option to specify on Windows which encoding is used for output from child process. * The "math(EXPR)" command gained support for unary "+" and "-" operators. * The "source_group()" command gained "TREE" and "PREFIX" options to add groups following source tree directory structure. * The "string(TIMESTAMP)" command learned to treat "%%" as a way to encode plain "%". * The "string(TIMESTAMP)" command will now honor the "SOURCE_DATE_EPOCH" environment variable and use its value instead of the current time. * The "try_compile()" command source file signature gained new options to specify the language standard to use in the generated test project. * The "try_compile()" command source file signature now honors language standard variables like "CMAKE_CXX_STANDARD". See policy "CMP0067". Variables --------- * A "CMAKE_CODELITE_USE_TARGETS" variable was added to tell the "CodeLite" extra generator to change the generated project to have target-centric organization. The "build", "rebuild", and "clean" operations within "CodeLite" then work on a selected target rather than the whole workspace. (Note that the "Ninja" clean operation on a target includes its dependencies, though.) * The "CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS" variable was added to tell the "Sublime Text 2" extra generator to place specified environment variables in the generated ".sublime-project". * The "CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE" variable was added to tell the "Sublime Text 2" extra generator whether to exclude the build tree from the ".sublime-project" when it is inside the source tree. * A "CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD" variable was added to tell Visual Studio Generators for VS 2010 and above to include the "PACKAGE" target in the default build, similar to the existing "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" variable for the "INSTALL" target. Properties ---------- * A "BUILD_RPATH" target property and corresponding "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH" locations to be added to binaries in the build tree. * The "COMPILE_FLAGS" source file property learned to support "generator expressions". * The "FRAMEWORK" target property may now also be applied to static libraries on Apple targets. It will result in a proper Framework but with a static library inside. * Imported Interface Libraries learned new "IMPORTED_LIBNAME" and "IMPORTED_LIBNAME_" target properties to specify a link library name since interface libraries do not build their own library files. * A "_CPPLINT" target property and supporting "CMAKE__CPPLINT" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run the "cpplint" style checker along with the compiler for "C" and "CXX" languages. * A "MANUALLY_ADDED_DEPENDENCIES" target property has been added. It provides a read-only list of dependencies that have been added with the "add_dependencies()" command. * The "MAP_IMPORTED_CONFIG_" target property learned to interpret empty list elements as referring to the configuration-less imported location specified by "IMPORTED_LOCATION". * The "NO_SYSTEM_FROM_IMPORTED" target property is now supported on Imported Interface Libraries. * New source file properties "SKIP_AUTOMOC", "SKIP_AUTOUIC", "SKIP_AUTORCC", and "SKIP_AUTOGEN" were added to allow source files to be excluded from processing by "AUTOMOC", "AUTOUIC", and "AUTORCC" target properties. * A "VS_COPY_TO_OUT_DIR" source file property was added to tell Visual Studio Generators for VS 2010 and above whether or not a file should e copied to the output directory. * A "VS_DEBUGGER_WORKING_DIRECTORY" target property was added to tell Visual Studio Generators for VS 2010 and above what debugger working directory should be set for the target. * A "VS_DOTNET_REFERENCES_COPY_LOCAL" target property was added to specify whether to copy referenced assemblies to the output directory. * A "VS_DOTNET_REFERENCE_" target property was added to tell Visual Studio Generators for VS 2010 and above to add a .NET reference with a given hint path. * A "VS_INCLUDE_IN_VSIX" source file property was added to tell Visual Studio Generators for VS 2010 and above whether to include the file in a Visual Studio extension package. * A "VS_RESOURCE_GENERATOR" source file property was added to give Visual Studio Generators for VS 2010 and above a setting for the resource generator ("C#" only). * A "VS_USER_PROPS" target property was added to tell Visual Studio Generators for VS 2010 and above to use a custom MSBuild user ".props" file. * A "XCODE_EMIT_EFFECTIVE_PLATFORM_NAME" global property was added to tell the "Xcode" generator whether to emit the "EFFECTIVE_PLATFORM_NAME" variable. This is useful when building with multiple SDKs like "macosx" and "iphoneos" in parallel. * New "XCODE_PRODUCT_TYPE" and "XCODE_EXPLICIT_FILE_TYPE" target properties were created to tell the "Xcode" generator to use custom values of the corresponding attributes for a target in the generated Xcode project. Modules ------- * A "CSharpUtilities" module was added to aid parameterization of Visual Studio C# targets. It provides functions to allow automated setting of source file properties to support Windows Forms, WPF/XAML or other technologies as needed. * The "ExternalData" module learned to support multiple content links for one data file using different hashes, e.g. "img.png.sha256" and "img.png.sha1". This allows objects to be fetched from sources indexed by different hash algorithms. * The "ExternalProject" module gained the "GIT_PROGRESS" option to force Git to show progress when cloning repositories. * The "ExternalProject" module gained a "GIT_CONFIG" option to pass " --config" options to Git when cloning repositories. * The "FeatureSummary" module "feature_summary()" command now accepts a new "QUIET_ON_EMPTY" option that suppresses the output when the list of packages that belong to the selected category is empty. * The "FeatureSummary" module "add_feature_info()" command now accepts lists of dependencies for deciding whether a feature is enabled or not. * The package types accepted by the "FeatureSummary" module can now be tweaked by changing the "FeatureSummary_PKG_TYPES", "FeatureSummary_REQUIRED_PKG_TYPES" and "FeatureSummary_DEFAULT_PKG_TYPE" global properties. * The "FindOpenGL" module now provides imported targets "OpenGL::GL" and "OpenGL::GLU" when the libraries are found. * The "UseSWIG" module gained a "swig_add_library" command to give more flexibility over the old "swig_add_module" command. * The "UseSWIG" module "swig_add_source_to_module" command learned a new "SWIG_OUTFILE_DIR" option to control the output file location ("swig -o"). * The "WriteCompilerDetectionHeader" module gained the "ALLOW_UNKNOWN_COMPILERS" and "ALLOW_UNKNOWN_COMPILER_VERSIONS" options that allow creation of headers that will work also with unknown or old compilers by simply assuming they do not support any of the requested features. CTest ----- * The "ctest_memcheck()" command gained a "DEFECT_COUNT " option to capture the number of memory defects detected. * The "ctest_memcheck()" command learned to read the location of suppressions files for sanitizers from the "CTEST_MEMORYCHECK_SUPPRESSIONS_FILE" variable. * The "ctest_memcheck()" command learned to support "LeakSanitizer" independently from "AddressSanitizer". * The "ctest_update()" command "CDASH_UPLOAD" signature was taught to honor the "RETRY_COUNT", "RETRY_DELAY", and "QUIET" options. CPack ----- * The "CPackIFWConfigureFile" module was added to define a new "cpack_ifw_configure_file()" command to configure file templates prepared in QtIFW/SDK/Creator style. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "DEFAULT", "VIRTUAL", "FORCED_INSTALLATION", "REQUIRES_ADMIN_RIGHTS", "DISPLAY_NAME", "UPDATE_TEXT", "DESCRIPTION", "RELEASE_DATE", "AUTO_DEPEND_ON" and "TRANSLATIONS" options to more specific configuration. * The "CPackIFW" module "cpack_ifw_configure_component()" command gained a new "DEPENDENCIES" alias for "DEPENDS" option. * The "CPackIFW" module "cpack_ifw_configure_component_group()" command gained a new "DEPENDS" option. The "DEPENDENCIES" alias also added. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands "PRIORITY" option now is deprecated and will be removed in a future version of CMake. Please use new "SORTING_PRIORITY" option instead. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_WATERMARK", "CPACK_IFW_PACKAGE_BANNER", "CPACK_IFW_PACKAGE_BACKGROUND", "CPACK_IFW_PACKAGE_WIZARD_STYLE", "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH", "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT", and "CPACK_IFW_PACKAGE_TITLE_COLOR" variables to customize a QtIFW installer look. * The "CPackProductBuild" module gained options to sign packages. See the variables "CPACK_PRODUCTBUILD_IDENTITY_NAME", "CPACK_PRODUCTBUILD_KEYCHAIN_PATH", "CPACK_PKGBUILD_IDENTITY_NAME", and "CPACK_PKGBUILD_KEYCHAIN_PATH". * The "CPackRPM" module learned to omit tags that are not supported by provided "rpmbuild" tool. If unsupported tags are set they are ignored and a developer warning is printed out. * The "CPackRPM" module learned to generate main component package which forces generation of a rpm for defined component without component suffix in filename and package name. See "CPACK_RPM_MAIN_COMPONENT" variable. * The "CPackRPM" module learned to generate a single "debuginfo" package on demand even if components packaging is used. See "CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE" variable. * The "CPackRPM" module learned to support multiple directives per file when using "CPACK_RPM_USER_FILELIST" variable. Other ----- * CMake functionality using cryptographic hashes now supports SHA-3 algorithms. * A new generator expression "$" was added. It resolves to the true-value if the condition is "1" and resolves to the false-value if the condition is "0". Deprecated and Removed Features =============================== * The "FeatureSummary" module commands "set_package_info()", "set_feature_info()", "print_enabled_features()", and "print_disabled_features()" are now deprecated. * The "UseSWIG" module "swig_add_module" command is now deprecated in favor of "swig_add_library". Other Changes ============= * If a command specified by the "_CLANG_TIDY" target property returns non-zero at build time this is now treated as an error instead of silently ignored. * The "ctest_memcheck()" command no longer automatically adds "leak_check=1" to the options used by "AddressSanitizer". The default behavior of "AddressSanitizer" is to run *LeakSanitizer* to check leaks unless "leak_check=0". * The "ctest_memcheck()" command was fixed to correctly append extra sanitizer options read from the "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable to the environment variables used internally by the sanitizers. * The "FeatureSummary" module "set_package_properties()" command no longer forces the package type to "OPTIONAL" when the type is not explicitly set. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX and Windows platforms. * Calls to the "FindPkgConfig" module "pkg_check_modules()" command following a successful call learned to re-evaluate the cached values for a given prefix after changes to the parameters to the command for that prefix. * When using "AUTOMOC" or "AUTOUIC", generated "moc_*", "*.moc" and "ui_*" are placed in the "/_autogen/include" directory which is automatically added to the target's "INCLUDE_DIRECTORIES". It is therefore not necessary anymore to have "CMAKE_CURRENT_BINARY_DIR" in the target's "INCLUDE_DIRECTORIES". * The "Sublime Text 2" generator no longer runs the native build command (e.g. "ninja" or "make") with verbose build output enabled. * The "try_compile()" command source file signature now honors the "CMAKE_WARN_DEPRECATED" variable value in the generated test project. * The Visual Studio Generators for VS 2010 and above now place per- source file flags after target-wide flags when they are classified as raw flags with no project file setting ("AdditionalOptions"). This behavior is more consistent with the ordering of flags produced by other generators, and allows flags on more-specific properties (per-source) to override those on more general ones (per-target). * The precompiled Windows binary MSI package provided on "cmake.org" now records the installation directory in the Windows Registry under the key "HKLM\Software\Kitware\CMake" with a value named "InstallDir". ---------------------------------------------------------------------------- Changes made since CMake 3.8.0-rc2: Ben Boeckel (1): FindHDF5: fix quoting Brad King (22): Revert "Remove CTestTestfile.cmake when BUILD_TESTING is OFF" FindGit: Avoid finding VS 2017 non-general Git installation Help: Fix typo in CMAKE_VS_PLATFORM_TOOLSET_HOST_ARCHITECTURE libarchive: backport rc4 crypto requirement update FindHDF5: Improve HDF5_ROOT variable documentation FindHDF5: Add option to skip finding package configuration file Ninja: Fix Fortran `include` dependency on generated file FindwxWidgets: Use `MSVC_VERSION` instead of `MSVC##` FindwxWidgets: Add support for VS 2017 v141 toolset MSVC: Exclude future cl 20+ from MSVC14 variable Help: Clarify MSVC14 docs w.r.t. VS 2017 v141 toolset Help: Document preference of `MSVC_VERSION` over `MSVC##` InstallRequiredSystemLibraries: Use `MSVC_VERSION` instead of `MSVC##` InstallRequiredSystemLibraries: Refactor to avoid macros InstallRequiredSystemLibraries: Drop version from variable names FindBoost: Avoid mentioning discouraged `MSVC##`` variable FindGTK2: Use `MSVC_VERSION` instead of `MSVC##` FindRuby: Use `MSVC_VERSION` instead of `MSVC##` InstallRequiredSystemLibraries: Split VS IDE and DLL versions InstallRequiredSystemLibraries: Split MFC redist dir variable InstallRequiredSystemLibraries: Add support for VS 2017 CMake 3.8.0-rc3 Daniel Black (1): CPack/RPM: fix error message associated with source path length Domen Vrankar (1): CPack/RPM: fix cpack_rpm_debugsymbol_check parameter Gregor Jasny (1): FindBLAS/LAPACK: Format documentation Kris Thielemans (1): FindHDF5: Restore `-D` in HDF5_DEFINITIONS Mateusz ?oskot (2): FindBoost: Add support for 1.64 FindBoost: Update support for 1.64 Matth?us G. Chajdas (1): FindVulkan: Fix for SDK versions < 1.0.42 on 32-bit Windows Michael St?rmer (2): VS: Do not treat custom targets as CSharp targets CSharpUtilities: Fix documentation Robert Maynard (1): CUDA: Disable support for using response files. Tobias Hunger (1): server-mode: Make CMAKE_HOME_DIRECTORY more reliable Wojciech Mamrak (1): Help: Update MSVC_VERSION for Visual Studio 2017 From jerry.c.t at web.de Fri Mar 24 14:35:52 2017 From: jerry.c.t at web.de (jerry.c.t at web.de) Date: Fri, 24 Mar 2017 19:35:52 +0100 Subject: [cmake-developers] Build multiple CMake projects Message-ID: Hi, I have some CMake projects which depend on each other. They provide Config scripts (all generated with the help of CMakePackageConfigHelpers) and the CMake projects find there dependencies with find_package(). Even the transitive dependencies are correctly modelled (exported to the Config scripts with find_dependency). The setup in general is fine. The only drawback is that I have to build and install them manually in the correct order. For example A depends on B depends on C, I have to build+install first C, than B, then A ... The number of projects are getting more and more and it's getting harder to build them. So my question: a) Is there a CMake way to generate a dependency graph and build them in the correct order, i.e., the same as CMake does within a project with the targets but this time on project level? b) What possiblities are provided by CMake to support this? c) Are there tools you can recommend? jerry From petr.kmoch at gmail.com Mon Mar 27 03:18:58 2017 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 27 Mar 2017 09:18:58 +0200 Subject: [cmake-developers] Build multiple CMake projects In-Reply-To: References: Message-ID: Hi Jerry, from your description, it seems like you might be looking for the CMake module ExternalProject: https://cmake.org/cmake/help/latest/module/ExternalProject.html The idea is that you create a "superbuild" CMake project which consists of ExternalProject_Add calls and related infrastructure, specifying dependencies between the projects etc. Building this "superbuild" will then result in acquiring, building, and installing the individual external projects, in proper order. Petr On 24 March 2017 at 19:35, wrote: > Hi, > > I have some CMake projects which depend on each other. They provide Config > scripts (all generated with the help of CMakePackageConfigHelpers) and the > CMake projects find there dependencies with find_package(). Even the > transitive dependencies are correctly modelled (exported to the Config > scripts with find_dependency). > > The setup in general is fine. The only drawback is that I have to build > and install them manually in the correct order. For example A depends on B > depends on C, I have to build+install first C, than B, then A ... > > The number of projects are getting more and more and it's getting harder > to build them. > > So my question: > a) Is there a CMake way to generate a dependency graph and build them in > the correct order, i.e., the same as CMake does within a project with the > targets but this time on project level? > b) What possiblities are provided by CMake to support this? > c) Are there tools you can recommend? > > jerry > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at pfeifer-mail.de Mon Mar 27 03:35:59 2017 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Mon, 27 Mar 2017 09:35:59 +0200 Subject: [cmake-developers] Build multiple CMake projects In-Reply-To: References: Message-ID: On Fri, Mar 24, 2017 at 7:35 PM, wrote: > Hi, > > I have some CMake projects which depend on each other. They provide Config > scripts (all generated with the help of CMakePackageConfigHelpers) and the > CMake projects find there dependencies with find_package(). Even the > transitive dependencies are correctly modelled (exported to the Config > scripts with find_dependency). > > The setup in general is fine. The only drawback is that I have to build > and install them manually in the correct order. For example A depends on B > depends on C, I have to build+install first C, than B, then A ... > > The number of projects are getting more and more and it's getting harder > to build them. > > So my question: > a) Is there a CMake way to generate a dependency graph and build them in > the correct order, i.e., the same as CMake does within a project with the > targets but this time on project level? > b) What possiblities are provided by CMake to support this? > c) Are there tools you can recommend? > Make sure that your projects can be used both as a sub-project and as a installed package. That means: if the installed package provides a target called C::C, create an alias target with that name, so that projects A and B can use that name in target_link_libraries in both cases. The next thing is to make sure that `find_package(C REQUIRED)` finds the installed package when it supposed to be used, but does nothing when C is used as a sub-project. This can be achieved by overriding the `find_package` command. The original command can be called by prefixing it with _. Your top-level project might look like this: set(subprojects A B C) macro(find_package name) if("${name}" IN_LIST subprojects) set("${name}_FOUND" TRUE) else() _find_package("${name}" ${ARGN}) endif() endmacro() add_subdirectory(A) add_subdirectory(B) add_subdirectory(C) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleigh at codelibre.net Mon Mar 27 17:03:39 2017 From: rleigh at codelibre.net (Roger Leigh) Date: Mon, 27 Mar 2017 22:03:39 +0100 Subject: [cmake-developers] Support for version suffixes Message-ID: Hi folks, I'd like to bring this issue to your attention to canvas some feedback regarding the use of version suffixes: https://gitlab.kitware.com/cmake/cmake/issues/16716 This is basically a proposal to allow an optional version suffix like "-rc3", "-beta1" etc. in addition to the existing major.minor.patch.tweak pattern, for better interoperability with systems and software releases already using such suffixes, and also to permit the use of such suffixes by CMake projects for their own purposes. A version suffix would be usable anywhere currently using 4 digit versions, with all the necessary functionality in CMake being updated to handle this. The proposal linked above contains a much more detailed rationale and suggested implementation strategy. I'd be very happy to hear any thoughts anyone has regarding this either on the above issue, or here. Thanks all, Roger From jeanmichael.celerier at gmail.com Tue Mar 28 04:07:59 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Tue, 28 Mar 2017 10:07:59 +0200 Subject: [cmake-developers] Support for version suffixes In-Reply-To: References: Message-ID: I remember asking for the same thing a few weeks ago on IRC because of a small behaviour change in cmake 3.8.0 rc2 that I wanted to put behind an if(version_less). Alphanumeric ordering would certainly work for most projects : alpha < beta < rc. (I generally use a0, a1, a2... b0, b1, b2...) Best Jean-Micha?l On Mon, Mar 27, 2017 at 11:03 PM, Roger Leigh wrote: > Hi folks, > > I'd like to bring this issue to your attention to canvas some feedback > regarding the use of version suffixes: > > https://gitlab.kitware.com/cmake/cmake/issues/16716 > > This is basically a proposal to allow an optional version suffix like > "-rc3", "-beta1" etc. in addition to the existing major.minor.patch.tweak > pattern, for better interoperability with systems and software releases > already using such suffixes, and also to permit the use of such suffixes by > CMake projects for their own purposes. A version suffix would be usable > anywhere currently using 4 digit versions, with all the necessary > functionality in CMake being updated to handle this. > > The proposal linked above contains a much more detailed rationale and > suggested implementation strategy. I'd be very happy to hear any thoughts > anyone has regarding this either on the above issue, or here. > > > Thanks all, > Roger > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at pfeifer-mail.de Tue Mar 28 05:31:09 2017 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Tue, 28 Mar 2017 11:31:09 +0200 Subject: [cmake-developers] Support for version suffixes In-Reply-To: References: Message-ID: On Mon, Mar 27, 2017 at 11:03 PM, Roger Leigh wrote: > Hi folks, > > I'd like to bring this issue to your attention to canvas some feedback > regarding the use of version suffixes: > > https://gitlab.kitware.com/cmake/cmake/issues/16716 > > This is basically a proposal to allow an optional version suffix like > "-rc3", "-beta1" etc. in addition to the existing major.minor.patch.tweak > pattern, for better interoperability with systems and software releases > already using such suffixes, and also to permit the use of such suffixes by > CMake projects for their own purposes. A version suffix would be usable > anywhere currently using 4 digit versions, with all the necessary > functionality in CMake being updated to handle this. > > The proposal linked above contains a much more detailed rationale and > suggested implementation strategy. I'd be very happy to hear any thoughts > anyone has regarding this either on the above issue, or here. > Hi Roger, Thanks for starting this discussion! I started a prototype for a PKGCONF mode for find_package in addition to CONFIG and PACKAGE. In this mode, CMake parses .pc files and creates one imported target per file where values from the .pc file are set as target properties. It works pretty well and does not rely on pkg-config. To be compatible with pkg-config, I needed to extend `cmSystemTools::VersionCompare`, because pkg-config uses RPM version comparison. This however breaks current tests because 1.2 != 1.2.0 in the RPM version comparison. It might be necessary to provide several version comparison algorithms like Debian, RPM, Semver. Also splitting the version string into components may depend on the versioning scheme. Given OpenSSL version 1.0.2g, is that patch 2 suffix g, or rather patch 2g? Cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Mar 28 09:16:05 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 28 Mar 2017 09:16:05 -0400 Subject: [cmake-developers] Support for version suffixes In-Reply-To: References: Message-ID: <853024c5-08c0-b62c-62e5-fecc5fc5f85e@kitware.com> On 03/28/2017 04:07 AM, Jean-Micha?l Celerier wrote: > I remember asking for the same thing a few weeks ago on IRC because of > a small behaviour change in cmake 3.8.0 rc2 that I wanted to put behind > an if(version_less). For reference, this was also proposed in issue 16656 [1]. The problem is that 3.8.0-rc1 must not compare as less than 3.8.0 or the release candidate will not satisfy `cmake_minimum_required(VERSION 3.8.0)`. We want the release candidates to behave for projects as if they were the final release in order to fully test them as such. Users running a release candidate should always be running the latest candidate. Once the final release for a given version of CMake is out, none of its corresponding release candidates should be used anymore. Projects should write their code under this assumption. If a project has trouble with a specific release candidate then it can use `if(MATCHES)` or another string-based approach to reject that specific release candidate version, just as it might do if there were a problem with a final release version of CMake. -Brad [1] https://gitlab.kitware.com/cmake/cmake/issues/16656 From brad.king at kitware.com Tue Mar 28 09:18:38 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 28 Mar 2017 09:18:38 -0400 Subject: [cmake-developers] Support for version suffixes In-Reply-To: References: Message-ID: <9b8d3179-1266-2201-2ce8-640e22de6d58@kitware.com> On 03/27/2017 05:03 PM, Roger Leigh wrote: > I'd like to bring this issue to your attention to canvas some feedback > regarding the use of version suffixes: > > https://gitlab.kitware.com/cmake/cmake/issues/16716 > > The proposal linked above contains a much more detailed rationale and > suggested implementation strategy. I'd be very happy to hear any > thoughts anyone has regarding this either on the above issue, or here. Thanks for starting this thread. I agree it would be nice to do more general version comparisons. However, I think more design work is needed first. Currently we have: * cmSystemTools::VersionCompare compares leading unsigned integer components separated by `.` and ignores suffixes. This is used by VERSION_LESS and such. * cmSystemTools::strverscmp implements the strverscmp(3) function. This will happen to include suffixes in the version comparison due to a very clever definition of the comparison function, but it does not specifically treat suffixes as special. It is also compatible with cmSystemTools::VersionCompare unless an integer component has leading zeros. It is used by `CMAKE_FIND_PACKAGE_SORT_ORDER`, but otherwise we have no way to access it from the CMake language. There are several version comparison conventions out there that interpret suffixes in some way. For example, PEP 440 [1]. I'd like to see a summary of such schemes that are widely used. Since CMake code often ends up comparing versions of other projects, we may even need to implement several comparison functions and provide a more general interface to specify which one to use for a given check. Thanks, -Brad [1] https://www.python.org/dev/peps/pep-0440/#version-scheme From chuck.atkins at kitware.com Tue Mar 28 16:51:55 2017 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Tue, 28 Mar 2017 16:51:55 -0400 Subject: [cmake-developers] Some info about AIX needed In-Reply-To: <5660ab24-9cfa-5e78-1c9d-b00aab07f484@googlemail.com> References: <5660ab24-9cfa-5e78-1c9d-b00aab07f484@googlemail.com> Message-ID: Hi Gregor, Please try to keep these sort of conversations on the dev list to ensure that others can benefit from or contribute to the discussion as well. I just checked on the AIX 7.2 dashboard machine. Here's the output from all possible uname switches described in the manpage: uname -a AIX power8-aix 2 7 00FA74164C00 uname -x AIX power8-aix 4201911884 2 7 00FA74164C00 uname -F 80000B6460800000 uname -f 80000B6460800003 uname -l 4201911884 uname -L 3 p3-power8-aix uname -m 00FA74164C00 uname -M IBM,8284-22A uname -n power8-aix uname -p powerpc uname -r 2 uname -s AIX uname -u IBM,02217416W uname -v 7 uname -W 0 Attached is the cmake --system-information output from that same machine using the CMake nightly build build with the IBM XL compiler 13.1.3: [atkins3 at power8-aix My_Tests]$ ./CMake_IBM-13.1.3/CMake-build/bin/cmake --version cmake version 3.8.20170327-gc4c307 CMake suite maintained and supported by Kitware (kitware.com/cmake). [atkins3 at power8-aix My_Tests]$ - Chuck On Tue, Mar 28, 2017 at 4:32 PM, Gregor Jasny wrote: > On 3/28/17 10:08 PM, Gregor Jasny wrote: > > Could you please run the following on you AIX box? > > > > uname -s ; uname -v ; uname -r > > Maybe also > > cmake --system-information aix.txt and attach the output. > > Thanks, > Gregor > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Avoid ctest truncation of output: CTEST_FULL_OUTPUT ======================================================== === MAIN VARIABLES ======================================================== CMAKE_STATIC_LIBRARY_PREFIX == "lib" CMAKE_STATIC_LIBRARY_SUFFIX == ".a" CMAKE_SHARED_LIBRARY_PREFIX == "lib" CMAKE_SHARED_LIBRARY_SUFFIX == ".so" CMAKE_SHARED_MODULE_PREFIX == "lib" CMAKE_SHARED_MODULE_SUFFIX == ".so" CMAKE_DL_LIBS == "-lld" CMAKE_LIBRARY_PATH_FLAG == "-L" CMAKE_LINK_LIBRARY_FLAG == "-l" CMAKE_SKIP_RPATH == "NO" CMAKE_SYSTEM_INFO_FILE == "Platform/AIX" CMAKE_SYSTEM_NAME == "AIX" CMAKE_SYSTEM == "AIX-2" CMAKE_CXX_COMPILER == "/usr/bin/c++" CMAKE_C_COMPILER == "/usr/bin/gcc" CMAKE_COMPILER_IS_GNUCC == "1" CMAKE_COMPILER_IS_GNUCXX == "1" // C shared library flag CMAKE_SHARED_LIBRARY_C_FLAGS == "-fPIC" CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS == "-shared -Wl,-G,-bnoipath" CMAKE_SHARED_LIBRARY_LINK_FLAGS == "" CMAKE_SHARED_LIBRARY_RUNTIME_FLAG == "" CMAKE_SHARED_LIBRARY_RUNTIME_FLAG_SEP == "" CMAKE_SHARED_LIBRARY_LINK_STATIC_C_FLAGS == "" CMAKE_SHARED_LIBRARY_LINK_DYNAMIC_C_FLAGS == "" // C shared module flags CMAKE_SHARED_MODULE_C_FLAGS == "-fPIC" CMAKE_SHARED_MODULE_CREATE_C_FLAGS == "-shared -Wl,-G,-bnoipath" CMAKE_SHARED_MODULE_LINK_STATIC_C_FLAGS == "" CMAKE_SHARED_MODULE_LINK_DYNAMIC_C_FLAGS == "" // C exe flags CMAKE_EXE_LINK_STATIC_C_FLAGS == "" CMAKE_EXE_LINK_DYNAMIC_C_FLAGS == "" // CXX shared library flags CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS == "-shared -Wl,-G,-bnoipath" CMAKE_SHARED_LIBRARY_CXX_FLAGS == "-fPIC" CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS == "-Wl,-bexpall" CMAKE_SHARED_LIBRARY_RUNTIME_CXX_FLAG == "-Wl,-blibpath:" CMAKE_SHARED_LIBRARY_RUNTIME_CXX_FLAG_SEP == ":" CMAKE_SHARED_LIBRARY_LINK_STATIC_CXX_FLAGS == "" CMAKE_SHARED_LIBRARY_LINK_DYNAMIC_CXX_FLAGS == "" // CXX shared module flags CMAKE_SHARED_MODULE_CREATE_CXX_FLAGS == "-shared -Wl,-G,-bnoipath" CMAKE_SHARED_MODULE_CXX_FLAGS == "-fPIC" CMAKE_SHARED_MODULE_LINK_STATIC_CXX_FLAGS == "" CMAKE_SHARED_MODULE_LINK_DYNAMIC_CXX_FLAGS == "" // CXX exe flags CMAKE_EXE_LINK_STATIC_CXX_FLAGS == "" CMAKE_EXE_LINK_DYNAMIC_CXX_FLAGS == "" CMAKE_USER_MAKE_RULES_OVERRIDE == "" CMAKE_VERBOSE_MAKEFILE == "FALSE" CMAKE_BUILD_TYPE == "" CMAKE_CXX_FLAGS == "" CMAKE_CXX_FLAGS_DEBUG == "-g" CMAKE_CXX_FLAGS_MINSIZEREL == "-Os -DNDEBUG" CMAKE_CXX_FLAGS_RELEASE == "-O3 -DNDEBUG" CMAKE_CXX_FLAGS_RELWITHDEBINFO == "-O2 -g -DNDEBUG" CMAKE_C_FLAGS == "" CMAKE_C_FLAGS_DEBUG == "-g" CMAKE_C_FLAGS_MINSIZEREL == "-Os -DNDEBUG" CMAKE_C_FLAGS_RELEASE == "-O3 -DNDEBUG" CMAKE_C_FLAGS_RELWITHDEBINFO == "-O2 -g -DNDEBUG" // build rules CMAKE_CXX_CREATE_SHARED_LIBRARY == " -o " CMAKE_CXX_CREATE_SHARED_MODULE == " -o " CMAKE_C_CREATE_SHARED_LIBRARY == " -o " CMAKE_C_CREATE_SHARED_MODULE == " -o " CMAKE_CXX_CREATE_STATIC_LIBRARY == "" CMAKE_C_CREATE_STATIC_LIBRARY == "" CMAKE_CXX_COMPILE_OBJECT == " -o -c " CMAKE_C_COMPILE_OBJECT == " -o -c " CMAKE_C_LINK_EXECUTABLE == " -o " CMAKE_CXX_LINK_EXECUTABLE == " -o " ================================================================= === VARIABLES ================================================================= CMAKE_AR "/usr/bin/ar" CMAKE_AR "/usr/bin/ar" CMAKE_BASE_NAME "g++" CMAKE_BINARY_DIR "/home/atkins3/Dashboards/My_Tests/__cmake_systeminformation" CMAKE_BUILD_TOOL "/usr/bin/gmake" CMAKE_BUILD_TYPE "" CMAKE_C11_COMPILE_FEATURES "c_std_11;c_static_assert" CMAKE_C11_EXTENSION_COMPILE_OPTION "-std=gnu11" CMAKE_C11_STANDARD_COMPILE_OPTION "-std=c11" CMAKE_C90_COMPILE_FEATURES "c_std_90;c_function_prototypes" CMAKE_C90_EXTENSION_COMPILE_OPTION "-std=gnu90" CMAKE_C90_STANDARD_COMPILE_OPTION "-std=c90" CMAKE_C99_COMPILE_FEATURES "c_std_99;c_restrict;c_variadic_macros" CMAKE_C99_EXTENSION_COMPILE_OPTION "-std=gnu99" CMAKE_C99_STANDARD_COMPILE_OPTION "-std=c99" CMAKE_CFG_INTDIR "." CMAKE_COLOR_MAKEFILE "ON" CMAKE_COMMAND "/home/atkins3/Dashboards/My_Tests/CMake_IBM-13.1.3/CMake-build/bin/cmake" CMAKE_COMPILER_IS_GNUCC "1" CMAKE_COMPILER_IS_GNUCXX "1" CMAKE_CPACK_COMMAND "/home/atkins3/Dashboards/My_Tests/CMake_IBM-13.1.3/CMake-build/bin/cpack" CMAKE_CROSSCOMPILING "FALSE" CMAKE_CTEST_COMMAND "/home/atkins3/Dashboards/My_Tests/CMake_IBM-13.1.3/CMake-build/bin/ctest" CMAKE_CURRENT_BINARY_DIR "/home/atkins3/Dashboards/My_Tests/__cmake_systeminformation" CMAKE_CURRENT_LIST_DIR "/home/atkins3/Dashboards/My_Tests/__cmake_systeminformation" CMAKE_CURRENT_LIST_FILE "/home/atkins3/Dashboards/My_Tests/__cmake_systeminformation/CMakeLists.txt" CMAKE_CURRENT_SOURCE_DIR "/home/atkins3/Dashboards/My_Tests/__cmake_systeminformation" CMAKE_CXX11_COMPILE_FEATURES "cxx_std_11;cxx_alias_templates;cxx_alignas;cxx_alignof;cxx_attributes;cxx_auto_type;cxx_constexpr;cxx_decltype;cxx_decltype_incomplete_return_types;cxx_default_function_template_args;cxx_defaulted_functions;cxx_defaulted_move_initializers;cxx_delegating_constructors;cxx_deleted_functions;cxx_enum_forward_declarations;cxx_explicit_conversions;cxx_extended_friend_declarations;cxx_extern_templates;cxx_final;cxx_func_identifier;cxx_generalized_initializers;cxx_inheriting_constructors;cxx_inline_namespaces;cxx_lambdas;cxx_local_type_template_args;cxx_long_long_type;cxx_noexcept;cxx_nonstatic_member_init;cxx_nullptr;cxx_override;cxx_range_for;cxx_raw_string_literals;cxx_reference_qualified_functions;cxx_right_angle_brackets;cxx_rvalue_references;cxx_sizeof_member;cxx_static_assert;cxx_strong_enums;cxx_thread_local;cxx_trailing_return_types;cxx_unicode_literals;cxx_uniform_initialization;cxx_unrestricted_unions;cxx_user_literals;cxx_variadic_macros;cxx_variadic_templates" CMAKE_CXX11_EXTENSION_COMPILE_OPTION "-std=gnu++11" CMAKE_CXX11_STANDARD_COMPILE_OPTION "-std=c++11" CMAKE_CXX14_COMPILE_FEATURES "cxx_std_14;cxx_aggregate_default_initializers;cxx_attribute_deprecated;cxx_binary_literals;cxx_contextual_conversions;cxx_decltype_auto;cxx_digit_separators;cxx_generic_lambdas;cxx_lambda_init_captures;cxx_relaxed_constexpr;cxx_return_type_deduction;cxx_variable_templates" CMAKE_CXX14_EXTENSION_COMPILE_OPTION "-std=gnu++14" CMAKE_CXX14_STANDARD_COMPILE_OPTION "-std=c++14" CMAKE_CXX17_COMPILE_FEATURES "cxx_std_17" CMAKE_CXX17_EXTENSION_COMPILE_OPTION "-std=gnu++1z" CMAKE_CXX17_STANDARD_COMPILE_OPTION "-std=c++1z" CMAKE_CXX98_COMPILE_FEATURES "cxx_std_98;cxx_template_template_parameters" CMAKE_CXX98_EXTENSION_COMPILE_OPTION "-std=gnu++98" CMAKE_CXX98_STANDARD_COMPILE_OPTION "-std=c++98" CMAKE_CXX_ABI_COMPILED "TRUE" CMAKE_CXX_ARCHIVE_APPEND " q " CMAKE_CXX_ARCHIVE_CREATE " qc " CMAKE_CXX_ARCHIVE_FINISH " " CMAKE_CXX_CL_SHOWINCLUDES_PREFIX "" CMAKE_CXX_COMPILER "/usr/bin/c++" CMAKE_CXX_COMPILER "/usr/bin/c++" CMAKE_CXX_COMPILER_ABI "" CMAKE_CXX_COMPILER_ARG1 "" CMAKE_CXX_COMPILER_ENV_VAR "CXX" CMAKE_CXX_COMPILER_ID "GNU" CMAKE_CXX_COMPILER_ID_PLATFORM_CONTENT "#define STRINGIFY_HELPER(X) #X #define STRINGIFY(X) STRINGIFY_HELPER(X) /* Identify known platforms by name. */ #if defined(__linux) || defined(__linux__) || defined(linux) # define PLATFORM_ID "Linux" #elif defined(__CYGWIN__) # define PLATFORM_ID "Cygwin" #elif defined(__MINGW32__) # define PLATFORM_ID "MinGW" #elif defined(__APPLE__) # define PLATFORM_ID "Darwin" #elif defined(_WIN32) || defined(__WIN32__) || defined(WIN32) # define PLATFORM_ID "Windows" #elif defined(__FreeBSD__) || defined(__FreeBSD) # define PLATFORM_ID "FreeBSD" #elif defined(__NetBSD__) || defined(__NetBSD) # define PLATFORM_ID "NetBSD" #elif defined(__OpenBSD__) || defined(__OPENBSD) # define PLATFORM_ID "OpenBSD" #elif defined(__sun) || defined(sun) # define PLATFORM_ID "SunOS" #elif defined(_AIX) || defined(__AIX) || defined(__AIX__) || defined(__aix) || defined(__aix__) # define PLATFORM_ID "AIX" #elif defined(__sgi) || defined(__sgi__) || defined(_SGI) # define PLATFORM_ID "IRIX" #elif defined(__hpux) || defined(__hpux__) # define PLATFORM_ID "HP-UX" #elif defined(__HAIKU__) # define PLATFORM_ID "Haiku" #elif defined(__BeOS) || defined(__BEOS__) || defined(_BEOS) # define PLATFORM_ID "BeOS" #elif defined(__QNX__) || defined(__QNXNTO__) # define PLATFORM_ID "QNX" #elif defined(__tru64) || defined(_tru64) || defined(__TRU64__) # define PLATFORM_ID "Tru64" #elif defined(__riscos) || defined(__riscos__) # define PLATFORM_ID "RISCos" #elif defined(__sinix) || defined(__sinix__) || defined(__SINIX__) # define PLATFORM_ID "SINIX" #elif defined(__UNIX_SV__) # define PLATFORM_ID "UNIX_SV" #elif defined(__bsdos__) # define PLATFORM_ID "BSDOS" #elif defined(_MPRAS) || defined(MPRAS) # define PLATFORM_ID "MP-RAS" #elif defined(__osf) || defined(__osf__) # define PLATFORM_ID "OSF1" #elif defined(_SCO_SV) || defined(SCO_SV) || defined(sco_sv) # define PLATFORM_ID "SCO_SV" #elif defined(__ultrix) || defined(__ultrix__) || defined(_ULTRIX) # define PLATFORM_ID "ULTRIX" #elif defined(__XENIX__) || defined(_XENIX) || defined(XENIX) # define PLATFORM_ID "Xenix" #elif defined(__WATCOMC__) # if defined(__LINUX__) # define PLATFORM_ID "Linux" # elif defined(__DOS__) # define PLATFORM_ID "DOS" # elif defined(__OS2__) # define PLATFORM_ID "OS2" # elif defined(__WINDOWS__) # define PLATFORM_ID "Windows3x" # else /* unknown platform */ # define PLATFORM_ID # endif #else /* unknown platform */ # define PLATFORM_ID #endif /* For windows compilers MSVC and Intel we can determine the architecture of the compiler being used. This is because the compilers do not have flags that can change the architecture, but rather depend on which compiler is being used */ #if defined(_WIN32) && defined(_MSC_VER) # if defined(_M_IA64) # define ARCHITECTURE_ID "IA64" # elif defined(_M_X64) || defined(_M_AMD64) # define ARCHITECTURE_ID "x64" # elif defined(_M_IX86) # define ARCHITECTURE_ID "X86" # elif defined(_M_ARM) # if _M_ARM == 4 # define ARCHITECTURE_ID "ARMV4I" # elif _M_ARM == 5 # define ARCHITECTURE_ID "ARMV5I" # else # define ARCHITECTURE_ID "ARMV" STRINGIFY(_M_ARM) # endif # elif defined(_M_MIPS) # define ARCHITECTURE_ID "MIPS" # elif defined(_M_SH) # define ARCHITECTURE_ID "SHx" # else /* unknown architecture */ # define ARCHITECTURE_ID "" # endif #elif defined(__WATCOMC__) # if defined(_M_I86) # define ARCHITECTURE_ID "I86" # elif defined(_M_IX86) # define ARCHITECTURE_ID "X86" # else /* unknown architecture */ # define ARCHITECTURE_ID "" # endif #else # define ARCHITECTURE_ID #endif /* Convert integer to decimal digit literals. */ #define DEC(n) \ ('0' + (((n) / 10000000)%10)), \ ('0' + (((n) / 1000000)%10)), \ ('0' + (((n) / 100000)%10)), \ ('0' + (((n) / 10000)%10)), \ ('0' + (((n) / 1000)%10)), \ ('0' + (((n) / 100)%10)), \ ('0' + (((n) / 10)%10)), \ ('0' + ((n) % 10)) /* Convert integer to hex digit literals. */ #define HEX(n) \ ('0' + ((n)>>28 & 0xF)), \ ('0' + ((n)>>24 & 0xF)), \ ('0' + ((n)>>20 & 0xF)), \ ('0' + ((n)>>16 & 0xF)), \ ('0' + ((n)>>12 & 0xF)), \ ('0' + ((n)>>8 & 0xF)), \ ('0' + ((n)>>4 & 0xF)), \ ('0' + ((n) & 0xF)) /* Construct a string literal encoding the version number components. */ #ifdef COMPILER_VERSION_MAJOR char const info_version[] = { 'I', 'N', 'F', 'O', ':', 'c','o','m','p','i','l','e','r','_','v','e','r','s','i','o','n','[', COMPILER_VERSION_MAJOR, # ifdef COMPILER_VERSION_MINOR '.', COMPILER_VERSION_MINOR, # ifdef COMPILER_VERSION_PATCH '.', COMPILER_VERSION_PATCH, # ifdef COMPILER_VERSION_TWEAK '.', COMPILER_VERSION_TWEAK, # endif # endif # endif ']','\0'}; #endif /* Construct a string literal encoding the version number components. */ #ifdef SIMULATE_VERSION_MAJOR char const info_simulate_version[] = { 'I', 'N', 'F', 'O', ':', 's','i','m','u','l','a','t','e','_','v','e','r','s','i','o','n','[', SIMULATE_VERSION_MAJOR, # ifdef SIMULATE_VERSION_MINOR '.', SIMULATE_VERSION_MINOR, # ifdef SIMULATE_VERSION_PATCH '.', SIMULATE_VERSION_PATCH, # ifdef SIMULATE_VERSION_TWEAK '.', SIMULATE_VERSION_TWEAK, # endif # endif # endif ']','\0'}; #endif /* Construct the string literal in pieces to prevent the source from getting matched. Store it in a pointer rather than an array because some compilers will just produce instructions to fill the array rather than assigning a pointer to a static array. */ char const* info_platform = "INFO" ":" "platform[" PLATFORM_ID "]"; char const* info_arch = "INFO" ":" "arch[" ARCHITECTURE_ID "]"; " CMAKE_CXX_COMPILER_ID_RUN "1" CMAKE_CXX_COMPILER_ID_TEST_FLAGS "-c" CMAKE_CXX_COMPILER_ID_TOOL_MATCH_INDEX "2" CMAKE_CXX_COMPILER_ID_TOOL_MATCH_REGEX " Ld[^ ]*( [ ]+[^ ]*)* [ ]+([^ ]+)[^ ]*-o[^ ]*CompilerIdCXX/(\./)?(CompilerIdCXX.xctest/)?CompilerIdCXX[ \"]" CMAKE_CXX_COMPILER_ID_VENDORS "IAR" CMAKE_CXX_COMPILER_ID_VENDOR_REGEX_IAR "IAR .+ Compiler" CMAKE_CXX_COMPILER_INIT "NOTFOUND" CMAKE_CXX_COMPILER_LIST "CC;c++;g++;aCC;cl;bcc;xlC;clang++" CMAKE_CXX_COMPILER_LOADED "1" CMAKE_CXX_COMPILER_NAMES "CC" CMAKE_CXX_COMPILER_PRODUCED_FILES "a.out" CMAKE_CXX_COMPILER_PRODUCED_OUTPUT "" CMAKE_CXX_COMPILER_VERSION "6.1.0" CMAKE_CXX_COMPILER_WORKS "TRUE" CMAKE_CXX_COMPILER_WRAPPER "" CMAKE_CXX_COMPILE_FEATURES "cxx_std_98;cxx_template_template_parameters;cxx_std_11;cxx_alias_templates;cxx_alignas;cxx_alignof;cxx_attributes;cxx_auto_type;cxx_constexpr;cxx_decltype;cxx_decltype_incomplete_return_types;cxx_default_function_template_args;cxx_defaulted_functions;cxx_defaulted_move_initializers;cxx_delegating_constructors;cxx_deleted_functions;cxx_enum_forward_declarations;cxx_explicit_conversions;cxx_extended_friend_declarations;cxx_extern_templates;cxx_final;cxx_func_identifier;cxx_generalized_initializers;cxx_inheriting_constructors;cxx_inline_namespaces;cxx_lambdas;cxx_local_type_template_args;cxx_long_long_type;cxx_noexcept;cxx_nonstatic_member_init;cxx_nullptr;cxx_override;cxx_range_for;cxx_raw_string_literals;cxx_reference_qualified_functions;cxx_right_angle_brackets;cxx_rvalue_references;cxx_sizeof_member;cxx_static_assert;cxx_strong_enums;cxx_thread_local;cxx_trailing_return_types;cxx_unicode_literals;cxx_uniform_initialization;cxx_unrestricted_unions;cxx_user_literals;cxx_variadic_macros;cxx_variadic_templates;cxx_std_14;cxx_aggregate_default_initializers;cxx_attribute_deprecated;cxx_binary_literals;cxx_contextual_conversions;cxx_decltype_auto;cxx_digit_separators;cxx_generic_lambdas;cxx_lambda_init_captures;cxx_relaxed_constexpr;cxx_return_type_deduction;cxx_variable_templates;cxx_std_17" CMAKE_CXX_COMPILE_OBJECT " -o -c " CMAKE_CXX_COMPILE_OPTIONS_PIC "-fPIC" CMAKE_CXX_COMPILE_OPTIONS_PIE "-fPIE" CMAKE_CXX_COMPILE_OPTIONS_SYSROOT "--sysroot=" CMAKE_CXX_CREATE_ASSEMBLY_SOURCE " -S -o " CMAKE_CXX_CREATE_PREPROCESSED_SOURCE " -E > " CMAKE_CXX_CREATE_SHARED_LIBRARY " -o " CMAKE_CXX_CREATE_SHARED_MODULE " -o " CMAKE_CXX_FLAGS "" CMAKE_CXX_FLAGS_DEBUG "-g" CMAKE_CXX_FLAGS_DEBUG_INIT "-g" CMAKE_CXX_FLAGS_INIT "" CMAKE_CXX_FLAGS_MINSIZEREL "-Os -DNDEBUG" CMAKE_CXX_FLAGS_MINSIZEREL_INIT "-Os -DNDEBUG" CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CMAKE_CXX_FLAGS_RELEASE_INIT "-O3 -DNDEBUG" CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O2 -g -DNDEBUG" CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT "-O2 -g -DNDEBUG" CMAKE_CXX_IGNORE_EXTENSIONS "inl;h;hpp;HPP;H;o;O;obj;OBJ;def;DEF;rc;RC" CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES "/usr/include" CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/6.1.0;/opt/freeware/lib" CMAKE_CXX_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES "" CMAKE_CXX_IMPLICIT_LINK_LIBRARIES "stdc++;m;/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/6.1.0/libgcc.a;c;/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/6.1.0/libgcc.a" CMAKE_CXX_INFORMATION_LOADED "1" CMAKE_CXX_LIBRARY_ARCHITECTURE "" CMAKE_CXX_LINKER_PREFERENCE "30" CMAKE_CXX_LINKER_PREFERENCE_PROPAGATES "1" CMAKE_CXX_LINK_EXECUTABLE " -o " CMAKE_CXX_LINK_FLAGS "-Wl,-bnoipath" CMAKE_CXX_OUTPUT_EXTENSION ".o" CMAKE_CXX_PLATFORM_ID "AIX" CMAKE_CXX_SIMULATE_ID "" CMAKE_CXX_SIMULATE_VERSION "" CMAKE_CXX_SIZEOF_DATA_PTR "4" CMAKE_CXX_SOURCE_FILE_EXTENSIONS "C;M;c++;cc;cpp;cxx;mm;CPP" CMAKE_CXX_STANDARD_COMPUTED_DEFAULT "14" CMAKE_CXX_STANDARD_DEFAULT "14" CMAKE_CXX_USE_IMPLICIT_LINK_DIRECTORIES_IN_RUNTIME_PATH "1" CMAKE_CXX_VERBOSE_FLAG "-v" CMAKE_C_ABI_COMPILED "TRUE" CMAKE_C_ARCHIVE_APPEND " q " CMAKE_C_ARCHIVE_CREATE " qc " CMAKE_C_ARCHIVE_FINISH " " CMAKE_C_CL_SHOWINCLUDES_PREFIX "" CMAKE_C_COMPILER "/usr/bin/gcc" CMAKE_C_COMPILER "/usr/bin/gcc" CMAKE_C_COMPILER_ABI "" CMAKE_C_COMPILER_ARG1 "" CMAKE_C_COMPILER_ENV_VAR "CC" CMAKE_C_COMPILER_ID "GNU" CMAKE_C_COMPILER_ID_PLATFORM_CONTENT "#define STRINGIFY_HELPER(X) #X #define STRINGIFY(X) STRINGIFY_HELPER(X) /* Identify known platforms by name. */ #if defined(__linux) || defined(__linux__) || defined(linux) # define PLATFORM_ID "Linux" #elif defined(__CYGWIN__) # define PLATFORM_ID "Cygwin" #elif defined(__MINGW32__) # define PLATFORM_ID "MinGW" #elif defined(__APPLE__) # define PLATFORM_ID "Darwin" #elif defined(_WIN32) || defined(__WIN32__) || defined(WIN32) # define PLATFORM_ID "Windows" #elif defined(__FreeBSD__) || defined(__FreeBSD) # define PLATFORM_ID "FreeBSD" #elif defined(__NetBSD__) || defined(__NetBSD) # define PLATFORM_ID "NetBSD" #elif defined(__OpenBSD__) || defined(__OPENBSD) # define PLATFORM_ID "OpenBSD" #elif defined(__sun) || defined(sun) # define PLATFORM_ID "SunOS" #elif defined(_AIX) || defined(__AIX) || defined(__AIX__) || defined(__aix) || defined(__aix__) # define PLATFORM_ID "AIX" #elif defined(__sgi) || defined(__sgi__) || defined(_SGI) # define PLATFORM_ID "IRIX" #elif defined(__hpux) || defined(__hpux__) # define PLATFORM_ID "HP-UX" #elif defined(__HAIKU__) # define PLATFORM_ID "Haiku" #elif defined(__BeOS) || defined(__BEOS__) || defined(_BEOS) # define PLATFORM_ID "BeOS" #elif defined(__QNX__) || defined(__QNXNTO__) # define PLATFORM_ID "QNX" #elif defined(__tru64) || defined(_tru64) || defined(__TRU64__) # define PLATFORM_ID "Tru64" #elif defined(__riscos) || defined(__riscos__) # define PLATFORM_ID "RISCos" #elif defined(__sinix) || defined(__sinix__) || defined(__SINIX__) # define PLATFORM_ID "SINIX" #elif defined(__UNIX_SV__) # define PLATFORM_ID "UNIX_SV" #elif defined(__bsdos__) # define PLATFORM_ID "BSDOS" #elif defined(_MPRAS) || defined(MPRAS) # define PLATFORM_ID "MP-RAS" #elif defined(__osf) || defined(__osf__) # define PLATFORM_ID "OSF1" #elif defined(_SCO_SV) || defined(SCO_SV) || defined(sco_sv) # define PLATFORM_ID "SCO_SV" #elif defined(__ultrix) || defined(__ultrix__) || defined(_ULTRIX) # define PLATFORM_ID "ULTRIX" #elif defined(__XENIX__) || defined(_XENIX) || defined(XENIX) # define PLATFORM_ID "Xenix" #elif defined(__WATCOMC__) # if defined(__LINUX__) # define PLATFORM_ID "Linux" # elif defined(__DOS__) # define PLATFORM_ID "DOS" # elif defined(__OS2__) # define PLATFORM_ID "OS2" # elif defined(__WINDOWS__) # define PLATFORM_ID "Windows3x" # else /* unknown platform */ # define PLATFORM_ID # endif #else /* unknown platform */ # define PLATFORM_ID #endif /* For windows compilers MSVC and Intel we can determine the architecture of the compiler being used. This is because the compilers do not have flags that can change the architecture, but rather depend on which compiler is being used */ #if defined(_WIN32) && defined(_MSC_VER) # if defined(_M_IA64) # define ARCHITECTURE_ID "IA64" # elif defined(_M_X64) || defined(_M_AMD64) # define ARCHITECTURE_ID "x64" # elif defined(_M_IX86) # define ARCHITECTURE_ID "X86" # elif defined(_M_ARM) # if _M_ARM == 4 # define ARCHITECTURE_ID "ARMV4I" # elif _M_ARM == 5 # define ARCHITECTURE_ID "ARMV5I" # else # define ARCHITECTURE_ID "ARMV" STRINGIFY(_M_ARM) # endif # elif defined(_M_MIPS) # define ARCHITECTURE_ID "MIPS" # elif defined(_M_SH) # define ARCHITECTURE_ID "SHx" # else /* unknown architecture */ # define ARCHITECTURE_ID "" # endif #elif defined(__WATCOMC__) # if defined(_M_I86) # define ARCHITECTURE_ID "I86" # elif defined(_M_IX86) # define ARCHITECTURE_ID "X86" # else /* unknown architecture */ # define ARCHITECTURE_ID "" # endif #else # define ARCHITECTURE_ID #endif /* Convert integer to decimal digit literals. */ #define DEC(n) \ ('0' + (((n) / 10000000)%10)), \ ('0' + (((n) / 1000000)%10)), \ ('0' + (((n) / 100000)%10)), \ ('0' + (((n) / 10000)%10)), \ ('0' + (((n) / 1000)%10)), \ ('0' + (((n) / 100)%10)), \ ('0' + (((n) / 10)%10)), \ ('0' + ((n) % 10)) /* Convert integer to hex digit literals. */ #define HEX(n) \ ('0' + ((n)>>28 & 0xF)), \ ('0' + ((n)>>24 & 0xF)), \ ('0' + ((n)>>20 & 0xF)), \ ('0' + ((n)>>16 & 0xF)), \ ('0' + ((n)>>12 & 0xF)), \ ('0' + ((n)>>8 & 0xF)), \ ('0' + ((n)>>4 & 0xF)), \ ('0' + ((n) & 0xF)) /* Construct a string literal encoding the version number components. */ #ifdef COMPILER_VERSION_MAJOR char const info_version[] = { 'I', 'N', 'F', 'O', ':', 'c','o','m','p','i','l','e','r','_','v','e','r','s','i','o','n','[', COMPILER_VERSION_MAJOR, # ifdef COMPILER_VERSION_MINOR '.', COMPILER_VERSION_MINOR, # ifdef COMPILER_VERSION_PATCH '.', COMPILER_VERSION_PATCH, # ifdef COMPILER_VERSION_TWEAK '.', COMPILER_VERSION_TWEAK, # endif # endif # endif ']','\0'}; #endif /* Construct a string literal encoding the version number components. */ #ifdef SIMULATE_VERSION_MAJOR char const info_simulate_version[] = { 'I', 'N', 'F', 'O', ':', 's','i','m','u','l','a','t','e','_','v','e','r','s','i','o','n','[', SIMULATE_VERSION_MAJOR, # ifdef SIMULATE_VERSION_MINOR '.', SIMULATE_VERSION_MINOR, # ifdef SIMULATE_VERSION_PATCH '.', SIMULATE_VERSION_PATCH, # ifdef SIMULATE_VERSION_TWEAK '.', SIMULATE_VERSION_TWEAK, # endif # endif # endif ']','\0'}; #endif /* Construct the string literal in pieces to prevent the source from getting matched. Store it in a pointer rather than an array because some compilers will just produce instructions to fill the array rather than assigning a pointer to a static array. */ char const* info_platform = "INFO" ":" "platform[" PLATFORM_ID "]"; char const* info_arch = "INFO" ":" "arch[" ARCHITECTURE_ID "]"; " CMAKE_C_COMPILER_ID_RUN "1" CMAKE_C_COMPILER_ID_TEST_FLAGS "-c;-Aa;-D__CLASSIC_C__" CMAKE_C_COMPILER_ID_TOOL_MATCH_INDEX "2" CMAKE_C_COMPILER_ID_TOOL_MATCH_REGEX " Ld[^ ]*( [ ]+[^ ]*)* [ ]+([^ ]+)[^ ]*-o[^ ]*CompilerIdC/(\./)?(CompilerIdC.xctest/)?CompilerIdC[ \"]" CMAKE_C_COMPILER_ID_VENDORS "IAR" CMAKE_C_COMPILER_ID_VENDOR_REGEX_IAR "IAR .+ Compiler" CMAKE_C_COMPILER_INIT "NOTFOUND" CMAKE_C_COMPILER_LIST "cc;gcc;cl;bcc;xlc;clang" CMAKE_C_COMPILER_LOADED "1" CMAKE_C_COMPILER_NAMES "cc" CMAKE_C_COMPILER_PRODUCED_FILES "a.out" CMAKE_C_COMPILER_PRODUCED_OUTPUT "" CMAKE_C_COMPILER_VERSION "6.1.0" CMAKE_C_COMPILER_WORKS "TRUE" CMAKE_C_COMPILER_WRAPPER "" CMAKE_C_COMPILE_FEATURES "c_std_90;c_function_prototypes;c_std_99;c_restrict;c_variadic_macros;c_std_11;c_static_assert" CMAKE_C_COMPILE_OBJECT " -o -c " CMAKE_C_COMPILE_OPTIONS_PIC "-fPIC" CMAKE_C_COMPILE_OPTIONS_PIE "-fPIE" CMAKE_C_COMPILE_OPTIONS_SYSROOT "--sysroot=" CMAKE_C_CREATE_ASSEMBLY_SOURCE " -S -o " CMAKE_C_CREATE_PREPROCESSED_SOURCE " -E > " CMAKE_C_CREATE_SHARED_LIBRARY " -o " CMAKE_C_CREATE_SHARED_MODULE " -o " CMAKE_C_FLAGS "" CMAKE_C_FLAGS_DEBUG "-g" CMAKE_C_FLAGS_DEBUG_INIT "-g" CMAKE_C_FLAGS_INIT "" CMAKE_C_FLAGS_MINSIZEREL "-Os -DNDEBUG" CMAKE_C_FLAGS_MINSIZEREL_INIT "-Os -DNDEBUG" CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" CMAKE_C_FLAGS_RELEASE_INIT "-O3 -DNDEBUG" CMAKE_C_FLAGS_RELWITHDEBINFO "-O2 -g -DNDEBUG" CMAKE_C_FLAGS_RELWITHDEBINFO_INIT "-O2 -g -DNDEBUG" CMAKE_C_IGNORE_EXTENSIONS "h;H;o;O;obj;OBJ;def;DEF;rc;RC" CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES "/usr/include" CMAKE_C_IMPLICIT_LINK_DIRECTORIES "/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/6.1.0;/opt/freeware/lib" CMAKE_C_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES "" CMAKE_C_IMPLICIT_LINK_LIBRARIES "/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/6.1.0/libgcc.a;/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/6.1.0/libgcc_eh.a;c;/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/6.1.0/libgcc.a;/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/6.1.0/libgcc_eh.a" CMAKE_C_INFORMATION_LOADED "1" CMAKE_C_LIBRARY_ARCHITECTURE "" CMAKE_C_LINKER_PREFERENCE "10" CMAKE_C_LINK_EXECUTABLE " -o " CMAKE_C_LINK_FLAGS "-Wl,-bnoipath" CMAKE_C_OUTPUT_EXTENSION ".o" CMAKE_C_PLATFORM_ID "AIX" CMAKE_C_SIMULATE_ID "" CMAKE_C_SIMULATE_VERSION "" CMAKE_C_SIZEOF_DATA_PTR "4" CMAKE_C_SOURCE_FILE_EXTENSIONS "c;m" CMAKE_C_STANDARD_COMPUTED_DEFAULT "11" CMAKE_C_STANDARD_DEFAULT "11" CMAKE_C_USE_IMPLICIT_LINK_DIRECTORIES_IN_RUNTIME_PATH "1" CMAKE_C_VERBOSE_FLAG "-v" CMAKE_DEPFILE_FLAGS_C "-MD -MT -MF " CMAKE_DEPFILE_FLAGS_CXX "-MD -MT -MF " CMAKE_DL_LIBS "-lld" CMAKE_EDIT_COMMAND "/home/atkins3/Dashboards/My_Tests/CMake_IBM-13.1.3/CMake-build/bin/ccmake" CMAKE_EXECUTABLE_FORMAT "Unknown" CMAKE_EXECUTABLE_RUNTIME_CXX_FLAG "-Wl,-blibpath:" CMAKE_EXECUTABLE_RUNTIME_CXX_FLAG_SEP ":" CMAKE_EXECUTABLE_RUNTIME_C_FLAG "-Wl,-blibpath:" CMAKE_EXECUTABLE_RUNTIME_C_FLAG_SEP ":" CMAKE_EXECUTABLE_SUFFIX "" CMAKE_EXE_LINKER_FLAGS "-Wl,-brtl" CMAKE_EXE_LINKER_FLAGS_DEBUG "" CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "" CMAKE_EXE_LINKER_FLAGS_INIT "-Wl,-brtl" CMAKE_EXE_LINKER_FLAGS_MINSIZEREL "" CMAKE_EXE_LINKER_FLAGS_MINSIZEREL_INIT "" CMAKE_EXE_LINKER_FLAGS_RELEASE "" CMAKE_EXE_LINKER_FLAGS_RELEASE_INIT "" CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO "" CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO_INIT "" CMAKE_EXPORT_COMPILE_COMMANDS "OFF" CMAKE_EXTRA_GENERATOR "" CMAKE_FILES_DIRECTORY "/CMakeFiles" CMAKE_FIND_LIBRARY_PREFIXES "lib" CMAKE_FIND_LIBRARY_SUFFIXES ".so;.a" CMAKE_GCC_AR "CMAKE_GCC_AR-NOTFOUND" CMAKE_GCC_AR "CMAKE_GCC_AR-NOTFOUND" CMAKE_GCC_RANLIB "CMAKE_GCC_RANLIB-NOTFOUND" CMAKE_GCC_RANLIB "CMAKE_GCC_RANLIB-NOTFOUND" CMAKE_GENERATOR "Unix Makefiles" CMAKE_GENERATOR_PLATFORM "" CMAKE_GENERATOR_TOOLSET "" CMAKE_HOME_DIRECTORY "/home/atkins3/Dashboards/My_Tests/__cmake_systeminformation" CMAKE_HOST_SYSTEM "AIX-2" CMAKE_HOST_SYSTEM_NAME "AIX" CMAKE_HOST_SYSTEM_PROCESSOR "powerpc" CMAKE_HOST_SYSTEM_VERSION "2" CMAKE_HOST_UNIX "1" CMAKE_INCLUDE_FLAG_C "-I" CMAKE_INCLUDE_FLAG_CXX "-I" CMAKE_INCLUDE_FLAG_C_SEP "" CMAKE_INCLUDE_SYSTEM_FLAG_C "-isystem " CMAKE_INCLUDE_SYSTEM_FLAG_CXX "-isystem " CMAKE_INSTALL_DEFAULT_COMPONENT_NAME "Unspecified" CMAKE_INSTALL_PREFIX "/usr/local" CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT "1" CMAKE_LIBRARY_PATH_FLAG "-L" CMAKE_LIBRARY_PATH_TERMINATOR "" CMAKE_LINKER "/usr/bin/ld" CMAKE_LINKER "/usr/bin/ld" CMAKE_LINK_LIBRARY_FLAG "-l" CMAKE_LINK_LIBRARY_SUFFIX "" CMAKE_MAJOR_VERSION "3" CMAKE_MAKE_PROGRAM "/usr/bin/gmake" CMAKE_MATCH_0 "" CMAKE_MATCH_1 "" CMAKE_MATCH_COUNT "0" CMAKE_MINIMUM_REQUIRED_VERSION "3.8.20170327-gc4c307" CMAKE_MINOR_VERSION "8" CMAKE_MODULE_LINKER_FLAGS "-Wl,-brtl" CMAKE_MODULE_LINKER_FLAGS_DEBUG "" CMAKE_MODULE_LINKER_FLAGS_DEBUG_INIT "" CMAKE_MODULE_LINKER_FLAGS_INIT "-Wl,-brtl" CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL "" CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL_INIT "" CMAKE_MODULE_LINKER_FLAGS_RELEASE "" CMAKE_MODULE_LINKER_FLAGS_RELEASE_INIT "" CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO "" CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO_INIT "" CMAKE_NM "/usr/bin/nm" CMAKE_OBJCOPY "CMAKE_OBJCOPY-NOTFOUND" CMAKE_OBJDUMP "CMAKE_OBJDUMP-NOTFOUND" CMAKE_PARENT_LIST_FILE "/home/atkins3/Dashboards/My_Tests/__cmake_systeminformation/CMakeLists.txt" CMAKE_PATCH_VERSION "20170327" CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "/lib;/lib32;/lib64;/usr/lib;/usr/lib32;/usr/lib64" CMAKE_PLATFORM_INFO_DIR "/home/atkins3/Dashboards/My_Tests/__cmake_systeminformation/CMakeFiles/3.8.20170327-gc4c307" CMAKE_PLATFORM_INFO_INITIALIZED "1" CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH "/usr/lib;/lib" CMAKE_PROJECT_NAME "DumpInformation" CMAKE_RANLIB "/usr/bin/ranlib" CMAKE_RANLIB "/usr/bin/ranlib" CMAKE_ROOT "/home/atkins3/Dashboards/My_Tests/CMake_IBM-13.1.3/CMake" CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS "-shared -Wl,-G,-bnoipath" CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS "-shared -Wl,-G,-bnoipath" CMAKE_SHARED_LIBRARY_CXX_FLAGS "-fPIC" CMAKE_SHARED_LIBRARY_C_FLAGS "-fPIC" CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "-Wl,-bexpall" CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "-Wl,-bexpall" CMAKE_SHARED_LIBRARY_PREFIX "lib" CMAKE_SHARED_LIBRARY_RUNTIME_CXX_FLAG "-Wl,-blibpath:" CMAKE_SHARED_LIBRARY_RUNTIME_CXX_FLAG_SEP ":" CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG "-Wl,-blibpath:" CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG_SEP ":" CMAKE_SHARED_LIBRARY_SUFFIX ".so" CMAKE_SHARED_LINKER_FLAGS "-Wl,-brtl" CMAKE_SHARED_LINKER_FLAGS_DEBUG "" CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT "" CMAKE_SHARED_LINKER_FLAGS_INIT "-Wl,-brtl" CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL "" CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL_INIT "" CMAKE_SHARED_LINKER_FLAGS_RELEASE "" CMAKE_SHARED_LINKER_FLAGS_RELEASE_INIT "" CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO "" CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO_INIT "" CMAKE_SHARED_MODULE_CREATE_CXX_FLAGS "-shared -Wl,-G,-bnoipath" CMAKE_SHARED_MODULE_CREATE_C_FLAGS "-shared -Wl,-G,-bnoipath" CMAKE_SHARED_MODULE_CXX_FLAGS "-fPIC" CMAKE_SHARED_MODULE_C_FLAGS "-fPIC" CMAKE_SHARED_MODULE_PREFIX "lib" CMAKE_SHARED_MODULE_SUFFIX ".so" CMAKE_SIZEOF_VOID_P "4" CMAKE_SKIP_INSTALL_RPATH "NO" CMAKE_SKIP_RPATH "NO" CMAKE_SOURCE_DIR "/home/atkins3/Dashboards/My_Tests/__cmake_systeminformation" CMAKE_STATIC_LIBRARY_PREFIX "lib" CMAKE_STATIC_LIBRARY_SUFFIX ".a" CMAKE_STATIC_LINKER_FLAGS "" CMAKE_STATIC_LINKER_FLAGS_DEBUG "" CMAKE_STATIC_LINKER_FLAGS_DEBUG_INIT "" CMAKE_STATIC_LINKER_FLAGS_INIT "" CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL "" CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL_INIT "" CMAKE_STATIC_LINKER_FLAGS_RELEASE "" CMAKE_STATIC_LINKER_FLAGS_RELEASE_INIT "" CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO "" CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO_INIT "" CMAKE_STRIP "/usr/bin/strip" CMAKE_SYSTEM "AIX-2" CMAKE_SYSTEM_INCLUDE_PATH "/usr/include/X11" CMAKE_SYSTEM_INFO_FILE "Platform/AIX" CMAKE_SYSTEM_LIBRARY_PATH "/usr/lib/X11" CMAKE_SYSTEM_LOADED "1" CMAKE_SYSTEM_NAME "AIX" CMAKE_SYSTEM_PREFIX_PATH "/usr/local;/usr;/;/home/atkins3/Dashboards/My_Tests;/usr/local;/usr/X11R6;/usr/pkg;/opt" CMAKE_SYSTEM_PROCESSOR "powerpc" CMAKE_SYSTEM_SPECIFIC_INFORMATION_LOADED "1" CMAKE_SYSTEM_SPECIFIC_INITIALIZE_LOADED "1" CMAKE_SYSTEM_VERSION "2" CMAKE_TWEAK_VERSION "0" CMAKE_UNAME "/usr/bin/uname" CMAKE_VERBOSE_MAKEFILE "FALSE" CMAKE_VERSION "3.8.20170327-gc4c307" CXX_TEST_WAS_RUN "1" C_TEST_WAS_RUN "1" DumpInformation_BINARY_DIR "/home/atkins3/Dashboards/My_Tests/__cmake_systeminformation" DumpInformation_SOURCE_DIR "/home/atkins3/Dashboards/My_Tests/__cmake_systeminformation" MSVC_CXX_ARCHITECTURE_ID "" MSVC_C_ARCHITECTURE_ID "" PRESET_CMAKE_SYSTEM_NAME "FALSE" PROJECT_BINARY_DIR "/home/atkins3/Dashboards/My_Tests/__cmake_systeminformation" PROJECT_NAME "DumpInformation" PROJECT_SOURCE_DIR "/home/atkins3/Dashboards/My_Tests/__cmake_systeminformation" RESULT_FILE "/home/atkins3/Dashboards/My_Tests/aix.txt" RUN_CONFIGURE "ON" UNIX "1" _CMAKE_INSTALL_DIR "/home/atkins3/Dashboards/My_Tests" _CMAKE_TOOLCHAIN_LOCATION "/usr/bin" _INCLUDED_FILE "/home/atkins3/Dashboards/My_Tests/CMake_IBM-13.1.3/CMake/Modules/Platform/AIX-GNU-CXX.cmake" _INCLUDED_SYSTEM_INFO_FILE "/home/atkins3/Dashboards/My_Tests/CMake_IBM-13.1.3/CMake/Modules/Platform/AIX.cmake" _IN_TC "0" __AIX_COMPILER_GNU "1" __COMPILER_GNU "1" __UNIX_PATHS_INCLUDED "1" __gcc_hints "/usr/bin" __version_x_y "6.1" c "" f "" incl "/home/atkins3/Dashboards/My_Tests/__cmake_systeminformation/This does not exists" l "" t "" type "" val "0" ================================================================= === COMMANDS ================================================================= ___cmake_include_compiler_wrapper __aix_compiler_gnu __cmake_find_compiler __cmake_find_compiler_path __cmake_include_compiler_wrapper __compiler_gnu __readfile __record_compiler_features __record_compiler_features_c __record_compiler_features_cxx _cmake_determine_compile_features _cmake_determine_compiler_abi _cmake_determine_compiler_id _cmake_determine_compiler_id_build _cmake_determine_compiler_id_check _cmake_determine_compiler_id_match_vendor _cmake_determine_compiler_id_vendor _cmake_determine_compiler_id_write _cmake_determine_msvc_showincludes_prefix _cmake_find_compiler _cmake_find_compiler_path _cmake_parse_implicit_link_info _compiler_id_detection _printtestcompilerstatus _readfile _record_compiler_features _record_compiler_features_c _record_compiler_features_cxx add_compile_options add_custom_command add_custom_target add_definitions add_dependencies add_executable add_library add_subdirectory add_test adjust_cmake_system_variables aux_source_directory break build_command build_name cmake_determine_compile_features cmake_determine_compiler_abi cmake_determine_compiler_id cmake_determine_compiler_id_build cmake_determine_compiler_id_check cmake_determine_compiler_id_match_vendor cmake_determine_compiler_id_vendor cmake_determine_compiler_id_write cmake_determine_msvc_showincludes_prefix cmake_host_system_information cmake_minimum_required cmake_parse_arguments cmake_parse_implicit_link_info cmake_policy cmake_record_c_compile_features cmake_record_cxx_compile_features compiler_id_detection configure_file continue create_test_sourcelist define_property else elseif enable_language enable_testing endforeach endfunction endif endmacro endwhile exec_program execute_process export export_library_dependencies file find_file find_library find_package find_path find_program fltk_wrap_ui foreach function get_cmake_property get_directory_property get_filename_component get_property get_source_file_property get_target_property get_test_property getdefaultwindowsprefixbase if include include_directories include_external_msproject include_regular_expression install install_files install_programs install_targets link_directories link_libraries list load_cache load_command macro make_directory mark_as_advanced math message option output_required_files printtestcompilerstatus project qt_wrap_cpp qt_wrap_ui remove remove_definitions return separate_arguments set set_directory_properties set_property set_source_files_properties set_target_properties set_tests_properties site_name source_group string subdir_depends subdirs target_compile_definitions target_compile_features target_compile_options target_include_directories target_link_libraries target_sources try_compile try_run unset use_mangled_mesa utility_source variable_requires variable_watch while write_file ================================================================= === MACROS ================================================================= ADJUST_CMAKE_SYSTEM_VARIABLES _cmake_find_compiler _cmake_find_compiler_path _cmake_find_compiler _cmake_find_compiler_path __cmake_include_compiler_wrapper __compiler_gnu cmake_record_c_compile_features __aix_compiler_gnu _record_compiler_features _record_compiler_features_c _record_compiler_features_cxx __cmake_include_compiler_wrapper cmake_record_cxx_compile_features _record_compiler_features _record_compiler_features_c _record_compiler_features_cxx ================================================================= === OTHER ================================================================= INCLUDE_DIRECTORY: /home/atkins3/Dashboards/My_Tests/__cmake_systeminformation INCLUDE_DIRECTORY: /home/atkins3/Dashboards/My_Tests/__cmake_systeminformation INCLUDE_REGULAR_EXPRESSION: ^.*$ From gjasny at googlemail.com Wed Mar 29 15:59:14 2017 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 29 Mar 2017 21:59:14 +0200 Subject: [cmake-developers] Email addresses of Mantis bug reporters Message-ID: <5e5a0d57-2f6f-74da-df7c-e8efa7b16b6a@googlemail.com> Hello, while walking through old bug reports contacting the reporters by email would be helpful sometimes. Is there a way for me access this information in Mantis? Thanks, Gregor From brad.king at kitware.com Wed Mar 29 16:02:48 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 29 Mar 2017 16:02:48 -0400 Subject: [cmake-developers] Email addresses of Mantis bug reporters In-Reply-To: <5e5a0d57-2f6f-74da-df7c-e8efa7b16b6a@googlemail.com> References: <5e5a0d57-2f6f-74da-df7c-e8efa7b16b6a@googlemail.com> Message-ID: <2a25ebe8-6d52-c901-2931-ba1de228105b@kitware.com> On 03/29/2017 03:59 PM, Gregor Jasny via cmake-developers wrote: > while walking through old bug reports contacting the reporters by email > would be helpful sometimes. Is there a way for me access this > information in Mantis? I don't think that information is publicly accessible in Mantis. Contact me via private email with the user names and I'll see if I can find the emails. Thanks, -Brad From tobias.hunger at gmail.com Thu Mar 30 07:13:14 2017 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Thu, 30 Mar 2017 13:13:14 +0200 Subject: [cmake-developers] Targets with same name in different projects Message-ID: Hello, I found a project recently which looks odd in the Qt Creator project tree. Looking into it I found that this project has several projects defined and two of those define the same target (same SOURCE file, same name, etc.). It seems like both projects somehow include the same CMakeLists.txt file defining that target (have not yet checked for the specifics). So I was wondering: Is this even allowed? The CMake manual says target names must be unique within a project. I had always read that as "unique within one build system", but now I am confused:-) Maybe this is actually about PROJECTs defined in CMakeLists.txt files? If different PROJECTs may have targets with the same name: How do I call cmake to build one of those targets via the command line interface but not the other? Best Regards, Tobias From brad.king at kitware.com Thu Mar 30 07:45:01 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Mar 2017 07:45:01 -0400 Subject: [cmake-developers] Targets with same name in different projects In-Reply-To: References: Message-ID: <876d5d75-ec87-ebfd-a086-ffe954ece518@kitware.com> On 03/30/2017 07:13 AM, Tobias Hunger wrote: > So I was wondering: Is this even allowed? The CMake manual says target > names must be unique within a project. It shouldn't be allowed. See CMP0002 [1]. -Brad [1] https://cmake.org/cmake/help/v3.8/policy/CMP0002.html From robert.maynard at kitware.com Thu Mar 30 11:53:41 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 30 Mar 2017 11:53:41 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.8.0-rc4 now ready for testing! Message-ID: I am proud to announce the fourth CMake 3.8 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.8 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.8/release/3.8.html Some of the more significant changes in CMake 3.8 are: * CMake now supports "CSharp" (C#) as a first-class language. It is currently supported by the Visual Studio Generators for VS 2010 and above. * CMake now supports "CUDA" as a first-class language. It is currently supported by the Makefile Generators and the "Ninja" generator on Linux, macOS, and Windows. Support for the Visual Studio IDE is under development but not included in this release. * The "Compile Features" functionality now offers meta-features that request compiler modes for specific language standard levels (e.g. "cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and "CMAKE_CXX_KNOWN_FEATURES". * The "Compile Features" functionality is now aware of C++ 17. No specific features are yet enumerated besides the "cxx_std_17" meta- feature. * The Visual Studio Generators for VS 2013 and above learned to support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit toolchain on 64-bit hosts. * The Visual Studio Generators learned to treat files passed to "target_link_libraries()" whose names end in ".targets" as MSBuild "targets" files to be imported into generated project files. * The "try_compile()" command source file signature gained new options to specify the language standard to use in the generated test project. * The "try_compile()" command source file signature now honors language standard variables like "CMAKE_CXX_STANDARD". See policy "CMP0067". * A "BUILD_RPATH" target property and corresponding "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH" locations to be added to binaries in the build tree. * The "COMPILE_FLAGS" source file property learned to support "generator expressions". * A new generator expression "$" was added. It resolves to the true-value if the condition is "1" and resolves to the false-value if the condition is "0". * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX and Windows platforms. * The Visual Studio Generators for VS 2010 and above now place per- source file flags after target-wide flags when they are classified as raw flags with no project file setting ("AdditionalOptions"). This behavior is more consistent with the ordering of flags produced by other generators, and allows flags on more-specific properties (per-source) to override those on more general ones (per-target). * The precompiled Windows binary MSI package provided on "cmake.org" now records the installation directory in the Windows Registry under the key "HKLM\Software\Kitware\CMake" with a value named "InstallDir". CMake 3.8 Release Notes *********************** Changes made since CMake 3.7 include the following. New Features ============ Languages --------- C# ~~ * CMake learned to support "CSharp" (C#) as a first-class language that can be enabled via the "project()" and "enable_language()" commands. It is currently supported by the Visual Studio Generators for VS 2010 and above. C# assemblies and programs can be added just like common C++ targets using the "add_library()" and "add_executable()" commands. References between C# targets in the same source tree may be specified by "target_link_libraries()" like for C++. References to system or 3rd-party assemblies may be specified by the target properties "VS_DOTNET_REFERENCE_" and "VS_DOTNET_REFERENCES". * More fine tuning of C# targets may be done using target and source file properties. Specifically the target properties related to Visual Studio ("VS_*") are worth a look (for setting toolset versions, root namespaces, assembly icons, ...). CUDA ~~~~ * CMake learned to support "CUDA" as a first-class language that can be enabled via the "project()" and "enable_language()" commands. * "CUDA" is currently supported by the Makefile Generators and the "Ninja" generator on Linux, macOS, and Windows. Support for the Visual Studio IDE is under development but not included in this release. * The NVIDIA CUDA Toolkit compiler ("nvcc") is supported. C & C++ ~~~~~~~ * The "Compile Features" functionality now offers meta-features that request compiler modes for specific language standard levels (e.g. "cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and "CMAKE_CXX_KNOWN_FEATURES". * The "Compile Features" functionality is now aware of C++ 17. No specific features are yet enumerated besides the "cxx_std_17" meta- feature. * The "Compile Features" functionality is now aware of the availability of C99 in gcc since version 3.4. Platforms --------- * A new minimal platform file for "Fuchsia" was added. Generators ---------- * The "CodeBlocks" extra generator may now be used to generate with "NMake Makefiles JOM". * The Visual Studio Generators for VS 2013 and above learned to support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit toolchain on 64-bit hosts. * The Visual Studio Generators learned to treat files passed to "target_link_libraries()" whose names end in ".targets" as MSBuild "targets" files to be imported into generated project files. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned the option "COMMAND_EXPAND_LISTS" which causes lists in the "COMMAND" argument to be expanded, including lists created by generator expressions. * The "execute_process()" command gained an "ENCODING" option to specify on Windows which encoding is used for output from child process. * The "math(EXPR)" command gained support for unary "+" and "-" operators. * The "source_group()" command gained "TREE" and "PREFIX" options to add groups following source tree directory structure. * The "string(TIMESTAMP)" command learned to treat "%%" as a way to encode plain "%". * The "string(TIMESTAMP)" command will now honor the "SOURCE_DATE_EPOCH" environment variable and use its value instead of the current time. * The "try_compile()" command source file signature gained new options to specify the language standard to use in the generated test project. * The "try_compile()" command source file signature now honors language standard variables like "CMAKE_CXX_STANDARD". See policy "CMP0067". Variables --------- * A "CMAKE_CODELITE_USE_TARGETS" variable was added to tell the "CodeLite" extra generator to change the generated project to have target-centric organization. The "build", "rebuild", and "clean" operations within "CodeLite" then work on a selected target rather than the whole workspace. (Note that the "Ninja" clean operation on a target includes its dependencies, though.) * The "CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS" variable was added to tell the "Sublime Text 2" extra generator to place specified environment variables in the generated ".sublime-project". * The "CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE" variable was added to tell the "Sublime Text 2" extra generator whether to exclude the build tree from the ".sublime-project" when it is inside the source tree. * A "CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD" variable was added to tell Visual Studio Generators for VS 2010 and above to include the "PACKAGE" target in the default build, similar to the existing "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" variable for the "INSTALL" target. Properties ---------- * A "BUILD_RPATH" target property and corresponding "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH" locations to be added to binaries in the build tree. * The "COMPILE_FLAGS" source file property learned to support "generator expressions". * The "FRAMEWORK" target property may now also be applied to static libraries on Apple targets. It will result in a proper Framework but with a static library inside. * Imported Interface Libraries learned new "IMPORTED_LIBNAME" and "IMPORTED_LIBNAME_" target properties to specify a link library name since interface libraries do not build their own library files. * A "_CPPLINT" target property and supporting "CMAKE__CPPLINT" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run the "cpplint" style checker along with the compiler for "C" and "CXX" languages. * A "MANUALLY_ADDED_DEPENDENCIES" target property has been added. It provides a read-only list of dependencies that have been added with the "add_dependencies()" command. * The "MAP_IMPORTED_CONFIG_" target property learned to interpret empty list elements as referring to the configuration-less imported location specified by "IMPORTED_LOCATION". * The "NO_SYSTEM_FROM_IMPORTED" target property is now supported on Imported Interface Libraries. * New source file properties "SKIP_AUTOMOC", "SKIP_AUTOUIC", "SKIP_AUTORCC", and "SKIP_AUTOGEN" were added to allow source files to be excluded from processing by "AUTOMOC", "AUTOUIC", and "AUTORCC" target properties. * A "VS_COPY_TO_OUT_DIR" source file property was added to tell Visual Studio Generators for VS 2010 and above whether or not a file should e copied to the output directory. * A "VS_DEBUGGER_WORKING_DIRECTORY" target property was added to tell Visual Studio Generators for VS 2010 and above what debugger working directory should be set for the target. * A "VS_DOTNET_REFERENCES_COPY_LOCAL" target property was added to specify whether to copy referenced assemblies to the output directory. * A "VS_DOTNET_REFERENCE_" target property was added to tell Visual Studio Generators for VS 2010 and above to add a .NET reference with a given hint path. * A "VS_INCLUDE_IN_VSIX" source file property was added to tell Visual Studio Generators for VS 2010 and above whether to include the file in a Visual Studio extension package. * A "VS_RESOURCE_GENERATOR" source file property was added to give Visual Studio Generators for VS 2010 and above a setting for the resource generator ("C#" only). * A "VS_USER_PROPS" target property was added to tell Visual Studio Generators for VS 2010 and above to use a custom MSBuild user ".props" file. * A "XCODE_EMIT_EFFECTIVE_PLATFORM_NAME" global property was added to tell the "Xcode" generator whether to emit the "EFFECTIVE_PLATFORM_NAME" variable. This is useful when building with multiple SDKs like "macosx" and "iphoneos" in parallel. * New "XCODE_PRODUCT_TYPE" and "XCODE_EXPLICIT_FILE_TYPE" target properties were created to tell the "Xcode" generator to use custom values of the corresponding attributes for a target in the generated Xcode project. Modules ------- * A "CSharpUtilities" module was added to aid parameterization of Visual Studio C# targets. It provides functions to allow automated setting of source file properties to support Windows Forms, WPF/XAML or other technologies as needed. * The "ExternalData" module learned to support multiple content links for one data file using different hashes, e.g. "img.png.sha256" and "img.png.sha1". This allows objects to be fetched from sources indexed by different hash algorithms. * The "ExternalProject" module gained the "GIT_PROGRESS" option to force Git to show progress when cloning repositories. * The "ExternalProject" module gained a "GIT_CONFIG" option to pass " --config" options to Git when cloning repositories. * The "FeatureSummary" module "feature_summary()" command now accepts a new "QUIET_ON_EMPTY" option that suppresses the output when the list of packages that belong to the selected category is empty. * The "FeatureSummary" module "add_feature_info()" command now accepts lists of dependencies for deciding whether a feature is enabled or not. * The package types accepted by the "FeatureSummary" module can now be tweaked by changing the "FeatureSummary_PKG_TYPES", "FeatureSummary_REQUIRED_PKG_TYPES" and "FeatureSummary_DEFAULT_PKG_TYPE" global properties. * The "FindOpenGL" module now provides imported targets "OpenGL::GL" and "OpenGL::GLU" when the libraries are found. * The "UseSWIG" module gained a "swig_add_library" command to give more flexibility over the old "swig_add_module" command. * The "UseSWIG" module "swig_add_source_to_module" command learned a new "SWIG_OUTFILE_DIR" option to control the output file location ("swig -o"). * The "WriteCompilerDetectionHeader" module gained the "ALLOW_UNKNOWN_COMPILERS" and "ALLOW_UNKNOWN_COMPILER_VERSIONS" options that allow creation of headers that will work also with unknown or old compilers by simply assuming they do not support any of the requested features. CTest ----- * The "ctest_memcheck()" command gained a "DEFECT_COUNT " option to capture the number of memory defects detected. * The "ctest_memcheck()" command learned to read the location of suppressions files for sanitizers from the "CTEST_MEMORYCHECK_SUPPRESSIONS_FILE" variable. * The "ctest_memcheck()" command learned to support "LeakSanitizer" independently from "AddressSanitizer". * The "ctest_update()" command "CDASH_UPLOAD" signature was taught to honor the "RETRY_COUNT", "RETRY_DELAY", and "QUIET" options. CPack ----- * The "CPackIFWConfigureFile" module was added to define a new "cpack_ifw_configure_file()" command to configure file templates prepared in QtIFW/SDK/Creator style. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "DEFAULT", "VIRTUAL", "FORCED_INSTALLATION", "REQUIRES_ADMIN_RIGHTS", "DISPLAY_NAME", "UPDATE_TEXT", "DESCRIPTION", "RELEASE_DATE", "AUTO_DEPEND_ON" and "TRANSLATIONS" options to more specific configuration. * The "CPackIFW" module "cpack_ifw_configure_component()" command gained a new "DEPENDENCIES" alias for "DEPENDS" option. * The "CPackIFW" module "cpack_ifw_configure_component_group()" command gained a new "DEPENDS" option. The "DEPENDENCIES" alias also added. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands "PRIORITY" option now is deprecated and will be removed in a future version of CMake. Please use new "SORTING_PRIORITY" option instead. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_WATERMARK", "CPACK_IFW_PACKAGE_BANNER", "CPACK_IFW_PACKAGE_BACKGROUND", "CPACK_IFW_PACKAGE_WIZARD_STYLE", "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH", "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT", and "CPACK_IFW_PACKAGE_TITLE_COLOR" variables to customize a QtIFW installer look. * The "CPackProductBuild" module gained options to sign packages. See the variables "CPACK_PRODUCTBUILD_IDENTITY_NAME", "CPACK_PRODUCTBUILD_KEYCHAIN_PATH", "CPACK_PKGBUILD_IDENTITY_NAME", and "CPACK_PKGBUILD_KEYCHAIN_PATH". * The "CPackRPM" module learned to omit tags that are not supported by provided "rpmbuild" tool. If unsupported tags are set they are ignored and a developer warning is printed out. * The "CPackRPM" module learned to generate main component package which forces generation of a rpm for defined component without component suffix in filename and package name. See "CPACK_RPM_MAIN_COMPONENT" variable. * The "CPackRPM" module learned to generate a single "debuginfo" package on demand even if components packaging is used. See "CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE" variable. * The "CPackRPM" module learned to support multiple directives per file when using "CPACK_RPM_USER_FILELIST" variable. Other ----- * CMake functionality using cryptographic hashes now supports SHA-3 algorithms. * A new generator expression "$" was added. It resolves to the true-value if the condition is "1" and resolves to the false-value if the condition is "0". Deprecated and Removed Features =============================== * The "FeatureSummary" module commands "set_package_info()", "set_feature_info()", "print_enabled_features()", and "print_disabled_features()" are now deprecated. * The "UseSWIG" module "swig_add_module" command is now deprecated in favor of "swig_add_library". Other Changes ============= * If a command specified by the "_CLANG_TIDY" target property returns non-zero at build time this is now treated as an error instead of silently ignored. * The "ctest_memcheck()" command no longer automatically adds "leak_check=1" to the options used by "AddressSanitizer". The default behavior of "AddressSanitizer" is to run *LeakSanitizer* to check leaks unless "leak_check=0". * The "ctest_memcheck()" command was fixed to correctly append extra sanitizer options read from the "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable to the environment variables used internally by the sanitizers. * The "FeatureSummary" module "set_package_properties()" command no longer forces the package type to "OPTIONAL" when the type is not explicitly set. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX and Windows platforms. * Calls to the "FindPkgConfig" module "pkg_check_modules()" command following a successful call learned to re-evaluate the cached values for a given prefix after changes to the parameters to the command for that prefix. * When using "AUTOMOC" or "AUTOUIC", generated "moc_*", "*.moc" and "ui_*" are placed in the "/_autogen/include" directory which is automatically added to the target's "INCLUDE_DIRECTORIES". It is therefore not necessary anymore to have "CMAKE_CURRENT_BINARY_DIR" in the target's "INCLUDE_DIRECTORIES". * The "Sublime Text 2" generator no longer runs the native build command (e.g. "ninja" or "make") with verbose build output enabled. * The "try_compile()" command source file signature now honors the "CMAKE_WARN_DEPRECATED" variable value in the generated test project. * The Visual Studio Generators for VS 2010 and above now place per- source file flags after target-wide flags when they are classified as raw flags with no project file setting ("AdditionalOptions"). This behavior is more consistent with the ordering of flags produced by other generators, and allows flags on more-specific properties (per-source) to override those on more general ones (per-target). * The precompiled Windows binary MSI package provided on "cmake.org" now records the installation directory in the Windows Registry under the key "HKLM\Software\Kitware\CMake" with a value named "InstallDir". ---------------------------------------------------------------------------- Changes made since CMake 3.8.0-rc3: Brad King (11): InstallRequiredSystemLibraries: Split VS 2017 search paths Add undocumented CMake language means to find VS 2017 InstallRequiredSystemLibraries: Find VS 2017 redist directory libarchive: backport zip directory recognition fix cmIDEOptions: Add GetDefines method cmVisualStudio10TargetGenerator: De-duplicate preprocessor defs VS: Honor preprocessor definitions in RC flags RC: Add missing CMAKE_RC_FLAGS_ entries to cache MSVC: Restore _DEBUG preprocessor definition in RC debug builds SDCC: Fix identification of current sdcc compiler CMake 3.8.0-rc4 Christian Pfeiffer (1): Ninja: Fix command line limit when sysconf has no ARG_MAX Domen Vrankar (2): CPack/RPM can now generate a single debuginfo package CPack/RPM tests: handle build-id links Gregor Jasny (2): Swift: Default to Swift 3.0 with Xcode 8.3 and later Swift: Simplify mixed test case to make it version agnostic Roger Leigh (1): FindBoost: Update 1.64 dependencies using 1.64 beta1 From brad.king at kitware.com Fri Mar 31 13:49:49 2017 From: brad.king at kitware.com (Brad King) Date: Fri, 31 Mar 2017 13:49:49 -0400 Subject: [cmake-developers] Problems with CTestTestParallel In-Reply-To: <3a91004f-80f4-c7a8-5a49-496a81801e35@kitware.com> References: <2069405.2jKWzDYVeC@devpool21> <3a91004f-80f4-c7a8-5a49-496a81801e35@kitware.com> Message-ID: On 03/10/2017 10:32 AM, Brad King wrote: > On 03/10/2017 06:34 AM, Rolf Eike Beer wrote: >> I've attached the complete build dir of that test, maybe anyone >> has a clue what is going on there > > The `Testing/Temporary/LastSubmit_20170310-1035.log` shows errors > submitting to CDash. However, the `test.cmake` script does not > include a `ctest_submit` call. Any idea what happens there? It turns out another test was accidentally stepping on this one. That's why it always passed locally but failed at night. I can reproduce the failure by running `CTestTestParallel` and `CTestTestChecksum` in parallel. Here is a fix: https://gitlab.kitware.com/cmake/cmake/merge_requests/650 Thanks, -Brad