From robert.maynard at kitware.com Fri Nov 2 13:57:03 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 2 Nov 2018 13:57:03 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.12.4 available for download Message-ID: We are pleased to announce that CMake 3.12.4 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.12.4 since 3.12.3: Brad King (4): cmake: Distinguish '-E tar' warnings from errors copying data set_directory_properties: Restore in script mode CSharp: Fix regression in VS project type selection for custom target CMake 3.12.4 Chuck Atkins (1): FindMatlab: Guard against nonexistent installation Marc Chevrier (1): UseSWIG: fix regression for PHP language Robert Maynard (2): CUDA: Filter out host link flags during device linking CUDA: Filter out non-static libraries during device linking Vladimir Penev (1): server: Fix assertion failure on directory paths in file monitor From tobias.hunger at gmail.com Tue Nov 6 05:57:26 2018 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Tue, 6 Nov 2018 11:57:26 +0100 Subject: [cmake-developers] CMake, Ninja and Clang on windows? Message-ID: Hi CMake Developers, we are currently trying to support Clang (without the -cl;-) on Windows. This fails since CMake adds extra compiler flags to the command line which are not in the expected format. Stackoverflow[1] suggests to set CMAKE_SYSTEM_NAME to "Generic" to stop that from happening. The blog post[2] referenced by StackOverflow suggests setting CMAKE_C_FLAGS and CMAKE_CXX_FLAGS to TRUE. Both approaches seem like big hammers to me. Are there better ways to get this going that will have less potential side effects? Best Regards, Tobias [1]: https://stackoverflow.com/questions/46553436/building-with-cmake-ninja-and-clang-on-windows#46593308 [2]: https://metricpanda.com/rival-fortress-update-27-compiling-with-clang-on-windows From jeanmichael.celerier at gmail.com Tue Nov 6 07:47:10 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Tue, 6 Nov 2018 13:47:10 +0100 Subject: [cmake-developers] CMake, Ninja and Clang on windows? In-Reply-To: References: Message-ID: Hi, to do this I currently use the following cross-compiling toolchain : https://github.com/mstorsjo/llvm-mingw I was able to build Qt (except webstuff since I don't use them) and a large CMake-based project with it for instance. Maybe it can be useful ? Best, ------- Jean-Micha?l Celerier http://www.jcelerier.name On Tue, Nov 6, 2018 at 11:57 AM Tobias Hunger wrote: > Hi CMake Developers, > > we are currently trying to support Clang (without the -cl;-) on > Windows. This fails since CMake adds extra compiler flags to the > command line which are not in the expected format. > > Stackoverflow[1] suggests to set CMAKE_SYSTEM_NAME to "Generic" to > stop that from happening. > > The blog post[2] referenced by StackOverflow suggests setting > CMAKE_C_FLAGS and CMAKE_CXX_FLAGS to TRUE. > > Both approaches seem like big hammers to me. Are there better ways to > get this going that will have less potential side effects? > > Best Regards, > Tobias > > [1]: > https://stackoverflow.com/questions/46553436/building-with-cmake-ninja-and-clang-on-windows#46593308 > [2]: > https://metricpanda.com/rival-fortress-update-27-compiling-with-clang-on-windows > -- > > 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: > https://cmake.org/mailman/listinfo/cmake-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Nov 6 09:03:37 2018 From: brad.king at kitware.com (Brad King) Date: Tue, 6 Nov 2018 09:03:37 -0500 Subject: [cmake-developers] CMake, Ninja and Clang on windows? In-Reply-To: References: Message-ID: <2d345452-25b7-bc1d-2803-bbcf22e0556e@kitware.com> On 11/06/2018 05:57 AM, Tobias Hunger wrote: > we are currently trying to support Clang (without the -cl;-) on > Windows. This fails since CMake adds extra compiler flags to the > command line which are not in the expected format. Clang with a GNU-like command targeting the MSVC ABI is not supported. See this issue: https://gitlab.kitware.com/cmake/cmake/issues/16439 The MSVC-like command-line (with -cl) works fine. -Brad From robert.maynard at kitware.com Wed Nov 7 12:21:32 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 7 Nov 2018 12:21:32 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.13.0-rc3 is ready for testing Message-ID: I am proud to announce the third CMake 3.13 release candidate. https://cmake.org/download/ The first 3.13.0 release candidates included a change to allow generator expressions in "install(CODE)" and "install(SCRIPT)". This has been reverted in rc2 due to breaking backwards compatibility. See issue #18435. Documentation is available at: https://cmake.org/cmake/help/v3.13 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.13/release/3.13.html Some of the more significant changes in CMake 3.13 are: * The Visual Studio Generators for VS 2010 and above learned to support the "INTERPROCEDURAL_OPTIMIZATION" target property and supporting "CheckIPOSupported" module. * The "Green Hills MULTI" generator has been updated to include support for platform, architecture, and toolset selection. * The "cmake" command gained the "-S " command line option to specify the location of the source directory. This option can be used independently of "-B". * The "cmake" command gained the "-B " command line option to specify the location of the build directory. This option can be used independently of "-S". * The "cmake" "-E create_symlink" command can now be used on Windows. * The "target_link_directories()" command was created to specify link directories for targets and their dependents. * The "target_link_options()" command was created to specify link options for targets and their dependents. * The "target_link_libraries()" command may now be called to modify targets created outside the current directory. See policy "CMP0079". * The "install(TARGETS)" command learned to install targets created outside the current directory. * A "VS_DEBUGGER_COMMAND_ARGUMENTS" target property was created to set the debugging command line arguments with Visual Studio Generators for VS 2010 and above. * A "VS_DEBUGGER_ENVIRONMENT" target property was created to set the debugging environment with Visual Studio Generators for VS 2010 and above. * The "option()" command now honors an existing normal variable of the same name and does nothing instead of possibly creating a cache entry (or setting its type) and removing the normal variable. See policy "CMP0077". * The "target_sources()" command now interprets relative source file paths as relative to the current source directory. This simplifies incrementally building up a target's sources from subdirectories. The "CMP0076" policy was added to provide backward compatibility with the old behavior where required. CMake 3.13 Release Notes ************************ Changes made since CMake 3.12 include the following. New Features ============ Generators ---------- * The Visual Studio Generators for VS 2010 and above learned to support the "INTERPROCEDURAL_OPTIMIZATION" target property and supporting "CheckIPOSupported" module. * The "Xcode" generator learned to configure more Xcode Scheme fields. See the "CMAKE_XCODE_GENERATE_SCHEME" variable. * The "Green Hills MULTI" generator has been updated: * Added support for architecture selection through "CMAKE_GENERATOR_PLATFORM": e.g. "arm", "ppc", and "86". * Added support for toolset selection through "CMAKE_GENERATOR_TOOLSET", e.g. "comp_201205", "comp_201510", "comp_201722_beta". * Added support for platform selection through "GHS_TARGET_PLATFORM", e.g. "integrity", "linux", "standalone", etc. * No longer checks that "arm" based compilers are installed but ensures that the correct "gbuild.exe" exists. * No longer hard-codes ARM files, BSP, toolset, or OS locations. Command-Line ------------ * The "cmake(1)" command gained the "-S " command line option to specify the location of the source directory. This option can be used independently of "-B". * The "cmake(1)" command gained the "-B " command line option to specify the location of the build directory. This option can be used independently of "-S". * The "cmake(1)" "-E create_symlink" command can now be used on Windows. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned to support generator expressions in "WORKING_DIRECTORY" options. * The "add_link_options()" command was created to add link options in the current directory. * The "install(TARGETS)" command learned to install targets created outside the current directory. * The "link_directories()" command gained options to control insertion position. * The "list(SORT)" command gained options to control the comparison operation used to order the entries. * The "math()" command gained options for hexadecimal. * The "target_link_directories()" command was created to specify link directories for targets and their dependents. * The "target_link_options()" command was created to specify link options for targets and their dependents. * The "target_link_libraries()" command may now be called to modify targets created outside the current directory. See policy "CMP0079". Variables --------- * A "CMAKE_AUTOGEN_VERBOSE" variable was added to optionally increase the verbosity of "AUTOMOC", "AUTOUIC" and "AUTORCC" from within CMake project code. * A "CMAKE_VS_GLOBALS" variable was added to initialize "VS_GLOBAL_" target properties on targets as they are created. Properties ---------- * The "DEPLOYMENT_ADDITIONAL_FILES" target property was added to tell the "Visual Studio 9 2008" generator to specify additional files for deployment to WinCE devices for remote debugging. * The "INTERFACE_LINK_DEPENDS" target property was created to specify transitive link dependencies on files. * The "LINK_DEPENDS" target property learned to support "generator expressions". * "LINK_DIRECTORIES" and "INTERFACE_LINK_DIRECTORIES" target properties were added to collect link directories for a target and its dependents. Use the "target_link_directories()" command to set them. * "LINK_OPTIONS" and "INTERFACE_LINK_OPTIONS" target properties were added to collect link options for a target and its dependents. Use the "target_link_options()" command to set them. * A "LINK_OPTIONS" directory property was added to collect link options for targets created under the current directory. Use the "add_link_options()" command to set it. * A "STATIC_LIBRARY_OPTIONS" target property was created to specify archiver options to use when creating static libraries. * A "VS_DEBUGGER_COMMAND_ARGUMENTS" target property was created to set the debugging command line arguments with Visual Studio Generators for VS 2010 and above. * A "VS_DEBUGGER_ENVIRONMENT" target property was created to set the debugging environment with Visual Studio Generators for VS 2010 and above. * The "VS_DEBUGGER_COMMAND" and "VS_DEBUGGER_WORKING_DIRECTORY" target properties now support generator expressions. Modules ------- * The "FindBoost" module gained a "Boost_ARCHITECTURE" option to specify a Boost architecture-specific library filename fragment. * The "FindCURL" module learned to find debug and release variants separately. * The "FindMatlab" module gained new components "ENGINE_LIBRARY" and "DATAARRAY_LIBRARY" to request finding the Matlab C++ Engine and DataArray libraries respectively. * The "FindMatlab" module now explicitly exports mexFunction in Visual Studio. * The "FindMatlab" module gained a new "MCC_COMPILER" component to request finding the Matlab Compiler add-on. * The "FindPkgConfig" module gained an option to create imported targets in global scope. * The "FindPkgConfig" module gained support for "<" and ">" operators for version checks in addition to the already supported operators ">=", "<=", and "=". * Modules "FindPython3", "FindPython2" and "FindPython" gain capability to control order of resource lookup on macOS (Framework) and Windows (Registry). * The "FindSubversion" module "Subversion_WC_INFO" command gained an "IGNORE_SVN_FAILURE" option to suppress failures, e.g. when the source tree is not under Subversion control. * The "UseSWIG" module learned to manage target property "INCLUDE_DIRECTORIES" for "SWIG" compilation. CTest ----- * "ctest(1)" gained a "--progress" option to enable a live test progress summary when output goes to a terminal. CPack ----- * The "CPack DEB Generator" learned to split debug symbols into a corresponding .ddeb package when "CPACK_DEBIAN_DEBUGINFO_PACKAGE" is set. * The "CPack DEB Generator" learned to honor the "SOURCE_DATE_EPOCH" environment variable when packaging files. This is useful for generating reproducible packages. * CPack gained a new "CPack External Generator" which is used to export the CPack metadata in a format that other software can understand. The intention of this generator is to allow external packaging software to take advantage of CPack's features when it may not be possible to use CPack for the entire packaging process. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policies "CMP0055" through "CMP0063" ("CMP0054" and below were already deprecated). The "cmake-policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors. Other Changes ============= * The precompiled binaries provided on "cmake.org" now include qthelp- format documentation. * The "option()" command now honors an existing normal variable of the same name and does nothing instead of possibly creating a cache entry (or setting its type) and removing the normal variable. See policy "CMP0077". * The Makefile Generators learned to remove custom command and custom target byproducts during "make clean". * The "target_sources()" command now interprets relative source file paths as relative to the current source directory. This simplifies incrementally building up a target's sources from subdirectories. The "CMP0076" policy was added to provide backward compatibility with the old behavior where required. * The "BundleUtilities" module may no longer be included at configure time. This was always a bug anyway. See policy "CMP0080". * The "UseSWIG" module has changed strategy for target naming. See policy "CMP0078". * The "LINK_DIRECTORIES" target property now expects absolute paths. See policy "CMP0081". * The CPack generators have been moved into their own separate section in the documentation, rather than having the documentation in their internal implementation modules. These internal implementation modules are also no longer available to scripts that may have been incorrectly including them, because they should never have been available in the first place. ---------------------------------------------------------------------------- Changes made since CMake 3.13.0-rc2: Brad King (12): FindMPI: Pass -pthread to CUDA compiler through -Xcompiler set_directory_properties: Restore in script mode Flang: Fix command-line used to preprocess sources CSharp: Fix regression in VS project type selection for custom target curl: Update script to get curl 7.62.0 curl: Update build within CMake to account for 7.62 changes FindProtobuf: Add missing link dependencies on threads curl: Modernize tiny test code used for build inside CMake curl: backport upstream fix to 7.62.0 regression add_custom_{command,target}: Fix WORKING_DIRECTORY leading genex FindBoost: Add explicit Boost_ARCHITECTURE option CMake 3.13.0-rc3 Craig Scott (3): Help: Fix generators link in cpack(1) manual CPack: Rename Ext generator to External Help: Use correct CPack generator names Curl Upstream (1): curl 2018-10-30 (19667715) Ivan Pozdeev (2): FindOpenMP: Fix warnings with -Wstrict-prototypes FindOpenMP: Log error output Jakub Benda (2): FindBLAS: Correct symbol searched in BLAS95 wrapper FindLAPACK: Correct library name and symbol searched in LAPACK95 wrapper Maikel van den Hurk (1): QNX: Update qcc depfile flags to be compliant with ccache Marc Chevrier (2): Help: clarify "LINKER:" prefix usage UseSWIG: multiple input files must be supported in version 2 Martin Quinson (1): FindBoost: Add support for stacktrace components Robert Maynard (1): CUDA: Filter out non-static libraries during device linking Sylvain Joubert (3): UseSWIG: Typo, add missing letter UseSWIG: Add target language and input file in command description FindPostgreSQL: Search for version 11 Vladimir Penev (1): server: Fix assertion failure on directory paths in file monitor From j.wuttke at fz-juelich.de Fri Nov 9 05:34:22 2018 From: j.wuttke at fz-juelich.de (Joachim Wuttke) Date: Fri, 9 Nov 2018 11:34:22 +0100 Subject: [cmake-developers] module proposal: PreventInSourceBuilds Message-ID: <545c4402-7101-f208-2006-27625a5898d2@fz-juelich.de> In all my projects, the top-level CMakeLists.txt contains the line include(PreventInSourceBuilds) to protect users (and myself) from unintentionally running CMake in the source directory. Would you consider adding this little module to the CMake code base? I would then add an option so that users can override the not-in-source policy. /Joachim --- #.rst: # PreventInSourceBuilds # --------------------- # # Prevent in-source builds # # It is generally acknowledged that it is preferable to run CMake out of source, # in a dedicated build directory. To prevent users from accidentally running # CMake in the source directory, just include this module. # make sure the user doesn't play dirty with symlinks get_filename_component(srcdir "${CMAKE_SOURCE_DIR}" REALPATH) get_filename_component(bindir "${CMAKE_BINARY_DIR}" REALPATH) # disallow in-source builds if("${srcdir}" STREQUAL "${bindir}") message(FATAL_ERROR "\ CMake must not to be run in the source directory. \ Rather create a dedicated build directory and run CMake there. \ To clean up after this aborted in-source compilation: rm -r CMakeCache.txt CMakeFiles ") endif() -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5110 bytes Desc: S/MIME Cryptographic Signature URL: From rleigh at codelibre.net Fri Nov 9 06:44:36 2018 From: rleigh at codelibre.net (Roger Leigh) Date: Fri, 9 Nov 2018 11:44:36 +0000 Subject: [cmake-developers] module proposal: PreventInSourceBuilds In-Reply-To: <545c4402-7101-f208-2006-27625a5898d2@fz-juelich.de> References: <545c4402-7101-f208-2006-27625a5898d2@fz-juelich.de> Message-ID: <59227b97-6c89-2edb-9ed3-293c290842d4@codelibre.net> On 09/11/2018 10:34, Joachim Wuttke wrote: > In all my projects, the top-level CMakeLists.txt contains the line > > include(PreventInSourceBuilds) > > to protect users (and myself) from unintentionally running CMake > in the source directory. I for one have an equivalent to this logic in all my projects to prevent in-source builds. Having a standardised version would be very useful, and I would certainly make use of it. Thanks, Roger From brad.king at kitware.com Fri Nov 9 07:14:26 2018 From: brad.king at kitware.com (Brad King) Date: Fri, 9 Nov 2018 07:14:26 -0500 Subject: [cmake-developers] option to prevent in-source builds In-Reply-To: <545c4402-7101-f208-2006-27625a5898d2@fz-juelich.de> References: <545c4402-7101-f208-2006-27625a5898d2@fz-juelich.de> Message-ID: On 11/09/2018 05:34 AM, Joachim Wuttke wrote: > include(PreventInSourceBuilds) > > to protect users (and myself) from unintentionally running CMake > in the source directory. > > Would you consider adding this little module to the CMake code base? If we are going to offer an upstream solution for this I think it should be done in a way that avoids ever creating any files (like CMakeCache.txt or CMakeFiles) in the first place. This could be achieved by looking for a `.cmake/init.json` file at the top of the source tree with declarative information about the project's preferences. One of those settings could reject in-source builds. -Brad From taylorcholberton at gmail.com Fri Nov 9 07:28:54 2018 From: taylorcholberton at gmail.com (Taylor Holberton) Date: Fri, 9 Nov 2018 07:28:54 -0500 Subject: [cmake-developers] option to prevent in-source builds In-Reply-To: References: <545c4402-7101-f208-2006-27625a5898d2@fz-juelich.de> Message-ID: A lot of projects that use CMake already have a `./cmake` directory, I would think `./cmake/init.json` would fit nicer as opposed to the hidden directory. I'm not a fan of hidden directories in software projects anyway. I would prefer an init file be written as a CMake file instead of JSON. JSON is nice because it plays well with GUIs, but I think using CMake syntax will function better if the file ever needs to be a bit more complicated. On Fri, Nov 9, 2018, 07:14 Brad King On 11/09/2018 05:34 AM, Joachim Wuttke wrote: > > include(PreventInSourceBuilds) > > > > to protect users (and myself) from unintentionally running CMake > > in the source directory. > > > > Would you consider adding this little module to the CMake code base? > > If we are going to offer an upstream solution for this I think > it should be done in a way that avoids ever creating any files > (like CMakeCache.txt or CMakeFiles) in the first place. This > could be achieved by looking for a `.cmake/init.json` file > at the top of the source tree with declarative information > about the project's preferences. One of those settings could > reject in-source builds. > > -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: > https://cmake.org/mailman/listinfo/cmake-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Fri Nov 9 08:06:20 2018 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 09 Nov 2018 14:06:20 +0100 Subject: [cmake-developers] module proposal: PreventInSourceBuilds In-Reply-To: <545c4402-7101-f208-2006-27625a5898d2@fz-juelich.de> References: <545c4402-7101-f208-2006-27625a5898d2@fz-juelich.de> Message-ID: <47dd8306aac8a88a5ae0e268b4d435f9@sf-mail.de> (correct list this time) > # disallow in-source builds > if("${srcdir}" STREQUAL "${bindir}") if(srcdir STREQUAL bindir) HTH Eike -- From brad.king at kitware.com Fri Nov 9 08:49:24 2018 From: brad.king at kitware.com (Brad King) Date: Fri, 9 Nov 2018 08:49:24 -0500 Subject: [cmake-developers] option to prevent in-source builds In-Reply-To: References: <545c4402-7101-f208-2006-27625a5898d2@fz-juelich.de> Message-ID: On 11/09/2018 07:28 AM, Taylor Holberton wrote: > A lot of projects that use CMake already have a `./cmake` directory, > I would think `./cmake/init.json` would fit nicer as opposed to the > hidden directory. We could have a list of supported places so projects can choose. > I would prefer an init file be written as a CMake file instead of JSON. We need to be able to load the file without initializing much. If it is a CMake language file then people will try to write `if` conditions to check things that we wouldn't provide access to at that point. The idea of this file is to have a purely declarative specification. A format like JSON will work well for that. -Brad From j.wuttke at fz-juelich.de Fri Nov 9 08:55:27 2018 From: j.wuttke at fz-juelich.de (Joachim Wuttke) Date: Fri, 9 Nov 2018 14:55:27 +0100 Subject: [cmake-developers] CMake string question In-Reply-To: <47dd8306aac8a88a5ae0e268b4d435f9@sf-mail.de> References: <545c4402-7101-f208-2006-27625a5898d2@fz-juelich.de> <47dd8306aac8a88a5ae0e268b4d435f9@sf-mail.de> Message-ID: >> if("${srcdir}" STREQUAL "${bindir}") > > if(srcdir STREQUAL bindir) looks more idiomatic, thank you Eike - But can we be sure that srcdir contains no blank? Or does STREQUAL work even for argument strings that contain blanks? - Joachim -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5110 bytes Desc: S/MIME Cryptographic Signature URL: From eike at sf-mail.de Fri Nov 9 09:12:52 2018 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 09 Nov 2018 15:12:52 +0100 Subject: [cmake-developers] CMake string question In-Reply-To: References: <545c4402-7101-f208-2006-27625a5898d2@fz-juelich.de> <47dd8306aac8a88a5ae0e268b4d435f9@sf-mail.de> Message-ID: <299803693fcd46f062e8230d42c9d2d5@sf-mail.de> Am 2018-11-09 14:55, schrieb Joachim Wuttke: >>> if("${srcdir}" STREQUAL "${bindir}") >> >> if(srcdir STREQUAL bindir) > > looks more idiomatic, thank you Eike - > > But can we be sure that srcdir contains no blank? > Or does STREQUAL work even for argument strings > that contain blanks? If you pass in only the variable names CMake will do the expansion only internally, so this is save. It just works (tm). Eike -- From ben.boeckel at kitware.com Fri Nov 9 11:03:37 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 9 Nov 2018 11:03:37 -0500 Subject: [cmake-developers] option to prevent in-source builds In-Reply-To: References: <545c4402-7101-f208-2006-27625a5898d2@fz-juelich.de> Message-ID: <20181109160337.GB21280@rotor.localdomain> On Fri, Nov 09, 2018 at 07:28:54 -0500, Taylor Holberton wrote: > A lot of projects that use CMake already have a `./cmake` directory, I > would think `./cmake/init.json` would fit nicer as opposed to the hidden > directory. I'm not a fan of hidden directories in software projects anyway. There are also `./CMake` directories. HDF5 uses `./config/cmake`. I think just claiming a "hidden" directory with exact casing is better. --Ben From eric.noulard at gmail.com Fri Nov 9 14:17:24 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 9 Nov 2018 20:17:24 +0100 Subject: [cmake-developers] option to prevent in-source builds In-Reply-To: <20181109160337.GB21280@rotor.localdomain> References: <545c4402-7101-f208-2006-27625a5898d2@fz-juelich.de> <20181109160337.GB21280@rotor.localdomain> Message-ID: Just a small remark to say this request of "builtin" way to forbid in-source is quite old: https://gitlab.kitware.com/cmake/cmake/issues/6672 which find its origin in: https://cmake.org/Bug/view.php?id=6672 I don't know if the note from that initial discussion are valid nowadays but the fact that: "Code in CMakeLists.txt is not even executed until after the cache is initialized so there would have to be some other way to indicate in the source tree that it should not be built in-source." and the fact that "The cache is initialized before the procedural steps start to run. With cmake-gui or the cmake command-line "-D" option it is even possible to store entries in the cache before CMake even parses CMakeLists.txt" almost implies that this should be done outside CMakeLists.txt That said, I think that I would rather have some obviously visible and fixed place like CMakeInit.json that should be located in the very same directory as the concerned CMakeLists.txt rather than some list of possible places (cmake/, cmake/init, .cmake, etc...). The exact path to CMakeInit.json could be overwritten by some new command line option, like --init-file if for some reason we want a configurable place (may be used in various CI scripts occasion). This file could hold more options than "just forbid in-source" it could indicate a default generator (which may be different from the usual default generator on the concerned platform), some a toolchain. It's usage would be different than the initial cache precisely because it could work before cache is created. Le ven. 9 nov. 2018 ? 17:03, Ben Boeckel a ?crit : > On Fri, Nov 09, 2018 at 07:28:54 -0500, Taylor Holberton wrote: > > A lot of projects that use CMake already have a `./cmake` directory, I > > would think `./cmake/init.json` would fit nicer as opposed to the hidden > > directory. I'm not a fan of hidden directories in software projects > anyway. > > There are also `./CMake` directories. HDF5 uses `./config/cmake`. I > think just claiming a "hidden" directory with exact casing is better. > > --Ben > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake-developers > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.wuttke at fz-juelich.de Mon Nov 12 17:49:50 2018 From: j.wuttke at fz-juelich.de (Joachim Wuttke) Date: Mon, 12 Nov 2018 23:49:50 +0100 Subject: [cmake-developers] Preferred case for macro names? In-Reply-To: References: Message-ID: <08161d6d-0917-f2ea-558e-5b0d25ececa1@fz-juelich.de> My understanding was that prevalent usage in modern CMake is all lowercase for function names, all uppercase for macro names. In this sense, I submitted a number of merge requests where function and macro names are normalized, and in https://gitlab.kitware.com/cmake/cmake/merge_requests/2607 I suggest an explicit recommendation in the macro and function doc pages. Now I am learning from Craig Scott that the more recent convention is actually all lowercase for macros as well as for functions. Thus two requests for comments: - Shall the reference manual give a clear recommendation on preferred case, to stear the community away from the inherited anarchy? - Macro names all uppercase or all uppercase? /Joachim -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5110 bytes Desc: S/MIME Cryptographic Signature URL: From taylorcholberton at gmail.com Mon Nov 12 17:53:38 2018 From: taylorcholberton at gmail.com (Taylor Holberton) Date: Mon, 12 Nov 2018 17:53:38 -0500 Subject: [cmake-developers] CMake Cache Library Message-ID: Hello everyone! Today I released a short and sweet C++ library for accessing and modifying CMake Cache files. Feel free to use it, critique it, or ignore it entirely. You can find it on GitHub, at https://github.com/tay10r/cmake-cache Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Mon Nov 12 18:20:45 2018 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 13 Nov 2018 10:20:45 +1100 Subject: [cmake-developers] Preferred case for macro names? In-Reply-To: <08161d6d-0917-f2ea-558e-5b0d25ececa1@fz-juelich.de> References: <08161d6d-0917-f2ea-558e-5b0d25ececa1@fz-juelich.de> Message-ID: On Tue, Nov 13, 2018 at 9:51 AM Joachim Wuttke wrote: > My understanding was that prevalent usage in modern CMake > is all lowercase for function names, all uppercase for > macro names. In this sense, I submitted a number of merge > requests where function and macro names are normalized, and > in > https://gitlab.kitware.com/cmake/cmake/merge_requests/2607 > I suggest an explicit recommendation in the macro and > function doc pages. > > Now I am learning from Craig Scott that the more recent > convention is actually all lowercase for macros as well > as for functions. > To be clear, my understanding is that in the past (many years ago), uppercase tended to be common, but I don't see that used much these days for functions, macros or built-in commands. The general sentiment seems to be that uppercase tends to be a bit "shouty" now. I'm suggesting that if we're going to bring some consistency to the docs, I propose that we just go with lowercase everywhere (functions, macros, built-in commands and examples). Regarding the finer points of macros versus functions versus built-in commands and establishing a convention, it's actually a bit difficult to draw a hard line in behaviour across all three. Consider commands like find_package() and project(). These are built-in commands, but they behave like a macros in that they add variables to the calling scope (yes, functions can do that too, but the primary reason to use macros is to inject variables into the calling scope). Most built-in commands act more like functions and do not modify the calling scope. Trying to decide whether built-in commands act like macros and which do not and making them upper or lowercase based on that is unlikely to be a distinction that most users would make, so a mix of upper and lowercase for built-in commands would be unexpected. A consequence of this is that having macros and functions with differing case conventions would seem to create a potential inconsistency with whatever convention is used for built-in commands. The only way to really have consistency here would seem to be just use the one case convention, for which lowercase seems to be the logical and increasingly prevalent choice. > > Thus two requests for comments: > > - Shall the reference manual give a clear recommendation > on preferred case, to stear the community away from the > inherited anarchy? > The docs can be consistent throughout, but matters of style are ultimately up to individual projects and their own coding conventions. Over time, making the CMake docs present a consistent style will likely encourage projects that don't have a convention of their own to adopt that style out of familiarity. -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Tue Nov 13 03:58:54 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 13 Nov 2018 09:58:54 +0100 Subject: [cmake-developers] Preferred case for macro names? In-Reply-To: References: <08161d6d-0917-f2ea-558e-5b0d25ececa1@fz-juelich.de> Message-ID: Le mar. 13 nov. 2018 ? 00:21, Craig Scott a ?crit : > > > On Tue, Nov 13, 2018 at 9:51 AM Joachim Wuttke > wrote: > >> My understanding was that prevalent usage in modern CMake >> is all lowercase for function names, all uppercase for >> macro names. In this sense, I submitted a number of merge >> requests where function and macro names are normalized, and >> in >> https://gitlab.kitware.com/cmake/cmake/merge_requests/2607 >> I suggest an explicit recommendation in the macro and >> function doc pages. >> >> Now I am learning from Craig Scott that the more recent >> convention is actually all lowercase for macros as well >> as for functions. >> > > To be clear, my understanding is that in the past (many years ago), > uppercase tended to be common, but I don't see that used much these days > for functions, macros or built-in commands. The general sentiment seems to > be that uppercase tends to be a bit "shouty" now. I'm suggesting that if > we're going to bring some consistency to the docs, I propose that we just > go with lowercase everywhere (functions, macros, built-in commands and > examples). > > > Regarding the finer points of macros versus functions versus built-in > commands and establishing a convention, it's actually a bit difficult to > draw a hard line in behaviour across all three. Consider commands like > find_package() and project(). These are built-in commands, but they behave > like a macros in that they add variables to the calling scope (yes, > functions can do that too, but the primary reason to use macros is to > inject variables into the calling scope). Most built-in commands act more > like functions and do not modify the calling scope. Trying to decide > whether built-in commands act like macros and which do not and making them > upper or lowercase based on that is unlikely to be a distinction that most > users would make, so a mix of upper and lowercase for built-in commands > would be unexpected. A consequence of this is that having macros and > functions with differing case conventions would seem to create a potential > inconsistency with whatever convention is used for built-in commands. The > only way to really have consistency here would seem to be just use the one > case convention, for which lowercase seems to be the logical and > increasingly prevalent choice. > > I would add that sometimes useful macro/function may become builtin See example for include_guard in https://github.com/dev-cafe/cmake-cookbook/blob/master/chapter-07/recipe-06/example/CMakeLists.txt So differentiating macro/function/builtin by their case does not seems a good option to me. My personal opinion though. +1 for lower case for every function, macro or builtin. macro or function OPTION are UPPERCASE properties are UPPERCASE as well and I personnally tend to define CMake VARIABLES as uppercase too. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Tue Nov 13 04:40:55 2018 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Tue, 13 Nov 2018 10:40:55 +0100 Subject: [cmake-developers] Preferred case for macro names? In-Reply-To: References: <08161d6d-0917-f2ea-558e-5b0d25ececa1@fz-juelich.de> Message-ID: I agree as well that trying to distinguish macros from functions is not a good idea because functions can act in the same way as macros (i.e. changing calling environment) but with a better control over environment changes (changes are done explicitly by using 'set(... PARENT_SCOPE)'). so also +1 for lower case for every function, macro or builtin. And good point to standardize macro or function OPTION to UPPERCASE. Now, for variables, the problem is a bit different because they are case sensitive: 'set(my_var ...)' and 'set (MY_VAR ...)' will create two different variables. My personal tendency is to use lower case for local variables and upper case for global variables. May be we can normalize variables to upper case regarding global variables used by CMake itself (which is globally the current rule). Le mar. 13 nov. 2018 ? 09:59, Eric Noulard a ?crit : > > > Le mar. 13 nov. 2018 ? 00:21, Craig Scott a > ?crit : > >> >> >> On Tue, Nov 13, 2018 at 9:51 AM Joachim Wuttke >> wrote: >> >>> My understanding was that prevalent usage in modern CMake >>> is all lowercase for function names, all uppercase for >>> macro names. In this sense, I submitted a number of merge >>> requests where function and macro names are normalized, and >>> in >>> https://gitlab.kitware.com/cmake/cmake/merge_requests/2607 >>> I suggest an explicit recommendation in the macro and >>> function doc pages. >>> >>> Now I am learning from Craig Scott that the more recent >>> convention is actually all lowercase for macros as well >>> as for functions. >>> >> >> To be clear, my understanding is that in the past (many years ago), >> uppercase tended to be common, but I don't see that used much these days >> for functions, macros or built-in commands. The general sentiment seems to >> be that uppercase tends to be a bit "shouty" now. I'm suggesting that if >> we're going to bring some consistency to the docs, I propose that we just >> go with lowercase everywhere (functions, macros, built-in commands and >> examples). >> >> >> Regarding the finer points of macros versus functions versus built-in >> commands and establishing a convention, it's actually a bit difficult to >> draw a hard line in behaviour across all three. Consider commands like >> find_package() and project(). These are built-in commands, but they behave >> like a macros in that they add variables to the calling scope (yes, >> functions can do that too, but the primary reason to use macros is to >> inject variables into the calling scope). Most built-in commands act more >> like functions and do not modify the calling scope. Trying to decide >> whether built-in commands act like macros and which do not and making them >> upper or lowercase based on that is unlikely to be a distinction that most >> users would make, so a mix of upper and lowercase for built-in commands >> would be unexpected. A consequence of this is that having macros and >> functions with differing case conventions would seem to create a potential >> inconsistency with whatever convention is used for built-in commands. The >> only way to really have consistency here would seem to be just use the one >> case convention, for which lowercase seems to be the logical and >> increasingly prevalent choice. >> >> > > I would add that sometimes useful macro/function may become builtin > See example for include_guard in > https://github.com/dev-cafe/cmake-cookbook/blob/master/chapter-07/recipe-06/example/CMakeLists.txt > > So differentiating macro/function/builtin by their case does not seems a > good option to me. > My personal opinion though. > > +1 for lower case for every function, macro or builtin. > macro or function OPTION are UPPERCASE > properties are UPPERCASE as well > and I personnally tend to define CMake VARIABLES as uppercase too. > > > -- > Eric > -- > > 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: > https://cmake.org/mailman/listinfo/cmake-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Tue Nov 13 05:36:24 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 13 Nov 2018 11:36:24 +0100 Subject: [cmake-developers] Preferred case for macro names? In-Reply-To: References: <08161d6d-0917-f2ea-558e-5b0d25ececa1@fz-juelich.de> Message-ID: Le mar. 13 nov. 2018 ? 10:41, Marc CHEVRIER a ?crit : > I agree as well that trying to distinguish macros from functions is not a > good idea because functions can act in the same way as macros (i.e. > changing calling environment) but with a better control over environment > changes (changes are done explicitly by using 'set(... PARENT_SCOPE)'). > > so also +1 for lower case for every function, macro or builtin. And good > point to standardize macro or function OPTION to UPPERCASE. > > Now, for variables, the problem is a bit different because they are case > sensitive: 'set(my_var ...)' and 'set (MY_VAR ...)' will create two > different variables. > Yes damn right. > My personal tendency is to use lower case for local variables and upper > case for global variables. May be we can normalize variables to upper case > regarding global variables used by CMake itself (which is globally the > current rule). > Having a convention for local is nice and I tend to prefix with _ (single or double) variables that should be local. lowercasing locals is fine too, however I think that enforcing casing on "user-defined" variable may not be desirable, concerning CMAKE_ CTEST_ and CPACK_ I guess they already are all UPPERCASE so we may stick with this as a convention? A small quote to the cmake-format ( https://github.com/cheshirekow/cmake_format) tool which is trying to beautify CMakeLists.txt, I'm not using it on complex projects because it still has some issues but I find it otherwise useful. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Tue Nov 13 06:11:26 2018 From: DLRdave at aol.com (David Cole) Date: Tue, 13 Nov 2018 06:11:26 -0500 Subject: [cmake-developers] Preferred case for macro names? In-Reply-To: References: <08161d6d-0917-f2ea-558e-5b0d25ececa1@fz-juelich.de> Message-ID: I would just like to point out that some modules (ExternalData, ExternalProject, to name two specific examples) adopted the convention to prefix all their provided function names with the module name and an underscore: for example, ExternalProject_Add and ExternalData_Expand_Arguments. These functions adopt a mixed-case function naming convention, since the module name is mixed case, and since module names are file names, and some file systems have case sensitive file names ...... they should stay that way regardless of any convention you may like to try to adopt elsewhere. David C. On Tue, Nov 13, 2018 at 5:36 AM Eric Noulard wrote: > > > > Le mar. 13 nov. 2018 ? 10:41, Marc CHEVRIER a ?crit : >> >> I agree as well that trying to distinguish macros from functions is not a good idea because functions can act in the same way as macros (i.e. changing calling environment) but with a better control over environment changes (changes are done explicitly by using 'set(... PARENT_SCOPE)'). >> >> so also +1 for lower case for every function, macro or builtin. And good point to standardize macro or function OPTION to UPPERCASE. >> >> Now, for variables, the problem is a bit different because they are case sensitive: 'set(my_var ...)' and 'set (MY_VAR ...)' will create two different variables. > > > Yes damn right. > >> >> My personal tendency is to use lower case for local variables and upper case for global variables. May be we can normalize variables to upper case regarding global variables used by CMake itself (which is globally the current rule). > > > Having a convention for local is nice and I tend to prefix with _ (single or double) variables that should be local. > lowercasing locals is fine too, however I think that enforcing casing on "user-defined" variable may not be desirable, concerning CMAKE_ CTEST_ and CPACK_ > I guess they already are all UPPERCASE so we may stick with this as a convention? > > A small quote to the cmake-format (https://github.com/cheshirekow/cmake_format) tool which is trying to beautify CMakeLists.txt, I'm not using it on complex projects > because it still has some issues but I find it otherwise useful. > > > -- > Eric > -- > > 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: > https://cmake.org/mailman/listinfo/cmake-developers From neundorf at kde.org Tue Nov 13 15:42:01 2018 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 13 Nov 2018 21:42:01 +0100 Subject: [cmake-developers] CMake Cache Library In-Reply-To: References: Message-ID: <1737298.x3NfnslfAa@linux-l7nd> On 2018 M11 12, Mon 17:53:38 CET Taylor Holberton wrote: > Hello everyone! > > Today I released a short and sweet C++ library for accessing and modifying > CMake Cache files. > > Feel free to use it, critique it, or ignore it entirely. > > You can find it on GitHub, at https://github.com/tay10r/cmake-cache > > Thanks! did you really choose GPLv3 as license for this ? Alex From ben.boeckel at kitware.com Wed Nov 14 09:38:21 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 14 Nov 2018 09:38:21 -0500 Subject: [cmake-developers] Preferred case for macro names? In-Reply-To: References: <08161d6d-0917-f2ea-558e-5b0d25ececa1@fz-juelich.de> Message-ID: <20181114143821.GB15548@rotor.localdomain> On Tue, Nov 13, 2018 at 06:11:26 -0500, David Cole via cmake-developers wrote: > I would just like to point out that some modules (ExternalData, > ExternalProject, to name two specific examples) adopted the convention > to prefix all their provided function names with the module name and > an underscore: for example, ExternalProject_Add and > ExternalData_Expand_Arguments. > > These functions adopt a mixed-case function naming convention, since > the module name is mixed case, and since module names are file names, > and some file systems have case sensitive file names ...... they > should stay that way regardless of any convention you may like to try > to adopt elsewhere. Agreed. I use lower case everywhere I can, but externalproject_add just looks worse than ExternalProject_add (though I'd really prefer external_project_add, that ship sailed long ago). --Ben From ben.boeckel at kitware.com Wed Nov 14 09:40:55 2018 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 14 Nov 2018 09:40:55 -0500 Subject: [cmake-developers] Preferred case for macro names? In-Reply-To: References: <08161d6d-0917-f2ea-558e-5b0d25ececa1@fz-juelich.de> Message-ID: <20181114144055.GC15548@rotor.localdomain> On Tue, Nov 13, 2018 at 11:36:24 +0100, Eric Noulard wrote: > > My personal tendency is to use lower case for local variables and upper > > case for global variables. May be we can normalize variables to upper case > > regarding global variables used by CMake itself (which is globally the > > current rule). > > Having a convention for local is nice and I tend to prefix with _ (single > or double) variables that should be local. > lowercasing locals is fine too, however I think that enforcing casing on > "user-defined" variable may not be desirable, concerning CMAKE_ CTEST_ and > CPACK_ > I guess they already are all UPPERCASE so we may stick with this as a > convention? My personal style is to use lowercase for derived or internal variables (and properties). Uppercase is left for environment (e.g., CMake) or user variables. Note that CMake also defines some un-namespaced variables including: - BUILD_SHARED_LIBS - BUILD_TESTING - many CTest variables (*_COMMAND, DART_TESTING_TIMEOUT, etc.) --Ben From tjwrona1992 at gmail.com Fri Nov 16 17:53:24 2018 From: tjwrona1992 at gmail.com (Timothy Wrona) Date: Fri, 16 Nov 2018 17:53:24 -0500 Subject: [cmake-developers] Conan Integration for CMake Message-ID: I recently started using a new package manager for C++ called "Conan" and I'm finding it is solves many of the dependency issues that plague all of my previous C++/CMake projects. Conan is an up-and-coming tool, but it seems to be gaining quite a bit of traction. It is designed with CMake in mind and works very well with CMake projects. There is just some functionality that feels like it could be a little more streamlined and the only way to make that happen would be to add built-in support in CMake for Conan. An effort has been made to add some CMake tools around Conan at " https://github.com/conan-io/cmake-conan" and they really help streamline the process. Integrating Conan support into CMake itself would make it so you don't have to grab this library from GitHub everytime you want to use Conan with a CMake project and would simplify the process. Is this something that could possibly be integrated into CMake in a future version? If others think that it would be well received I wouldn't mind offering some of my time to be part of the integration effort. *For anyone using CMake and programming in C or C++, if you are unfamiliar with Conan I strongly suggest you check it out. It solves many difficult dependency management issues in ways that CMake alone cannot. For more information on Conan see "https://conan.io/ "* -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg at kaa.org.ua Tue Nov 20 09:19:29 2018 From: oleg at kaa.org.ua (Oleh Kravchenko) Date: Tue, 20 Nov 2018 16:19:29 +0200 Subject: [cmake-developers] ENV{SOURCE_DATE_EPOCH} In-Reply-To: References: Message-ID: Hello CMake Developers, My use case is to use UNIX timestamp from git history to setup SOURCE_DATE_EPOCH and get the same binary. I would like to set SOURCE_DATE_EPOCH environment variable from CMake during configuration step. How I can do it? -- Best regards, Oleh Kravchenko -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From sergey.nikulov at gmail.com Tue Nov 20 10:13:47 2018 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Tue, 20 Nov 2018 18:13:47 +0300 Subject: [cmake-developers] ENV{SOURCE_DATE_EPOCH} In-Reply-To: References: Message-ID: ??, 20 ????. 2018 ?. ? 17:29, Oleh Kravchenko : > > Hello CMake Developers, > > My use case is to use UNIX timestamp from git history to setup > SOURCE_DATE_EPOCH and get the same binary. > I would like to set SOURCE_DATE_EPOCH environment variable from CMake > during configuration step. > > How I can do it? As per manual https://cmake.org/cmake/help/latest/command/set.html set(ENV{SOURCE_DATE_EPOCH} ...) should work during configuration step. Should not work during build step when you invoke make or ninja. > -- Best regards, Oleh Kravchenko > > > -- > > 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: > https://cmake.org/mailman/listinfo/cmake-developers -- Best Regards, Sergei Nikulov From oleg at kaa.org.ua Tue Nov 20 10:51:25 2018 From: oleg at kaa.org.ua (Oleh Kravchenko) Date: Tue, 20 Nov 2018 17:51:25 +0200 Subject: [cmake-developers] ENV{SOURCE_DATE_EPOCH} In-Reply-To: References: Message-ID: <6aab98d6-d9d1-f328-51bd-fc44a71b64f8@kaa.org.ua> Thank you Sergei, but this is not what I asked.. I would like to set this variable during configuration step and get the same binary, that's means CMake should pass this variable to build tool (GNU Make, Ninja, ...). From my point of view CMake should have such functionality. I can create a patch, but will be acceptable for merging? On 20.11.18 17:13, Sergei Nikulov wrote: > ??, 20 ????. 2018 ?. ? 17:29, Oleh Kravchenko : >> Hello CMake Developers, >> >> My use case is to use UNIX timestamp from git history to setup >> SOURCE_DATE_EPOCH and get the same binary. >> I would like to set SOURCE_DATE_EPOCH environment variable from CMake >> during configuration step. >> >> How I can do it? > As per manual https://cmake.org/cmake/help/latest/command/set.html > set(ENV{SOURCE_DATE_EPOCH} ...) > should work during configuration step. > > Should not work during build step when you invoke make or ninja. > >> -- Best regards, Oleh Kravchenko >> >> >> -- >> >> 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: >> https://cmake.org/mailman/listinfo/cmake-developers > > -- Best regards, Oleh Kravchenko From robert.maynard at kitware.com Tue Nov 20 14:37:37 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 20 Nov 2018 14:37:37 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.13.0 available for download Message-ID: I am happy to announce that CMake 3.13.0 is now available for download at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.13 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.13/release/3.13.html Some of the more significant changes in CMake 3.13 are: * The Visual Studio Generators for VS 2010 and above learned to support the "INTERPROCEDURAL_OPTIMIZATION" target property and supporting "CheckIPOSupported" module. * The "Green Hills MULTI" generator has been updated to include support for platform, architecture, and toolset selection. * The "cmake" command gained the "-S " command line option to specify the location of the source directory. This option can be used independently of "-B". * The "cmake" command gained the "-B " command line option to specify the location of the build directory. This option can be used independently of "-S". * The "cmake" "-E create_symlink" command can now be used on Windows. * The "target_link_directories()" command was created to specify link directories for targets and their dependents. * The "target_link_options()" command was created to specify link options for targets and their dependents. * The "target_link_libraries()" command may now be called to modify targets created outside the current directory. See policy "CMP0079". * The "install(TARGETS)" command learned to install targets created outside the current directory. * A "VS_DEBUGGER_COMMAND_ARGUMENTS" target property was created to set the debugging command line arguments with Visual Studio Generators for VS 2010 and above. * A "VS_DEBUGGER_ENVIRONMENT" target property was created to set the debugging environment with Visual Studio Generators for VS 2010 and above. * The "option()" command now honors an existing normal variable of the same name and does nothing instead of possibly creating a cache entry (or setting its type) and removing the normal variable. See policy "CMP0077". * The "target_sources()" command now interprets relative source file paths as relative to the current source directory. This simplifies incrementally building up a target's sources from subdirectories. The "CMP0076" policy was added to provide backward compatibility with the old behavior where required. CMake 3.13 Release Notes ************************ Changes made since CMake 3.12 include the following. New Features ============ Generators ---------- * The Visual Studio Generators for VS 2010 and above learned to support the "INTERPROCEDURAL_OPTIMIZATION" target property and supporting "CheckIPOSupported" module. * The "Xcode" generator learned to configure more Xcode Scheme fields. See the "CMAKE_XCODE_GENERATE_SCHEME" variable. * The "Green Hills MULTI" generator has been updated: * Added support for architecture selection through "CMAKE_GENERATOR_PLATFORM": e.g. "arm", "ppc", and "86". * Added support for toolset selection through "CMAKE_GENERATOR_TOOLSET", e.g. "comp_201205", "comp_201510", "comp_201722_beta". * Added support for platform selection through "GHS_TARGET_PLATFORM", e.g. "integrity", "linux", "standalone", etc. * No longer checks that "arm" based compilers are installed but ensures that the correct "gbuild.exe" exists. * No longer hard-codes ARM files, BSP, toolset, or OS locations. Command-Line ------------ * The "cmake(1)" command gained the "-S " command line option to specify the location of the source directory. This option can be used independently of "-B". * The "cmake(1)" command gained the "-B " command line option to specify the location of the build directory. This option can be used independently of "-S". * The "cmake(1)" "-E create_symlink" command can now be used on Windows. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned to support generator expressions in "WORKING_DIRECTORY" options. * The "add_link_options()" command was created to add link options in the current directory. * The "install(TARGETS)" command learned to install targets created outside the current directory. * The "link_directories()" command gained options to control insertion position. * The "list(SORT)" command gained options to control the comparison operation used to order the entries. * The "math()" command gained options for hexadecimal. * The "target_link_directories()" command was created to specify link directories for targets and their dependents. * The "target_link_options()" command was created to specify link options for targets and their dependents. * The "target_link_libraries()" command may now be called to modify targets created outside the current directory. See policy "CMP0079". Variables --------- * A "CMAKE_AUTOGEN_VERBOSE" variable was added to optionally increase the verbosity of "AUTOMOC", "AUTOUIC" and "AUTORCC" from within CMake project code. * A "CMAKE_VS_GLOBALS" variable was added to initialize "VS_GLOBAL_" target properties on targets as they are created. Properties ---------- * The "DEPLOYMENT_ADDITIONAL_FILES" target property was added to tell the "Visual Studio 9 2008" generator to specify additional files for deployment to WinCE devices for remote debugging. * The "INTERFACE_LINK_DEPENDS" target property was created to specify transitive link dependencies on files. * The "LINK_DEPENDS" target property learned to support "generator expressions". * "LINK_DIRECTORIES" and "INTERFACE_LINK_DIRECTORIES" target properties were added to collect link directories for a target and its dependents. Use the "target_link_directories()" command to set them. * "LINK_OPTIONS" and "INTERFACE_LINK_OPTIONS" target properties were added to collect link options for a target and its dependents. Use the "target_link_options()" command to set them. * A "LINK_OPTIONS" directory property was added to collect link options for targets created under the current directory. Use the "add_link_options()" command to set it. * A "STATIC_LIBRARY_OPTIONS" target property was created to specify archiver options to use when creating static libraries. * A "VS_DEBUGGER_COMMAND_ARGUMENTS" target property was created to set the debugging command line arguments with Visual Studio Generators for VS 2010 and above. * A "VS_DEBUGGER_ENVIRONMENT" target property was created to set the debugging environment with Visual Studio Generators for VS 2010 and above. * The "VS_DEBUGGER_COMMAND" and "VS_DEBUGGER_WORKING_DIRECTORY" target properties now support generator expressions. Modules ------- * The "FindBoost" module gained a "Boost_ARCHITECTURE" option to specify a Boost architecture-specific library filename fragment. * The "FindCURL" module learned to find debug and release variants separately. * The "FindMatlab" module gained new components "ENGINE_LIBRARY" and "DATAARRAY_LIBRARY" to request finding the Matlab C++ Engine and DataArray libraries respectively. * The "FindMatlab" module now explicitly exports mexFunction in Visual Studio. * The "FindMatlab" module gained a new "MCC_COMPILER" component to request finding the Matlab Compiler add-on. * The "FindPkgConfig" module gained an option to create imported targets in global scope. * The "FindPkgConfig" module gained support for "<" and ">" operators for version checks in addition to the already supported operators ">=", "<=", and "=". * Modules "FindPython3", "FindPython2" and "FindPython" gain capability to control order of resource lookup on macOS (Framework) and Windows (Registry). * The "FindSubversion" module "Subversion_WC_INFO" command gained an "IGNORE_SVN_FAILURE" option to suppress failures, e.g. when the source tree is not under Subversion control. * The "UseSWIG" module learned to manage target property "INCLUDE_DIRECTORIES" for "SWIG" compilation. CTest ----- * "ctest(1)" gained a "--progress" option to enable a live test progress summary when output goes to a terminal. CPack ----- * The "CPack DEB Generator" learned to split debug symbols into a corresponding .ddeb package when "CPACK_DEBIAN_DEBUGINFO_PACKAGE" is set. * The "CPack DEB Generator" learned to honor the "SOURCE_DATE_EPOCH" environment variable when packaging files. This is useful for generating reproducible packages. * CPack gained a new "CPack External Generator" which is used to export the CPack metadata in a format that other software can understand. The intention of this generator is to allow external packaging software to take advantage of CPack's features when it may not be possible to use CPack for the entire packaging process. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policies "CMP0055" through "CMP0063" ("CMP0054" and below were already deprecated). The "cmake-policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors. Other Changes ============= * The precompiled binaries provided on "cmake.org" now include qthelp- format documentation. * The "option()" command now honors an existing normal variable of the same name and does nothing instead of possibly creating a cache entry (or setting its type) and removing the normal variable. See policy "CMP0077". * The Makefile Generators learned to remove custom command and custom target byproducts during "make clean". * The "target_sources()" command now interprets relative source file paths as relative to the current source directory. This simplifies incrementally building up a target's sources from subdirectories. The "CMP0076" policy was added to provide backward compatibility with the old behavior where required. * The "BundleUtilities" module may no longer be included at configure time. This was always a bug anyway. See policy "CMP0080". * The "UseSWIG" module has changed strategy for target naming. See policy "CMP0078". * The "LINK_DIRECTORIES" target property now expects absolute paths. See policy "CMP0081". * The CPack generators have been moved into their own separate section in the documentation, rather than having the documentation in their internal implementation modules. These internal implementation modules are also no longer available to scripts that may have been incorrectly including them, because they should never have been available in the first place. ---------------------------------------------------------------------------- Changes made since CMake 3.13.0-rc3: Brad King (5): ASM: Detect compiler id for Clang used as Assembler Tests: Teach RunCMake infrastructure to optionally provide stdin CTest: Restore inheritance of stdin by test processes IRSL: Detect versioned Windows Universal CRT directories CMake 3.13.0 Felix Geyer (1): FindBoost: Add system thread library to Boost_LIBRARIES Frank Benkstein (1): configure_file: canonicalize input and output path in dependencies Marc Chevrier (1): FindPython: Ensure config tool matches library architecture Martin von Gagern (1): FindBLAS: Restore BLAS_FOUND when found using pkgconfig Mateusz ?oskot (1): FindBoost: Improve compiler prefix detection for GCC 5+ and clang 4+ Roger Leigh (1): FindBoost: Additional fixes for 1.69 From brad.king at kitware.com Tue Nov 20 14:44:09 2018 From: brad.king at kitware.com (Brad King) Date: Tue, 20 Nov 2018 14:44:09 -0500 Subject: [cmake-developers] ENV{SOURCE_DATE_EPOCH} In-Reply-To: <6aab98d6-d9d1-f328-51bd-fc44a71b64f8@kaa.org.ua> References: <6aab98d6-d9d1-f328-51bd-fc44a71b64f8@kaa.org.ua> Message-ID: On 11/20/18 10:51 AM, Oleh Kravchenko wrote: > CMake should pass this variable to build tool (GNU Make, Ninja, ...). CMake doesn't invoke the build tool to build the project. The workflow is "run cmake, then run make". With the Makefile and Ninja generators it is up to the user to provide the environment for the toolchain to operate as desired. -Brad From oleg at kaa.org.ua Tue Nov 20 15:26:40 2018 From: oleg at kaa.org.ua (Oleh Kravchenko) Date: Tue, 20 Nov 2018 22:26:40 +0200 Subject: [cmake-developers] ENV{SOURCE_DATE_EPOCH} In-Reply-To: References: <6aab98d6-d9d1-f328-51bd-fc44a71b64f8@kaa.org.ua> Message-ID: Hello Brad, CFLAGS, CXXFLAGS and LDFLAGS is a part of toolchain, but suddenly CMake handle it and pass to the build tools.. Double standards? 20.11.18 21:44, Brad King wrote: > On 11/20/18 10:51 AM, Oleh Kravchenko wrote: >> CMake should pass this variable to build tool (GNU Make, Ninja, ...). > > CMake doesn't invoke the build tool to build the project. > The workflow is "run cmake, then run make". > > With the Makefile and Ninja generators it is up to the user to > provide the environment for the toolchain to operate as desired. > > -Brad > -- Best regards, Oleh Kravchenko From brad.king at kitware.com Tue Nov 20 15:59:57 2018 From: brad.king at kitware.com (Brad King) Date: Tue, 20 Nov 2018 15:59:57 -0500 Subject: [cmake-developers] ENV{SOURCE_DATE_EPOCH} In-Reply-To: References: <6aab98d6-d9d1-f328-51bd-fc44a71b64f8@kaa.org.ua> Message-ID: On 11/20/18 3:26 PM, Oleh Kravchenko wrote: > CFLAGS, CXXFLAGS and LDFLAGS is a part of toolchain, > but suddenly CMake handle it and pass to the build tools.. No, those are interpreted by the buildsystem and converted into flags passed to the compiler. Running env CFLAGS=-DFOO cc foo.c does not use those flags to compile `foo.c`. `SOURCE_DATE_EPOCH` is directly interpreted by the compiler. -Brad From oleg at kaa.org.ua Tue Nov 20 16:13:56 2018 From: oleg at kaa.org.ua (Oleh Kravchenko) Date: Tue, 20 Nov 2018 23:13:56 +0200 Subject: [cmake-developers] ENV{SOURCE_DATE_EPOCH} In-Reply-To: References: <6aab98d6-d9d1-f328-51bd-fc44a71b64f8@kaa.org.ua> Message-ID: So what you will advice? I don't like idea to cover "cmake && make" with special bash script, just to export SOURCE_DATE_EPOCH. 20.11.18 22:59, Brad King wrote: > On 11/20/18 3:26 PM, Oleh Kravchenko wrote: >> CFLAGS, CXXFLAGS and LDFLAGS is a part of toolchain, >> but suddenly CMake handle it and pass to the build tools.. > > No, those are interpreted by the buildsystem and converted > into flags passed to the compiler. Running > > env CFLAGS=-DFOO cc foo.c > > does not use those flags to compile `foo.c`. > > `SOURCE_DATE_EPOCH` is directly interpreted by the compiler. > > -Brad > -- Best regards, Oleh Kravchenko From brad.king at kitware.com Tue Nov 20 16:29:41 2018 From: brad.king at kitware.com (Brad King) Date: Tue, 20 Nov 2018 16:29:41 -0500 Subject: [cmake-developers] ENV{SOURCE_DATE_EPOCH} In-Reply-To: References: <6aab98d6-d9d1-f328-51bd-fc44a71b64f8@kaa.org.ua> Message-ID: <47aa1cb2-9d7b-f673-1448-ad520d10bebe@kitware.com> On 11/20/18 4:13 PM, Oleh Kravchenko wrote: > I don't like idea to cover "cmake && make" with special bash script, > just to export SOURCE_DATE_EPOCH. SOURCE_DATE_EPOCH was created for use by packagers where tools already wrap the build. By making it an environment variable packagers could jump through any number of build system layers with no patching. Build systems configure compilers with command-line flags, not environment variables. If you want to do this from within the build system then GCC could be taught a new option for that. You could try hacking it with `CMAKE__COMPILER_LAUNCHER`: https://cmake.org/cmake/help/v3.13/variable/CMAKE_LANG_COMPILER_LAUNCHER.html e.g. -DCMAKE_C_COMPILER_LAUNCHER='env;SOURCE_DATE_EPOCH=1' or ```cmake set(CMAKE_C_COMPILER_LAUNCHER env SOURCE_DATE_EPOCH=1) ``` -Brad From oleg at kaa.org.ua Tue Nov 20 16:40:24 2018 From: oleg at kaa.org.ua (Oleh Kravchenko) Date: Tue, 20 Nov 2018 23:40:24 +0200 Subject: [cmake-developers] ENV{SOURCE_DATE_EPOCH} In-Reply-To: <47aa1cb2-9d7b-f673-1448-ad520d10bebe@kitware.com> References: <6aab98d6-d9d1-f328-51bd-fc44a71b64f8@kaa.org.ua> <47aa1cb2-9d7b-f673-1448-ad520d10bebe@kitware.com> Message-ID: <8314a365-2c96-0e64-583d-eb14bdc9883f@kaa.org.ua> 20.11.18 23:29, Brad King wrote: > SOURCE_DATE_EPOCH was created for use by packagers where tools > already wrap the build. By making it an environment variable > packagers could jump through any number of build system layers > with no patching. That's makes me confused, because CMake has CPack. And with CPack process looks like: - `cmake && make package` So there are no any packagers tools, all work done with CMake. > Build systems configure compilers with command-line flags, not > environment variables. If you want to do this from within the > build system then GCC could be taught a new option for that. > > You could try hacking it with `CMAKE__COMPILER_LAUNCHER`: > > https://cmake.org/cmake/help/v3.13/variable/CMAKE_LANG_COMPILER_LAUNCHER.html > > e.g. -DCMAKE_C_COMPILER_LAUNCHER='env;SOURCE_DATE_EPOCH=1' or > > ```cmake > set(CMAKE_C_COMPILER_LAUNCHER env SOURCE_DATE_EPOCH=1) > ``` Thank you, I will try that. -- Best regards, Oleh Kravchenko From eric.noulard at gmail.com Wed Nov 21 03:32:47 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 21 Nov 2018 09:32:47 +0100 Subject: [cmake-developers] ENV{SOURCE_DATE_EPOCH} In-Reply-To: <8314a365-2c96-0e64-583d-eb14bdc9883f@kaa.org.ua> References: <6aab98d6-d9d1-f328-51bd-fc44a71b64f8@kaa.org.ua> <47aa1cb2-9d7b-f673-1448-ad520d10bebe@kitware.com> <8314a365-2c96-0e64-583d-eb14bdc9883f@kaa.org.ua> Message-ID: Le mar. 20 nov. 2018 ? 22:40, Oleh Kravchenko a ?crit : > 20.11.18 23:29, Brad King wrote: > > SOURCE_DATE_EPOCH was created for use by packagers where tools > > already wrap the build. By making it an environment variable > > packagers could jump through any number of build system layers > > with no patching. > > That's makes me confused, because CMake has CPack. > And with CPack process looks like: > - `cmake && make package` > So there are no any packagers tools, all work done with CMake. > The package tool here is CPack. You consider CMake and CPack as monolithic software they were not designed this way (and I personally find it nice to be so). CMake and CPack (or CTest) may work together but they may well be used independently. Moreover they do not run at the same time, have a look at the figure here: https://github.com/dev-cafe/cmake-cookbook/blob/master/figures/cmake-times/cmake-times.jpg And you may see that setting environment var at configure time is relatively far away from packaging time. All that saif you are right CPack may honor SOURCE_DATE_EPOCH, and CMake "may" forward the usage of SOURCE_DATE_EPOCH from configuration time down to CPack time. At least one CPack generator (the DEB one) recently honor SOURCE_DATE_EPOCH https://gitlab.kitware.com/cmake/cmake/commit/548ac51d8ea319c65abefa0a771636893c45014c If you use a https://cmake.org/cmake/help/v3.12/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE for your project you may easily set the SOURCE_DATE_EPOCH env var at CPack time, i.e. when CPack runs. > > Build systems configure compilers with command-line flags, not > > environment variables. If you want to do this from within the > > build system then GCC could be taught a new option for that. > Apparently gcc team decided to use env var for that: https://gcc.gnu.org/onlinedocs/cpp/Environment-Variables.html see associated discussion (I did not read it all): https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02210.html llvm/clang discussion on this does not seem to be closed: https://reviews.llvm.org/D23934 > > > > You could try hacking it with `CMAKE__COMPILER_LAUNCHER`: > > > > > https://cmake.org/cmake/help/v3.13/variable/CMAKE_LANG_COMPILER_LAUNCHER.html > > > > e.g. -DCMAKE_C_COMPILER_LAUNCHER='env;SOURCE_DATE_EPOCH=1' or > > > > ```cmake > > set(CMAKE_C_COMPILER_LAUNCHER env SOURCE_DATE_EPOCH=1) > > ``` > > Thank you, I will try that. > AFAIU this should already work with gcc. I discovered https://reproducible-builds.org/, while reading your question. The goal is nice, and I think CMake/CPack should support that for compiler/[package] build tools that support it. I won't have time to work on patches for that but I'll certainly take time to read/test one if someone is working on it. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Tue Nov 27 05:28:02 2018 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 27 Nov 2018 11:28:02 +0100 Subject: [cmake-developers] [CMake] dependencies of cross compiliations In-Reply-To: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> Message-ID: Am 2018-11-09 10:04, schrieb Torsten Robitzki: > Hi, > I hope this question was not asked before. I work in the embedded > field and there it is usually to have at least two different build > platforms. The Host platform, where unit tests are build (and where > CMake is running) and an embedded Target platform, where targets are > build with a cross compiler. Sometimes such a system comes with > self-written tools that are build and run on the Host platform to > build a target for the embedded Target platform (adding meta data to a > binary to be used by a bootloader for example). > > Usually I have two different build folders, one for the Host platform > and one for the Target platform, using different calls to cmake to > choose from a set of tools and targets. But when using this approach, > it is necessary that the Host platform build ran before the Target > platform build, so that tools that are required for the Target > platform are build during the Host target build. > > One solution I?ve came up with, is to build the required tools during > the Target platform build, using an add_custom_target() to invoke the > Target compiler directly. This works fine, as long as the tools are > basically build just out of a couple of files. > > What would be the ?CMake-Way? to add the tools (that have to be build > on the Target platform) as dependency to targets that have to be build > for the Target (cross compile) platform? TL;DR: there is not "good" way yet. But there should be one. I'm hijacking this and move it to the developers list, because that is something "big", and we need to think about how to do that. I find it important to correctly solve this as it would simplify a lot of things. Especially given that Qt is thinking to use CMake to build Qt itself, which I bet all of us would love to see. But they will be after us if we don't offer a solution for this. And given the increasing amount of cross-setups these days I'm sure that a lot of other people would benefit. My first idea was to have something like add_host_executable(), which would only be called when this is not CMAKE_CROSSCOMPILING, but at the end I think this clutters things too much. Then I came up with: add_host_build("relative source dir" "build dir" [VARS]) This would create an entirely new CMake scope (with it's own CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir", and would not take the CMAKE_TOOLCHAIN_FILE into account. People are free to pass "." as relative source dir in case they want to start at top level, but they may as well pass "tools", "generators" or whatever they call it. This is not intended to be called multiple times from the same project as it would scan for compiler and environment once for every call, but doing so does no harm beyond being slow(er) and the targets of one such sub-build not being visible to the others. My idea would be that things added by add_executable() inside such a sub-build are visible as targets from the outer build. Other things like libraries and the like need not to be, they can't be linked in the outer world. The user is free to build with shared libs inside, and running the things from the build tree would result in the correct freshly build libs being picked up because of RPATH or whatever. There is no install of those targets possible from the outer build, this can entirely be managed from the host build. Of course one must be possible to set variables on the host build, that's where VARS comes into play. This holds a list of variable names that will be passed to the hostbuild. No values, to avoid all sorts of quoting issues. Helpful would be a special variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and a non-sysroot thing prefix in the toolchain file). Confused? Granted, here is an example: if (CMAKE_CROSSCOMPILING) set(HOST_INSTALL_DIR "/some/where") add_host_build(. host HOST_INSTALL_DIR) endif () add_executable(magic magic.cpp) install(TARGETS magic DESTINATION bin) # installs both the host and the target tool! add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND magic) # will call the host build if (NOT CMAKE_HOST_BUILD) add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp) install(TARGETS foo DESTINATION bin) endif () This should end up in a layout like this: /tmp/install/prefix/tools/bin/magic.exe # Windows host /tmp/install/prefix/sysroot/usr/bin/magic # Unix guest /tmp/install/prefix/sysroot/usr/bin/foo The toolchain file would look somehow like this: set(CMAKE_HOST_PREFIX prefix set(CMAKE_SYSROOT ${CMAKE_HOST_PREFIX}/sysroot) and the CMake command would look like this: cmake -D CMAKE_TOOLCHAIN_FILE=tc.cmake -D CMAKE_INSTALL_PREFIX=/usr -D CMAKE_HOST_INSTALL_PREFIX=tools ... The wish-season is coming up, so that's sort of what I would like to have. Now it's your turn. No bikeshedding please, only deliveries ;) Eike -- From mingw.android at gmail.com Tue Nov 27 05:36:51 2018 From: mingw.android at gmail.com (Ray Donnelly) Date: Tue, 27 Nov 2018 10:36:51 +0000 Subject: [cmake-developers] [CMake] dependencies of cross compiliations In-Reply-To: References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> Message-ID: > which I bet all of us would love to see. This is not correct. I would strongly prefer they continue with QBS instead. Cmake is defacto, but very suboptional. On Tue, Nov 27, 2018, 10:28 AM Rolf Eike Beer Am 2018-11-09 10:04, schrieb Torsten Robitzki: > > Hi, > > I hope this question was not asked before. I work in the embedded > > field and there it is usually to have at least two different build > > platforms. The Host platform, where unit tests are build (and where > > CMake is running) and an embedded Target platform, where targets are > > build with a cross compiler. Sometimes such a system comes with > > self-written tools that are build and run on the Host platform to > > build a target for the embedded Target platform (adding meta data to a > > binary to be used by a bootloader for example). > > > > Usually I have two different build folders, one for the Host platform > > and one for the Target platform, using different calls to cmake to > > choose from a set of tools and targets. But when using this approach, > > it is necessary that the Host platform build ran before the Target > > platform build, so that tools that are required for the Target > > platform are build during the Host target build. > > > > One solution I?ve came up with, is to build the required tools during > > the Target platform build, using an add_custom_target() to invoke the > > Target compiler directly. This works fine, as long as the tools are > > basically build just out of a couple of files. > > > > What would be the ?CMake-Way? to add the tools (that have to be build > > on the Target platform) as dependency to targets that have to be build > > for the Target (cross compile) platform? > > TL;DR: there is not "good" way yet. But there should be one. > > I'm hijacking this and move it to the developers list, because that is > something "big", and we need to think about how to do that. I find it > important to correctly solve this as it would simplify a lot of things. > Especially given that Qt is thinking to use CMake to build Qt itself, > which I bet all of us would love to see. But they will be after us if we > don't offer a solution for this. And given the increasing amount of > cross-setups these days I'm sure that a lot of other people would > benefit. > > My first idea was to have something like add_host_executable(), which > would only be called when this is not CMAKE_CROSSCOMPILING, but at the > end I think this clutters things too much. > > Then I came up with: > > add_host_build("relative source dir" "build dir" [VARS]) > > This would create an entirely new CMake scope (with it's own > CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir", > and would not take the CMAKE_TOOLCHAIN_FILE into account. People are > free to pass "." as relative source dir in case they want to start at > top level, but they may as well pass "tools", "generators" or whatever > they call it. This is not intended to be called multiple times from the > same project as it would scan for compiler and environment once for > every call, but doing so does no harm beyond being slow(er) and the > targets of one such sub-build not being visible to the others. > > My idea would be that things added by add_executable() inside such a > sub-build are visible as targets from the outer build. Other things like > libraries and the like need not to be, they can't be linked in the outer > world. The user is free to build with shared libs inside, and running > the things from the build tree would result in the correct freshly build > libs being picked up because of RPATH or whatever. There is no install > of those targets possible from the outer build, this can entirely be > managed from the host build. Of course one must be possible to set > variables on the host build, that's where VARS comes into play. This > holds a list of variable names that will be passed to the hostbuild. No > values, to avoid all sorts of quoting issues. Helpful would be a special > variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and > a non-sysroot thing prefix in the toolchain file). Confused? Granted, > here is an example: > > if (CMAKE_CROSSCOMPILING) > set(HOST_INSTALL_DIR "/some/where") > add_host_build(. host HOST_INSTALL_DIR) > endif () > add_executable(magic magic.cpp) > install(TARGETS magic DESTINATION bin) # installs both the host and the > target tool! > add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND > magic) # will call the host build > if (NOT CMAKE_HOST_BUILD) > add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp) > install(TARGETS foo DESTINATION bin) > endif () > > This should end up in a layout like this: > > /tmp/install/prefix/tools/bin/magic.exe # Windows host > /tmp/install/prefix/sysroot/usr/bin/magic # Unix guest > /tmp/install/prefix/sysroot/usr/bin/foo > > The toolchain file would look somehow like this: > > set(CMAKE_HOST_PREFIX prefix > set(CMAKE_SYSROOT ${CMAKE_HOST_PREFIX}/sysroot) > > and the CMake command would look like this: > > cmake -D CMAKE_TOOLCHAIN_FILE=tc.cmake -D CMAKE_INSTALL_PREFIX=/usr -D > CMAKE_HOST_INSTALL_PREFIX=tools ... > > The wish-season is coming up, so that's sort of what I would like to > have. Now it's your turn. No bikeshedding please, only deliveries ;) > > Eike > -- > -- > > 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: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanmichael.celerier at gmail.com Tue Nov 27 06:55:57 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean-Micha=c3=abl_Celerier?=) Date: Tue, 27 Nov 2018 12:55:57 +0100 Subject: [cmake-developers] [CMake] dependencies of cross compiliations In-Reply-To: References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> Message-ID: On 27/11/2018 11:36, Ray Donnelly wrote: > Cmake is defacto, but very suboptional. (I suppose you meant suboptimal). well yes, that's why people like Eike are trying to do stuff to improve it. QBS is also fairly suboptimal in my opinion even if the language is cleaner - had my share of bugs (sometimes meaning that I couldn't run a build at all) with some projects using it (namely OpenFrameworks) and ended up using CMake ports which were much more reliable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Nov 27 07:01:36 2018 From: brad.king at kitware.com (Brad King) Date: Tue, 27 Nov 2018 07:01:36 -0500 Subject: [cmake-developers] [CMake] building host tools during cross compiliations (was: dependencies of cross compiliations) In-Reply-To: References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> Message-ID: On 11/27/18 5:28 AM, Rolf Eike Beer wrote: > Then I came up with: > > add_host_build("relative source dir" "build dir" [VARS]) > > This would create an entirely new CMake scope (with it's own > CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir", > and would not take the CMAKE_TOOLCHAIN_FILE into account. [snip] > My idea would be that things added by add_executable() inside such a > sub-build are visible as targets from the outer build. For reference, some projects are already using the ExternalProject module to approximate that approach and bring in the host tools as imported executable targets. The actual host build is viewed as a custom target from the cross-compiled project. -Brad From eric.noulard at gmail.com Tue Nov 27 13:55:56 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 27 Nov 2018 19:55:56 +0100 Subject: [cmake-developers] [CMake] dependencies of cross compiliations In-Reply-To: References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> Message-ID: Le mar. 27 nov. 2018 ? 11:28, Rolf Eike Beer a ?crit : > Am 2018-11-09 10:04, schrieb Torsten Robitzki: > > Hi, > > I hope this question was not asked before. I work in the embedded > > field and there it is usually to have at least two different build > > platforms. The Host platform, where unit tests are build (and where > > CMake is running) and an embedded Target platform, where targets are > > build with a cross compiler. Sometimes such a system comes with > > self-written tools that are build and run on the Host platform to > > build a target for the embedded Target platform (adding meta data to a > > binary to be used by a bootloader for example). > > > > Usually I have two different build folders, one for the Host platform > > and one for the Target platform, using different calls to cmake to > > choose from a set of tools and targets. But when using this approach, > > it is necessary that the Host platform build ran before the Target > > platform build, so that tools that are required for the Target > > platform are build during the Host target build. > > > > One solution I?ve came up with, is to build the required tools during > > the Target platform build, using an add_custom_target() to invoke the > > Target compiler directly. This works fine, as long as the tools are > > basically build just out of a couple of files. > > > > What would be the ?CMake-Way? to add the tools (that have to be build > > on the Target platform) as dependency to targets that have to be build > > for the Target (cross compile) platform? > > TL;DR: there is not "good" way yet. But there should be one. > > I do agree with that quote I was quite surprised (a long time ago) that CMake did not support cross-compiling. Back then I was using recursive hand-written makefiles for cross-compiling. When I wanted to build the whole thing I only had to hit "make" and wait. Moreover I think CMake cross-compiling support was biased by the fact CMake wasn't designed for that initially. Please don't take my remark as bare criticism I am using CMake for a long time now, I do like CMake very much and I was pleased to see the cross-compiling support coming. However from my point of view and my cross-compiling experience when you cross-compile you have: 1) the host compiler which is used to compile "host tools" 2) the target compiler (may be several of them) to "cross-compile" My assumption are: a) when you cross-compile your build is a "whole" and you shouldn't have to setup some superbuild structure for building host tools ht_exe and another for target1 tool t1t_exe and another one for target2 tool t2t_exe. b) what you want is to build: ht_exe for the host possibly use ht_exe during the build to generate some [source] file t1t_exe for the [cross]target1 t2t_exe for the [cross]target2 c) you seldomly compile the same source for the host AND the target, but it may happen. And you want to build all that stuff with a single configure+build command AND take advantage of fast and efficient parallel build for the **whole build**. I don't want to cd /build/for/host ninja cd /build/for/target1 ninja etc... > Helpful would be a special > variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and > a non-sysroot thing prefix in the toolchain file). Confused? Granted, > here is an example: > > if (CMAKE_CROSSCOMPILING) > set(HOST_INSTALL_DIR "/some/where") > add_host_build(. host HOST_INSTALL_DIR) > endif () > add_executable(magic magic.cpp) > install(TARGETS magic DESTINATION bin) # installs both the host and the > target tool! > add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND > magic) # will call the host build > if (NOT CMAKE_HOST_BUILD) > add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp) > install(TARGETS foo DESTINATION bin) > endif () > I get your point but I think we may try a more declarative way. add_executable(magic magic.cpp) install(TARGETS magic DESTINATION bin) add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND magic) add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp) install(TARGETS foo DESTINATION bin) set_target_properties(magic PROPERTIES BUILD_TARGET "host;cross_target1") set_target_properties(foo PROPERTIES BUILD_TARGET "cross_target1") after that we know that `magic` is to be built both for "host" and "cross_target1" whereas `foo` is only for "cross_target1". before that we may have to "declaratively" define what is cross_target1 (and may be cross_target2) with something like: enable_cross_target(NAME cross_target1 TOOLCHAIN ${CMAKE_CURRENT_SOURCE _DIR}/cmake/target1-toolchain.cmake) enable_cross_target(NAME cross_target2 TOOLCHAIN ${CMAKE_CURRENT_SOURCE _DIR}/cmake/target2-toolchain.cmake) and assume "host" builtin target is the one coming from the command line. each define_cross_target(..) will create a separate subdir in the build tree (much like CMAKE_CFG_INTDIR is working for multi-config generators) may something like ${CMAKE_CURRENT_BINARY_DIR}/${CROSS_TARGET_NAME} if we assume cross target name are unique. all cmake command (install, add_executable, add_library, etc...) shall know that a target is to be build for the host and/or cross target1 and/or cross target2 etc... add_custom_command COMMAND argument refering to a built target always refer to "host target" because there is usually no need (or mean) to execute cross target during the build anyway. in the end you will have a project which specify all the target (exe, lib, custom) the usual declarative "modern CMake" way and you won't have your CMakeLists.txt filled with IF(CMAKE_CROSSCOMPILING) IF(NOT CMAKE_HOST_BUILD) controls. if you need cross_target specific CMAKE_XXXX variables, they should either go in the target toolchain file or should be put in with cross_target_set(cross_target1 VARIABLE CMAKE_INSTALL_PREFIX "/opt/target1") You may even decide that if a "build target" is not enabled because you have something like: if (CROSS_BUILD_TARGET1) enable_cross_target(NAME cross_target1 TOOLCHAIN ${CMAKE_CURRENT_SOURCE _DIR}/cmake/target1-toolchain.cmake) endif() if (CROSS_BUILD_TARGET2) enable_cross_target(NAME cross_target2 TOOLCHAIN ${CMAKE_CURRENT_SOURCE _DIR}/cmake/target2-toolchain.cmake) endif() The build could succeed and emit some warning telling that some "cross target" were not built. This should end up in a layout like this: > > /tmp/install/prefix/tools/bin/magic.exe # Windows host > /tmp/install/prefix/sysroot/usr/bin/magic # Unix guest > /tmp/install/prefix/sysroot/usr/bin/foo > > The toolchain file would look somehow like this: > > set(CMAKE_HOST_PREFIX prefix > set(CMAKE_SYSROOT ${CMAKE_HOST_PREFIX}/sysroot) > > and the CMake command would look like this: > > cmake -D CMAKE_TOOLCHAIN_FILE=tc.cmake -D CMAKE_INSTALL_PREFIX=/usr -D > CMAKE_HOST_INSTALL_PREFIX=tools ... > I think that most of the time specifying the toolchain on the command line drives you to some superbuild structure. > > The wish-season is coming up, so that's sort of what I would like to > have. Now it's your turn. No bikeshedding please, only deliveries ;) > I wish an integrated multi-target cross building support in CMake with little or no flow-control scripting command in the CMakeLists.txt. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Nov 28 09:09:49 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 28 Nov 2018 09:09:49 -0500 Subject: [cmake-developers] [ANNOUNCE] CMake 3.13.1 available for download Message-ID: We are pleased to announce that CMake 3.13.1 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.13.1 since 3.13.0: Brad King (3): Fortran: Fix module dependency scanning with upper-case SUBMODULE FindBoost: Restore finding without CXX language enabled CMake 3.13.1 Harry Mallon (1): VS: Avoid crash with VS 2015 when all SDKs are higher than 10.0.14393.0 Sebastian Holtermann (1): Autogen: Fix empty uic executable string From eike at sf-mail.de Wed Nov 28 15:02:52 2018 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 28 Nov 2018 21:02:52 +0100 Subject: [cmake-developers] [CMake] dependencies of cross compiliations In-Reply-To: References: <7D02012F-99E4-44DA-96E3-C6D0D1955FD3@Robitzki.de> Message-ID: <4054095.oukdIuTTYd@daneel.sf-tec.de> Am Dienstag, 27. November 2018, 19:55:56 CET schrieb Eric Noulard: > Le mar. 27 nov. 2018 ? 11:28, Rolf Eike Beer a ?crit : > > Am 2018-11-09 10:04, schrieb Torsten Robitzki: > > > Hi, > > > I hope this question was not asked before. I work in the embedded > > > field and there it is usually to have at least two different build > > > platforms. The Host platform, where unit tests are build (and where > > > CMake is running) and an embedded Target platform, where targets are > > > build with a cross compiler. Sometimes such a system comes with > > > self-written tools that are build and run on the Host platform to > > > build a target for the embedded Target platform (adding meta data to a > > > binary to be used by a bootloader for example). > > > > > > Usually I have two different build folders, one for the Host platform > > > and one for the Target platform, using different calls to cmake to > > > choose from a set of tools and targets. But when using this approach, > > > it is necessary that the Host platform build ran before the Target > > > platform build, so that tools that are required for the Target > > > platform are build during the Host target build. > > > > > > One solution I?ve came up with, is to build the required tools during > > > the Target platform build, using an add_custom_target() to invoke the > > > Target compiler directly. This works fine, as long as the tools are > > > basically build just out of a couple of files. > > > > > > What would be the ?CMake-Way? to add the tools (that have to be build > > > on the Target platform) as dependency to targets that have to be build > > > for the Target (cross compile) platform? > > > > TL;DR: there is not "good" way yet. But there should be one. > > I do agree with that quote I was quite surprised (a long time ago) that > CMake did not support cross-compiling. > Back then I was using recursive hand-written makefiles for cross-compiling. > When I wanted to build > the whole thing I only had to hit "make" and wait. > > Moreover I think CMake cross-compiling support was biased by the fact CMake > wasn't designed for that initially. > Please don't take my remark as bare criticism I am using CMake for a long > time now, I do like CMake very much > and I was pleased to see the cross-compiling support coming. > > However from my point of view and my cross-compiling experience when you > cross-compile you have: > > 1) the host compiler which is used to compile "host tools" > 2) the target compiler (may be several of them) to "cross-compile" > > My assumption are: > a) when you cross-compile your build is a "whole" and you shouldn't have > to setup some superbuild > structure for building host tools ht_exe and another for target1 tool > t1t_exe and another one for target2 tool t2t_exe. > > b) what you want is to build: > ht_exe for the host > possibly use ht_exe during the build to generate some [source] file > t1t_exe for the [cross]target1 > t2t_exe for the [cross]target2 > > c) you seldomly compile the same source for the host AND the target, but > it may happen. > > And you want to build all that stuff with a single configure+build command > AND take advantage > of fast and efficient parallel build for the **whole build**. I don't want > to > > cd /build/for/host > ninja > cd /build/for/target1 > ninja > etc... > > > Helpful would be a special > > > > variable for CMAKE_INSTALL_PREFIX as this needs a bit of attention (and > > a non-sysroot thing prefix in the toolchain file). Confused? Granted, > > here is an example: > > > > if (CMAKE_CROSSCOMPILING) > > > > set(HOST_INSTALL_DIR "/some/where") > > add_host_build(. host HOST_INSTALL_DIR) > > > > endif () > > add_executable(magic magic.cpp) > > install(TARGETS magic DESTINATION bin) # installs both the host and the > > target tool! > > add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND > > magic) # will call the host build > > if (NOT CMAKE_HOST_BUILD) > > > > add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp) > > install(TARGETS foo DESTINATION bin) > > > > endif () > > I get your point but I think we may try a more declarative way. > > add_executable(magic magic.cpp) > install(TARGETS magic DESTINATION bin) > add_custom_command(OUTPUT ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp COMMAND magic) > add_executable(foo ${CMAKE_CURRENT_BUILD_DIR}/foo.cpp) > install(TARGETS foo DESTINATION bin) > > set_target_properties(magic PROPERTIES BUILD_TARGET "host;cross_target1") > set_target_properties(foo PROPERTIES BUILD_TARGET "cross_target1") That makes sense in general. We would need generator expressions for those to be able to e.g. selectively include sources into one or the other build. > after that we know that `magic` is to be built both for "host" and > "cross_target1" whereas > `foo` is only for "cross_target1". > > before that we may have to "declaratively" define what is cross_target1 > (and may be cross_target2) with something like: > > enable_cross_target(NAME cross_target1 TOOLCHAIN ${CMAKE_CURRENT_SOURCE > _DIR}/cmake/target1-toolchain.cmake) > enable_cross_target(NAME cross_target2 TOOLCHAIN ${CMAKE_CURRENT_SOURCE > _DIR}/cmake/target2-toolchain.cmake) > and assume "host" builtin target is the one coming from the command line. > > each define_cross_target(..) will create a separate subdir in the build > tree (much like CMAKE_CFG_INTDIR is working for multi-config generators) > may something like ${CMAKE_CURRENT_BINARY_DIR}/${CROSS_TARGET_NAME} if we > assume cross target name are unique. That would mean we would need something like "-D CMAKE_TOOLCHAIN_FILES=foo.cmake,bar.cmake" to pass multiple of them. In general you invert what I have said, having the host directory on the outside. That makes sense if you have multiple cross-targets in the same build tree. But: I'm not sure I'm into this. It may make sense for some projects, but less for others, e.g. if the generators are target-specific. How do I tell CMake that this is not possible? I would go for the simple way and say: host tools are build with the target tools. If you have multiple targets, then you have multiple build dirs, the host tools are build multiple times. > all cmake command (install, add_executable, add_library, etc...) shall know > that a target is to be build for the host and/or cross target1 > and/or cross target2 etc... > > add_custom_command COMMAND argument refering to a built target > always refer to "host target" because there is usually no need (or mean) to > execute cross target during the build anyway. Yes. > in the end you will have a project which specify all the target (exe, lib, > custom) the usual declarative "modern CMake" way > and you won't have your CMakeLists.txt filled with > > IF(CMAKE_CROSSCOMPILING) > > IF(NOT CMAKE_HOST_BUILD) > > controls. We will need some of those at the end anyway. Let's stay with Qt: they need a host libpng to build some whatever helpers for QtWebEngine, as well as a target one. Both of course need to be kept separated, and one may acually decide to search for host dependencies with less flags, other versions or whatever. > if you need cross_target specific CMAKE_XXXX variables, they should either > go in the target toolchain file > or should be put in with > cross_target_set(cross_target1 VARIABLE CMAKE_INSTALL_PREFIX "/opt/target1") > > You may even decide that if a "build target" is not enabled because you > have something like: And here things are getting messy. If we stick with one-target-per-builddir as we already do for say 32 and 64 bit now the code will get cleaner. > I think that most of the time specifying the toolchain on the command line > drives you to some superbuild structure. Which is not bad by itself, but I would like to see that CMake can provide things that avoid people reinventing the boilerplate code, and probably getting them wrong at least 80% of the time. Like they would do with dependencies and other things if they would write their Makefiles by hand instead of using CMake, just one level higher. > > The wish-season is coming up, so that's sort of what I would like to > > have. Now it's your turn. No bikeshedding please, only deliveries ;) > > I wish an integrated multi-target cross building support in CMake with > little or no flow-control scripting command in the CMakeLists.txt. That would mean introducing HOST and TARGET flags to every find_* call, I'm not sure if that is cleaner than explicit if()'s. But I'm not fundamentally opposed to it, I'm just not sure it's worth the effort. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: