From robert.maynard at kitware.com Wed Nov 1 15:55:45 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 1 Nov 2017 15:55:45 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.10.0-rc4 is now ready for testing Message-ID: I am proud to announce the fourth CMake 3.10 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.10 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.10/release/3.10.html Some of the more significant changes in CMake 3.10 are: * The flang Fortran compiler is now supported, with compiler id "Flang". * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * "FindMPI" received a major overhaul. It now features language specific components, better Fortran support, and support for statically linked MPI implementations. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module underwent numerous improvements. It has gained support for GLVND and EGL on Linux. It now has import targets that separate the OpenGL library and OpenGL contexts. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". CMake 3.10 Release Notes ************************ Changes made since CMake 3.9 include the following. New Features ============ Platforms --------- * The flang Fortran compiler is now supported, with compiler id "Flang". * A new minimal platform file for "Midipix" was added. * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * Support for the IAR ARM Compiler was improved. Generators ---------- * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools like ccache along with the compiler for the "CUDA" language ("C" and "CXX" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * The "CodeBlocks" extra generator learned to optionally exclude files from outside the project root directory from the generated project. See the "CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES" variable. Commands -------- * The "cmake_host_system_information()" command learned more keys to get information about the processor capabilities and the host OS version. * The "configure_file()" command learned to support indented "# cmakedefine" and "# cmakedefine01". Spaces and/or tabs between the "#" character and the "cmakedefine"/"cmakedefine01" words are now understood and preserved in the output. * The "execute_process()" command gained a "RESULTS_VARIABLE" option to collect a list of results from all children in a pipeline of processes when multiple "COMMAND" arguments are given. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * The "string()" command learned a new "PREPEND" subcommand. * The "string(TIMESTAMP)" command now supports "%A" for full weekday name and "%B" for full month name. Variables --------- * A "CMAKE_DIRECTORY_LABELS" variable was added to specify labels for all tests in a directory. Properties ---------- * A "_CPPCHECK" target property and supporting "CMAKE__CPPCHECK" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "cppcheck" with the compiler for "C" and "CXX" languages. * A "LABELS" directory property was added to specify labels for all targets and tests in a directory. * A "TEST_INCLUDE_FILES" directory property was added to list any number of files to be included when running tests with "ctest(1)". This generalizes the "TEST_INCLUDE_FILE" property. * The "VS_DOTNET_REFERENCEPROP__TAG_" target property was added to support custom XML tags for reference assemblies in C# targets. * Source file properties "VS_SHADER_OUTPUT_HEADER_FILE" and "VS_SHADER_VARIABLE_NAME" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "FindCurses" module gained a "CURSES_NEED_WIDE" option to request the wide-character variant. * The "FindEXPAT" module now provides imported targets. * The "FindFreetype" module now provides imported targets. * "FindMPI" gained a number of new features, including: * Language-specific components have been added to the module. * Many more MPI environments are now supported. * The environmental support for Fortran has been improved. * A user now has fine-grained control over the MPI selection process, including passing custom parameters to the MPI compiler. * The version of the implemented MPI standard is now being exposed. * MPI-2 C++ bindings can now be detected and also suppressed if so desired. * The available Fortran bindings are now being detected and verified. * Various MPI-3 information can be requested, including the library version and Fortran capabilities of the individual bindings. * Statically linked MPI implementations are supported. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module gained support for GLVND on Linux. * The "FindOpenMP" module gained support for language-specific components. * A "FindPatch" module was added to find the "patch" command-line executable. * The "FindProtobuf" module "protobuf_generate_cpp()" command gained a "DESCRIPTORS" option to generate descriptor files. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. Unlike the source parsing approach, dynamic discovery executes the test (in 'list available tests' mode) at build time to discover tests. This is robust against unusual ways of labeling tests, provides much better support for advanced features such as parameterized tests, and does not require re-running CMake to discover added or removed tests within a test executable. * The "InstallRequiredSystemLibraries" module gained support for installing Intel compiler runtimes. Autogen ------- * When using "AUTOMOC" or "AUTOUIC" with a multi configuration generator (e.g. "Xcode"), included "*.moc", "moc_*.cpp" and "ui_*.h" files are generated in "/include_" instead of "/include". * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * When using "AUTOMOC", CMake searches for the strings "Q_OBJECT", "Q_GADGET" or "Q_NAMESPACE" in a source file to determine if it needs to be "moc" processed. The new "CMAKE_AUTOMOC_MACRO_NAMES" variable and "AUTOMOC_MACRO_NAMES" target property may be set to register additional strings (macro names) to search for. * When using "AUTOMOC", the new "CMAKE_AUTOMOC_COMPILER_PREDEFINES" variable and "AUTOMOC_COMPILER_PREDEFINES" target property specify whether to enable or disable the generation of the compiler pre definitions file "moc_predefs.h". CTest ----- * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. CPack ----- * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "CPackDeb" module learned to set package release version in "Version" info property. See the "CPACK_DEBIAN_PACKAGE_RELEASE" variable. * The "CPackDeb" module learned more strict package version checking that complies with Debian rules. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "REPLACES" and "CHECKABLE" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_FILE_EXTENSION" variable to customize target binary format. * The "CPackIFW" module gained new "CPACK_IFW_REPOSITORIES_DIRECTORIES" variable to specify additional repositories dirs that will be used to resolve and repack dependent components. This feature is only available when using QtIFW 3.1 or later. * Modules "CPackRPM" and "CPackDeb" learned to set package epoch version. See "CPACK_RPM_PACKAGE_EPOCH" and "CPACK_DEBIAN_PACKAGE_EPOCH" variables. Other ----- * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The graphviz output now distinguishes among the different dependency types "PUBLIC", "PRIVATE" and "INTERFACE" and represents them in the output graph as solid, dashed and dotted edges. Deprecated and Removed Features =============================== * Support for building CMake itself with C++98 compilers was dropped. CMake is now implemented using C++11. * Support for building CMake on HP-UX has been dropped pending better support for C++11 and a port of libuv. See CMake Issue 17137. Use CMake 3.9 or lower instead for HP-UX support. Other Changes ============= * On FreeBSD the C++ compiler named "c++" is now the preferred default. * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". * The "get_filename_component()" "PROGRAM" mode semantics have been revised to not tolerate unquoted spaces in the path to the program while also accepting arguments. While technically incompatible with the old behavior, it is expected that behavior under typical use cases with properly-quoted command-lines has not changed. ---------------------------------------------------------------------------- Changes made since CMake 3.10.0-rc3: Brad King (7): Clang: Use -TP flag for C++ sources with clang-cl CMP0040: Clarify policy warning to match documentation cmcmd: Rename loop iteration variable for clarity cmcmd: Convert lint handlers to file-static functions cmcmd: Restore support for running multiple lint tools Record C compile features flags for MinGW Clang on Windows CMake 3.10.0-rc4 Christian Pfeiffer (5): Flang: Remove unsupported fbounds-check flag Help: Correct _STANDARD help w.r.t. MSVC GNUInstallDirs: Enable CMP0054 FindMPI: Use physical cores for MPIEXEC_MAX_NUMPROCS Find{OpenMP,OpenACC}: Fix detection with -Werror=return-type Domen Vrankar (1): CPack/RPM: DIST-MONOLITHIC-type subtest fix Henry Schreiner (1): FindOpenCL: Add detection of OpenCL 2.1 and 2.2 Sebastian Holtermann (6): Autogen: Don't add STATIC_LIBRARY cycle targets to the _autogen dependencies Autogen: Tests: Add test for STATIC_LIBRARY cycles Autogen: RCC: Append checksum suffix to wrapped file name Autogen: Make rcc output file suffix static (instead of pseudo-random) Autogen: Don't use AUTOMOC_MOC_OPTIONS in moc-predefs command Autogen: Tests: Set AUTOMOC_MOC_OPTIONS in a simple test From taylorcholberton at gmail.com Wed Nov 1 19:30:44 2017 From: taylorcholberton at gmail.com (Taylor Holberton) Date: Wed, 1 Nov 2017 19:30:44 -0400 Subject: [cmake-developers] NASM Bug Message-ID: I noticed that CMake strips the trailing forward slash from an include directory when assembling an object file with NASM. The trailing slash is required with NASM. See section 2.1.16 from the NASM manual . I've included an example that illustrates the bug. I copied the command text and added the trailing slash and wrote '-f elf64' instead of '-f elf'. The command ran successfully. Then I ran `make` again to resume the CMake build and it failed. I noticed that the Makefile was using NASM to link the executable. I don't believe NASM has this capability. I believe the stripping of the trailing slash and using NASM for linking are bugs. If I'm just doing something wrong then I'd love to know how to fix it. In the meantime, I'll just be using NASM with add_custom_command to get the job done. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nasm-bug.tar.gz Type: application/x-gzip Size: 493 bytes Desc: not available URL: From brad.king at kitware.com Fri Nov 3 07:38:51 2017 From: brad.king at kitware.com (Brad King) Date: Fri, 3 Nov 2017 07:38:51 -0400 Subject: [cmake-developers] NASM Bug In-Reply-To: References: Message-ID: <55cc548d-0037-424b-7db2-2d6f77edfb19@kitware.com> On 11/01/2017 07:30 PM, Taylor Holberton wrote: > I noticed that CMake strips the trailing forward slash from an > include directory when assembling an object file with NASM. > The trailing slash is required with NASM. This will likely require `Modules/CMakeASM_NASMInformation.cmake` to get some new variable setting to tell the Makefile and Ninja generators to add a trailing slash when generating the include directory flags. -Brad From robert.maynard at kitware.com Fri Nov 3 15:01:17 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 3 Nov 2017 15:01:17 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.9.5 available for download Message-ID: We are pleased to announce that CMake 3.9.5 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.9.5 since 3.9.4: Brad King (1): CMake 3.9.5 Sebastian Holtermann (1): Autogen: Don't add AUTOMOC_MOC_OPTIONS to moc-predefs command From steveire at gmail.com Sun Nov 5 13:09:03 2017 From: steveire at gmail.com (Stephen Kelly) Date: Sun, 05 Nov 2017 18:09:03 +0000 Subject: [cmake-developers] Embracing Modern CMake Video and Slides Message-ID: Hi, I know I'm not active here at the moment, but I thought this post might be interesting for some here: https://steveire.wordpress.com/2017/11/05/embracing-modern-cmake/ Thanks, Steve. From llvm.999 at outlook.com Sun Nov 5 15:12:32 2017 From: llvm.999 at outlook.com (llvm 999) Date: Sun, 5 Nov 2017 20:12:32 +0000 Subject: [cmake-developers] CMAKE architecture generator expression Message-ID: Can anyone tell me the most appropriate generator expression to obtain the x32 vs x64 build info regardless of platform (windows or Linux)? I would like to place some static libs into certain output folders based on whether I am building for a x32 or x64 architecture. Any info would be much appreciated! Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Mon Nov 6 03:17:00 2017 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 6 Nov 2017 16:17:00 +0800 Subject: [cmake-developers] CMAKE architecture generator expression In-Reply-To: References: Message-ID: On Mon, Nov 6, 2017 at 4:12 AM, llvm 999 wrote: > > > Can anyone tell me the most appropriate generator expression to obtain the > x32 vs x64 build info regardless of platform (windows or Linux)? > > > > I would like to place some static libs into certain output folders based > on whether I am building for a x32 or x64 architecture. > Assuming you just want to differentiate between 32- and 64-bit builds, something like the following should point you in the right direction: $<$:...> # 32-bit build $<$:...> # 64-bit build -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Nov 6 11:01:44 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 6 Nov 2017 11:01:44 -0500 Subject: [cmake-developers] PLplot contract test In-Reply-To: <94308752-9c9e-fa9a-ad28-8d79ce1647ea@kitware.com> References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> <89836f65-79ec-7457-db25-114e3b383b71@kitware.com> <94308752-9c9e-fa9a-ad28-8d79ce1647ea@kitware.com> Message-ID: On 10/30/2017 11:38 AM, Brad King wrote: > FYI I'm refactoring the way the existing contract tests work to make > it easier to add and maintain one for PLplot. Once that is done I'll > look at actually adding PLplot and report back here. I've opened a MR to add the PLplot contract test here: * https://gitlab.kitware.com/cmake/cmake/merge_requests/1452 Please revise your dashboard script to add the following line to the `dashboard_cache` setting: ``` CMake_TEST_CONTRACT_PLplot:BOOL=ON ``` The MR is already staged so this should activate the contract test on the next build after you update the script. Thanks, -Brad From irwin at beluga.phys.uvic.ca Mon Nov 6 17:24:15 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 6 Nov 2017 14:24:15 -0800 (PST) Subject: [cmake-developers] PLplot contract test In-Reply-To: References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> <89836f65-79ec-7457-db25-114e3b383b71@kitware.com> <94308752-9c9e-fa9a-ad28-8d79ce1647ea@kitware.com> Message-ID: On 2017-11-06 11:01-0500 Brad King wrote: > On 10/30/2017 11:38 AM, Brad King wrote: >> FYI I'm refactoring the way the existing contract tests work to make >> it easier to add and maintain one for PLplot. Once that is done I'll >> look at actually adding PLplot and report back here. > > I've opened a MR to add the PLplot contract test here: > > * https://gitlab.kitware.com/cmake/cmake/merge_requests/1452 > > Please revise your dashboard script to add the following line to > the `dashboard_cache` setting: > > ``` > CMake_TEST_CONTRACT_PLplot:BOOL=ON > ``` > > The MR is already staged so this should activate the contract > test on the next build after you update the script. Hi Brad: I followed the above directions in Experimental mode (and also they will be followed later in Nightly mode as well). But I can see nothing related to a PLplot git checkout, configuration or build in the Experimental mode results, see . Is there something I have missed in those results or something wrong? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From brad.king at kitware.com Tue Nov 7 07:14:37 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 7 Nov 2017 07:14:37 -0500 Subject: [cmake-developers] PLplot contract test In-Reply-To: References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> <89836f65-79ec-7457-db25-114e3b383b71@kitware.com> <94308752-9c9e-fa9a-ad28-8d79ce1647ea@kitware.com> Message-ID: <8f1308c6-6393-3146-a143-1241501b6dbf@kitware.com> On 11/06/2017 05:24 PM, Alan W. Irwin wrote: > https://open.cdash.org/viewTest.php?onlypassed&buildid=5131552 > Is there something I have missed in those results or something wrong? Your script now has: ``` set(dashboard_cache " ... # Do build of PLplot as a ctest of CMake. set(CMake_TEST_CONTRACT_PLplot:BOOL=ON) ... ") ``` but it should be: ``` set(dashboard_cache " ... // Do build of PLplot as a test of CMake. CMake_TEST_CONTRACT_PLplot:BOOL=ON ... ") ``` -Brad From irwin at beluga.phys.uvic.ca Tue Nov 7 15:50:22 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 7 Nov 2017 12:50:22 -0800 (PST) Subject: [cmake-developers] PLplot contract test In-Reply-To: <8f1308c6-6393-3146-a143-1241501b6dbf@kitware.com> References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> <89836f65-79ec-7457-db25-114e3b383b71@kitware.com> <94308752-9c9e-fa9a-ad28-8d79ce1647ea@kitware.com> <8f1308c6-6393-3146-a143-1241501b6dbf@kitware.com> Message-ID: On 2017-11-07 07:14-0500 Brad King wrote: > On 11/06/2017 05:24 PM, Alan W. Irwin wrote: >> https://open.cdash.org/viewTest.php?onlypassed&buildid=5131552 >> Is there something I have missed in those results or something wrong? > > Your script now has: > > ``` > set(dashboard_cache " > ... > # Do build of PLplot as a ctest of CMake. > set(CMake_TEST_CONTRACT_PLplot:BOOL=ON) > ... > ") > ``` > > but it should be: > > ``` > set(dashboard_cache " > ... > // Do build of PLplot as a test of CMake. > CMake_TEST_CONTRACT_PLplot:BOOL=ON > ... > ") > ``` Your suggested change above does work, but the default PLplot configuration only enables part of the potential configure, build, and install tests. Therefore, to remove that limitation on this test, I would like to set the following CMake options in the PLplot configure step: -DBUILD_TEST:BOOL=ON -DBUILD_DOC=ON -DBUILD_DOX_DOC=ON (to build additional PLplot examples in the build tree, to build the DocBook documentation, and to build the Doxygen documentation.) I tried set(dashboard_cache " ... CMake_TEST_CONTRACT_PLplot_CMAKE_ARGS:STRING=-DBUILD_TEST=ON -DBUILD_DOC=ON -DBUILD_DOX_DOC=ON ... ) and that partially works: The relevant PLplot CMakeCache.txt file includes the line BUILD_TEST=ON -DBUILD_DOC=ON -DBUILD_DOX_DOC=ON >From the results, the first part of that line is accepted and the rest ignored (rather than erroring out, see aside above). So what syntax do I have to use to set BUILD_TEST=ON BUILD_DOC=ON BUILD_DOX_DOC=ON on separate lines in the PLplot CMakeCache.txt file? Finally, how can I change the default tag currently used ("plplot-5.13.0") for checking out PLplot? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From wesley.hoke at gmail.com Tue Nov 7 17:11:16 2017 From: wesley.hoke at gmail.com (Wesley Smith) Date: Tue, 7 Nov 2017 14:11:16 -0800 Subject: [cmake-developers] Embracing Modern CMake Video and Slides In-Reply-To: References: Message-ID: Thanks for sharing! On Sun, Nov 5, 2017 at 10:09 AM, Stephen Kelly wrote: > Hi, > > I know I'm not active here at the moment, but I thought this post might be > interesting for some here: > > https://steveire.wordpress.com/2017/11/05/embracing-modern-cmake/ > > Thanks, > > Steve. > > > -- > > 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 brad.king at kitware.com Wed Nov 8 06:54:21 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 8 Nov 2017 06:54:21 -0500 Subject: [cmake-developers] PLplot contract test In-Reply-To: References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> <89836f65-79ec-7457-db25-114e3b383b71@kitware.com> <94308752-9c9e-fa9a-ad28-8d79ce1647ea@kitware.com> <8f1308c6-6393-3146-a143-1241501b6dbf@kitware.com> Message-ID: <63684265-356c-c0fc-cb9c-02e0e314c831@kitware.com> On 11/07/2017 03:50 PM, Alan W. Irwin wrote: >> # Do build of PLplot as a ctest of CMake. >> set(CMake_TEST_CONTRACT_PLplot:BOOL=ON) > > Why could I set garbage in the cache > file as above with the result that that garbage was read > and ignored with no error message? Isn't that a CMake bug? The `#` is a comment whiel the `//` is documentation. The format of the cache entries themselves is *very* tolerant. Your line set a variable called "set(CMake_TEST_CONTRACT_PLplot" to the value "ON)". > CMake_TEST_CONTRACT_PLplot_CMAKE_ARGS:STRING=-DBUILD_TEST=ON -DBUILD_DOC=ON -DBUILD_DOX_DOC=ON I've updated the test. Change the name from _ARGS to _FLAGS: ``` CMake_TEST_CONTRACT_PLplot_CMAKE_FLAGS:STRING=-DBUILD_TEST=ON -DBUILD_DOC=ON -DBUILD_DOX_DOC=ON ``` > Finally, how can I change the default tag currently used > ("plplot-5.13.0") for checking out PLplot? I've added an option: ``` CMake_TEST_CONTRACT_PLplot_GIT_TAG:STRING=plplot-5.12.0 ``` The value can be anything that `git checkout` understands (tag, branch, commit sha1, etc.). -Brad From irwin at beluga.phys.uvic.ca Wed Nov 8 15:39:15 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 8 Nov 2017 12:39:15 -0800 (PST) Subject: [cmake-developers] PLplot contract test In-Reply-To: <63684265-356c-c0fc-cb9c-02e0e314c831@kitware.com> References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> <89836f65-79ec-7457-db25-114e3b383b71@kitware.com> <94308752-9c9e-fa9a-ad28-8d79ce1647ea@kitware.com> <8f1308c6-6393-3146-a143-1241501b6dbf@kitware.com> <63684265-356c-c0fc-cb9c-02e0e314c831@kitware.com> Message-ID: On 2017-11-08 06:54-0500 Brad King wrote: [...] > I've updated the test. Change the name from _ARGS to _FLAGS: > > ``` > CMake_TEST_CONTRACT_PLplot_CMAKE_FLAGS:STRING=-DBUILD_TEST=ON -DBUILD_DOC=ON -DBUILD_DOX_DOC=ON > ``` [...] > I've added an option: > > ``` > CMake_TEST_CONTRACT_PLplot_GIT_TAG:STRING=plplot-5.12.0 > ``` > > The value can be anything that `git checkout` understands > (tag, branch, commit sha1, etc.). Hi Brad: Thanks for these changes which all work well (see for details). The Contracts.PLplot test (for the current PLplot master branch HEAD) passed in < 10 minutes (even with all the extra documentation building I have configured) which is acceptable when compared to the total length of this test. As far as I can tell there is only one issue left which is I get the following X11 authentication warnings when running this test in Experimental mode. # Check DISPLAY environment variable software at raven> printenv |grep DISPLAY DISPLAY=localhost:10.0 software at raven> time (nice -19 ctest -S ~/cmake/Dashboards/Scripts/CMakeScripts/my_dashboard.cmake -VV >& ctest.out16) X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. The only thing I can find in ctest.out16 corresponding to these warnings is 264: application-specific initialization failed: couldn't connect to display "localhost:10.0" 264: Error in startup script: couldn't connect to display "localhost:10.0" As a result of that error, the PLplot build system concludes Tk does not work for the given platform and as a result it disables building all Tk-related components of PLplot for this contract test. Which makes this contract test not quite as powerful as it should be. What is going on behind the scenes is the PLplot build system executes the Tk "wish" command to simply confirm version consistency. So it is used in a noninteractive way even though by default wish momentarily displays a blank GUI before wish exits with the required version information. That works fine when I run cmake by hand to configure PLplot since for those cases I never get the above X11 authentication errors. And I can launch any X application I like (such as wish or xterm) without such authentication errors as well. In other words, my X11 authentication environment is just fine. As a result for my interactive desktop environment, running wish with execute_process and configuring PLplot always "just works". But in Nightly mode, a crontab environment obviously does not include a DISPLAY variable so any attempt to configure PLplot in that environment would encounter this same error. So I plan to drop the wish version consistency check that is currently implemented whenever the DISPLAY environment variable is not set, and I am virtually positive that will fix this issue for the Nightly case. However, it appears this planned change will NOT fix the issue for the above Experimental case because I am pretty sure DISPLAY was defined internally when the above ctest command was being executed (because the error message referred to "localhost:10.0" which is the same as the DISPLAY environment variable set before the above ctest command was executed). So if that proves to be the case, I also plan to drop the wish-based version consistency checks when a particular PLplot build-system option is set, and also set that option for the Experimental case. Of course, if that additional fix (beyond the DISPLAY check) is necessary it smacks of a workaround for some X11 authentication issue for the CMake contract testing environment for the Experimental case so I thought I should bring that issue to your attention just in case there is an easy solution you could implement for that issue. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From ben.boeckel at kitware.com Wed Nov 8 16:14:01 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 8 Nov 2017 16:14:01 -0500 Subject: [cmake-developers] PLplot contract test In-Reply-To: References: <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> <89836f65-79ec-7457-db25-114e3b383b71@kitware.com> <94308752-9c9e-fa9a-ad28-8d79ce1647ea@kitware.com> <8f1308c6-6393-3146-a143-1241501b6dbf@kitware.com> <63684265-356c-c0fc-cb9c-02e0e314c831@kitware.com> Message-ID: <20171108211401.GA21622@megas.kitware.com> On Wed, Nov 08, 2017 at 12:39:15 -0800, Alan W. Irwin wrote: > software at raven> time (nice -19 ctest -S ~/cmake/Dashboards/Scripts/CMakeScripts/my_dashboard.cmake -VV >& ctest.out16) > X11 connection rejected because of wrong authentication. > X11 connection rejected because of wrong authentication. > X11 connection rejected because of wrong authentication. > X11 connection rejected because of wrong authentication. > X11 connection rejected because of wrong authentication. > X11 connection rejected because of wrong authentication. > X11 connection rejected because of wrong authentication. > > The only thing I can find in ctest.out16 corresponding to these > warnings is > > 264: application-specific initialization failed: couldn't connect to display "localhost:10.0" > 264: Error in startup script: couldn't connect to display "localhost:10.0" The Xauthority file is not available to the nightly build job. You can share it using the XAUTHORITY environment variable and putting it in a place that both the user running the X server and the job know about and can access. See also the `xhost` tool for managing the file itself. You may need to authorize other users to use the X server, but I've only needed that for a setup here where the host provides a VNC server for a Docker image to use (which also needs cross-host authentication allowances). --Ben From irwin at beluga.phys.uvic.ca Wed Nov 8 21:00:28 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 8 Nov 2017 18:00:28 -0800 (PST) Subject: [cmake-developers] PLplot contract test In-Reply-To: <20171108211401.GA21622@megas.kitware.com> References: <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> <89836f65-79ec-7457-db25-114e3b383b71@kitware.com> <94308752-9c9e-fa9a-ad28-8d79ce1647ea@kitware.com> <8f1308c6-6393-3146-a143-1241501b6dbf@kitware.com> <63684265-356c-c0fc-cb9c-02e0e314c831@kitware.com> <20171108211401.GA21622@megas.kitware.com> Message-ID: On 2017-11-08 16:14-0500 Ben Boeckel wrote: > On Wed, Nov 08, 2017 at 12:39:15 -0800, Alan W. Irwin wrote: >> software at raven> time (nice -19 ctest -S ~/cmake/Dashboards/Scripts/CMakeScripts/my_dashboard.cmake -VV >& ctest.out16) >> X11 connection rejected because of wrong authentication. >> X11 connection rejected because of wrong authentication. >> X11 connection rejected because of wrong authentication. >> X11 connection rejected because of wrong authentication. >> X11 connection rejected because of wrong authentication. >> X11 connection rejected because of wrong authentication. >> X11 connection rejected because of wrong authentication. >> >> The only thing I can find in ctest.out16 corresponding to these >> warnings is >> >> 264: application-specific initialization failed: couldn't connect to display "localhost:10.0" >> 264: Error in startup script: couldn't connect to display "localhost:10.0" > > The Xauthority file is not available to the nightly build job. Hi Ben: Note the above issue is for an Experimental test and not for a Nightly one, i.e., the above errors occurred for a command-line environment where X authentication normally just works (i.e., I can fire up another konsole or xterm, run "xauth list", etc. without issues). The corresponding X authority file is located at /home/software/.Xauthority. Following up on another comment you made concerning the XAUTHORITY environment variable I decided to try setting that environment variable using macro(dashboard_hook_build) .... set(ENV{XAUTHORITY} /home/software/.Xauthority) .... endmacro() within my Scripts/CMakeScripts/my_dashboard.cmake file following how I set other environment variables for this contract test. That change completely solved the above Experimental X authority issues and the Tk-related components of PLplot built for that particular test. So thanks very much for that XAUTHORITY idea! Changing topics back to the Nightly case where the job is started in a crontab environment rather than on the normal desktop command line as above, further research indicates it is possible to set DISPLAY for such environments (assuming that DISPLAY exists at the time the crontab job fires as is typical for my case). So I am going to try that to see if that change plus the above setting of XAUTHORITY solves the Nightly issue as well. @Brad: I still have no idea why setting XAUTHORITY to the file that is used in any case should be needed, and I am therefore pretty sure doing that as above merely works around an issue with contract tests (or deeper) where it is possible not enough care is being used to propagate X authority. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From irwin at beluga.phys.uvic.ca Fri Nov 10 00:40:36 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 9 Nov 2017 21:40:36 -0800 (PST) Subject: [cmake-developers] PLplot contract test In-Reply-To: References: <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> <89836f65-79ec-7457-db25-114e3b383b71@kitware.com> <94308752-9c9e-fa9a-ad28-8d79ce1647ea@kitware.com> <8f1308c6-6393-3146-a143-1241501b6dbf@kitware.com> <63684265-356c-c0fc-cb9c-02e0e314c831@kitware.com> <20171108211401.GA21622@megas.kitware.com> Message-ID: On 2017-11-08 18:00-0800 Alan W. Irwin wrote: [...] > Changing topics back to the Nightly case where the job is started in a > crontab environment rather than on the normal desktop command line as > above, further research indicates it is possible to set DISPLAY for > such environments (assuming that DISPLAY exists at the time the > crontab job fires as is typical for my case). So I am going to try > that to see if that change plus the above setting of XAUTHORITY solves > the Nightly issue as well. Thanks to that crontab change to define the DISPLAY environment variable, all is now well with the Nightly case, see . So that appears to be the end of the configuration issues with the Contracts.PLplot test, and my thanks to Brad for implementing this test in the first place, and both Brad and Ben for some key help with my configuration of this test. So for others here that might be interested, Contracts.PLplot tests a build of the stage/master/nightly/latest branch of CMake by using ExternalProject_Add to git checkout a specified version of PLplot and to configure, build, and install that version with user control of the PLplot version selected for the test and the CMake options used to build PLplot. So this test is good from the PLplot perspective because it makes it more difficult for some new CMake development to cause PLplot developers problems without us knowing it long in advance of CMake releases. And it is also good from the CMake testing perspective since it is a test that exercises a lot of different CMake functionality in a realistic way (i.e., as used in a rather complex build system, warts and all). Additional notes are (1) because of the relatively small size of the PLplot project (despite its build-system complexity) this test adds less than ~30 per cent to the overall cost of building and testing CMake, and (2) this test should work on essentially all platforms (the build of PLplot is known to work on at least Linux, Mac OS X, Cygwin, MinGW-w64/MSYS2, and MSVC). So if anyone else is interested in trying this test on their favorite platform(s), feel free to contact me for help with configuring it and overcoming any PLplot build failures in the unlikely event of you encountering those. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From robert.maynard at kitware.com Fri Nov 10 09:57:34 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 10 Nov 2017 09:57:34 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.9.6 available for download Message-ID: We are pleased to announce that CMake 3.9.6 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.9.6 since 3.9.5: Brad King (1): CMake 3.9.6 Christian Pfeiffer (1): Restore exclusion of "gcc_eh" from implicit link libraries From robert.maynard at kitware.com Fri Nov 10 14:06:15 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 10 Nov 2017 14:06:15 -0500 Subject: [cmake-developers] CMake 3.10.0-rc5 is now ready for testing Message-ID: I am proud to announce the fifth CMake 3.10 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.10 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.10/release/3.10.html Some of the more significant changes in CMake 3.10 are: * The flang Fortran compiler is now supported, with compiler id "Flang". * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * "FindMPI" received a major overhaul. It now features language specific components, better Fortran support, and support for statically linked MPI implementations. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module underwent numerous improvements. It has gained support for GLVND and EGL on Linux. It now has import targets that separate the OpenGL library and OpenGL contexts. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". CMake 3.10 Release Notes ************************ Changes made since CMake 3.9 include the following. New Features ============ Platforms --------- * The flang Fortran compiler is now supported, with compiler id "Flang". * A new minimal platform file for "Midipix" was added. * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * Support for the IAR ARM Compiler was improved. Generators ---------- * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools like ccache along with the compiler for the "CUDA" language ("C" and "CXX" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * The "CodeBlocks" extra generator learned to optionally exclude files from outside the project root directory from the generated project. See the "CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES" variable. Commands -------- * The "cmake_host_system_information()" command learned more keys to get information about the processor capabilities and the host OS version. * The "configure_file()" command learned to support indented "# cmakedefine" and "# cmakedefine01". Spaces and/or tabs between the "#" character and the "cmakedefine"/"cmakedefine01" words are now understood and preserved in the output. * The "execute_process()" command gained a "RESULTS_VARIABLE" option to collect a list of results from all children in a pipeline of processes when multiple "COMMAND" arguments are given. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * The "string()" command learned a new "PREPEND" subcommand. * The "string(TIMESTAMP)" command now supports "%A" for full weekday name and "%B" for full month name. Variables --------- * A "CMAKE_DIRECTORY_LABELS" variable was added to specify labels for all tests in a directory. Properties ---------- * A "_CPPCHECK" target property and supporting "CMAKE__CPPCHECK" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "cppcheck" with the compiler for "C" and "CXX" languages. * A "LABELS" directory property was added to specify labels for all targets and tests in a directory. * A "TEST_INCLUDE_FILES" directory property was added to list any number of files to be included when running tests with "ctest(1)". This generalizes the "TEST_INCLUDE_FILE" property. * The "VS_DOTNET_REFERENCEPROP__TAG_" target property was added to support custom XML tags for reference assemblies in C# targets. * Source file properties "VS_SHADER_OUTPUT_HEADER_FILE" and "VS_SHADER_VARIABLE_NAME" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "FindCurses" module gained a "CURSES_NEED_WIDE" option to request the wide-character variant. * The "FindEXPAT" module now provides imported targets. * The "FindFreetype" module now provides imported targets. * "FindMPI" gained a number of new features, including: * Language-specific components have been added to the module. * Many more MPI environments are now supported. * The environmental support for Fortran has been improved. * A user now has fine-grained control over the MPI selection process, including passing custom parameters to the MPI compiler. * The version of the implemented MPI standard is now being exposed. * MPI-2 C++ bindings can now be detected and also suppressed if so desired. * The available Fortran bindings are now being detected and verified. * Various MPI-3 information can be requested, including the library version and Fortran capabilities of the individual bindings. * Statically linked MPI implementations are supported. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module gained support for GLVND on Linux. * The "FindOpenMP" module gained support for language-specific components. * A "FindPatch" module was added to find the "patch" command-line executable. * The "FindProtobuf" module "protobuf_generate_cpp()" command gained a "DESCRIPTORS" option to generate descriptor files. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. Unlike the source parsing approach, dynamic discovery executes the test (in 'list available tests' mode) at build time to discover tests. This is robust against unusual ways of labeling tests, provides much better support for advanced features such as parameterized tests, and does not require re-running CMake to discover added or removed tests within a test executable. * The "InstallRequiredSystemLibraries" module gained support for installing Intel compiler runtimes. Autogen ------- * When using "AUTOMOC" or "AUTOUIC" with a multi configuration generator (e.g. "Xcode"), included "*.moc", "moc_*.cpp" and "ui_*.h" files are generated in "/include_" instead of "/include". * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * When using "AUTOMOC", CMake searches for the strings "Q_OBJECT", "Q_GADGET" or "Q_NAMESPACE" in a source file to determine if it needs to be "moc" processed. The new "CMAKE_AUTOMOC_MACRO_NAMES" variable and "AUTOMOC_MACRO_NAMES" target property may be set to register additional strings (macro names) to search for. * When using "AUTOMOC", the new "CMAKE_AUTOMOC_COMPILER_PREDEFINES" variable and "AUTOMOC_COMPILER_PREDEFINES" target property specify whether to enable or disable the generation of the compiler pre definitions file "moc_predefs.h". CTest ----- * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. CPack ----- * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "CPackDeb" module learned to set package release version in "Version" info property. See the "CPACK_DEBIAN_PACKAGE_RELEASE" variable. * The "CPackDeb" module learned more strict package version checking that complies with Debian rules. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "REPLACES" and "CHECKABLE" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_FILE_EXTENSION" variable to customize target binary format. * The "CPackIFW" module gained new "CPACK_IFW_REPOSITORIES_DIRECTORIES" variable to specify additional repositories dirs that will be used to resolve and repack dependent components. This feature is only available when using QtIFW 3.1 or later. * Modules "CPackRPM" and "CPackDeb" learned to set package epoch version. See "CPACK_RPM_PACKAGE_EPOCH" and "CPACK_DEBIAN_PACKAGE_EPOCH" variables. Other ----- * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The graphviz output now distinguishes among the different dependency types "PUBLIC", "PRIVATE" and "INTERFACE" and represents them in the output graph as solid, dashed and dotted edges. Deprecated and Removed Features =============================== * Support for building CMake itself with C++98 compilers was dropped. CMake is now implemented using C++11. * Support for building CMake on HP-UX has been dropped pending better support for C++11 and a port of libuv. See CMake Issue 17137. Use CMake 3.9 or lower instead for HP-UX support. Other Changes ============= * On FreeBSD the C++ compiler named "c++" is now the preferred default. * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". * The "get_filename_component()" "PROGRAM" mode semantics have been revised to not tolerate unquoted spaces in the path to the program while also accepting arguments. While technically incompatible with the old behavior, it is expected that behavior under typical use cases with properly-quoted command-lines has not changed. ---------------------------------------------------------------------------- Changes made since CMake 3.10.0-rc4: Andr? Apitzsch (1): FindDoxygen: Fix setting of HAVE_DOT in non-backward-compat mode Axel Huebl (1): FindHDF5: Fix H5_VERSION on Patch in C Brad King (4): FindOpenGL: Clarify logic constructing OPENGL_LIBRARIES FindOpenGL: Default to non-GLVND libraries for legacy GL Windows: Do not report manifest tool update notification as failure CMake 3.10.0-rc5 Christian Pfeiffer (2): IRSL: Add support for the 2018 release on Windows. Restore exclusion of "gcc_eh" from implicit link libraries Yoshinori Tahara (1): CSharp: Fix compiler version detection in non-English languages From g.bogle at auckland.ac.nz Sun Nov 12 17:58:58 2017 From: g.bogle at auckland.ac.nz (Gib Bogle) Date: Sun, 12 Nov 2017 22:58:58 +0000 Subject: [cmake-developers] VS2013 + cmake 3.10.0-rc3 errors Message-ID: <1510527537279.5082@auckland.ac.nz> I am not a developer, I just want to report a problem. Using cmake 3.10.0-rc3 to build with VS 2013, with a very simple CMakeLists.txt: set(PROJECTNAME "am_block") ADD_EXECUTABLE(${PROJECTNAME} am_block.cpp cmgui.cpp network.h) TARGET_LINK_LIBRARIES(${PROJECTNAME} ) and cmake -G "Visual Studio 12 Win64" gives a large number of errors that all concern unrecognised compiler flags, e.g.: cl /c /Zi /W3 /WX- /Od /Ob0 /D WIN32 /D _WINDOWS /D "C_HAS_WARNING-Wno-uninitialized" /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"cmTC_0758f.dir\Debug\\" /Fd"cmTC_0758f.dir\Debug\vc120.pdb" /Gd /TC /errorReport:queue -Wno-uninitialized "C:\Users\Alos Diallo\Desktop\build\CMakeFiles\CMakeTmp\src.c" cl : Command line error D8021: invalid numeric argument '/Wno-uninitialized' [C:\Users\Alos Diallo\Desktop\build\CMakeFiles\CMakeTmp\cmTC_0758f.vcxproj] Other unrecognised flags detected are: Wno-long-double Wcast-align Wdisabled-optimization Wextra ... These look as if they might be GCC flags. I see that the latest candidate is rc5, so maybe this has been fixed (I'm reporting the experience of somebody who contacted me with a problem trying to build my software). Cheers Gib -------------- next part -------------- An HTML attachment was scrubbed... URL: From lectem at gmail.com Tue Nov 14 01:42:44 2017 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Tue, 14 Nov 2017 07:42:44 +0100 Subject: [cmake-developers] Make it easier for beginners In-Reply-To: References: <59eb601a.648c500a.25a84.6b45@mx.google.com> <2194adbe-b31f-f470-7d19-57cb671939f2@kitware.com> Message-ID: Sorry, while I am motivated I had quite a busy month and let this thread quietly slumber, which was not my intent. I was hoping for a concrete answer to my questions but I suppose it requires some sort of merge request (for the documentation/tutorials part), as it would be more effective to get answers and feedback. I just didn't want to have work being rejected just because "we don't put tutorials in the documentation". However I still think what I said for the wiki, if we can't put an automated banner on CMake pages, then I guess I will have to edit those myself. @Bill sending you an email for the account. If anybody has any resources or would like to help me for the tutorials, please tell me. While I think I already have most of the resources and knowledge for most of it, it never hurts. Cheers, - Lectem 2017-10-26 10:46 GMT+02:00 Nicholas Devenish : > On Thu, Oct 26, 2017 at 12:49 AM, Wesley Smith > wrote: > >> I still don't understand the scoped syntax in Daniel Pfeifer's talk (e.g. >> boost::boost) >> > > Easy: It doesn't mean anything special, it's almost entirely just a name > (think of :: as any other character). > > The advantage is, > a) bookkeeping e.g. cleanly namespacing stuff (which admittedly could be > done with _/prefixes) > and more importantly > b) If you give an undefined name e.g. "boost_notalib" (or something > mis-spelled) to target_link_libraries it'll just add "-lboost_notalib" to > the link command - because it doesn't know if it's a custom library that it > doesn't know about, or an undefined target. A name like "Boost::NotALib" > can never be a library name, so if it's not a defined target you'll get an > error at configuration time rather than build time. > > (Caveat: I am not an expert so could be completely wrong in incomplete or > subtle ways, but this is definitely one way it makes a difference) > > Nick > > -- > > 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 csiga.biga at aol.com Tue Nov 14 04:19:59 2017 From: csiga.biga at aol.com (=?utf-8?Q?M=C3=A1t=C3=A9_Ferenc_Nagy-Egri?=) Date: Tue, 14 Nov 2017 10:19:59 +0100 Subject: [cmake-developers] FW: [CMake] custom_command and compile_commands.json In-Reply-To: <87373553f1c147559cffc6434c6d2682@ES08AMSNLNT.srn.sandia.gov> References: <87373553f1c147559cffc6434c6d2682@ES08AMSNLNT.srn.sandia.gov> Message-ID: This thread on the CMake users mailing list has been silent for the past week. I wanted to bring it over to the dev list, because there might be more expertise here on the subject at hand. tl;dr: can custom_commands be exported into compile_commands.json? This is another projection of the problem: how to add new languages to CMake conveniently. If I need to make LaTeX a first-class language to make the export, it?s an awful lot of work only to make IDE extensions LaTeX aware (and I could go on with SYCL, GnuPlot, etc.). Cheers, M?t? Felad?: Moreland, Kenneth Elk?ldve: 2017. november 6., h?tf? 18:28 C?mzett: Nagy-Egri M?t? Ferenc M?solatot kap: cmake at cmake.org T?rgy: RE: [CMake] custom_command and compile_commands.json M?t?, I don?t know anything about the CMAKE_EXPORT_COMPILE_COMMANDS feature, but I can attest that the UseLATEX commands are all created with add_custom_command (with some add_custom_target commands to set up the targets). Someone who knows the CMAKE_EXPORT_COMPILE_COMMANDS feature will have to answer whether it is possible to export custom commands. -Ken From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Nagy-Egri M?t? Ferenc via CMake Sent: Sunday, November 5, 2017 11:07 AM To: Cmake Mailing List Subject: [EXTERNAL] [CMake] custom_command and compile_commands.json Hi! I am trying to export a custom_command to the compile_commands.json database, but no luck up until now. The only similar question I found on the web is a Stackoverflow thread named ?cmake clang-tidy (or other script) as custom target?. I am trying to bring together C/C++ compilation, GnuPlot and LaTeX into a single Cmake script (done), and have the relevant Visual Studio Code extensions hook into the compile_commands.json file to recognize CMakes machinery and that they themselves are not responsible for kicking off the compilation of their respective source files. Microsofts C++ extension is compile_commands.json aware, but the LaTeX-Workshop extensino is not. I wanted to do the research before jumping to feature requests: is it possible to export @kmorel Github users UseLATEX custom_commands into the compile_commands.json database? As far as I saw, setting CMAKE_EXPORT_COMPILE_COMMANDS to ON right before add_latex_document() is not enough. Does LATEX need to be a first-class CMake language in order for this machinery to kick off? Tanks in advance, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From llvm.999 at outlook.com Thu Nov 16 12:56:51 2017 From: llvm.999 at outlook.com (llvm 999) Date: Thu, 16 Nov 2017 17:56:51 +0000 Subject: [cmake-developers] CMAKE Generator for Embacardero RAD Studio IDE Message-ID: I have noticed that the latest version of CMAKE does not support a generator for RAD Studio IDE. I would like to know if there is any plan to add support for it. Or perhaps, there is some technical issue related to this particular IDE that makes it impossible to support such IDE. I'd appreciate someone shedding light into this. If time permits, I would make an effort to add support for this IDE if it is technically doable. Also, is there any good CMAKE documentation for developers who are beginners and wish to take a stab at adding functionalities to CMAKE? Like a developer guide? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Nov 17 09:13:49 2017 From: brad.king at kitware.com (Brad King) Date: Fri, 17 Nov 2017 09:13:49 -0500 Subject: [cmake-developers] CMAKE Generator for Embacardero RAD Studio IDE In-Reply-To: References: Message-ID: On 11/16/2017 12:56 PM, llvm 999 wrote: > I would like to know if there is any plan to add support for it. Not of which I'm aware. > Or perhaps, there is some technical issue related to this particular > IDE that makes it impossible to support such IDE. I'm not familiar with that IDE, but in order to be directly supported by a generator its native build system would need to support everything in CMake's code model (static/shared/exe binaries, custom commands, etc.). An alternative is to create an "extra" generator that produces project files that sit next to Ninja or Makefile generator outputs. The latter is the real build system. The extra project files are for the IDE. We'd also require that someone run nightly testing for the generator on a long-term basis in order to keep it supported. > Also, is there any good CMAKE documentation for developers who are beginners > and wish to take a stab at adding functionalities to CMAKE? There is workflow guidance in `CONTRIBUTING.rst` and `Help/dev/*.rst`. As for the code itself, it is poorly documented for developers. -Brad From llvm.999 at outlook.com Fri Nov 17 22:54:16 2017 From: llvm.999 at outlook.com (llvm 999) Date: Sat, 18 Nov 2017 03:54:16 +0000 Subject: [cmake-developers] CMAKE Generator for Embacardero RAD Studio IDE In-Reply-To: References: , Message-ID: ________________________________ From: cmake-developers on behalf of Brad King Sent: November 17, 2017 6:13 AM To: cmake-developers at cmake.org Subject: Re: [cmake-developers] CMAKE Generator for Embacardero RAD Studio IDE On 11/16/2017 12:56 PM, llvm 999 wrote: > I would like to know if there is any plan to add support for it. Not of which I'm aware. > Or perhaps, there is some technical issue related to this particular > IDE that makes it impossible to support such IDE. I'm not familiar with that IDE, but in order to be directly supported by a generator its native build system would need to support everything in CMake's code model (static/shared/exe binaries, custom commands, etc.). is this requirement published somewhere? I would like to get a better understanding on this ... also, where can I find the detailed description of the internal data structures used by the various components of the cmake program? An alternative is to create an "extra" generator that produces project files that sit next to Ninja or Makefile generator outputs. The latter is the real build system. The extra project files are for the IDE. there is currently support for a Borland generator. I think this is the makefile generator ... if so, then we just need to add the "extra" stuff for the IDE ??? We'd also require that someone run nightly testing for the generator on a long-term basis in order to keep it supported. > Also, is there any good CMAKE documentation for developers who are beginners > and wish to take a stab at adding functionalities to CMAKE? There is workflow guidance in `CONTRIBUTING.rst` and `Help/dev/*.rst`. As for the code itself, it is poorly documented for developers. -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 CMake - Training cmake.org CMake is a cross-platform, open-source build system. CMake is part of a family of tools designed to build, test and package software. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers cmake-developers Info Page - Kitware public.kitware.com To see the collection of prior postings to the list, visit the cmake-developers Archives. Using cmake-developers: To post a message to all the list ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Nov 20 15:02:45 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Nov 2017 15:02:45 -0500 Subject: [cmake-developers] CMAKE Generator for Embacardero RAD Studio IDE In-Reply-To: References: Message-ID: On 11/18/2017 03:08 AM, Tobias Hunger wrote: >> I'm not familiar with that IDE, but in order to be directly supported >> by a generator its native build system would need to support everything >> in CMake's code model (static/shared/exe binaries, custom commands, etc.). > > This is only necessary if that IDE has a built-in build system like Visual > Studio has. If the IDE uses other build systems in the background, then this > seems like overkill to me. Yes. @llvm.999 when one uses that IDE to create a project by hand, and clicks "Build", how is the compiler then invoked? > Extra generators are a horrible hack IMHO and we should strive to get rid > of them and not encourage users to add more. I don't like them either, and they are a horrible way to do integration when the upstream IDE is interested in supporting CMake. The IDE should talk to cmake's server mode. Extra generators were created as a way to support IDEs before IDEs supported CMake (i.e. ecosystem bootstrapping). > I would suggest to write some python script using CMake server-mode to > extract data out of CMake and then generate files in whatever syntax > this IDE requires. That would be a good approach that doesn't require changes to the IDE or to CMake. It essentially implements an extra generator externally. The actual build system would still need to use one of the existing generators, such as "Borland Makefiles". -Brad From robert.maynard at kitware.com Mon Nov 20 16:23:46 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 20 Nov 2017 16:23:46 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.10.0 available for download Message-ID: I am proud to announce that CMake 3.10.0 is now available for download at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.10 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.10/release/3.10.html Some of the more significant changes in CMake 3.10 are: * The flang Fortran compiler is now supported, with compiler id "Flang". * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * "FindMPI" received a major overhaul. It now features language specific components, better Fortran support, and support for statically linked MPI implementations. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module underwent numerous improvements. It has gained support for GLVND and EGL on Linux. It now has import targets that separate the OpenGL library and OpenGL contexts. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". CMake 3.10 Release Notes ************************ Changes made since CMake 3.9 include the following. New Features ============ Platforms --------- * The flang Fortran compiler is now supported, with compiler id "Flang". * A new minimal platform file for "Midipix" was added. * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * Support for the IAR ARM Compiler was improved. Generators ---------- * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools like ccache along with the compiler for the "CUDA" language ("C" and "CXX" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * The "CodeBlocks" extra generator learned to optionally exclude files from outside the project root directory from the generated project. See the "CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES" variable. Commands -------- * The "cmake_host_system_information()" command learned more keys to get information about the processor capabilities and the host OS version. * The "configure_file()" command learned to support indented "# cmakedefine" and "# cmakedefine01". Spaces and/or tabs between the "#" character and the "cmakedefine"/"cmakedefine01" words are now understood and preserved in the output. * The "execute_process()" command gained a "RESULTS_VARIABLE" option to collect a list of results from all children in a pipeline of processes when multiple "COMMAND" arguments are given. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * The "string()" command learned a new "PREPEND" subcommand. * The "string(TIMESTAMP)" command now supports "%A" for full weekday name and "%B" for full month name. Variables --------- * A "CMAKE_DIRECTORY_LABELS" variable was added to specify labels for all tests in a directory. Properties ---------- * A "_CPPCHECK" target property and supporting "CMAKE__CPPCHECK" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "cppcheck" with the compiler for "C" and "CXX" languages. * A "LABELS" directory property was added to specify labels for all targets and tests in a directory. * A "TEST_INCLUDE_FILES" directory property was added to list any number of files to be included when running tests with "ctest(1)". This generalizes the "TEST_INCLUDE_FILE" property. * The "VS_DOTNET_REFERENCEPROP__TAG_" target property was added to support custom XML tags for reference assemblies in C# targets. * Source file properties "VS_SHADER_OUTPUT_HEADER_FILE" and "VS_SHADER_VARIABLE_NAME" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "FindCurses" module gained a "CURSES_NEED_WIDE" option to request the wide-character variant. * The "FindEXPAT" module now provides imported targets. * The "FindFreetype" module now provides imported targets. * "FindMPI" gained a number of new features, including: * Language-specific components have been added to the module. * Many more MPI environments are now supported. * The environmental support for Fortran has been improved. * A user now has fine-grained control over the MPI selection process, including passing custom parameters to the MPI compiler. * The version of the implemented MPI standard is now being exposed. * MPI-2 C++ bindings can now be detected and also suppressed if so desired. * The available Fortran bindings are now being detected and verified. * Various MPI-3 information can be requested, including the library version and Fortran capabilities of the individual bindings. * Statically linked MPI implementations are supported. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module gained support for GLVND on Linux. * The "FindOpenMP" module gained support for language-specific components. * A "FindPatch" module was added to find the "patch" command-line executable. * The "FindProtobuf" module "protobuf_generate_cpp()" command gained a "DESCRIPTORS" option to generate descriptor files. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. Unlike the source parsing approach, dynamic discovery executes the test (in 'list available tests' mode) at build time to discover tests. This is robust against unusual ways of labeling tests, provides much better support for advanced features such as parameterized tests, and does not require re-running CMake to discover added or removed tests within a test executable. * The "InstallRequiredSystemLibraries" module gained support for installing Intel compiler runtimes. Autogen ------- * When using "AUTOMOC" or "AUTOUIC" with a multi configuration generator (e.g. "Xcode"), included "*.moc", "moc_*.cpp" and "ui_*.h" files are generated in "/include_" instead of "/include". * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * When using "AUTOMOC", CMake searches for the strings "Q_OBJECT", "Q_GADGET" or "Q_NAMESPACE" in a source file to determine if it needs to be "moc" processed. The new "CMAKE_AUTOMOC_MACRO_NAMES" variable and "AUTOMOC_MACRO_NAMES" target property may be set to register additional strings (macro names) to search for. * When using "AUTOMOC", the new "CMAKE_AUTOMOC_COMPILER_PREDEFINES" variable and "AUTOMOC_COMPILER_PREDEFINES" target property specify whether to enable or disable the generation of the compiler pre definitions file "moc_predefs.h". CTest ----- * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. CPack ----- * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "CPackDeb" module learned to set package release version in "Version" info property. See the "CPACK_DEBIAN_PACKAGE_RELEASE" variable. * The "CPackDeb" module learned more strict package version checking that complies with Debian rules. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "REPLACES" and "CHECKABLE" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_FILE_EXTENSION" variable to customize target binary format. * The "CPackIFW" module gained new "CPACK_IFW_REPOSITORIES_DIRECTORIES" variable to specify additional repositories dirs that will be used to resolve and repack dependent components. This feature is only available when using QtIFW 3.1 or later. * Modules "CPackRPM" and "CPackDeb" learned to set package epoch version. See "CPACK_RPM_PACKAGE_EPOCH" and "CPACK_DEBIAN_PACKAGE_EPOCH" variables. Other ----- * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The graphviz output now distinguishes among the different dependency types "PUBLIC", "PRIVATE" and "INTERFACE" and represents them in the output graph as solid, dashed and dotted edges. Deprecated and Removed Features =============================== * Support for building CMake itself with C++98 compilers was dropped. CMake is now implemented using C++11. * Support for building CMake on HP-UX has been dropped pending better support for C++11 and a port of libuv. See CMake Issue 17137. Use CMake 3.9 or lower instead for HP-UX support. Other Changes ============= * On FreeBSD the C++ compiler named "c++" is now the preferred default. * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". * The "get_filename_component()" "PROGRAM" mode semantics have been revised to not tolerate unquoted spaces in the path to the program while also accepting arguments. While technically incompatible with the old behavior, it is expected that behavior under typical use cases with properly-quoted command-lines has not changed. ---------------------------------------------------------------------------- Changes made since CMake 3.10.0-rc5: Brad King (5): cmake-gui: Add build option to use Qt5 windows plugin statically Tests: Add options to disable tests requiring Qt FindOpenGL: Re-order component library searches FindOpenGL: Add option to prefer GLVND for legacy GL CMake 3.10.0 vector-of-bool (1): server: Fix regression in partial message handling From csiga.biga at aol.com Tue Nov 21 05:31:53 2017 From: csiga.biga at aol.com (=?utf-8?Q?M=C3=A1t=C3=A9_Ferenc_Nagy-Egri?=) Date: Tue, 21 Nov 2017 11:31:53 +0100 Subject: [cmake-developers] FW: [CMake] custom_command andcompile_commands.json In-Reply-To: <20171114092521.95FC9102C2F@public.kitware.com> References: <87373553f1c147559cffc6434c6d2682@ES08AMSNLNT.srn.sandia.gov> <20171114092521.95FC9102C2F@public.kitware.com> Message-ID: Allow me to bump this message. The question is very simple; can we export custom commands into compile_commands.json? Felad?: M?t? Ferenc Nagy-Egri via cmake-developers Elk?ldve: 2017. november 14., kedd 10:25 C?mzett: CMake Developers T?rgy: [cmake-developers] FW: [CMake] custom_command andcompile_commands.json This thread on the CMake users mailing list has been silent for the past week. I wanted to bring it over to the dev list, because there might be more expertise here on the subject at hand. tl;dr: can custom_commands be exported into compile_commands.json? This is another projection of the problem: how to add new languages to CMake conveniently. If I need to make LaTeX a first-class language to make the export, it?s an awful lot of work only to make IDE extensions LaTeX aware (and I could go on with SYCL, GnuPlot, etc.). Cheers, M?t? Felad?: Moreland, Kenneth Elk?ldve: 2017. november 6., h?tf? 18:28 C?mzett: Nagy-Egri M?t? Ferenc M?solatot kap: cmake at cmake.org T?rgy: RE: [CMake] custom_command and compile_commands.json M?t?, I don?t know anything about the CMAKE_EXPORT_COMPILE_COMMANDS feature, but I can attest that the UseLATEX commands are all created with add_custom_command (with some add_custom_target commands to set up the targets). Someone who knows the CMAKE_EXPORT_COMPILE_COMMANDS feature will have to answer whether it is possible to export custom commands. -Ken From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Nagy-Egri M?t? Ferenc via CMake Sent: Sunday, November 5, 2017 11:07 AM To: Cmake Mailing List Subject: [EXTERNAL] [CMake] custom_command and compile_commands.json Hi! I am trying to export a custom_command to the compile_commands.json database, but no luck up until now. The only similar question I found on the web is a Stackoverflow thread named ?cmake clang-tidy (or other script) as custom target?. I am trying to bring together C/C++ compilation, GnuPlot and LaTeX into a single Cmake script (done), and have the relevant Visual Studio Code extensions hook into the compile_commands.json file to recognize CMakes machinery and that they themselves are not responsible for kicking off the compilation of their respective source files. Microsofts C++ extension is compile_commands.json aware, but the LaTeX-Workshop extensino is not. I wanted to do the research before jumping to feature requests: is it possible to export @kmorel Github users UseLATEX custom_commands into the compile_commands.json database? As far as I saw, setting CMAKE_EXPORT_COMPILE_COMMANDS to ON right before add_latex_document() is not enough. Does LATEX need to be a first-class CMake language in order for this machinery to kick off? Tanks in advance, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Nov 21 09:59:57 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Nov 2017 09:59:57 -0500 Subject: [cmake-developers] custom_command and compile_commands.json In-Reply-To: <20171121103158.08C91102C21@public.kitware.com> References: <87373553f1c147559cffc6434c6d2682@ES08AMSNLNT.srn.sandia.gov> <20171114092521.95FC9102C2F@public.kitware.com> <20171121103158.08C91102C21@public.kitware.com> Message-ID: On 11/21/2017 05:31 AM, M?t? Ferenc Nagy-Egri via cmake-developers wrote: > can we export custom commands into compile_commands.json? The purpose of that file is to make compile commands available to tools like clang-tidy. Custom commands do not belong in it. Its purpose has been largely superseded by first-class support for running such tools along with the compiler, e.g. https://cmake.org/cmake/help/v3.10/prop_tgt/LANG_CLANG_TIDY.html It is also not produced by all generators. > have the relevant Visual Studio Code extensions hook into > ... LaTeX-Workshop extensino is not. Please explain this use case. -Brad From oliver.zabel at egoproducts.com Wed Nov 22 04:37:00 2017 From: oliver.zabel at egoproducts.com (oliver.zabel at egoproducts.com) Date: Wed, 22 Nov 2017 10:37:00 +0100 Subject: [cmake-developers] Non supported toolchain Message-ID: Hi, i know this is the dev mailing list, but i tried to solve my problem in the normal one (see here https://www.mail-archive.com/cmake at cmake.org/msg57862.html) with no success. In Short: i have a toolchain for an microcontroller (renesas rx serjes) running on windows. I want to build my project with cmake and therefor wrote a toolchain file. The problem now is, that the compiler needs instead of "-I" for includes "-include=" and for defines "-define=". I found out that there seems to be internal variables CMAKE_INCLUDE_FLAG_C and CMAKE_DEFINE_FLAC_C but they don't seem to accesible from the toolchain file. Is there any chance beside writing a new module for a compiler to get this toolchain running? Thanks a lot and sorry for asking on the dev list! Best regards, Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Wed Nov 22 06:37:46 2017 From: csiga.biga at aol.com (=?utf-8?Q?M=C3=A1t=C3=A9_Ferenc_Nagy-Egri?=) Date: Wed, 22 Nov 2017 12:37:46 +0100 Subject: [cmake-developers] custom_command and compile_commands.json In-Reply-To: References: <87373553f1c147559cffc6434c6d2682@ES08AMSNLNT.srn.sandia.gov> <20171114092521.95FC9102C2F@public.kitware.com> <20171121103158.08C91102C21@public.kitware.com> Message-ID: Well, my impression was that it is generally for external tools to be aware of the build process, or the commands CMake executes. compile_commands.json is how Microsofts C++ extension to Visual Studio Code fetches compiler definitions and include directories. See last paragraph of: https://github.com/Microsoft/vscode-cpptools/blob/master/Documentation/Getting%20started.md The most feature complete LaTeX extension for VS Code is James Yus LaTeX Workshop https://marketplace.visualstudio.com/items?itemName=James-Yu.latex-workshop If I have a multi-language project (where CMake shines) that is end-to-end automated, such as the example found here: https://github.com/Wigner-GPU-Lab/Teaching/tree/master/KutInf (don?t heed git commit messages, Latex does work) which does: 1. Compiles a library 2. Compiles an executable that links to it 3. Runs the exe to get data 4. Invokes GnuPlot to create a diagram 5. Invokes LaTeX to create a doc with the diagram in it The nice thing about it is, that if someone decides they need to alter the library, or just the exe, or just rename the plot axis? dependencies are tracked by CMake and building the doc target gets the job done with minimal effort. The C++ part of this works fine in VS Code, but I would like to make the LaTeX Workshop extension also aware of an external build system, much as how cpptools can be made aware of external magic. In the end, I would like to be able to all the featues of LaTeX Workshop (linting, two-way navigation between resulting PDF & source .tex files (aka. SyncTeX), being able to display the result PDFs?) without having to do much more, other than authoring a decent CMakeLists.txt file and telling the extension where compile_commands.json is, much like as is the case with cpptools. It is nice to have prime time support for Clang-tidy inside CMake, but hiding everything in the internals of CMake doesn?t help much with the tooling. Hope my use case was made clear enough. Cheers, M?t? Felad?: Brad King Elk?ldve: 2017. november 21., kedd 16:00 C?mzett: cmake-developers at cmake.org T?rgy: Re: [cmake-developers] custom_command and compile_commands.json On 11/21/2017 05:31 AM, M?t? Ferenc Nagy-Egri via cmake-developers wrote: > can we export custom commands into compile_commands.json? The purpose of that file is to make compile commands available to tools like clang-tidy. Custom commands do not belong in it. Its purpose has been largely superseded by first-class support for running such tools along with the compiler, e.g. https://cmake.org/cmake/help/v3.10/prop_tgt/LANG_CLANG_TIDY.html It is also not produced by all generators. > have the relevant Visual Studio Code extensions hook into > ... LaTeX-Workshop extensino is not. Please explain this 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Wed Nov 22 15:27:12 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 22 Nov 2017 21:27:12 +0100 Subject: [cmake-developers] Compiler changes on voyager.sf-tec.de Message-ID: <25622004.IhpD21hfPA@daneel.sf-tec.de> I will remove gcc 4.8 on voyager now. There will be a gcc 6.4 eventually as replacement. Greetings, Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From neundorf at kde.org Wed Nov 22 15:42:49 2017 From: neundorf at kde.org (Alexander Neundorf) Date: Wed, 22 Nov 2017 21:42:49 +0100 Subject: [cmake-developers] Non supported toolchain In-Reply-To: References: Message-ID: <4276419.EAGx9DGFRJ@linux-l7nd> On 2017 M11 22, Wed 10:37:00 CET oliver.zabel at egoproducts.com wrote: > Hi, > > i know this is the dev mailing list, but i tried to solve my problem in > the normal one (see here > https://www.mail-archive.com/cmake at cmake.org/msg57862.html) with no > success. > > In Short: i have a toolchain for an microcontroller (renesas rx serjes) > running on windows. I want to build my project with cmake and therefor > wrote a toolchain file. > The problem now is, that the compiler needs instead of "-I" for includes > "-include=" and for defines "-define=". I found out that there seems to be > internal variables CMAKE_INCLUDE_FLAG_C and CMAKE_DEFINE_FLAC_C but they > don't seem to accesible from the toolchain file. > > Is there any chance beside writing a new module for a compiler to get this > toolchain running? no, you probably need to write a module file for the compiler. This is actually not that complicated. Alex From oliver.zabel at egoproducts.com Thu Nov 23 01:22:19 2017 From: oliver.zabel at egoproducts.com (oliver.zabel at egoproducts.com) Date: Thu, 23 Nov 2017 07:22:19 +0100 Subject: [cmake-developers] Antwort: Re: Non supported toolchain In-Reply-To: <4276419.EAGx9DGFRJ@linux-l7nd> References: <4276419.EAGx9DGFRJ@linux-l7nd> Message-ID: Hi Alex, thanks for your answer. 1. is there some guide or at least some example? 2. Does this module needs to be in the offical build to be distributed or is there a possibility to distribute the modules locally? Thanks! Oli Von: Alexander Neundorf An: cmake-developers at cmake.org Datum: 22.11.2017 21:52 Betreff: Re: [cmake-developers] Non supported toolchain Gesendet von: "cmake-developers" On 2017 M11 22, Wed 10:37:00 CET oliver.zabel at egoproducts.com wrote: > Hi, > > i know this is the dev mailing list, but i tried to solve my problem in > the normal one (see here > https://www.mail-archive.com/cmake at cmake.org/msg57862.html) with no > success. > > In Short: i have a toolchain for an microcontroller (renesas rx serjes) > running on windows. I want to build my project with cmake and therefor > wrote a toolchain file. > The problem now is, that the compiler needs instead of "-I" for includes > "-include=" and for defines "-define=". I found out that there seems to be > internal variables CMAKE_INCLUDE_FLAG_C and CMAKE_DEFINE_FLAC_C but they > don't seem to accesible from the toolchain file. > > Is there any chance beside writing a new module for a compiler to get this > toolchain running? no, you probably need to write a module file for the compiler. This is actually not that complicated. Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From neundorf at kde.org Thu Nov 23 16:43:26 2017 From: neundorf at kde.org (Alexander Neundorf) Date: Thu, 23 Nov 2017 22:43:26 +0100 Subject: [cmake-developers] Antwort: Re: Non supported toolchain In-Reply-To: References: <4276419.EAGx9DGFRJ@linux-l7nd> Message-ID: <4805303.E6MqKNIYHk@linux-l7nd> On 2017 M11 23, Thu 07:22:19 CET oliver.zabel at egoproducts.com wrote: > Hi Alex, > > thanks for your answer. > 1. is there some guide or at least some example? > 2. Does this module needs to be in the offical build to be distributed or > is there a possibility to distribute the modules locally? you could have a look e.g. at Modules/Compiler/TI*.cmake, or the IAR files. You can try whether you can have your custom files in some directory and adjust CMAKE_MODULE_PATH accordingly. I'm not sure, but it might work. Alex From brad.king at kitware.com Mon Nov 27 08:19:20 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Nov 2017 08:19:20 -0500 Subject: [cmake-developers] custom_command and compile_commands.json In-Reply-To: <5a15618b.c526ed0a.f73ed.7b87SMTPIN_ADDED_MISSING@mx.google.com> References: <87373553f1c147559cffc6434c6d2682@ES08AMSNLNT.srn.sandia.gov> <20171114092521.95FC9102C2F@public.kitware.com> <20171121103158.08C91102C21@public.kitware.com> <5a15618b.c526ed0a.f73ed.7b87SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <0b400d70-c6a8-98fe-9a1d-c8864b8decbe@kitware.com> On 11/22/2017 06:37 AM, M?t? Ferenc Nagy-Egri wrote: > Well, my impression was that it is generally for external tools to be > aware of the build process, or the commands CMake executes. `compile_commands.json` was a hack to support clang-tidy and similar tools and was never meant to be a general way to get information. It has largely been superseded by dedicated support for specific tools plus the server mode query information in a more structured way. > compile_commands.json is how Microsofts C++ extension to Visual Studio Code > fetches compiler definitions and include directories. That should be ported to ask the server mode instead. > I would like to make the LaTeX Workshop extension also aware of an external > build system, much as how cpptools can be made aware of external magic. I don't think we should add custom commands to `compile_commands.json`, but instead find some other way to export the needed information. Maybe LaTeX should be a first-class language. Or, the same modules that create the custom commands could also themselves export the information to some tooling helper file. -Brad