From brad.king at kitware.com Mon Oct 3 09:20:21 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 3 Oct 2016 09:20:21 -0400 Subject: [cmake-developers] CMake 3.7 feature freeze on 2016-10-03 In-Reply-To: <9542584c-07a6-39e9-02c6-f47387b66368@kitware.com> References: <69df6fcf-a372-a99b-ef07-bfbe05c0d0b8@kitware.com> <9542584c-07a6-39e9-02c6-f47387b66368@kitware.com> Message-ID: On 09/28/2016 04:33 PM, Brad King wrote: > After 3.7 is branched I'll announce when post-3.7 > development in 'next' is open. I've branched 'release' for 3.7. The repository is now open for post-3.7 development. Please rebase any open topics on 'master' before merging to 'next'. > * Documentation updates > * Regression fixes > * Fixes for bugs in features new to 3.7 These types of changes may still be accepted to 'release' during the 3.7 release candidate cycle. The 3.7 release is now closed to new features and general bug fixes. -Brad From cliffyapp at gmail.com Mon Oct 3 11:17:25 2016 From: cliffyapp at gmail.com (Clifford Yapp) Date: Mon, 3 Oct 2016 11:17:25 -0400 Subject: [cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test? Message-ID: One of the functions we are wrapping in our build with CMake's "_" prefix debugging mechanism is add_test. Looking at why we do that, it should be possible to avoid wrapping if we can get access in CMake to the list of all test build targets defined with add_test. Essentially, we need to add them to some custom target dependencies, and it should be OK to do that after all tests are added if we can get access to the list of targets within CMake. Is there a property somewhere that exposes this list? Thanks, CY From brad.king at kitware.com Mon Oct 3 11:21:39 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 3 Oct 2016 11:21:39 -0400 Subject: [cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test? In-Reply-To: References: Message-ID: <3fa5d815-3c6e-b2bf-7e11-d23e7f11ddff@kitware.com> On 10/03/2016 11:17 AM, Clifford Yapp wrote: > One of the functions we are wrapping in our build with CMake's "_" > prefix debugging mechanism is add_test. Looking at why we do that, it > should be possible to avoid wrapping if we can get access in CMake to > the list of all test build targets defined with add_test. > Essentially, we need to add them to some custom target dependencies, > and it should be OK to do that after all tests are added if we can get > access to the list of targets within CMake. > > Is there a property somewhere that exposes this list? I don't recall one off the top of my head. Even if there were, the `set_property(TEST ...)` only works on tests in the invoking directory. There is no global scope for test names. Some projects use a `myproj_add_test()` wrapper around their `add_test()` calls specifically to provide customizations. -Brad From cliffyapp at gmail.com Mon Oct 3 12:14:29 2016 From: cliffyapp at gmail.com (Clifford Yapp) Date: Mon, 3 Oct 2016 12:14:29 -0400 Subject: [cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test? In-Reply-To: <3fa5d815-3c6e-b2bf-7e11-d23e7f11ddff@kitware.com> References: <3fa5d815-3c6e-b2bf-7e11-d23e7f11ddff@kitware.com> Message-ID: On Mon, Oct 3, 2016 at 11:21 AM, Brad King wrote: > On 10/03/2016 11:17 AM, Clifford Yapp wrote: >> One of the functions we are wrapping in our build with CMake's "_" >> prefix debugging mechanism is add_test. Looking at why we do that, it >> should be possible to avoid wrapping if we can get access in CMake to >> the list of all test build targets defined with add_test. >> Essentially, we need to add them to some custom target dependencies, >> and it should be OK to do that after all tests are added if we can get >> access to the list of targets within CMake. >> >> Is there a property somewhere that exposes this list? > > I don't recall one off the top of my head. Even if there were, > the `set_property(TEST ...)` only works on tests in the invoking > directory. There is no global scope for test names. Hmm. OK, so what we need is not actually the test names themselves, but a list of the executables used to run tests that are also defined as build targets. So, for example, we have a test that is named bu_basename_usr that runs the executable test_bu_basename. What we actually need is for the build target test_bu_basename to be a dependency of the custom target "check". Then, when the custom target "check" executes, it will first make sure all of the text executables (and their dependencies) have been built. The list we need would thus be built up to contain all COMMAND arguments to add_test that are also build targets in CMake. Does that make sense? > Some projects use a `myproj_add_test()` wrapper around their > `add_test()` calls specifically to provide customizations. I suspect that would run into issues similar to those we're seeing now trying to pass empty strings from the wrapper to the children, unless perhaps a macro wrapper would work where a function wrapper would not...: https://gitlab.kitware.com/cmake/cmake/issues/16341 Cheers, CY From brad.king at kitware.com Mon Oct 3 14:25:29 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 3 Oct 2016 14:25:29 -0400 Subject: [cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test? In-Reply-To: References: <3fa5d815-3c6e-b2bf-7e11-d23e7f11ddff@kitware.com> Message-ID: On 10/03/2016 12:14 PM, Clifford Yapp wrote: > so what we need is not actually the test names themselves, > but a list of the executables used to run tests that are also defined > as build targets. [snip] > The list we need would thus be built up to contain all COMMAND > arguments to add_test that are also build targets in CMake. The list would also need to include targets mentioned in generator expressions such as `$`. This will almost certainly be better done as a CMake feature implemented in C++. This was actually an early design philosophy: do the hard stuff in C++ so that complex logic is not needed in CMake-language code. > dependency of the custom target "check". Then, when the custom target > "check" executes, it will first make sure all of the test executables > (and their dependencies) have been built. Why do you need a "check" target instead of the CMake-defined "test" target? One could teach cmGlobalGenerator::AddGlobalTarget_Test an option to add a dependency on the "all" target from "test". Most projects do not have so many non-test targets that they cannot afford to build "all" before testing. Alternatively the implementation could directly add dependencies on targets referenced by tests. That may be a bit trickier though. -Brad From cliffyapp at gmail.com Tue Oct 4 11:22:57 2016 From: cliffyapp at gmail.com (Clifford Yapp) Date: Tue, 4 Oct 2016 11:22:57 -0400 Subject: [cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test? In-Reply-To: References: <3fa5d815-3c6e-b2bf-7e11-d23e7f11ddff@kitware.com> Message-ID: On Mon, Oct 3, 2016 at 2:25 PM, Brad King wrote: > On 10/03/2016 12:14 PM, Clifford Yapp wrote: >> so what we need is not actually the test names themselves, >> but a list of the executables used to run tests that are also defined >> as build targets. > [snip] >> The list we need would thus be built up to contain all COMMAND >> arguments to add_test that are also build targets in CMake. > > The list would also need to include targets mentioned in generator > expressions such as `$`. This will almost certainly > be better done as a CMake feature implemented in C++. This was actually > an early design philosophy: do the hard stuff in C++ so that complex > logic is not needed in CMake-language code. Sounds like a plan. I must confess I'm not familiar with the use of generator expressions yet (we've been holding off requiring CMake 3, but I see Debian stable has now updated so it's probably time) but I'll start catching up on my homework since I think they'll be needed to "modernize" some of our features that are still using the LOCATION property. >> dependency of the custom target "check". Then, when the custom target >> "check" executes, it will first make sure all of the test executables >> (and their dependencies) have been built. > > Why do you need a "check" target instead of the CMake-defined "test" > target? Primarily because we have experimental CTest targets that are in various stages of development, and not ready for prime time. check is the target we use when the test is ready to be used as a determining factor in whether something has broken. > One could teach cmGlobalGenerator::AddGlobalTarget_Test an option to add > a dependency on the "all" target from "test". Most projects do not have > so many non-test targets that they cannot afford to build "all" before > testing. While we could "afford" to, we have quite a large number of doc targets (for example) that aren't needed for make test so it would be a noticeable increase. > Alternatively the implementation could directly add dependencies > on targets referenced by tests. That may be a bit trickier though. That would be ideal, if it can be done. Cheers, CY From robert.maynard at kitware.com Tue Oct 4 16:32:27 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 4 Oct 2016 16:32:27 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.7.0-rc1 now ready for testing! Message-ID: I am proud to announce the first CMake 3.7 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.7 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.7/release/3.7.html Some of the more significant changes in CMake 3.7 are: * CMake now supports Cross Compiling for Android with simple toolchain files. * The "Ninja" generator learned to conditionally support Fortran when using a "ninja" tool that has the necessary features. See generator documentation for details. * The "if()" command gained new boolean comparison operations "LESS_EQUAL", "GREATER_EQUAL", "STRLESS_EQUAL", "STRGREATER_EQUAL", "VERSION_LESS_EQUAL", and "VERSION_GREATER_EQUAL". * The "try_compile()" command source file signature now honors configuration-specific flags (e.g. "CMAKE__FLAGS_DEBUG") in the generated test project. Previously only the default such flags for the current toolchain were used. See policy "CMP0066". * "Toolchain files" may now set "CMAKE_EXE_LINKER_FLAGS_INIT", "CMAKE_SHARED_LINKER_FLAGS_INIT", and "CMAKE_MODULE_LINKER_FLAGS_INIT" variables to initialize the "CMAKE_EXE_LINKER_FLAGS", "CMAKE_SHARED_LINKER_FLAGS", and "CMAKE_MODULE_LINKER_FLAGS" cache entries the first time a language is enabled in a build tree. * CTest now supports test fixtures through the new "FIXTURES_SETUP", "FIXTURES_CLEANUP" and "FIXTURES_REQUIRED" test properties. When using regular expressions or "--rerun-failed" to limit the tests to be run, a fixture's setup and cleanup tests will automatically be added to the execution set if any test requires that fixture. * We no longer provide Linux i386 binaries for download from "cmake.org" for new versions of CMake. * Vim support files "cmake-indent.vim", "cmake-syntax.vim", and "cmake-help.vim" have been removed in favor of the files now provided from the vim-cmake-syntax project. * Support for building CMake itself with some compilers was dropped: * Visual Studio 7.1 and 2005 -- superseded by VS 2008 and above * MinGW.org mingw32 -- superseded by MSYS2 mingw32 and mingw64 CMake still supports generating build systems for other projects using these compilers. CMake 3.7 Release Notes *********************** Changes made since CMake 3.6 include the following. New Features ============ Platforms --------- * CMake now supports Cross Compiling for Android with simple toolchain files. * The Clang compiler is now supported on AIX. Generators ---------- * The "Ninja" generator learned to conditionally support Fortran when using a "ninja" tool that has the necessary features. See generator documentation for details. * The "Ninja" generator learned to produce phony targets of the form "sub/dir/{test,install,package}" to drive the build of a subdirectory installation, test or packaging target. This is equivalent to "cd sub/dir; make {test,install,package}" with Makefile Generators. * The "Visual Studio 15" generator was added. This is experimental and based on Preview 4 because this version of VS has not been released. * Visual Studio Generators for VS 2010 and above learned to place ".natvis" source files into VS project files properly. * The "Xcode" generator's rudimentary Swift language support learned to honor a new "CMAKE_Swift_LANGUAGE_VERSION" variable to tell Xcode what version of Swift is used by the source. * The "CodeLite" generator gained a new "CMAKE_CODELITE_USE_TARGETS" option to change project creation from projects to targets. Commands -------- * The "add_custom_command()" command gained a new "DEPFILE" option that works with the "Ninja" generator to provide implicit dependency information to the build tool. * The "cmake_parse_arguments()" command gained a new "PARSE_ARGV" mode to read arguments directly from "ARGC" and "ARGV#" variables inside a "function()" body. * The "export()" command gained an "ANDROID_MK" option to generate "Android.mk" files referencing CMake-built libraries as prebuilts for the Android NDK build system. * The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "HTTPHEADER " and "USERPWD :" options. * The "find_library()" and "find_package()" commands learned to search in "lib32/" directories when the build targets a 32-bit architecture. See the "FIND_LIBRARY_USE_LIB32_PATHS" global property. * The "find_package()" command gained the possibility of sorting compatible libraries by "NAME" or by "NATURAL" sorting by setting the two new variables "CMAKE_FIND_PACKAGE_SORT_ORDER" and "CMAKE_FIND_PACKAGE_SORT_DIRECTION". * The "if()" command gained new boolean comparison operations "LESS_EQUAL", "GREATER_EQUAL", "STRLESS_EQUAL", "STRGREATER_EQUAL", "VERSION_LESS_EQUAL", and "VERSION_GREATER_EQUAL". * The "install()" command gained an "EXPORT_ANDROID_MK" subcommand to install "Android.mk" files referencing installed libraries as prebuilts for the Android NDK build system. * The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained support for the "%a" and "%b" placeholders. These are the abbreviated weekday and month names. * The "try_compile()" command source file signature now honors configuration-specific flags (e.g. "CMAKE__FLAGS_DEBUG") in the generated test project. Previously only the default such flags for the current toolchain were used. See policy "CMP0066". Variables --------- * Variable "CMAKE_FIND_PACKAGE_SORT_ORDER" was added to control the sorting mode of the "find_package()" command. * Variable "CMAKE_FIND_PACKAGE_SORT_DIRECTION" was added to control the sorting direction the "find_package()" command. * "Toolchain files" may now set a "CMAKE__FLAGS_INIT" variable to initialize the "CMAKE__FLAGS" cache entry the first time a language is enabled in a build tree. * "Toolchain files" may now set "CMAKE_EXE_LINKER_FLAGS_INIT", "CMAKE_SHARED_LINKER_FLAGS_INIT", and "CMAKE_MODULE_LINKER_FLAGS_INIT" variables to initialize the "CMAKE_EXE_LINKER_FLAGS", "CMAKE_SHARED_LINKER_FLAGS", and "CMAKE_MODULE_LINKER_FLAGS" cache entries the first time a language is enabled in a build tree. Properties ---------- * On Apple platforms the "BUNDLE_EXTENSION" target property now also applies to Frameworks and App Bundles. * A "BINARY_DIR" directory property was added to get the absolute path to the binary directory corresponding to the source directory on which the property is read. * A "BUILDSYSTEM_TARGETS" directory property was added to get the list of logical buildsystem target names added by the project in a directory. * A "LINK_WHAT_YOU_USE" target property and supporting "CMAKE_LINK_WHAT_YOU_USE" variable were introduced to detect (on UNIX) shared libraries that are linked but not needed by running "ldd -r -u". * A "SOURCE_DIR" directory property was added to get the absolute path to the source directory associated with a directory. * A "SUBDIRECTORIES" directory property was added to get the list of subdirectories added by a project in a directory. * A "VS_SDK_REFERENCES" target property was added to tell Visual Studio Generators to reference the named SDKs. * A "VS_TOOL_OVERRIDE" source file property was created to tell Visual Studio Generators what tool to use for a source file. * The "WINDOWS_EXPORT_ALL_SYMBOLS" target property now applies to executable targets with the "ENABLE_EXPORTS" property set. * A "XCODE_FILE_ATTRIBUTES" source file property was added to tell the "Xcode" generator to generate custom content in the Xcode project attributes for the file. Modules ------- * An "AndroidTestUtilities" module was added to manage transfer of test data to an Android device. * The "CheckFortranSourceCompiles" module macro "CHECK_Fortran_SOURCE_COMPILES" gained a "SRC_EXT" option to specify a custom test Fortran source file extension. * The "ExternalProject" module gained "HTTP_USERNAME" and "HTTP_PASSWORD" options to set http download credentials. * The "ExternalProject" module gained a "HTTP_HEADER" option to add http download headers. * The "FindBISON" module "BISON_TARGET" macro learned a new "REPORT_FILE" option to specify the bison "--report-file=" option. * The "FindBZip2" module now provides imported targets. * A "FindICU" module was introduced to find the International Components for Unicode (ICU) libraries and programs. * The "FindMatlab" module learned to find a SIMULINK component. * The "FindOpenCL" module now provides imported targets. * The "FindOpenMP" module learned to detect the OpenMP version (specification date) from the compiler. * A "FindVulkan" module was added. * The "GenerateExportHeader" module learned a new "CUSTOM_CONTENT_FROM_VARIABLE" option to specify a variable containing custom content for inclusion in the generated header. * The "GNUInstallDirs" module gained a new "GNUInstallDirs_get_absolute_install_dir()" command. * The "UseJava" module gained APIs to "export" jar targets for use by external CMake projects. See the "install_jar_exports" and "export_jars" functions. CTest ----- * CTest now supports test fixtures through the new "FIXTURES_SETUP", "FIXTURES_CLEANUP" and "FIXTURES_REQUIRED" test properties. When using regular expressions or "--rerun-failed" to limit the tests to be run, a fixture's setup and cleanup tests will automatically be added to the execution set if any test requires that fixture. * The "ctest_configure()", "ctest_build()", "ctest_test()", "ctest_coverage()", and "ctest_upload()" commands gained a new "CAPTURE_CMAKE_ERROR" option to capture any errors that occur as the commands run into a variable and avoid affecting the return code of the "ctest(1)" process. CPack ----- * CPack gained a "productbuild" generator on OS X, configured by the "CPackProductBuild" module. * CPack gained a new "CPACK_PACKAGE_CHECKSUM" variable to enable generation of a checksum file for each package file. * The "CPackDeb" module learned to support long file names when archive format is set to GNU tar. See "CPACK_DEBIAN_ARCHIVE_TYPE" * The "CPackIFW" module gained a new "cpack_ifw_add_package_resources()" command to include additional resources in the installer binary. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "USER_INTERFACES" option to add a list of additonal pages to the IFW installer. * The "CPackRPM" module learned to generate debuginfo packages on demand. See "CPACK_RPM_DEBUGINFO_PACKAGE" and its per component version. * The "CPackRPM" module learned to generate source rpm (SRPM) packages on demand. See "CPACK_RPM_PACKAGE_SOURCES", "CPACK_RPM_SOURCE_PKG_BUILD_PARAMS" and "CPACK_RPM_SOURCE_PKG_PACKAGING_INSTALL_PREFIX". * The CPack NSIS generator now supports "CPACK_NSIS__INSTALL_DIRECTORY". This can be used to set component specific installation directories. * The CPack WIX generator now supports "CPACK_WIX_SKIP_PROGRAM_FOLDER" to allow specification of a custom absolute installation prefix outside of the ProgramFiles folders. * The CPack WIX generator now supports "CPACK_COMPONENT__DISABLED". This can be used to deselect a component from being installed by default. * The CPack WIX generator now supports "CPACK_WIX_PATCH_FILE" fragments for Feature elements. * The CPack WIX generator now supports "CPACK_WIX_ROOT_FEATURE_TITLE" and "CPACK_WIX_ROOT_FEATURE_DESCRIPTION" to allow the specification of a custom title and description for the root feature element. Other ----- * "cmake(1)" gained a "-E capabilities" option to provide a machine- readable (JSON) description of the capabilities of the cmake tool (available generators, etc.). * A new "cmake-server(7)" mode was added to provide semantic information about a CMake-generated buildsystem to clients through a JSON protocol. Currently all protocols are experimental and subject to change. * The "cmake(1)" command learned a "--trace-source=" option. * "ccmake(1)" learned to support vim-like navigation bindings. * "cmake-gui(1)" gained a button to open the generated project file for Visual Studio Generators and the "Xcode" generator. Deprecated and Removed Features =============================== * We no longer provide Linux i386 binaries for download from "cmake.org" for new versions of CMake. * Vim support files "cmake-indent.vim", "cmake-syntax.vim", and "cmake-help.vim" have been removed in favor of the files now provided from the vim-cmake-syntax project. * Support for building CMake itself with some compilers was dropped: * Visual Studio 7.1 and 2005 -- superseded by VS 2008 and above * MinGW.org mingw32 -- superseded by MSYS2 mingw32 and mingw64 CMake still supports generating build systems for other projects using these compilers. Other Changes ============= * The Fortran dependency scanner learned to support the syntax of Fortran Submodules. * Vim support files "indent/cmake.vim" and "syntax/cmake.vim" from the vim-cmake-syntax project are now distributed with CMake. From steveire at gmail.com Tue Oct 4 17:46:44 2016 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 04 Oct 2016 23:46:44 +0200 Subject: [cmake-developers] [ANNOUNCE] CMake 3.7.0-rc1 now ready for testing! References: Message-ID: Robert Maynard wrote: > * The "CodeLite" generator gained a new "CMAKE_CODELITE_USE_TARGETS" > option to change project creation from projects to targets. Something that I have often noticed (and which causes problems) in my refactoring is that per-directory variable definitions are used when they are not appropriate or intended. This causes problems because now the code has to read the value for each directory and can't assume that the value is always the same as the value from the top-level CMakeLists file. It adds complexity to the code which could otherwise be removed. In some cases (language-specific definitions) the definition may not be defined in the top level due to an enable_language() in a subdirectory. As far as I know, in other sibling directories the language can still be used, so the variable definitions are telling an inconsistent story in that case. Perhaps enable_language should only be allowed in the top-level. This CodeLite variable looks like an example of this misuse of variable definitions too. It is read via cmMakefile::IsOn. That means that different directories can set it to different values, which is probably not the intention of the author of the feature, and it means that that (probably broken) behavior needs to be preserved. Does CMake need a 'better answer' to the question of 'how to add features like this to CMake'? Is the answer 'Use global properties or a cache variable instead'? Thanks, Steve. From Tobias.Hunger at qt.io Tue Oct 4 05:20:03 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Tue, 4 Oct 2016 09:20:03 +0000 Subject: [cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test? In-Reply-To: References: <3fa5d815-3c6e-b2bf-7e11-d23e7f11ddff@kitware.com> Message-ID: <1475572801.779.3.camel@qt.io> On Mo, 2016-10-03 at 14:25 -0400, Brad King wrote: > > The list we need would thus be built up to contain all COMMAND > > arguments to add_test that are also build targets in CMake. > > The list would also need to include targets mentioned in generator > expressions such as `$`.??This will almost certainly > be better done as a CMake feature implemented in C++.??This was actually > an early design philosophy: do the hard stuff in C++ so that complex > logic is not needed in CMake-language code. Access to the list of defined tests would be nice to have in the server-mode, too:-) If some work is done in that direction, please keep server-mode in mind when designing the APIs. I would love to reuse them to expose that information to clients. Best Regards, Tobias -- Tobias Hunger,?Senior?Software Engineer?| The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Gesch?ftsf?hrer: Mika P?lsi, Juha Varelius,?Mika Harjuaho.?Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From raffi.enficiaud at mines-paris.org Wed Oct 5 03:00:09 2016 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Wed, 5 Oct 2016 09:00:09 +0200 Subject: [cmake-developers] [ANNOUNCE] CMake 3.7.0-rc1 now ready for testing! In-Reply-To: References: Message-ID: Le 04/10/16 ? 22:32, Robert Maynard a ?crit : > I am proud to announce the first CMake 3.7 release candidate. > https://cmake.org/download/ > > Documentation is available at: > https://cmake.org/cmake/help/v3.7 > > Release notes appear below and are also published at > https://cmake.org/cmake/help/v3.7/release/3.7.html > > [snip] > > > Modules > ------- > [snip] > * The "FindMatlab" module learned to find a SIMULINK component. Hi there, Please add the following to the changelog of the FindMatlab module: The FindMatlab module learned to find the SIMULINK and MAT components. The matlab_add_mex command can now add executable and module mex files, and matlab_add_unit_test can now run inline matlab test code. Thanks! Raffi From nilsgladitz at gmail.com Wed Oct 5 06:54:36 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 5 Oct 2016 12:54:36 +0200 Subject: [cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test? In-Reply-To: <1475572801.779.3.camel@qt.io> References: <3fa5d815-3c6e-b2bf-7e11-d23e7f11ddff@kitware.com> <1475572801.779.3.camel@qt.io> Message-ID: <8239086a-bd62-43e0-35a2-0ba9ef38da0a@gmail.com> On 04.10.2016 11:20, Tobias Hunger wrote: > On Mo, 2016-10-03 at 14:25 -0400, Brad King wrote: >>> The list we need would thus be built up to contain all COMMAND >>> arguments to add_test that are also build targets in CMake. >> The list would also need to include targets mentioned in generator >> expressions such as `$`. This will almost certainly >> be better done as a CMake feature implemented in C++. This was actually >> an early design philosophy: do the hard stuff in C++ so that complex >> logic is not needed in CMake-language code. > Access to the list of defined tests would be nice to have in the server-mode, > too:-) > > If some work is done in that direction, please keep server-mode in mind when > designing the APIs. I would love to reuse them to expose that information to > clients. This might be rare but the tests that cmake knows about might differ from the tests that ctest knows about given that tests can be dynamically defined through TEST_INCLUDE_FILE[1]. I've never used it that way but I was considering e.g. querying test binaries (produced at build time) for the tests they define and making those available dynamically when ctest processes CTestTestfile.cmake. This is in contrast to e.g. FindGTests.cmake's GTEST_ADD_TESTS() which tries to accomplish the same thing at configuration time by parsing test sources instead. [1] https://cmake.org/cmake/help/v3.6/prop_dir/TEST_INCLUDE_FILE.html Nils From brad.king at kitware.com Wed Oct 5 09:06:48 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 5 Oct 2016 09:06:48 -0400 Subject: [cmake-developers] Generator options per-directory v. global (was: CMake 3.7.0-rc1 now ready for testing!) In-Reply-To: References: Message-ID: <2f8545ce-bf04-97b9-7f9b-236325ce6635@kitware.com> On 10/04/2016 05:46 PM, Stephen Kelly wrote: > This causes problems because now the code has to read the value for each > directory and can't assume that the value is always the same as the value > from the top-level CMakeLists file. Many of these are honored only in the top-level directory anyway. Such cases could have documentation updated. Some of them may be per-`project()`. > Is the answer 'Use global properties or a cache variable instead'? The options need to be something easy for the project to set itself or for a user to set. A cache entry can work for that, but we don't really often read cache entries directly and instead read variables that fall back to cache entries if not defined. The scoping doesn't match the generator semantics exactly, but it is easy to use and hasn't been a big problem. -Brad From roman.wueger at gmx.at Wed Oct 5 14:56:26 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 5 Oct 2016 20:56:26 +0200 Subject: [cmake-developers] Problems with icons for Windows Store 10.0 Message-ID: <31D73EA9-838C-4959-80A0-47F89DE23DF3@gmx.at> Hello, I tried the following to copy the required app icons to the required destination: configure_file(Logo.png ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY) The CMake process itself overrides those files at the end with the files from the CMake's Template directory, which are empty. So, how could I use my icon files and/or what is the preferred way of doing this? Thanks in advance Best Regards Roman From brad.king at kitware.com Wed Oct 5 15:09:18 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 5 Oct 2016 15:09:18 -0400 Subject: [cmake-developers] Problems with icons for Windows Store 10.0 In-Reply-To: <31D73EA9-838C-4959-80A0-47F89DE23DF3@gmx.at> References: <31D73EA9-838C-4959-80A0-47F89DE23DF3@gmx.at> Message-ID: <9e890c5e-bc99-b862-dbc8-9f1ddf54520c@kitware.com> On 10/05/2016 02:56 PM, Roman W?ger wrote: > I tried the following to copy the required app icons to the required destination: > > configure_file(Logo.png ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY) That's a CMake-private directory whose location is an implementation detail. Some other interface for configuring this behavior will be needed. > The CMake process itself overrides those files at the end with the files from the > CMake's Template directory, which are empty. >From the current implementation it doesn't look like there is anyway to prevent that. We'll need to have some configuration of where it gets those files. > So, how could I use my icon files and/or what is the preferred way of doing this? Gilles? -Brad From foss at grueninger.de Wed Oct 5 17:35:01 2016 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Wed, 5 Oct 2016 23:35:01 +0200 Subject: [cmake-developers] Patch: Don't emit warning when config file not found In-Reply-To: <25936235-f6e3-2b0a-5e42-2e0ea92413f3@kitware.com> References: <5dfb692f-2d8b-fc2b-be9c-fddb09415857@grueninger.de> <25936235-f6e3-2b0a-5e42-2e0ea92413f3@kitware.com> Message-ID: Hi Brad, I am sorry, but I have to take up this subject again. I want to include Vc (sometimes called Vc-Devel) as an optional dependency. Vc provides a ConfigVc.cmake. 1. When I use "find_package(Vc)", many users get warnings that neither FindVc.cmake nor VcConfig.cmake is found. The warning looks scary and even distracts myself when I am scanning for relevant warning. It is an optional dependency, so a single line "Could NOT find Vc (FindVc.cmake or VcConfig.cmake not found)" would be enough. 2. When I use "find_package(Vc QUIET)", Vc does not show up in the feature summary. How can I achieve both without patching CMake? Bye Christoph Am 10.08.2016 um 15:17 schrieb Brad King: > On 08/09/2016 04:35 PM, Christoph Gr?ninger wrote: >> I am annoyed by the lengthy and disturbing warning CMake emits when a >> package is not found because neither a Find*.cmake file is found nor a >> *config.cmake file. I always try to have zero warnings, but missing >> dependencies is common. Emitting a warning is too much and too noisy in >> my opinion. >> >> Please find attached patch, which reduces the warning to a single line >> with the status that the package was not found. > > We went through many iterations on the wording of that message in > response to user feedback before settling on what is currently there. > When someone wants a package to be found they need a good explanation > when it is not and hints about how to resolve the problem. > > If a dependency is optional and it is not a problem to be missing > then the project can use the find_package QUIET option and then > optionally add its own message() about the missing package. > > -Brad > From gilles.khouzam at microsoft.com Wed Oct 5 15:19:45 2016 From: gilles.khouzam at microsoft.com (Gilles Khouzam) Date: Wed, 5 Oct 2016 19:19:45 +0000 Subject: [cmake-developers] Problems with icons for Windows Store 10.0 In-Reply-To: <9e890c5e-bc99-b862-dbc8-9f1ddf54520c@kitware.com> References: <31D73EA9-838C-4959-80A0-47F89DE23DF3@gmx.at> <9e890c5e-bc99-b862-dbc8-9f1ddf54520c@kitware.com> Message-ID: That's most likely because you're missing an AppxManifest. In order to build the CMake detection projects, we inject some necessary files into the project when they aren't specified. This includes the manifest and the icons. Can you add your app manifest to the project (look at Tests\VSWinStorePhone if you want an example) and the icons should not be overridden then. Thanks -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Wednesday, October 5, 2016 12:09 To: Roman W?ger ; Gilles Khouzam Cc: CMake Developer MailingList ; CMake MailingList Subject: Re: [cmake-developers] Problems with icons for Windows Store 10.0 On 10/05/2016 02:56 PM, Roman W?ger wrote: > I tried the following to copy the required app icons to the required destination: > > configure_file(Logo.png > ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY) That's a CMake-private directory whose location is an implementation detail. Some other interface for configuring this behavior will be needed. > The CMake process itself overrides those files at the end with the > files from the CMake's Template directory, which are empty. >From the current implementation it doesn't look like there is anyway to prevent that. We'll need to have some configuration of where it gets those files. > So, how could I use my icon files and/or what is the preferred way of doing this? Gilles? -Brad From steveire at gmail.com Wed Oct 5 18:38:18 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 06 Oct 2016 00:38:18 +0200 Subject: [cmake-developers] Generator options per-directory v. global References: <2f8545ce-bf04-97b9-7f9b-236325ce6635@kitware.com> Message-ID: Brad King wrote: > On 10/04/2016 05:46 PM, Stephen Kelly wrote: >> This causes problems because now the code has to read the value for each >> directory and can't assume that the value is always the same as the value >> from the top-level CMakeLists file. > > Many of these are honored only in the top-level directory anyway. Some do... src/cmake$ git grep -c -e Makefiles --and -e "\[0\]" Source/cmGlobalGenerator.cxx:6 Source/cmGlobalUnixMakefileGenerator3.cxx:1 Source/cmake.cxx:1 src/cmake$ git grep -c -e LocalGenerators --and -e "\[0\]" Source/cmExtraEclipseCDT4Generator.cxx:4 Source/cmExtraKateGenerator.cxx:1 Source/cmGlobalGenerator.cxx:1 Source/cmGlobalKdevelopGenerator.cxx:1 Source/cmGlobalNinjaGenerator.cxx:10 Source/cmGlobalUnixMakefileGenerator3.cxx:6 Source/cmGlobalVisualStudioGenerator.cxx:2 Source/cmLocalNinjaGenerator.cxx:1 Source/cmake.cxx:1 ... but it is far more common for generate-time code to just get the closest cmMakefile and call GetDefinition on it. > Such cases could have documentation updated. > > Some of them may be per-`project()`. CMake doesn't have an appropriately scoped data for that, AFAIK (touched on below). >> Is the answer 'Use global properties or a cache variable instead'? > > The options need to be something easy for the project to set itself > or for a user to set. > A cache entry can work for that, but we don't > really often read cache entries directly and instead read variables > that fall back to cache entries if not defined. Yes, my suggestion is that this can be problematic. > The scoping doesn't > match the generator semantics exactly, but it is easy to use and > hasn't been a big problem. My mail is suggesting that it is a problem and is undesirable to maintain. Big is subjective, and there are not many complaints, because generally people don't try to set things like this per-directory (and if they did it would probably mostly do what they expect). The problems are 1) It is a behavior which is often not intended by the programmer. 2) It makes refactoring harder if such unintended behavior must be preserved. 3) It is unintuitive, because code such as set(FOO ON) project(p) add_library(bar ...) set(FOO OFF) looks like FOO is ON when defining the project and the target, but in reality it is only the value at the end of the directory that is consumed. Those are not problems users or contributors adding features encounter, so that might affect a perception of 'big'ness. These problems only bubble up during refactoring or under longer-term maintenance when the true semantics of the code become known. The suggestion to use the first cmMakefile for these kinds of definitions is a good one 1) It can be documented that the variable can only be set in the top level 2) It is what people already do probably 3) It is more convenient than the API for setting cache or global properties In this CODELITE case, I can't intuitively understand where the value will come from in the case of a tree of directories, some of which contain project() and others which don't, others which contain multiple project() calls, and where the project() may appear in between add_subdirectory() calls. I can't read the code and know that, because I know how subtle the projectMap stuff and the vector of cmLocalGenerator* is. I think code such as set(CMAKE_CODELITE_USE_TARGETS ON) will be ignored if it occurs in a directory which does not contain a project(). I might be wrong though, and there may be other semantics of the code as written which are unexpected. Should CMAKE_CODELITE_USE_TARGETS be changed to be 'global' and use something like the result of gg->GetMakefiles()[0]->GetDefinition() and should that be the model for how to access these kinds of settings in the future? cmGlobalGenerator could gain a GetGlobalSetting() for that purpose. Thanks, Steve. From craig.scott at crascit.com Wed Oct 5 18:57:04 2016 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 6 Oct 2016 09:57:04 +1100 Subject: [cmake-developers] Generator options per-directory v. global In-Reply-To: References: <2f8545ce-bf04-97b9-7f9b-236325ce6635@kitware.com> Message-ID: I'm coming in half way to this discussion, so apologies if my comments interspersed below are not so well related to the core topic of discussion. On Thu, Oct 6, 2016 at 9:38 AM, Stephen Kelly wrote: > Brad King wrote: > > > The scoping doesn't > > match the generator semantics exactly, but it is easy to use and > > hasn't been a big problem. > > My mail is suggesting that it is a problem and is undesirable to maintain. > > Big is subjective, and there are not many complaints, because generally > people don't try to set things like this per-directory (and if they did it > would probably mostly do what they expect). > > The problems are > > 1) It is a behavior which is often not intended by the programmer. > 2) It makes refactoring harder if such unintended behavior must be > preserved. > 3) It is unintuitive, because code such as > > set(FOO ON) > project(p) > add_library(bar ...) > set(FOO OFF) > > looks like FOO is ON when defining the project and the target, but in > reality it is only the value at the end of the directory that is consumed. > Consider the following example which perhaps better shows that this problem may not be as uncommon as first thought: set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -someOption") add_library(foo ...) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -somethingElse") I think most developers probably expect foo to not have the -somethingElse option when it is compiled, but I believe it would have it. Given that it is not unusual (but not necessarily wise) for projects to fiddle with variables like CMAKE_CXX_FLAGS in subdirectories which could be brought in via include() rather than add_subdirectory(), this behaviour of using the variable's value at the end of the directory processing is likely a surprise to many and probably already causes some head-scratching until devs figure it out. Is the problem being discussed here relating to CMAKE_CODELITE_USE_TARGETS much different? If I understand things correctly, directory *properties* don't typically have this unexpected behaviour as their value at the time of defining the targets is used, not at the end of that directory's processing. They serve as defaults for target-specific properties at the point of the target being defined. Not sure if that helps with the original topic of discussion here though. > > Those are not problems users or contributors adding features encounter, so > that might affect a perception of 'big'ness. These problems only bubble up > during refactoring or under longer-term maintenance when the true semantics > of the code become known. > Perhaps a bit more common than that, as the above example suggests. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Wed Oct 5 19:20:39 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 06 Oct 2016 01:20:39 +0200 Subject: [cmake-developers] Generator options per-directory v. global References: <2f8545ce-bf04-97b9-7f9b-236325ce6635@kitware.com> Message-ID: Craig Scott wrote: > I'm coming in half way to this discussion, so apologies if my comments > interspersed below are not so well related to the core topic of > discussion. Hi Craig, Thanks for your input. > Consider the following example which perhaps better shows that this > problem may not be as uncommon as first thought: > > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -someOption") > add_library(foo ...) > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -somethingElse") > > I think most developers probably expect foo to not have the -somethingElse > option when it is compiled, but I believe it would have it. The difference occurs depending on when the value is read. See my CMAKE_CXX_STANDARD example below. > If I understand things correctly, directory *properties* don't typically > have this unexpected behaviour as their value at the time of defining the > targets is used, not at the end of that directory's processing. It all depends on when the value is read. Something that is read at configure-time appears to have immediate effect, regardless of whether it is a 'directory property' or a set() 'definition'. When something that is read at generate-time (such as CMAKE_CXX_FLAGS) it takes on the value at the end of the directory. You might be referring to things like this, which are still 'definitions' not 'directory properties': set(CMAKE_CXX_STANDARD 11) # Reads CMAKE_CXX_STANDARD 'now' at configure time add_executable(foo ...) set(CMAKE_CXX_STANDARD 14) # Reads CMAKE_CXX_STANDARD 'now' again! add_executable(bar ...) The important distinction is where in the CMake C++ code the cmMakefile::GetDefinition call occurs - generate-time code or configure-time code. This is a sideline just for your information. What this thread is really about is whether things should be read 'only once' or 'once per directory', and whether the CMake C++ code chooses one or the other deliberately or accidentally, and what impact that has on maintainability and refactoring. > this behaviour of using the > variable's value at the end of the directory processing is likely a > surprise to many and probably already causes some head-scratching until > devs figure it out. Is the problem being discussed here relating to > CMAKE_CODELITE_USE_TARGETS > much different? It seems like a related example to me. The CMAKE_CODELITE_USE_TARGETS feature is trying to be related to a project() command, but it is read at the end of the directory. Usually, I would think that is not a problem the way most people write project() commands and set these kinds of settings. However, in the general sense of how 'global' settings should work, I think things could be better. >> Those are not problems users or contributors adding features encounter, >> so that might affect a perception of 'big'ness. These problems only >> bubble up during refactoring or under longer-term maintenance when the >> true semantics of the code become known. >> > > Perhaps a bit more common than that, as the above example suggests. Yes, those kinds of examples are the things that I would expect to arise during maintenance, perhaps several releases after a feature hits master. Thanks, Steve. From roman.wueger at gmx.at Thu Oct 6 01:39:07 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Thu, 6 Oct 2016 07:39:07 +0200 Subject: [cmake-developers] Problems with icons for Windows Store 10.0 In-Reply-To: References: <31D73EA9-838C-4959-80A0-47F89DE23DF3@gmx.at> <9e890c5e-bc99-b862-dbc8-9f1ddf54520c@kitware.com> Message-ID: <2CA63915-C4DF-4400-BCE2-D01251941B15@gmx.at> Thanks Gilles, I added a custom appxmanifest as you mentioned and it works, but it would nevertheless very helpful to customize such things via variables and let CMake fill out the rest. Regards Roman > Am 05.10.2016 um 21:19 schrieb Gilles Khouzam : > > That's most likely because you're missing an AppxManifest. > > In order to build the CMake detection projects, we inject some necessary files into the project when they aren't specified. This includes the manifest and the icons. Can you add your app manifest to the project (look at Tests\VSWinStorePhone if you want an example) and the icons should not be overridden then. > > Thanks > > -----Original Message----- > From: Brad King [mailto:brad.king at kitware.com] > Sent: Wednesday, October 5, 2016 12:09 > To: Roman W?ger ; Gilles Khouzam > Cc: CMake Developer MailingList ; CMake MailingList > Subject: Re: [cmake-developers] Problems with icons for Windows Store 10.0 > >> On 10/05/2016 02:56 PM, Roman W?ger wrote: >> I tried the following to copy the required app icons to the required destination: >> >> configure_file(Logo.png >> ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY) > > That's a CMake-private directory whose location is an implementation detail. > Some other interface for configuring this behavior will be needed. > >> The CMake process itself overrides those files at the end with the >> files from the CMake's Template directory, which are empty. > > From the current implementation it doesn't look like there is anyway to prevent that. We'll need to have some configuration of where it gets those files. > >> So, how could I use my icon files and/or what is the preferred way of doing this? > > Gilles? > > -Brad > From gilles.khouzam at microsoft.com Thu Oct 6 01:56:28 2016 From: gilles.khouzam at microsoft.com (Gilles Khouzam) Date: Thu, 6 Oct 2016 05:56:28 +0000 Subject: [cmake-developers] Problems with icons for Windows Store 10.0 In-Reply-To: <2CA63915-C4DF-4400-BCE2-D01251941B15@gmx.at> References: <31D73EA9-838C-4959-80A0-47F89DE23DF3@gmx.at> <9e890c5e-bc99-b862-dbc8-9f1ddf54520c@kitware.com> <2CA63915-C4DF-4400-BCE2-D01251941B15@gmx.at> Message-ID: Hi Roman, Glad to hear that it works. We discussed this when I implemented the feature, the only reason the functionality has been implemented is to supplement the intermediate projects that CMake produces that cannot easily be adapted for the requirements of a Windows Store application. For a user's project, the AppXManifest is a critical piece that describes the application. There are some fields that need to be appropriately set (publisher Id, application name and version), even the icons need to be properly specified unless you use the exact same name for the files and don't look at having different tile sizes. For prototyping this might seem like an unnecessary step, but once you start customizing the parts of the application, it seems counter intuitive to have customizations only apply under certain conditions. Perhaps a better solution would be to give an error message if any of the defaults are replaced but a manifest is not specified. -----Original Message----- From: Roman W?ger [mailto:roman.wueger at gmx.at] Sent: Wednesday, October 5, 2016 22:39 To: Gilles Khouzam Cc: Brad King ; CMake Developer MailingList ; CMake MailingList Subject: Re: [cmake-developers] Problems with icons for Windows Store 10.0 Thanks Gilles, I added a custom appxmanifest as you mentioned and it works, but it would nevertheless very helpful to customize such things via variables and let CMake fill out the rest. Regards Roman > Am 05.10.2016 um 21:19 schrieb Gilles Khouzam : > > That's most likely because you're missing an AppxManifest. > > In order to build the CMake detection projects, we inject some necessary files into the project when they aren't specified. This includes the manifest and the icons. Can you add your app manifest to the project (look at Tests\VSWinStorePhone if you want an example) and the icons should not be overridden then. > > Thanks > > -----Original Message----- > From: Brad King [mailto:brad.king at kitware.com] > Sent: Wednesday, October 5, 2016 12:09 > To: Roman W?ger ; Gilles Khouzam > > Cc: CMake Developer MailingList ; CMake > MailingList > Subject: Re: [cmake-developers] Problems with icons for Windows Store > 10.0 > >> On 10/05/2016 02:56 PM, Roman W?ger wrote: >> I tried the following to copy the required app icons to the required destination: >> >> configure_file(Logo.png >> ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY) > > That's a CMake-private directory whose location is an implementation detail. > Some other interface for configuring this behavior will be needed. > >> The CMake process itself overrides those files at the end with the >> files from the CMake's Template directory, which are empty. > > From the current implementation it doesn't look like there is anyway to prevent that. We'll need to have some configuration of where it gets those files. > >> So, how could I use my icon files and/or what is the preferred way of doing this? > > Gilles? > > -Brad > From daniel at pfeifer-mail.de Thu Oct 6 07:57:08 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Thu, 6 Oct 2016 13:57:08 +0200 Subject: [cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test? In-Reply-To: <8239086a-bd62-43e0-35a2-0ba9ef38da0a@gmail.com> References: <3fa5d815-3c6e-b2bf-7e11-d23e7f11ddff@kitware.com> <1475572801.779.3.camel@qt.io> <8239086a-bd62-43e0-35a2-0ba9ef38da0a@gmail.com> Message-ID: On Wed, Oct 5, 2016 at 12:54 PM, Nils Gladitz wrote: > On 04.10.2016 11:20, Tobias Hunger wrote: >> >> On Mo, 2016-10-03 at 14:25 -0400, Brad King wrote: >>>> >>>> The list we need would thus be built up to contain all COMMAND >>>> arguments to add_test that are also build targets in CMake. >>> >>> The list would also need to include targets mentioned in generator >>> expressions such as `$`. This will almost certainly >>> be better done as a CMake feature implemented in C++. This was actually >>> an early design philosophy: do the hard stuff in C++ so that complex >>> logic is not needed in CMake-language code. >> >> Access to the list of defined tests would be nice to have in the >> server-mode, >> too:-) >> >> If some work is done in that direction, please keep server-mode in mind >> when >> designing the APIs. I would love to reuse them to expose that information >> to >> clients. > > > This might be rare but the tests that cmake knows about might differ from > the tests that ctest knows about given that tests can be dynamically defined > through TEST_INCLUDE_FILE[1]. > > I've never used it that way but I was considering e.g. querying test > binaries (produced at build time) for the tests they define and making those > available dynamically when ctest processes CTestTestfile.cmake. This is in > contrast to e.g. FindGTests.cmake's GTEST_ADD_TESTS() which tries to > accomplish the same thing at configuration time by parsing test sources > instead. +1. I wrote about that approach here: http://purplekarrot.net/blog/cmake-and-test-suites.html From charles.huet at gmail.com Thu Oct 6 08:32:31 2016 From: charles.huet at gmail.com (Charles Huet) Date: Thu, 06 Oct 2016 12:32:31 +0000 Subject: [cmake-developers] FastBuild Generator In-Reply-To: References: <8d41e8e2-29c6-5188-43a7-f9f89a266917@kitware.com> <54439e7e-038c-1392-2d80-3f7609fb9956@kitware.com> <000a6011-505e-f4e9-cccc-bf1c3b748142@kitware.com> Message-ID: Hi, I rebased the Fastbuild generator on the latest master, and pushed my work to fastbuild-master. There are still some test fail, a few are due to an arror in manifest management, where multiple binarie's build try to write to the same manifest file at the same time (e.g. ObjectLibrary). Some issues are clearly identified but not solved yet, such as RunCMake.BuildDepends which fails because non-source dependencies are not yet managed properly. Some of these are new since the rebase on 3.7/master, either new tests (e.g. android-related) or regressions, I will work at identiofying and correcting those. Do you think it is time to start the review, or should it wait until I have 100% of the tests passing ? Here is a full list of failing tests: 93% tests passed, 28 tests failed out of 406 The following tests FAILED: 46 - ObjectLibrary (Failed) 52 - LinkDirectory (Failed) 61 - Preprocess (Failed) 62 - ExportImport (Timeout) 66 - CompileDefinitions (Failed) 76 - CMakeBuildTest (Failed) 79 - Module.ExternalData (Failed) 108 - CustomCommand (Failed) 109 - CustomCommandByproducts (Failed) 113 - BuildDepends (Failed) 114 - SimpleInstall (Failed) 115 - SimpleInstall-Stage2 (Failed) 131 - ExternalProject (Failed) 135 - ExternalProjectUpdateSetup (Failed) 136 - ExternalProjectUpdate (Failed) 153 - Plugin (Timeout) 225 - IncludeDirectories (Failed) 226 - InterfaceLinkLibraries (Failed) 276 - RunCMake.CMP0060 (Failed) 278 - RunCMake.CMP0065 (Timeout) 281 - RunCMake.AndroidTestUtilities (Failed) 282 - RunCMake.BuildDepends (Failed) 284 - RunCMake.Configure (Failed) 345 - RunCMake.try_compile (Failed) 372 - RunCMake.CrosscompilingEmulator (Failed) 374 - RunCMake.AutoExportDll (Failed) 389 - CMake.ModuleNotices (Failed) 406 - CMake.CheckSourceTree (Failed) Errors while running CTest Thanks. Le ven. 23 sept. 2016 ? 17:21, Charles Huet a ?crit : > Sorry I pushed on fastbuild-rebase, as the rebase on master fails evento > self host. > > I did not expect this to be merged for 3.7, as I'm not sure I'll have time > to polish it enough for release. > > On Fri, Sep 23, 2016, 16:52 Brad King wrote: > > On 09/23/2016 10:30 AM, Charles Huet wrote: > > If you want to take a quick glance it should be close to what you want > > Did you push an update to the fastbuild-master branch? It looks the same. > > FYI, I'd like to wait until after the Oct 3 branch for the 3.7 release > before introducing changes toward a major new feature. Therefore I > likely won't have a chance to take a serious look at this until after > that. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Oct 6 09:56:16 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 6 Oct 2016 09:56:16 -0400 Subject: [cmake-developers] Patch: Don't emit warning when config file not found In-Reply-To: References: <5dfb692f-2d8b-fc2b-be9c-fddb09415857@grueninger.de> <25936235-f6e3-2b0a-5e42-2e0ea92413f3@kitware.com> Message-ID: <47824be5-e09a-760d-7481-e199759a5b80@kitware.com> On 10/05/2016 05:35 PM, Christoph Gr?ninger wrote: > Vc provides a ConfigVc.cmake. > > 1. When I use "find_package(Vc)", many users get warnings that neither > FindVc.cmake nor VcConfig.cmake is found. You can use find_package(Vc CONFIG) to drop the FindVc part of the message. > 2. When I use "find_package(Vc QUIET)", Vc does not show up in the > feature summary. Try: find_package(Vc CONFIG QUIET) Then use the `INCLUDE_QUIET_PACKAGES` option to feature_summary(): https://cmake.org/cmake/help/v3.7/module/FeatureSummary.html -Brad From brad.king at kitware.com Thu Oct 6 09:57:11 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 6 Oct 2016 09:57:11 -0400 Subject: [cmake-developers] Generator options per-directory v. global In-Reply-To: References: <2f8545ce-bf04-97b9-7f9b-236325ce6635@kitware.com> Message-ID: <5b971405-b22e-83af-eef2-404ebbc93350@kitware.com> On 10/05/2016 06:38 PM, Stephen Kelly wrote: > The suggestion to use the first cmMakefile for these kinds of definitions is > a good one > > 1) It can be documented that the variable can only be set in the top level > 2) It is what people already do probably > 3) It is more convenient than the API for setting cache or global properties That makes sense, but the codelite feature is just following a long-standing convention used for many settings. If you want to make a sweeping effort to formalize this kind of scoping then that is fine with me. Mostly I think it will be documenting that the value of the variable at the end of the top-level CMakeLists.txt file is the one that is used. In some cases that may involve fixing generators to actually use that one. -Brad From brad.king at kitware.com Thu Oct 6 11:32:24 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 6 Oct 2016 11:32:24 -0400 Subject: [cmake-developers] FastBuild Generator In-Reply-To: References: <8d41e8e2-29c6-5188-43a7-f9f89a266917@kitware.com> <54439e7e-038c-1392-2d80-3f7609fb9956@kitware.com> <000a6011-505e-f4e9-cccc-bf1c3b748142@kitware.com> Message-ID: <9efa70ce-e3cc-6b80-eac3-09be25952b83@kitware.com> On 10/06/2016 08:32 AM, Charles Huet wrote: > Do you think it is time to start the review, or should it wait > until I have 100% of the tests passing ? Thanks for the update. Generally my reviews for new features mostly look at documentation, tests, style, etc. rather than at implementation details (which can easily be fixed/changed later). Therefore final review and integration should not start until everything is working. However, I'm happy to take quick glances at progress once in a while. Here are some comments from the current version: * Please use Utilities/Scripts/clang-format.bash for code style. This is easy to apply automatically later so don't worry about it too much. * For final integration I'd like the commits to be squashed and arranged in an organized way. This is hard to do until you have everything working though. * Please update the license notices to use the new style that we switched to in `master`. Both C++ and .cmake notices changed. Thanks, -Brad From steveire at gmail.com Thu Oct 6 12:44:55 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 06 Oct 2016 18:44:55 +0200 Subject: [cmake-developers] Generator options per-directory v. global References: <2f8545ce-bf04-97b9-7f9b-236325ce6635@kitware.com> <5b971405-b22e-83af-eef2-404ebbc93350@kitware.com> Message-ID: Brad King wrote: > On 10/05/2016 06:38 PM, Stephen Kelly wrote: >> The suggestion to use the first cmMakefile for these kinds of definitions >> is a good one >> >> 1) It can be documented that the variable can only be set in the top >> level 2) It is what people already do probably >> 3) It is more convenient than the API for setting cache or global >> properties > > That makes sense, but the codelite feature is just following a > long-standing convention used for many settings. If you want to > make a sweeping effort to formalize this kind of scoping then that > is fine with me. Mostly I think it will be documenting that the > value of the variable at the end of the top-level CMakeLists.txt > file is the one that is used. In some cases that may involve > fixing generators to actually use that one. Ok. I started by adjusting the new CodeLite feature. I based it on an early commit so that it can be merged to the release branch. The sweep belongs in master for the following release I think. Thanks, Steve. From charles.huet at gmail.com Thu Oct 6 13:33:09 2016 From: charles.huet at gmail.com (Charles Huet) Date: Thu, 06 Oct 2016 17:33:09 +0000 Subject: [cmake-developers] FastBuild Generator In-Reply-To: <9efa70ce-e3cc-6b80-eac3-09be25952b83@kitware.com> References: <8d41e8e2-29c6-5188-43a7-f9f89a266917@kitware.com> <54439e7e-038c-1392-2d80-3f7609fb9956@kitware.com> <000a6011-505e-f4e9-cccc-bf1c3b748142@kitware.com> <9efa70ce-e3cc-6b80-eac3-09be25952b83@kitware.com> Message-ID: >* Please use Utilities/Scripts/clang-format.bash for > code style. This is easy to apply automatically later > so don't worry about it too much. I'll get on this soon, I like to have proper style. > * For final integration I'd like the commits to be squashed > and arranged in an organized way. This is hard to do until > you have everything working though. Sure. For now there are the first few commits which I can't change much to keep proper attribuation, and a few commits on top which will be squashed together once the dev is complete (or maybe earlier if I feel like it). >* Please update the license notices to use the new style that > we switched to in `master`. Both C++ and .cmake notices > changed. Will do. Le jeu. 6 oct. 2016 ? 17:32, Brad King a ?crit : > On 10/06/2016 08:32 AM, Charles Huet wrote: > > Do you think it is time to start the review, or should it wait > > until I have 100% of the tests passing ? > > Thanks for the update. Generally my reviews for new features > mostly look at documentation, tests, style, etc. rather than > at implementation details (which can easily be fixed/changed > later). Therefore final review and integration should not start > until everything is working. > > However, I'm happy to take quick glances at progress once in > a while. Here are some comments from the current version: > > * Please use Utilities/Scripts/clang-format.bash for > code style. This is easy to apply automatically later > so don't worry about it too much. > > * For final integration I'd like the commits to be squashed > and arranged in an organized way. This is hard to do until > you have everything working though. > > * Please update the license notices to use the new style that > we switched to in `master`. Both C++ and .cmake notices > changed. > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Thu Oct 6 13:45:42 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 06 Oct 2016 19:45:42 +0200 Subject: [cmake-developers] CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065 Message-ID: Hi, I have encountered the implementation of CMP0065. As far as I can see, this is the only use of CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS, and it is not used for shared libraries, but for executables. Finding uses of variables like that is hard because they could be composed like "CMAKE_" + targetType + "_LINK_" + lang + "_FLAGS"; which is hard to find with grep. Am I missing something or is that also used for shared libraries? Or should the variable be renamed? Or should CMP0065 be using some other appropriate variable? Also, shouldn't that code be part of cmComputeLinkInformation? It seems out of place in cmLocalGenerator. If it were returned from cli.GetItems, then cmLocalVisualStudio7GeneratorInternals::OutputLibraries and cmGlobalXCodeGenerator::AddDependAndLinkInformation would make use of it, which as far as I can tell they currently do not. Should/do those generators support ENABLE_EXPORTS? Thanks, Steve. From brad.king at kitware.com Thu Oct 6 13:54:48 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 6 Oct 2016 13:54:48 -0400 Subject: [cmake-developers] CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065 In-Reply-To: References: Message-ID: <6f450b83-c07a-cab0-cc8a-a843206a5a12@kitware.com> On 10/06/2016 01:45 PM, Stephen Kelly wrote: > I have encountered the implementation of CMP0065. As far as I can see, this > is the only use of CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS, and it is not > used for shared libraries, but for executables. Correct. It was about exporting symbols from executables so plugins can see them. See the policy docs. > Am I missing something or is that also used for shared libraries? Or should > the variable be renamed? Or should CMP0065 be using some other appropriate > variable? The variable name refers to flags needed when linking an executable *to* shared libraries. It is a terrible name that has been around since the earliest days. One could rename the variable in our own platform files but would have to also honor the old name just in case. > Also, shouldn't that code be part of cmComputeLinkInformation? It seems out > of place in cmLocalGenerator. If it were returned from cli.GetItems, then > cmLocalVisualStudio7GeneratorInternals::OutputLibraries and > cmGlobalXCodeGenerator::AddDependAndLinkInformation would make use of it, > which as far as I can tell they currently do not. Should/do those generators > support ENABLE_EXPORTS? Yes, it could be moved. It hasn't really mattered because the variable is not populated on the platforms supported by those other generators. -Brad From steveire at gmail.com Thu Oct 6 14:06:05 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 06 Oct 2016 20:06:05 +0200 Subject: [cmake-developers] CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065 References: <6f450b83-c07a-cab0-cc8a-a843206a5a12@kitware.com> Message-ID: Brad King wrote: > The variable name refers to flags needed when linking an executable *to* > shared libraries. It is a terrible name that has been around since the > earliest days. One could rename the variable in our own platform files > but would have to also honor the old name just in case. That wouldn't be a rename. The infinite compatibility promises of CMake concern me. A policy could be added but those are also defined to never expire, so while they help users migrate, they don't help clean up code. End result: do nothing. >> Also, shouldn't that code be part of cmComputeLinkInformation? It seems >> out of place in cmLocalGenerator. If it were returned from cli.GetItems, >> then cmLocalVisualStudio7GeneratorInternals::OutputLibraries and >> cmGlobalXCodeGenerator::AddDependAndLinkInformation would make use of it, >> which as far as I can tell they currently do not. Should/do those >> generators support ENABLE_EXPORTS? > > Yes, it could be moved. It hasn't really mattered because the variable > is not populated on the platforms supported by those other generators. Ok. I might look into that. Thanks, Steve. From brad.king at kitware.com Thu Oct 6 14:45:15 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 6 Oct 2016 14:45:15 -0400 Subject: [cmake-developers] CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065 In-Reply-To: References: <6f450b83-c07a-cab0-cc8a-a843206a5a12@kitware.com> Message-ID: <37390289-25d5-75b1-ebd9-a47cc47b3e96@kitware.com> On 10/06/2016 02:06 PM, Stephen Kelly wrote: >> One could rename the variable in our own platform files >> but would have to also honor the old name just in case. > > That wouldn't be a rename. Sure it would. All the places that set the variable would have a new more understandable name. We would just leave undocumented support for reading the old name if it is set and otherwise use the new name. Actually since this is an internal variable I'd be okay with renaming it without compatibility, so long as it is easy to add support for the old name back in if it becomes a problem in the future. Or, we could even rename support for the old name and then add a commit to remove the support. That would provide a commit that is easy to revert to restore support. >>> out of place in cmLocalGenerator. If it were returned from cli.GetItems, >> >> Yes, it could be moved. > > Ok. I might look into that. It looks like OutputLinkLibraries currently puts the flag in the linkLibs (which goes to the placeholder) but it would more sensibly be located in the linkFlags (which goes to the placeholder). If we do clean this up it should be moved to . Therefore it should not go in GetItems, but instead in a separate helper that all generators can share. -Brad From steveire at gmail.com Thu Oct 6 15:46:20 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 06 Oct 2016 21:46:20 +0200 Subject: [cmake-developers] CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065 References: <6f450b83-c07a-cab0-cc8a-a843206a5a12@kitware.com> <37390289-25d5-75b1-ebd9-a47cc47b3e96@kitware.com> Message-ID: Brad King wrote: >>>> out of place in cmLocalGenerator. If it were returned from >>>> cli.GetItems, >>> >>> Yes, it could be moved. >> >> Ok. I might look into that. > > It looks like OutputLinkLibraries currently puts the flag in the > linkLibs (which goes to the placeholder) but it > would more sensibly be located in the linkFlags (which goes to > the placeholder). If we do clean this up it should > be moved to . Therefore it should not go in GetItems, > but instead in a separate helper that all generators can share. Do you know what CMAKE_EXE_EXPORTS_${lang}_FLAG is? It is added to the linkFlags already for executables with exports. For Linux, it contains "-Wl,--export-dynamic" CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS contains "-rdynamic" for Linux-GNU. According to https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html rdynamic means: "Pass the flag -export-dynamic to the ELF linker, on targets that support it." Is CMP0065 adding redundant flags? Thanks, Steve. From brad.king at kitware.com Thu Oct 6 16:01:24 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 6 Oct 2016 16:01:24 -0400 Subject: [cmake-developers] CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065 In-Reply-To: References: <6f450b83-c07a-cab0-cc8a-a843206a5a12@kitware.com> <37390289-25d5-75b1-ebd9-a47cc47b3e96@kitware.com> Message-ID: <21772326-99de-edfa-3706-0873a6ed31bf@kitware.com> On 10/06/2016 03:46 PM, Stephen Kelly wrote: > Do you know what CMAKE_EXE_EXPORTS_${lang}_FLAG is? It is added to the > linkFlags already for executables with exports. Ah, that does appear to be the same thing. > Is CMP0065 adding redundant flags? The policy only affects executables without exports, so it makes no difference for anything that is getting CMAKE_EXE_EXPORTS_${lang}_FLAG. However, the code path where the policy appears was already adding redundant flags. I think CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS values in platform files can be copied over to CMAKE_EXE_EXPORTS_${lang}_FLAG where they are not set already. Then the policy's NEW behavior can be changed to doing nothing because executables with exports will already have the flags needed. The only reason to keep the old settings of CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS around is then to honor the CMP0065 OLD behavior. -Brad From foss at grueninger.de Sun Oct 9 15:24:05 2016 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Sun, 9 Oct 2016 21:24:05 +0200 Subject: [cmake-developers] Patch: Don't emit warning when config file not found In-Reply-To: <47824be5-e09a-760d-7481-e199759a5b80@kitware.com> References: <5dfb692f-2d8b-fc2b-be9c-fddb09415857@grueninger.de> <25936235-f6e3-2b0a-5e42-2e0ea92413f3@kitware.com> <47824be5-e09a-760d-7481-e199759a5b80@kitware.com> Message-ID: <90690897-78ce-3ed5-730d-7fc2f891f33e@grueninger.de> Hi Brad, thanks again for your answer, but the core of the problem persists. >> 1. When I use "find_package(Vc)", many users get warnings that neither >> FindVc.cmake nor VcConfig.cmake is found. > > You can use > find_package(Vc CONFIG) > to drop the FindVc part of the message. Sure, that helps a bit. Still we get a warning with the stack trace, just for a missing optional dependency. >> 2. When I use "find_package(Vc QUIET)", Vc does not show up in the >> feature summary. > > Try: > find_package(Vc CONFIG QUIET) > Then use the `INCLUDE_QUIET_PACKAGES` option to feature_summary(): And all quiet packages will show up, including a dozen of internal packages. Using quiet has another disadvantage: If the package is found but does not work (wrong version, lib found but not the includes), the user has no way investigating that. More and more packages provide config files. We are left with * either having a warning for every missing dependency * or loosing the output of tests and feature summary, as both tests are QUIET. I'd prefer to write the error message to the CMakeError.log and reduce the output to one line. I think, the current behavior must be considered a bug. Best, Christoph From brad.king at kitware.com Mon Oct 10 08:51:09 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 10 Oct 2016 08:51:09 -0400 Subject: [cmake-developers] Patch: Don't emit warning when config file not found In-Reply-To: <90690897-78ce-3ed5-730d-7fc2f891f33e@grueninger.de> References: <5dfb692f-2d8b-fc2b-be9c-fddb09415857@grueninger.de> <25936235-f6e3-2b0a-5e42-2e0ea92413f3@kitware.com> <47824be5-e09a-760d-7481-e199759a5b80@kitware.com> <90690897-78ce-3ed5-730d-7fc2f891f33e@grueninger.de> Message-ID: <79078cb6-8eb9-bf6b-f95a-012367fa0d40@kitware.com> On 10/09/2016 03:24 PM, Christoph Gr?ninger wrote: > * or loosing the output of tests and feature summary, as both tests are QUIET. > > I'd prefer to write the error message to the CMakeError.log and reduce > the output to one line. I think, the current behavior must be considered > a bug. The default behavior evolved over many years to satisfy many use cases and give people the information they need to resolve real problems. It is not going to change. However, if you'd like to propose additional options to these interfaces to get the behavior you want then that would be fine. Perhaps find_package could gain an ``OPTIONAL`` switch. I'm not very familiar with feature_summary so I'm not sure what that would need off the top of my head. -Brad From charles.huet at gmail.com Mon Oct 10 09:39:21 2016 From: charles.huet at gmail.com (Charles Huet) Date: Mon, 10 Oct 2016 13:39:21 +0000 Subject: [cmake-developers] FastBuild Generator In-Reply-To: References: <8d41e8e2-29c6-5188-43a7-f9f89a266917@kitware.com> <54439e7e-038c-1392-2d80-3f7609fb9956@kitware.com> <000a6011-505e-f4e9-cccc-bf1c3b748142@kitware.com> <9efa70ce-e3cc-6b80-eac3-09be25952b83@kitware.com> Message-ID: Hi again. I performed all the aforementioned actions, please check everything is OK for you. I have a few questions: * the test CMake.CheckSourceTree does not work with Fastbuild, but I could not get it to work with Ninja either, maybe I have an environment problem ? * the test SimpleInstall requires trhe build tool to be able to run multiple instances in the same hierarchy, which Fastbuild does not support. Should I refactor the test to remove this requirement ? Or simply ignore the test ? * It seems SimpleInstall-Stage2 depends upon SimpleInstall, is this right ? The branch I recently pushed has only a few tests failing, quite a few seem to be related to a lack of non-source file dependencies as far as I can tell. Thanks. Le jeu. 6 oct. 2016 ? 19:33, Charles Huet a ?crit : > >* Please use Utilities/Scripts/clang-format.bash for > > code style. This is easy to apply automatically later > > so don't worry about it too much. > I'll get on this soon, I like to have proper style. > > > > * For final integration I'd like the commits to be squashed > > > and arranged in an organized way. This is hard to do until > > you have everything working though. > > Sure. For now there are the first few commits which I can't change much to > keep proper attribuation, and a few commits on top which will be squashed > together once the dev is complete (or maybe earlier if I feel like it). > > >* Please update the license notices to use the new style that > > we switched to in `master`. Both C++ and .cmake notices > > changed. > Will do. > > Le jeu. 6 oct. 2016 ? 17:32, Brad King a ?crit : > > On 10/06/2016 08:32 AM, Charles Huet wrote: > > Do you think it is time to start the review, or should it wait > > until I have 100% of the tests passing ? > > Thanks for the update. Generally my reviews for new features > mostly look at documentation, tests, style, etc. rather than > at implementation details (which can easily be fixed/changed > later). Therefore final review and integration should not start > until everything is working. > > However, I'm happy to take quick glances at progress once in > a while. Here are some comments from the current version: > > * Please use Utilities/Scripts/clang-format.bash for > code style. This is easy to apply automatically later > so don't worry about it too much. > > * For final integration I'd like the commits to be squashed > and arranged in an organized way. This is hard to do until > you have everything working though. > > * Please update the license notices to use the new style that > we switched to in `master`. Both C++ and .cmake notices > changed. > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Oct 10 13:13:42 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 10 Oct 2016 13:13:42 -0400 Subject: [cmake-developers] FastBuild Generator In-Reply-To: References: <8d41e8e2-29c6-5188-43a7-f9f89a266917@kitware.com> <54439e7e-038c-1392-2d80-3f7609fb9956@kitware.com> <000a6011-505e-f4e9-cccc-bf1c3b748142@kitware.com> <9efa70ce-e3cc-6b80-eac3-09be25952b83@kitware.com> Message-ID: On 10/10/2016 09:39 AM, Charles Huet wrote: > * the test CMake.CheckSourceTree does not work with Fastbuild, > but I could not get it to work with Ninja either, maybe I > have an environment problem ? It works with Ninja for me. Are you building CMake out-of-source? > * the test SimpleInstall requires the build tool to be able to > run multiple instances in the same hierarchy, which Fastbuild > does not support. I don't understand what you mean. > * It seems SimpleInstall-Stage2 depends upon SimpleInstall, > is this right ? Yes. -Brad From charles.huet at gmail.com Tue Oct 11 04:27:34 2016 From: charles.huet at gmail.com (Charles Huet) Date: Tue, 11 Oct 2016 08:27:34 +0000 Subject: [cmake-developers] FastBuild Generator In-Reply-To: References: <8d41e8e2-29c6-5188-43a7-f9f89a266917@kitware.com> <54439e7e-038c-1392-2d80-3f7609fb9956@kitware.com> <000a6011-505e-f4e9-cccc-bf1c3b748142@kitware.com> <9efa70ce-e3cc-6b80-eac3-09be25952b83@kitware.com> Message-ID: > It works with Ninja for me. Are you building CMake out-of-source? Yes. The complete list of commands I used is (from a clean build dir): cmake ..\CMake -G Ninja -DCMAKE_BUILD_TYPE=Debug ninja ctest -V -R CheckSourceTree In a MSVC2012 x64 command prompt. I used the installed CMake to both configure and test. the last message is : CMake Error at CheckSourceTreeTest.cmake:355 (message): test fails: local source tree non-additions: use git add before committing, or remove the files from the source tree >I don't understand what you mean. Like most CMake tests, the SimpleInstall test contains a CMakeLists, so the ctest process runs cmake and builds the test. This test has a custom_command which does 'cmake --build', so when you run the test, the build tool will call 'camke --build', which starts the build tool again, in the same folder hierarchy. This is not supported by fastbuild. Since it is highly paralellized, it uses a lock file to check if an instance is already running, in order to avoid all the common problems you would encounter by having two instances doing read/writes to its local database (for instance for its caching mechanism). Thus I am wondering how I can get this test to pass. Le lun. 10 oct. 2016 ? 19:13, Brad King a ?crit : > On 10/10/2016 09:39 AM, Charles Huet wrote: > > * the test CMake.CheckSourceTree does not work with Fastbuild, > > but I could not get it to work with Ninja either, maybe I > > have an environment problem ? > > It works with Ninja for me. Are you building CMake out-of-source? > > > * the test SimpleInstall requires the build tool to be able to > > run multiple instances in the same hierarchy, which Fastbuild > > does not support. > > I don't understand what you mean. > > > * It seems SimpleInstall-Stage2 depends upon SimpleInstall, > > is this right ? > > Yes. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Oct 11 09:39:09 2016 From: brad.king at kitware.com (Brad King) Date: Tue, 11 Oct 2016 09:39:09 -0400 Subject: [cmake-developers] FastBuild Generator In-Reply-To: References: <8d41e8e2-29c6-5188-43a7-f9f89a266917@kitware.com> <54439e7e-038c-1392-2d80-3f7609fb9956@kitware.com> <000a6011-505e-f4e9-cccc-bf1c3b748142@kitware.com> <9efa70ce-e3cc-6b80-eac3-09be25952b83@kitware.com> Message-ID: <0e127ce9-d277-d43f-5999-29db2bd5ab86@kitware.com> On 10/11/2016 04:27 AM, Charles Huet wrote: > CMake Error at CheckSourceTreeTest.cmake:355 (message): > test fails: local source tree non-additions: use git add before committing, > or remove the files from the source tree The purpose of the test is to fail if there are any local modifications to the source tree. Ignore it during local development. > This test has a custom_command which does 'cmake --build', so when you run the > test, the build tool will call 'camke --build', which starts the build tool again, > in the same folder hierarchy. > > This is not supported by fastbuild. The SimpleInstall and SimpleInstall-Stage2 tests need to be refactored to overcome this. Almost all of what they cover is also covered by the ExportImport test, so for now I think you can simply exclude the SimpleInstall tests with this generator. Please leave a comment explaining why so that future development can fix it. Thanks, -Brad From rleigh at codelibre.net Thu Oct 13 02:56:34 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Thu, 13 Oct 2016 07:56:34 +0100 Subject: [cmake-developers] [patch] Add support for Ice 3.6.3 to FindIce Message-ID: <67ad9ace-43a4-c832-a88a-903ccf6c9369@codelibre.net> Branch: ice-3.6.3. Pushed to next for testing. This is for a new point release recently issued by upstream. Regards, Roger From craig.scott at crascit.com Mon Oct 17 00:32:06 2016 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 17 Oct 2016 15:32:06 +1100 Subject: [cmake-developers] Java_INCLUDE_DIRS not populated by FindJava.cmake Message-ID: Unless I'm missing something, it would seem that even though the documentation says FindJava.cmake sets Java_INCLUDE_DIRS, I don't see anything in that file or things it includes which try to set it. Is the documentation out of date or is the FindJava.cmake implementation missing some things? Or am I just blind and missed something obvious? ;) In case anyone is wondering, the use case for me is when implementing a SWIG custom command to generate java wrappers, the jni.h header needs to be found by the generated sources. Cheers -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Oct 17 08:27:56 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 17 Oct 2016 08:27:56 -0400 Subject: [cmake-developers] Java_INCLUDE_DIRS not populated by FindJava.cmake In-Reply-To: References: Message-ID: <01be3c5b-7ddd-2894-0844-e7861491cd9b@kitware.com> On 10/17/2016 12:32 AM, Craig Scott wrote: > Unless I'm missing something, it would seem that even though > the documentation says FindJava.cmake sets Java_INCLUDE_DIRS The documentation was wrong and was fixed in 3.7: FindJava: Do not document variables we do not provide https://gitlab.kitware.com/cmake/cmake/commit/10a7459a -Brad From ben.boeckel at kitware.com Mon Oct 17 09:58:00 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 17 Oct 2016 09:58:00 -0400 Subject: [cmake-developers] Java_INCLUDE_DIRS not populated by FindJava.cmake In-Reply-To: References: Message-ID: <20161017135800.GB27621@megas.kitware.com> On Mon, Oct 17, 2016 at 15:32:06 +1100, Craig Scott wrote: > In case anyone is wondering, the use case for me is when implementing a > SWIG custom command to generate java wrappers, the jni.h header needs to be > found by the generated sources. There's FindJNI for that. --Ben From mfilimonov at nvidia.com Tue Oct 18 11:05:03 2016 From: mfilimonov at nvidia.com (Mikhail Filimonov) Date: Tue, 18 Oct 2016 15:05:03 +0000 Subject: [cmake-developers] Android Support In-Reply-To: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> References: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> Message-ID: Hi Brad, It looks that those commits broke CMake scripts used to generate Nsight Tegra projects: https://gitlab.kitware.com/cmake/cmake/issues/16371 Even CMake/tree/master/Tests/VSNsightTegra doesn't work with CMake ToT Regards, Mikhail Filimonov -----Original Message----- From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Brad King Sent: Friday, August 12, 2016 6:13 PM To: cmake-developers at cmake.org Subject: [cmake-developers] Android Support Hi Folks, I've implemented native support for cross-compiling to Android with CMake using either an Android NDK or an Android Standalone Toolchain. I plan to include this in the CMake 3.7 release. Please see the MR here: https://gitlab.kitware.com/cmake/cmake/merge_requests/62 This enables building with simple toolchain files, or even without one: $ cmake ../src -DCMAKE_SYSTEM_NAME=Android -DCMAKE_ANDROID_NDK=/path/to/ndk Note that interface compatibility with popular third-party Android toolchain files is a non-goal of this work (though we should not break them too much). Instead I'd like to make the support feel native within CMake. For example, the Android API level is naturally specified by CMAKE_SYSTEM_VERSION. If you're interested in this support please fetch the MR branch and try it out. The Help/manual/cmake-toolchains.7.rst manual has been updated with documentation about how to use this. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From brad.king at kitware.com Wed Oct 19 09:54:25 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 19 Oct 2016 09:54:25 -0400 Subject: [cmake-developers] [PATCH] preparations for native C# support In-Reply-To: References: <295a2badc7a641b59225c2a54ae9b6c5@DE013666.schaeffler.com> Message-ID: <82d6c9aa-e2bf-27d0-da51-e1466feac62e@kitware.com> On 09/23/2016 08:08 AM, Brad King wrote: > On 09/23/2016 06:29 AM, Stuermer, Michael SP/HZA-ZSEP wrote: >> These are some minor changes for native support of C# targets. >> The remaining C++ implementation will go into the Visual Studio >> target 10 generator class. > > I'd like to wait until after the 3.7 branch to start > introducing changes for a major new feature like this. I've applied the patch now, in two commits: VS: Add CSharp project uuid and file extension https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5618f712 VS: Add internal API for detecting "managed" projects https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2e2ba95c For further changes, please see the recently updated CONTRIBUTING.rst and submit merge requests through our GitLab instance. Thanks! -Brad From robert.maynard at kitware.com Wed Oct 19 15:52:19 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 19 Oct 2016 15:52:19 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.7.0-rc2 now ready for testing! Message-ID: I am proud to announce the second CMake 3.7 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.7 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.7/release/3.7.html Some of the more significant changes in CMake 3.7 are: * CMake now supports Cross Compiling for Android with simple toolchain files. * The "Ninja" generator learned to conditionally support Fortran when using a "ninja" tool that has the necessary features. See generator documentation for details. * The "if()" command gained new boolean comparison operations "LESS_EQUAL", "GREATER_EQUAL", "STRLESS_EQUAL", "STRGREATER_EQUAL", "VERSION_LESS_EQUAL", and "VERSION_GREATER_EQUAL". * The "try_compile()" command source file signature now honors configuration-specific flags (e.g. "CMAKE__FLAGS_DEBUG") in the generated test project. Previously only the default such flags for the current toolchain were used. See policy "CMP0066". * "Toolchain files" may now set "CMAKE_EXE_LINKER_FLAGS_INIT", "CMAKE_SHARED_LINKER_FLAGS_INIT", and "CMAKE_MODULE_LINKER_FLAGS_INIT" variables to initialize the "CMAKE_EXE_LINKER_FLAGS", "CMAKE_SHARED_LINKER_FLAGS", and "CMAKE_MODULE_LINKER_FLAGS" cache entries the first time a language is enabled in a build tree. * CTest now supports test fixtures through the new "FIXTURES_SETUP", "FIXTURES_CLEANUP" and "FIXTURES_REQUIRED" test properties. When using regular expressions or "--rerun-failed" to limit the tests to be run, a fixture's setup and cleanup tests will automatically be added to the execution set if any test requires that fixture. * We no longer provide Linux i386 binaries for download from "cmake.org" for new versions of CMake. * Vim support files "cmake-indent.vim", "cmake-syntax.vim", and "cmake-help.vim" have been removed in favor of the files now provided from the vim-cmake-syntax project. * Support for building CMake itself with some compilers was dropped: * Visual Studio 7.1 and 2005 -- superseded by VS 2008 and above * MinGW.org mingw32 -- superseded by MSYS2 mingw32 and mingw64 CMake still supports generating build systems for other projects using these compilers. CMake 3.7 Release Notes *********************** Changes made since CMake 3.6 include the following. New Features ============ Platforms --------- * CMake now supports Cross Compiling for Android with simple toolchain files. * The Clang compiler is now supported on AIX. Generators ---------- * The "Ninja" generator learned to conditionally support Fortran when using a "ninja" tool that has the necessary features. See generator documentation for details. * The "Ninja" generator learned to produce phony targets of the form "sub/dir/{test,install,package}" to drive the build of a subdirectory installation, test or packaging target. This is equivalent to "cd sub/dir; make {test,install,package}" with Makefile Generators. * The "Visual Studio 15" generator was added. This is experimental and based on Preview 4 because this version of VS has not been released. * Visual Studio Generators for VS 2010 and above learned to place ".natvis" source files into VS project files properly. * The "Xcode" generator's rudimentary Swift language support learned to honor a new "CMAKE_Swift_LANGUAGE_VERSION" variable to tell Xcode what version of Swift is used by the source. * The "CodeLite" generator gained a new "CMAKE_CODELITE_USE_TARGETS" option to change project creation from projects to targets. Commands -------- * The "add_custom_command()" command gained a new "DEPFILE" option that works with the "Ninja" generator to provide implicit dependency information to the build tool. * The "cmake_parse_arguments()" command gained a new "PARSE_ARGV" mode to read arguments directly from "ARGC" and "ARGV#" variables inside a "function()" body. * The "export()" command gained an "ANDROID_MK" option to generate "Android.mk" files referencing CMake-built libraries as prebuilts for the Android NDK build system. * The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "HTTPHEADER " and "USERPWD :" options. * The "find_library()" and "find_package()" commands learned to search in "lib32/" directories when the build targets a 32-bit architecture. See the "FIND_LIBRARY_USE_LIB32_PATHS" global property. * The "find_package()" command gained the possibility of sorting compatible libraries by "NAME" or by "NATURAL" sorting by setting the two new variables "CMAKE_FIND_PACKAGE_SORT_ORDER" and "CMAKE_FIND_PACKAGE_SORT_DIRECTION". * The "if()" command gained new boolean comparison operations "LESS_EQUAL", "GREATER_EQUAL", "STRLESS_EQUAL", "STRGREATER_EQUAL", "VERSION_LESS_EQUAL", and "VERSION_GREATER_EQUAL". * The "install()" command gained an "EXPORT_ANDROID_MK" subcommand to install "Android.mk" files referencing installed libraries as prebuilts for the Android NDK build system. * The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained support for the "%a" and "%b" placeholders. These are the abbreviated weekday and month names. * The "try_compile()" command source file signature now honors configuration-specific flags (e.g. "CMAKE__FLAGS_DEBUG") in the generated test project. Previously only the default such flags for the current toolchain were used. See policy "CMP0066". Variables --------- * Variable "CMAKE_FIND_PACKAGE_SORT_ORDER" was added to control the sorting mode of the "find_package()" command. * Variable "CMAKE_FIND_PACKAGE_SORT_DIRECTION" was added to control the sorting direction the "find_package()" command. * "Toolchain files" may now set a "CMAKE__FLAGS_INIT" variable to initialize the "CMAKE__FLAGS" cache entry the first time a language is enabled in a build tree. * "Toolchain files" may now set "CMAKE_EXE_LINKER_FLAGS_INIT", "CMAKE_SHARED_LINKER_FLAGS_INIT", and "CMAKE_MODULE_LINKER_FLAGS_INIT" variables to initialize the "CMAKE_EXE_LINKER_FLAGS", "CMAKE_SHARED_LINKER_FLAGS", and "CMAKE_MODULE_LINKER_FLAGS" cache entries the first time a language is enabled in a build tree. Properties ---------- * On Apple platforms the "BUNDLE_EXTENSION" target property now also applies to Frameworks and App Bundles. * A "BINARY_DIR" directory property was added to get the absolute path to the binary directory corresponding to the source directory on which the property is read. * A "BUILDSYSTEM_TARGETS" directory property was added to get the list of logical buildsystem target names added by the project in a directory. * A "LINK_WHAT_YOU_USE" target property and supporting "CMAKE_LINK_WHAT_YOU_USE" variable were introduced to detect (on UNIX) shared libraries that are linked but not needed by running "ldd -r -u". * A "SOURCE_DIR" directory property was added to get the absolute path to the source directory associated with a directory. * A "SUBDIRECTORIES" directory property was added to get the list of subdirectories added by a project in a directory. * A "VS_SDK_REFERENCES" target property was added to tell Visual Studio Generators to reference the named SDKs. * A "VS_TOOL_OVERRIDE" source file property was created to tell Visual Studio Generators what tool to use for a source file. * The "WINDOWS_EXPORT_ALL_SYMBOLS" target property now applies to executable targets with the "ENABLE_EXPORTS" property set. * A "XCODE_FILE_ATTRIBUTES" source file property was added to tell the "Xcode" generator to generate custom content in the Xcode project attributes for the file. Modules ------- * An "AndroidTestUtilities" module was added to manage transfer of test data to an Android device. * The "CheckFortranSourceCompiles" module macro "CHECK_Fortran_SOURCE_COMPILES" gained a "SRC_EXT" option to specify a custom test Fortran source file extension. * The "ExternalProject" module gained "HTTP_USERNAME" and "HTTP_PASSWORD" options to set http download credentials. * The "ExternalProject" module gained a "HTTP_HEADER" option to add http download headers. * The "FindBISON" module "BISON_TARGET" macro learned a new "REPORT_FILE" option to specify the bison "--report-file=" option. * The "FindBZip2" module now provides imported targets. * A "FindICU" module was introduced to find the International Components for Unicode (ICU) libraries and programs. * The "FindMatlab" module learned to find the SIMULINK and MAT components. * The "FindMatlab" module "matlab_add_mex()" command learned to add executables and modules. * The "FindMatlab" module "matlab_add_unit_test()" command learned to support inline Matlab test code. * The "FindOpenCL" module now provides imported targets. * The "FindOpenMP" module learned to detect the OpenMP version (specification date) from the compiler. * A "FindVulkan" module was added. * The "GenerateExportHeader" module learned a new "CUSTOM_CONTENT_FROM_VARIABLE" option to specify a variable containing custom content for inclusion in the generated header. * The "GNUInstallDirs" module gained a new "GNUInstallDirs_get_absolute_install_dir()" command. * The "UseJava" module gained APIs to "export" jar targets for use by external CMake projects. See the "install_jar_exports" and "export_jars" functions. CTest ----- * CTest now supports test fixtures through the new "FIXTURES_SETUP", "FIXTURES_CLEANUP" and "FIXTURES_REQUIRED" test properties. When using regular expressions or "--rerun-failed" to limit the tests to be run, a fixture's setup and cleanup tests will automatically be added to the execution set if any test requires that fixture. * The "ctest_configure()", "ctest_build()", "ctest_test()", "ctest_coverage()", and "ctest_upload()" commands gained a new "CAPTURE_CMAKE_ERROR" option to capture any errors that occur as the commands run into a variable and avoid affecting the return code of the "ctest(1)" process. CPack ----- * CPack gained a "productbuild" generator on OS X, configured by the "CPackProductBuild" module. * CPack gained a new "CPACK_PACKAGE_CHECKSUM" variable to enable generation of a checksum file for each package file. * The "CPackDeb" module learned to support long file names when archive format is set to GNU tar. See "CPACK_DEBIAN_ARCHIVE_TYPE" * The "CPackIFW" module gained a new "cpack_ifw_add_package_resources()" command to include additional resources in the installer binary. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "USER_INTERFACES" option to add a list of additonal pages to the IFW installer. * The "CPackRPM" module learned to generate debuginfo packages on demand. See "CPACK_RPM_DEBUGINFO_PACKAGE" and its per component version. * The "CPackRPM" module learned to generate source rpm (SRPM) packages on demand. See "CPACK_RPM_PACKAGE_SOURCES", "CPACK_RPM_SOURCE_PKG_BUILD_PARAMS" and "CPACK_RPM_SOURCE_PKG_PACKAGING_INSTALL_PREFIX". * The CPack NSIS generator now supports "CPACK_NSIS__INSTALL_DIRECTORY". This can be used to set component specific installation directories. * The CPack WIX generator now supports "CPACK_WIX_SKIP_PROGRAM_FOLDER" to allow specification of a custom absolute installation prefix outside of the ProgramFiles folders. * The CPack WIX generator now supports "CPACK_COMPONENT__DISABLED". This can be used to deselect a component from being installed by default. * The CPack WIX generator now supports "CPACK_WIX_PATCH_FILE" fragments for Feature elements. * The CPack WIX generator now supports "CPACK_WIX_ROOT_FEATURE_TITLE" and "CPACK_WIX_ROOT_FEATURE_DESCRIPTION" to allow the specification of a custom title and description for the root feature element. Other ----- * "cmake(1)" gained a "-E capabilities" option to provide a machine- readable (JSON) description of the capabilities of the cmake tool (available generators, etc.). * A new "cmake-server(7)" mode was added to provide semantic information about a CMake-generated buildsystem to clients through a JSON protocol. Currently all protocols are experimental and subject to change. * The "cmake(1)" command learned a "--trace-source=" option. * "ccmake(1)" learned to support vim-like navigation bindings. * "cmake-gui(1)" gained a button to open the generated project file for Visual Studio Generators and the "Xcode" generator. Deprecated and Removed Features =============================== * We no longer provide Linux i386 binaries for download from "cmake.org" for new versions of CMake. * Vim support files "cmake-indent.vim", "cmake-syntax.vim", and "cmake-help.vim" have been removed in favor of the files now provided from the vim-cmake-syntax project. * Support for building CMake itself with some compilers was dropped: * Visual Studio 7.1 and 2005 -- superseded by VS 2008 and above * MinGW.org mingw32 -- superseded by MSYS2 mingw32 and mingw64 CMake still supports generating build systems for other projects using these compilers. Other Changes ============= * The Fortran dependency scanner learned to support the syntax of Fortran Submodules. * Vim support files "indent/cmake.vim" and "syntax/cmake.vim" from the vim-cmake-syntax project are now distributed with CMake. ---------------------------------------------------------------------------- Changes made since CMake 3.7.0-rc1: Ben Boeckel (3): Ninja: Fix RC language depfile generation with cmcldeps ExternalProject: error out only if the property is unset ExternalProject: make SOURCE_SUBDIR directly appendable Brad King (15): QtIFW: Reference cmake.org via https in cmake.org.html Android: Suppress -Wattributes warnings in test case builds Android: Update libc++ include directories for NDK r13 Android: Fix support for cxxabi.h with libc++ Android: Record use of C++ by static libs in exported Android.mk files VS: Split flag table between v140 and v141 toolsets cmake-gui: Fix "extra" generator entries in drop-down list Ninja: Fix POST_BUILD commands on macOS Frameworks Help: Clarify `ctest_*` APPEND option behavior Help: Fix math(EXPR) documentation formatting FindwxWidgets: Fix finding unversioned VS-built directory prefixes VS: Fix NVIDIA Nsight Tegra Visual Studio Edition support Tests: Fix VSNsightTegra test on Android NDK r12b Tests: Add VSNsightTegra test for VS 2015 CMake 3.7.0-rc2 Chuck Atkins (2): Use find_package for JsonCpp and LibUV instead of include Set minimum version for LibUV to 1.0.0 Domen Vrankar (2): CPack/RPM debuginfo package objdump error suppression CPack/RPM debuginfo package without binaries Gregor Jasny (1): OS X: Do not try to set deployment target when cross-compiling Jamie Snape (1): Honor LINK_WHAT_YOU_USE when set to OFF KWSys Upstream (1): KWSys 2016-10-07 (dfe9b386) Martin Joly (1): FindProtobuf: Fix protobuf_generate_*() to handle subdirs Max Smolens (1): ExternalProject: Fix regression in passing list to CMAKE_CACHE_ARGS Raffi Enficiaud (3): FindMatlab: remove SIMULINK path from cache when FindMatlab is reconfigured FindMatlab: small documentation fixes Help: Extend 3.7 release notes for FindMatlab Roger Leigh (1): FindIce: Add support for version 3.6.3 Roman W?ger (1): VS: Use absolute target-specific directory for `resources.pri` Stephen Kelly (2): cmGlobalGenerator: Add API to get settings from top-level cmMakefile Codelite: Consume the CMAKE_CODELITE_USE_TARGETS setting globally Tobias Hunger (2): server-mode: Improve shutdown behavior server-mode: Fix named pipe mode From irwin at beluga.phys.uvic.ca Thu Oct 20 14:30:58 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 20 Oct 2016 11:30:58 -0700 (PDT) Subject: [cmake-developers] Current deficiencies of automoc Message-ID: This is a follow up to the CMake mailing list thread with the subject line "Cannot get automoc to work properly with recommended Qt5 support method". The deficiency I found with automoc is (as far as I can tell) it does not properly handle the case where the header that should be processed by moc is located in a different source-tree directory than the source file that includes that header. For PLplot I have worked around this deficiency by abandoning use of automoc altogether and instead used custom targets that invoked qt5_wrap_cpp. But the whole concept of automoc is far superior to a custom target approach so this is a plea to the CMake developers to fix the above deficiency in automoc. To be specific here is the way I believe automoc should work. If #include "moc_.cpp" is found in a source file under automoc control, then if moc_.cpp could not be found in any of the include directories for the target, then search those include directories (including source-tree equivalents of build-tree include directories) for .h, run moc on that file and place the result moc_.cpp in the build directory corresponding to . So the result is moc would be run just once on the correct header file with the moc_.cpp result stored in one logical location no matter how many different source files in different directories have code with the above #include. My experiments showed that automoc currently falls short of this behaviour and only works if .h is in the current source directory and I consider this deficiency to be a serious bug in automoc. Furthermore, the documentation of automoc needs improving to explicitly name the header file being processed by moc when encountering the above #include. Furthermore, the directories searched for that header file should be stated. For the current buggy state of automoc that would just be the current source tree, but once the bug was fixed it would be everything mentioned in include_directories and their source-tree equivalents. I hate to lose issues that can be trivially fixed on bug trackers, but if the above automoc fix and automoc documentation fix are not trivial, then I would be willing to incorporate the above and any further discussion here into an official CMake bug report. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From brad.king at kitware.com Thu Oct 20 15:08:24 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 20 Oct 2016 15:08:24 -0400 Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: References: Message-ID: On 10/20/2016 02:30 PM, Alan W. Irwin wrote: > The deficiency I found with automoc is (as far as I can tell) it does > not properly handle the case where the header that should be processed > by moc is located in a different source-tree directory than the source > file that includes that header. [snip] > To be specific here is the way I believe automoc should work. If > > #include "moc_.cpp" > > is found in a source file under automoc > control, then if moc_.cpp could not be found in any of the > include directories for the target, then search those include > directories (including source-tree equivalents of build-tree include > directories) for .h, run moc on that file and place the result > moc_.cpp in the build directory corresponding to . [snip] > this is a plea to the CMake developers to fix the above deficiency Adding to Cc some folks that may have worked on automoc features in the past. I have little understanding of the feature myself. Unless someone steps forward to implement this it is unlikely to be fixed. > I hate to lose issues that can be trivially fixed on bug trackers, but > if the above automoc fix and automoc documentation fix are not > trivial, then I would be willing to incorporate the above and any > further discussion here into an official CMake bug report. Please construct a minimal/complete example source tree/tarball that demonstrate the layout you'd like to have work. That will be helpful in constructing such a bug report. -Brad From tobias.hunger at gmail.com Thu Oct 20 15:17:30 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Thu, 20 Oct 2016 21:17:30 +0200 Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: References: Message-ID: Hi! Am 20.10.2016 21:08 schrieb "Brad King" : > On 10/20/2016 02:30 PM, Alan W. Irwin wrote: > > To be specific here is the way I believe automoc should work. If > > > > #include "moc_.cpp" > > > > is found in a source file under automoc > > control, then if moc_.cpp could not be found in any of the > > include directories for the target, then search those include > > directories (including source-tree equivalents of build-tree include > > directories) for .h, run moc on that file and place the result > > moc_.cpp in the build directory corresponding to . > [snip] > > this is a plea to the CMake developers to fix the above deficiency If you include moc_name.cpp, then you need to run moc on this *source* file. That is what allows you to have private classes in your source file that derive from QObject. The headers should be covered by automoc automatically: Any header containing a Q_OBJECT macro should be moc-ed. So there should not be any need to include moc_*.cpp files in source files for any header. At least that is how I always use this with qmake, but I am hardly an expert on how moc should work:-) Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Thu Oct 20 15:35:33 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 20 Oct 2016 14:35:33 -0500 Subject: [cmake-developers] Android Support In-Reply-To: References: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> Message-ID: So using takanome's cmake toolchain, he had support for native app glue. Does CMake offer support for this now? I was able to generate but I'm not able to load in native app glue from the NDK. On Tue, Oct 18, 2016 at 10:05 AM, Mikhail Filimonov wrote: > Hi Brad, > It looks that those commits broke CMake scripts used to generate Nsight Tegra projects: > https://gitlab.kitware.com/cmake/cmake/issues/16371 > Even CMake/tree/master/Tests/VSNsightTegra doesn't work with CMake ToT > > Regards, > Mikhail Filimonov > > -----Original Message----- > From: cmake-developers [mailto:cmake-developers-bounces at cmake.org] On Behalf Of Brad King > Sent: Friday, August 12, 2016 6:13 PM > To: cmake-developers at cmake.org > Subject: [cmake-developers] Android Support > > Hi Folks, > > I've implemented native support for cross-compiling to Android with CMake using either an Android NDK or an Android Standalone Toolchain. > I plan to include this in the CMake 3.7 release. > > Please see the MR here: > > https://gitlab.kitware.com/cmake/cmake/merge_requests/62 > > This enables building with simple toolchain files, or even without one: > > $ cmake ../src -DCMAKE_SYSTEM_NAME=Android -DCMAKE_ANDROID_NDK=/path/to/ndk > > Note that interface compatibility with popular third-party Android toolchain files is a non-goal of this work (though we should not break them too much). > Instead I'd like to make the support feel native within CMake. For example, the Android API level is naturally specified by CMAKE_SYSTEM_VERSION. > > If you're interested in this support please fetch the MR branch and try it out. The Help/manual/cmake-toolchains.7.rst manual has been updated with documentation about how to use this. > > -Brad > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > ----------------------------------------------------------------------------------- > This email message is for the sole use of the intended recipient(s) and may contain > confidential information. Any unauthorized review, use, disclosure or distribution > is prohibited. If you are not the intended recipient, please contact the sender by > reply email and destroy all copies of the original message. > ----------------------------------------------------------------------------------- > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers From brad.king at kitware.com Thu Oct 20 15:51:12 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 20 Oct 2016 15:51:12 -0400 Subject: [cmake-developers] Android Support In-Reply-To: References: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> Message-ID: <5b221fa0-fbe4-ef71-b15d-2f2a2e58466b@kitware.com> On 10/20/2016 03:35 PM, Robert Dailey wrote: > So using takanome's cmake toolchain, he had support for native app > glue. Does CMake offer support for this now? I was able to generate > but I'm not able to load in native app glue from the NDK. We don't currently offer a first-class interface for it but the locations are available relative to CMAKE_ANDROID_NDK: ``` include_directories("${CMAKE_ANDROID_NDK}/sources/android/native_app_glue") set(my_sources ... ${CMAKE_ANDROID_NDK}/sources/android/native_app_glue/android_native_app_glue.c ) ``` Similarly for cpufeatures and ndk_helper. That is why https://github.com/taka-no-me/android-cmake/blob/master/AndroidNdkModules.cmake simply wraps around hard-coded locations. -Brad From irwin at beluga.phys.uvic.ca Thu Oct 20 15:49:16 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 20 Oct 2016 12:49:16 -0700 (PDT) Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: References: Message-ID: Disclaimer: I am no expert on any of this stuff so the conclusions I have drawn are based on the particular experiments I have done and are probably limited because of that. On 2016-10-20 21:17+0200 Tobias Hunger wrote: > Hi! > > Am 20.10.2016 21:08 schrieb "Brad King" : >> On 10/20/2016 02:30 PM, Alan W. Irwin wrote: >>> To be specific here is the way I believe automoc should work. If >>> >>> #include "moc_.cpp" >>> >>> is found in a source file under automoc >>> control, then if moc_.cpp could not be found in any of the >>> include directories for the target, then search those include >>> directories (including source-tree equivalents of build-tree include >>> directories) for .h, run moc on that file and place the result >>> moc_.cpp in the build directory corresponding to . >> [snip] >>> this is a plea to the CMake developers to fix the above deficiency > > If you include moc_name.cpp, then you need to run moc on this *source* > file. That is what allows you to have private classes in your source file > that derive from QObject. That is not the case I am concerned with which is the source file has no direct reference to the Q_OBJECT macro. Instead it #includes a header that uses that macro. My experiments (see disclaimer above) with that case show moc needs to be run directly on the header, and the resulting generated file needs to be #included in the source file. > > The headers should be covered by automoc automatically: Any header > containing a Q_OBJECT macro should be moc-ed. So there should not be any > need to include moc_*.cpp files in source files for any header. Actually my experiments show the headers using the Q_OBJECT macro are completely ignored by automoc unless you specifically put #include moc_.cpp in the source file, and that works only if .h is in the current directory. And I want to see that severe current directory limitation removed as above. > > At least that is how I always use this with qmake, but I am hardly an > expert on how moc should work:-) That lack of expertise goes double for me. :-) See disclaimer above. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From rcdailey.lists at gmail.com Thu Oct 20 16:19:11 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 20 Oct 2016 15:19:11 -0500 Subject: [cmake-developers] Android Support In-Reply-To: <5b221fa0-fbe4-ef71-b15d-2f2a2e58466b@kitware.com> References: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> <5b221fa0-fbe4-ef71-b15d-2f2a2e58466b@kitware.com> Message-ID: On Thu, Oct 20, 2016 at 2:51 PM, Brad King wrote: > On 10/20/2016 03:35 PM, Robert Dailey wrote: >> So using takanome's cmake toolchain, he had support for native app >> glue. Does CMake offer support for this now? I was able to generate >> but I'm not able to load in native app glue from the NDK. > > We don't currently offer a first-class interface for it but the locations > are available relative to CMAKE_ANDROID_NDK: > > ``` > include_directories("${CMAKE_ANDROID_NDK}/sources/android/native_app_glue") > set(my_sources ... > ${CMAKE_ANDROID_NDK}/sources/android/native_app_glue/android_native_app_glue.c > ) > ``` > > Similarly for cpufeatures and ndk_helper. > > That is why > > https://github.com/taka-no-me/android-cmake/blob/master/AndroidNdkModules.cmake > > simply wraps around hard-coded locations. Thanks a bunch Brad. I simply modified AndroidNdkModules.cmake to use CMAKE_ANDROID_NDK and it works perfect now. Another question: Will CMake's android support only work with official NDK releases? Or can I expect it to function with unofficial NDKs such as Crystax? From irwin at beluga.phys.uvic.ca Thu Oct 20 16:24:27 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 20 Oct 2016 13:24:27 -0700 (PDT) Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: References: Message-ID: On 2016-10-20 15:08-0400 Brad King wrote: > Please construct a minimal/complete example source tree/tarball > that demonstrate the layout you'd like to have work. That will > be helpful in constructing such a bug report. A minimal example illustrating the issue is a great idea. However, the problem is I am not much of an expert on C++ or Qt5 so reducing the PLplot Qt5 example source code to such a minimal example is going to be somewhat time consuming for me. So unless someone here lends me a hand by implementing the needed simple Qt5 source code, I first plan to look through the many Qt5 demos accessible on the web to see if any of them qualify in terms of no Q_OBJECT in source, but Q_OBJECT in #included header, and as a last resort I will attempt to simplify the PLplot Qt5 example source code. Then follow up with implementing the CMake aspects of that simple example which should be trivial for me. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From brad.king at kitware.com Thu Oct 20 16:25:11 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 20 Oct 2016 16:25:11 -0400 Subject: [cmake-developers] Android Support In-Reply-To: References: <3144149b-a4f9-0f3b-0a85-9f1eefc2b0ad@kitware.com> <5b221fa0-fbe4-ef71-b15d-2f2a2e58466b@kitware.com> Message-ID: On 10/20/2016 04:19 PM, Robert Dailey wrote: > Another question: Will CMake's android support only work with official > NDK releases? Or can I expect it to function with unofficial NDKs such > as Crystax? We assume the official NDK layout. If an unofficial NDK has the same layout it may work. Otherwise additional work may be needed. -Brad From irwin at beluga.phys.uvic.ca Thu Oct 20 19:29:39 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 20 Oct 2016 16:29:39 -0700 (PDT) Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: References: Message-ID: On 2016-10-20 15:08-0400 Brad King wrote: > Please construct a minimal/complete example source tree/tarball > that demonstrate the layout you'd like to have work. That will > be helpful in constructing such a bug report. OK. I have attached the requested minimal example to serve as the basis for further discussion. The files in the tarball are test_qt5/ test_qt5/include/ test_qt5/include/test_q_object.h test_qt5/main.cpp test_qt5/CMakeLists.txt include/test_q_object.h is a header that contains a minimal use of Q_OBJECT. (Likely too minimal so I will need help with that see below.) main.cpp is a "hello-world" example that #includes that header. It also #includes the moc-generated moc_test_q_object.cpp. The USE_AUTOMOC option for this test project defaults to OFF. In that default case this test project is set up so that the qt5_wrap_cpp is called instead of using automoc, and the result is the compilation works fine (all headers and files generated by moc are found with no issues) but there is a link error CMakeFiles/helloworld.dir/main.cpp.o:(.data.rel.ro._ZTV7MyClass[_ZTV7MyClass]+0x28): undefined reference to MyClass::~MyClass()' which likely has to do with include/test_q_object.h being too minimal. I would appreciate help with that issue to complete this example, but that is a side issue and the principal result is the compile (as opposed to the link) was a success with the default -DUSE_AUTOMOC=OFF. However, if you try -DUSE_AUTOMOC=ON with this project the compile step (before it even gets to the link step) fails as follows: Automatic moc for target helloworld /home/software/cmake/install-3.5.2/bin/cmake -E cmake_autogen /home/software/plplot/HEAD/test_qt5/build_dir/CMakeFiles/helloworld_automoc.dir/ "" AUTOGEN: Checking /home/software/plplot/HEAD/test_qt5/main.cpp AUTOGEN: error: /home/software/plplot/HEAD/test_qt5/main.cpp The file includes the moc file "moc_test_q_object.cpp", but could not find header "test_q_object{.h,.hh,.h++,.hm,.hpp,.hxx,.in,.txx}" in /home/software/plplot/HEAD/test_qt5/ I hope a simple solution to this deficiency of the current automoc can be found using the following ideas (copied from my previous post to keep this self-contained). If #include "moc_.cpp" is found in a source file under automoc control, then if moc_.cpp could not be found in any of the include directories for the target, then search those include directories (including source-tree equivalents of build-tree include directories) for .h, run moc on that file and place the result moc_.cpp in the build directory corresponding to . So the result is moc would be run just once on the correct header file with the moc_.cpp result stored in one logical location no matter how many different source files in different directories have code with the above #include. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: test_qt5.tar.gz Type: application/x-gtar-compressed Size: 1149 bytes Desc: compressed tarball containing a minimal example of automoc compile failure URL: From seblist at xwmw.org Fri Oct 21 04:10:27 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Fri, 21 Oct 2016 10:10:27 +0200 Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: References: Message-ID: <77fefbf5-124c-44c4-288f-dae087d3c7f5@xwmw.org> Am 21.10.2016 um 01:29 schrieb Alan W. Irwin: > On 2016-10-20 15:08-0400 Brad King wrote: > >> Please construct a minimal/complete example source tree/tarball >> that demonstrate the layout you'd like to have work. That will >> be helpful in constructing such a bug report. > > OK. I have attached the requested minimal example to serve as the > basis for further discussion. The files in the tarball are > > test_qt5/ > test_qt5/include/ > test_qt5/include/test_q_object.h > test_qt5/main.cpp > test_qt5/CMakeLists.txt > > include/test_q_object.h is a header that contains a minimal use of > Q_OBJECT. (Likely too minimal so I will need help with that see below.) > main.cpp is a "hello-world" example that #includes that header. It also > #includes > the moc-generated moc_test_q_object.cpp. > > The USE_AUTOMOC option for this test project defaults to OFF. In that > default case this test project is set up so that the qt5_wrap_cpp is > called instead of using automoc, and the > result is the compilation works fine (all headers and files generated > by moc are found with no issues) but there is a link error > > CMakeFiles/helloworld.dir/main.cpp.o:(.data.rel.ro._ZTV7MyClass[_ZTV7MyClass]+0x28): > > undefined reference to MyClass::~MyClass()' > > which likely has to do with include/test_q_object.h being too minimal. > I would appreciate help with that issue to complete this example, but > that is a side issue and the principal result is the compile (as > opposed to the link) was a success with the default -DUSE_AUTOMOC=OFF. > > However, if you try -DUSE_AUTOMOC=ON with this project the compile > step (before it even gets to the link step) fails as follows: > > Automatic moc for target helloworld > /home/software/cmake/install-3.5.2/bin/cmake -E cmake_autogen > /home/software/plplot/HEAD/test_qt5/build_dir/CMakeFiles/helloworld_automoc.dir/ > "" > AUTOGEN: Checking /home/software/plplot/HEAD/test_qt5/main.cpp > AUTOGEN: error: /home/software/plplot/HEAD/test_qt5/main.cpp The file > includes the moc file "moc_test_q_object.cpp", but could not find header > "test_q_object{.h,.hh,.h++,.hm,.hpp,.hxx,.in,.txx}" in > /home/software/plplot/HEAD/test_qt5/ > > I hope a simple solution to this deficiency of the current automoc can > be found using the following ideas (copied from my previous post to > keep this self-contained). > > If > > #include "moc_.cpp" > > is found in a source file under automoc > control, then if moc_.cpp could not be found in any of the > include directories for the target, then search those include > directories (including source-tree equivalents of build-tree include > directories) for .h, run moc on that file and place the result > moc_.cpp in the build directory corresponding to . > > So the result is moc would be run just once on the correct header file > with the moc_.cpp result stored in one logical location no > matter how many different source files in different directories have > code with the above #include. > > Alan > __________________________ > Alan W. Irwin Hi! I tried your example. It isn't complete, test_q_object.h needs an #include and a constructor/destructor definition, e.g.: MyClass(QObject *parent = 0) {;} ~MyClass(){;} With regards to automoc the #include "moc_test_q_object.cpp" in the end should not be neccessary since #include "test_q_object.h" already references to the header. The problem is that this reference is not a direct path from the source file but relies on include_directories. CMake does not seem to populate automoc's scan list with files from include_directories. I tried to figure out why but this is quite complex. A quick fix for the example would be to explicitly add the headers-to-moc to the sources list. - add_executable(helloworld main.cpp) + add_executable(helloworld main.cpp + ${CMAKE_SOURCE_DIR}/include/test_q_object.h) The #include "moc_test_q_object.cpp" in main.cpp can be removed then. -Sebastian From jeanmichael.celerier at gmail.com Fri Oct 21 05:02:51 2016 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Fri, 21 Oct 2016 11:02:51 +0200 Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: <77fefbf5-124c-44c4-288f-dae087d3c7f5@xwmw.org> References: <77fefbf5-124c-44c4-288f-dae087d3c7f5@xwmw.org> Message-ID: On Fri, Oct 21, 2016 at 10:10 AM, Sebastian Holtermann wrote: > > A quick fix for the example would be to explicitly add the > headers-to-moc to the sources list. This has the nice side-effect of making your project much easier to use in IDEs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Fri Oct 21 07:39:00 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 21 Oct 2016 04:39:00 -0700 (PDT) Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: References: Message-ID: On 2016-10-21 09:42+0200 Sebastian Holtermann wrote: [...] > Hi! > > I tried your example. > It isn't complete, test_q_object.h needs an > #include > and a constructor/destructor definition, e.g.: > MyClass(QObject *parent = 0) {;} > ~MyClass(){;} Hi Sebastian: Thanks for that fix which indeed solves the linking issue. > > With regards to automoc the > #include "moc_test_q_object.cpp" > in the end should not be neccessary since > #include "test_q_object.h" > already references to the header. > The problem is that this reference is not a direct path from the > source file but relies on include_directories. > CMake does not seem to populate automoc's scan list with files > from include_directories. > I tried to figure out why but this is quite complex. I hope you are able to fix this along the lines I have mentioned (which includes putting all generated results in the build tree corresponding to the header) since using #include "moc_test_q_object.cpp" in main.cpp is currently the only documented way to use automoc (see, e.g., ). > > A quick fix for the example would be to explicitly add the > headers-to-moc to the sources list. > - add_executable(helloworld main.cpp) > + add_executable(helloworld main.cpp > + ${CMAKE_SOURCE_DIR}/include/test_q_object.h) > > The #include "moc_test_q_object.cpp" in main.cpp can be removed then. That idea (specifying the fullpath of the original header as part of the source code) does indeed make automoc work properly. "ldd -r helloworld" shows no linking issues, I can run the executable without issues, and "nm --defined-only --demangle helloworld |less" shows lots of references to MyClass. I attach a revised tarball example with the test_q_object.h fix and this change. However, there are still two problems with this method which I will call the fullpath method to distinguish it from the documented #include method. 1. The automoc documentation at only documents the #include method (which doesn't work for the current test case nor for PLplot), and the above working fullpath method is not documented at all there. 2. With that fullpath method, The automoc-generated helloworld_automoc.cpp and moc_test_q_object.cpp are located in ${CMAKE_CURRENT_BINARY_DIR} (the build directory where the helloworld executable is located), and that is not ideal. For example, I have no idea how the compile process found that directory to include those files since that directory is specifically not mentioned in include_directories for this project. It also means that for executables and libraries in a variety of directories that include ${CMAKE_SOURCE_DIR}/include/test_q_object.h in their source list will be generating duplicate moc_test_q_object.cpp in a variety of different directories. Thus, it seems to me the more logical location for these two automoc-generated files would be ${CMAKE_BINARY_DIR}/include. Note that ${CMAKE_BINARY_DIR}/include/helloworld_automoc.cpp is unique (because the target name helloworld must be unique), and ${CMAKE_BINARY_DIR}/include/moc_test_q_object.cpp is also unique because it corresponds to the unique filename ${CMAKE_SOURCE_DIR}/include/test_q_object.h. So this means there is no chance of nameclashes with this location (although to be fair that is also true of the current location for these two generated files). This suggested location is also the one I suggest for the #include method, and that consistency of location between the two methods (and also the qt5_wrap_cpp method) is important. Of course, if ${CMAKE_SOURCE_DIR}/include/test_q_object.h appears in source lists for lots of different executables and libraries, automoc has to test whether ${CMAKE_BINARY_DIR}/include/moc_test_q_object.cpp has already been generated so that generation is only done once. I presume such a check would be easy to implement if automoc doesn't do that already. In sum, I hope you are willing to fix the currently documented automoc "#include" method so it puts all generated results in the build tree corresponding to the header, update the automoc documentation so you also mention the "fullpath" alternative, and also similarly fix that method so the location of the two generated files is in the build directory corresponding to the header rather than the build directory corresponding to the source file. My apologies for making suggestions for improvement without being able to help you with the implementation (except testing of results), but my C++ skills and CMake developer skills are just not up to it (as you could probably tell from the required test_q_object.h fix you had to suggest.) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: version2_testqt5.tar.gz Type: application/x-gtar-compressed Size: 1159 bytes Desc: tarball containing version 2 of simple test project for automoc URL: From joubert.sy at gmail.com Fri Oct 21 09:51:20 2016 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Fri, 21 Oct 2016 15:51:20 +0200 Subject: [cmake-developers] [PATCH] Help: Fix cmake-server typo and message type consistency Message-ID: Hello, Please find attached a patch that corrects a typo and a inconsistency in a code snippet. The patch is based on the 'release' branch. Regards, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Help-Fix-cmake-server-typo-and-message-type-consiste.patch Type: text/x-patch Size: 1216 bytes Desc: not available URL: From brad.king at kitware.com Fri Oct 21 10:25:19 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 21 Oct 2016 10:25:19 -0400 Subject: [cmake-developers] [PATCH] Help: Fix cmake-server typo and message type consistency In-Reply-To: References: Message-ID: <871e1651-3f1c-197c-7d06-3bf989c74cfd@kitware.com> On 10/21/2016 09:51 AM, Sylvain Joubert wrote: > Please find attached a patch that corrects a typo and a inconsistency > in a code snippet. Thanks! BTW, since you last contributed we've switched from using the mailing list for patches to using GitLab merge requests: https://gitlab.kitware.com/cmake/cmake Please see the updated CONTRIBUTING.rst. > -This requist will generate build system files in the build directory and > +This request will generate build system files in the build directory and Good catch. > - {"type":"project"} > + {"type":"codemodel"} ... > - "inReplyTo":"project", > + "inReplyTo":"codemodel", Tobias, please confirm that this change is correct. It looks like `"project"` is used in the prose shortly after those hunks. Should those instances be changed too? Thanks, -Brad From tobias.hunger at gmail.com Fri Oct 21 10:30:10 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Fri, 21 Oct 2016 16:30:10 +0200 Subject: [cmake-developers] [PATCH] Help: Fix cmake-server typo and message type consistency In-Reply-To: <871e1651-3f1c-197c-7d06-3bf989c74cfd@kitware.com> References: <871e1651-3f1c-197c-7d06-3bf989c74cfd@kitware.com> Message-ID: Yes, this change is correct. I stumbled over this myself this afternoon. I changed the name pretty late before submitting the patches and apparently mused some occurrences in the docs:-( Best regards, Tobias Sylvain: Thanks for noticing and sending in patches to correct the mistakes you found! -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Oct 21 10:37:21 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 21 Oct 2016 10:37:21 -0400 Subject: [cmake-developers] [PATCH] Help: Fix cmake-server typo and message type consistency In-Reply-To: References: <871e1651-3f1c-197c-7d06-3bf989c74cfd@kitware.com> Message-ID: <7197c7b9-3224-d46e-3124-080d00bebd5d@kitware.com> On 10/21/2016 10:30 AM, Tobias Hunger wrote: > Yes, this change is correct. I stumbled over this myself this afternoon. Thanks. I've submitted a MR with the prose updated too here: https://gitlab.kitware.com/cmake/cmake/merge_requests/191 -Brad From nagger at gmx.de Fri Oct 21 19:01:03 2016 From: nagger at gmx.de (Nagger) Date: Sat, 22 Oct 2016 01:01:03 +0200 Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: References: Message-ID: <7e97e21c-ca92-6267-82cd-cba646ac0af6@gmx.de> Am 21.10.2016 um 13:39 schrieb Alan W. Irwin: > On 2016-10-21 09:42+0200 Sebastian Holtermann wrote: >> headers-to-moc to the sources list. >> - add_executable(helloworld main.cpp) >> + add_executable(helloworld main.cpp >> + ${CMAKE_SOURCE_DIR}/include/test_q_object.h) >> >> The #include "moc_test_q_object.cpp" in main.cpp can be removed then. > > 1. The automoc documentation at > only > documents the #include method (which doesn't work for the current test > case nor for PLplot), and the above working fullpath method is not > documented at all there. At least in cmake-qt(7) [1] this is documented: If a |Q_OBJECT| or |Q_GADGET| macro is found in a header file, |moc| will be run on the file. The result will be put into a file named according to |moc_.cpp|. If the macro is found in a C++ implementation file, the moc output will be put into a file named according to |.moc|, following the Qt conventions. The |moc file| may be included by the user in the C++ implementation file with a preprocessor |#include|. If it is not so included, it will be added to a separate file which is compiled into the target. Marc [1] https://cmake.org/cmake/help/v3.6/manual/cmake-qt.7.html#automoc -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Fri Oct 21 21:01:03 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 21 Oct 2016 18:01:03 -0700 (PDT) Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: References: Message-ID: On 2016-10-21 23:54+0200 el.bartho at gmx.de wrote: > >> 1. The automoc documentation at >> only >> documents the #include method (which doesn't work for the current test >> case nor for PLplot), and the above working fullpath method is not >> documented at all there. > > At least in cmake-qt(7) [1] this is documented: > > If a |Q_OBJECT| or |Q_GADGET| macro is found in a header file, |moc| will be > run on the file. The result will be put into a file named according to > |moc_.cpp|. If the macro is found in a C++ implementation file, the > moc output will be put into a file named according to |.moc|, > following the Qt conventions. The |moc file| may be included by the user in > the C++ implementation file with a preprocessor |#include|. If it is not so > included, it will be added to a separate file which is compiled into the > target. Hi Marc: I have put my response to your comment back on the list where I think it belongs. I don't agree with your above conclusion. The above remarks immediately refer to header files and imply automoc scans them to find the ones that contain the Q_OBJECT macro and certainly does not imply the user must list the files to be scanned directly as fullpaths in the add_executable (or add_library) command. And the last sentence implies that if the so-called #include method is not used, then automoc will figure everything out for itself, i.e., the fullpath method allowing the user to specify which headers are scanned by moc is not documented here at all. If the first sentence in the above paragraph had referred to header files appearing in the list of source files for add_executable or add_library and/or if the last sentence in the above paragraph had been replaced by "If it is not so included, the user must put the fullpaths of the headers that need moc processing in the source list for add_executable or add_library." then I would agree with your conclusion, but that type of specific documentation of the fullpath method is just not currently in the cmake-qt documentation. By the way, I have been able to show that the "leaving it completely to automoc" method documented above does not work with the second (fixed) version of my simple example, and I urge you to try that experiment also by making the following additional change (from "fullpath" to "leave it to automoc") - add_executable(helloworld main.cpp ${CMAKE_SOURCE_DIR}/include/test_q_object.h) + add_executable(helloworld main.cpp) For this case nm shows everything in test_q_object.h is completely ignored by automoc despite the '#include "test_q_object.h"' in main.cpp. N.B. the above documentation is likely correct and the "leave it to automoc" method should work but it doesn't for this simple example, and that is likely due to the same bug that keeps the "#include" method from working for this simple example of an include file in a separate directory. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From sascha at cunz-rad.com Fri Oct 21 22:35:45 2016 From: sascha at cunz-rad.com (Sascha Cunz) Date: Sat, 22 Oct 2016 03:35:45 +0100 Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: References: Message-ID: <52589C96-718A-431A-BD75-34BAF4B9BE10@cunz-rad.com> Hi Alan, > On 22 Oct 2016, at 02:01, Alan W. Irwin wrote: > ? > I don't agree with your above conclusion. The above remarks immediately refer to > header files and imply automoc scans them Which it does :) > to find the ones that contain the Q_OBJECT macro and and/or Q_GADGET. > certainly does not imply the user must list the files to be scanned directly Right. And it?s not required most of the time. But automoc must know where to look for. It can only do that if something tells it where to look - If your header files are in the same directory as the source files, they?re getting added and scanned automatically (Not related to automoc, actually). See the minimum example below. If, like in your example, the files are in different directories, you have to add them to add_executable / add_library in order to let automoc know that it shall scan them. > as fullpaths in the add_executable (or add_library) command. The full path requirement here is a false perception. It will certainly do no harm to be explicit with the parameters to add_executable/add_library, but the default is to search relative to ${CMAKE_CURRENT_SOURCE_DIR}. And as mentioned by others in the thread, it?s a good idea to explicitly list your header files. As this will improve how certain IDEs show your project. The above _is_ actually the default behaviour that suites 95% of the cases where moc needs to be run. For the other cases, where Q_OBJECT / Q_GADGET is used inside a .cpp file, there is the option to #include a file following the pattern ?moc_%s.cpp? where %s is the name of the containing C++ source file without extension. > And the last sentence implies that if the so-called #include method is not used, then > automoc will figure everything out for itself, i.e., the fullpath method allowing the > user to specify which headers are scanned by moc is not documented here at all. From cmake-qt[7]: The AUTOMOC target property controls whether cmake(1) inspects the C++ files in the target to determine if they require moc to be run. I clearly states that it will scan the files added to the target. However, I see that the take away from the thread should probably be that the wording in the documentation could be improved. To be fair, it is in general very hard for someone who knows a tool and it?s complete history to write documentation that someone who doesn?t have that prior knowledge is able to understand. So, improving things here usually relies on input like yours to figure out what actually has to be improved. I could imagine that in this case, the term ?C++ files? didn?t trigger an association to header files. Cheers, Sascha P.S.: Since both Qt4 and Qt5 integrations of Qt nowadays use generator expressions, in my experience it?s close to impossible to accurately mimic automoc behaviour inside CMakeLists.txt. This is though required in one specific scenario, but I don?t think this can be fixed unless automoc would be rewritten from scratch (If target T has a custom rule that creates a header file, which turns out to be run through moc - automoc, which is a separate target that T depends on, can impossibly scan the file that [through target-dependency] will be generated _after_ the automoc target is built). Minimal working example: $ tail -n50 CMakeLists.txt t.cpp t.hpp ==> CMakeLists.txt <== cmake_minimum_required(VERSION 3.6) project(X) set(CMAKE_AUTOMOC TRUE) find_package(Qt5Core) add_executable(a t.cpp) target_link_libraries(a Qt5::Core) ==> t.cpp <== #include "t.hpp" int main(int,char**) { X x; return 0; } ==> t.hpp <== #include struct X: public QObject{ X() = default; Q_OBJECT }; From irwin at beluga.phys.uvic.ca Sat Oct 22 00:44:29 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 21 Oct 2016 21:44:29 -0700 (PDT) Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: <52589C96-718A-431A-BD75-34BAF4B9BE10@cunz-rad.com> References: <52589C96-718A-431A-BD75-34BAF4B9BE10@cunz-rad.com> Message-ID: On 2016-10-22 03:35+0100 Sascha Cunz wrote: > But automoc must know where to look for. It can only do that if something tells it where to look - If your header files are in the same directory as the source files, they?re getting added and scanned automatically. > If, like in your example, the files are in different directories, you have to add them to add_executable / add_library in order to let automoc know that it shall scan them. That is a good summary of what I have discovered through experimentation. However, I view these results for the separate header file directory as an unexpected constraint of automoc at best. Compilers know exactly where the header files are through include_directories or the equivalent target PROPERTY so why can't automoc find those same header files using similar logic? Of course, I am in the odd position (as I explained before) of not being able to help out with implementing such logic so if it turns out nobody wants to clean up this issue at the moment, I will put it on the bugtracker for future reference. [...] > However, I see that the take away from the thread should probably be that the wording in the documentation could be improved. To be fair, it is in general very hard for someone who knows a tool and it?s complete history to write documentation that someone who doesn?t have that prior knowledge is able to understand. So, improving things here usually relies on input like yours to figure out what actually has to be improved. I agree. I have already suggested some possible changes to the documentation on the initial thread on the CMake mailing list and this additional thread here on the CMake developer list. But if nobody is inspired to take immediate action on fixing the problem summarized above (which would largely make the current documentation correct), I will write up these documentation issues for the current automoc behaviour for the bugtracker as well. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From sascha at cunz-rad.com Sat Oct 22 02:44:32 2016 From: sascha at cunz-rad.com (Sascha Cunz) Date: Sat, 22 Oct 2016 07:44:32 +0100 Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: References: <52589C96-718A-431A-BD75-34BAF4B9BE10@cunz-rad.com> Message-ID: <5D9F3509-419A-4C0A-9E38-563773115534@cunz-rad.com> > Compilers know exactly where the header files are through > include_directories or the equivalent target PROPERTY so why can't > automoc find those same header files using similar logic? In short: Because you really do not want automoc to do that. A bit longer; highlighting the semantic problem: The following applies to targets that you define as well as the external ones. The external one that you certainly can?t skip is QtCore, so I?ll explain it in terms of Qt5::Core. By adding Qt5::Core to your target?s dependencies at least one -I option is added to the compiler, so it knows where to find Qt5 Core?s header files. At the same time you might have a subdirectory in your source tree that contains some of your header files that you also want to be searched, so you add i.e. ?target_include_directories(MyTgt ${PROJECT_SOURCE_DIR}/FooModule)?. Now, the list of include directories for MyTgt contains two entries: Qt5::Core?s headers and FooModule. They are not distinguishable by any means. The question now is: How should automoc know which files you want to run through moc and which files not? There are actually 3+1 scenarios now: 1. qcoreapplication.h - If you run automoc on that file, your target ends up defining the meta data for QCoreApplication, which is inefficient and will either lead to undefined behaviour or on most platforms to linker errors. Independent of the technical things below, the decision to run or not run such headers through moc seems to be impossible to automate - One would need to either white or black list the directories used / not used for automoc. 2. FooModule/file1.h, which is included from file1.cpp in MyTgt - You might want to run that through moc, but actually only in the case that the compiler is building MyTgt. If the compiler is building another one of your targets that happens to require this include path, you end up the same as in case 1 above. 3. FooModule/file2.h, which does not have a corresponding .cpp file in MyTgt - (if this was on the system level: for example, not all files in /usr/include belong to the same project) This will lead to unresolved symbols in MyTgt (on most platforms) and the inability to actually execute MyTgt, unless it is linked against the library that actually contains the .cpp file (on all platforms). Then there is even more obscure cases: 4. Imagine the files x/x.cpp and x/public/x.hpp (Both belonging to target X). Now, someone decides that the target Y (with code in y/) doesn?t need all the code in target X but just that one class. So, they add the file x/x.cpp to target X and target Y. If x/x.cpp contains the line ?#include ?public/x.hpp?, then target Y doesn?t even need the -I for x/public. How should automoc figure out that the file needs to be run through moc anyway? And even longer with a bit of historic and technical background and focus on the technical problem: The automoc concept and original implementation had been developed for the KDE project. IIRC, the original purpose was to speed up compilation by reducing the absolute number of translation units (i.e. number of .cpp files == number of compiler runs == number of linker inputs). This was achieved by two mechanism: A) All header files that contained Q_OBJECT/GADGET are collected and run through moc, but the results of that were not added as translation units but rather were #include?ed in _one_ translation unit, which then was added to the target. b) All source files that contained Q_OBJECT/GADGET needed to include the ?.moc? file - if such an include was spotted, the .cpp file itself was run through moc. This tool was implemented outside of cmake and integrated into the build system as an additional target, on which the consuming target had a dependency. Much later, it was integrated into cmake, keeping this concept for various reasons. Now back to the cmake implementation of automoc: When automoc is enabled for target T, cmake will add an additional target to the build - let?s call it TAM. T has a dependency on TAM, so TAM is always build _before_ T even starts to scan for its dependencies (in makefile based builds). Note that some generators don?t even have the requirement to scan for dependencies at compile time (i.e. MSBuild / Visual Studio does that by itself). Scanning for dependencies is basically: ?Run the preprocessor and tell me what files it would read if it were to do the actual work, then create a file with rules to describe these dependencies?. Because when the cmake generator is run, it can?t actually know if there are indeed files that need to run through moc, it unconditionally adds the moc_T.cpp file to T (This is a problem for my current customer, because they have 500 targets where automoc is enabled based on whether Qt5::Core is a dependency or not - but only about 100 of these targets need automoc in the first place and it happens that Qt5::Core is a very low level dependency for them). The moc outputs that are #include?ed don?t need to be added to the target. The problem here is, that once a target is created in CMake, you can?t add any files to it. So this has to be done that way. Since the TAM target is build before T?s ?scan for dependencies?, automoc can?t know what files _exactly_ are included in the project (unless given through add_executable/add_library). This makes an informed automatic decision in the above cases 3 and 4 practically impossible. And for case 1, this means: We?d actually have to consider _all_ files in _all_ -I directories, possibly including /usr/include and /usr/local/include. So, what we?re left with is the actual command lines to the compiler, the include paths as defined in CMakeLists.txts. This _could_ be used to solve the case 2. But such a solution would be very error prone and still leaves case 1 to be sorted out somehow. > > I have already suggested some possible changes to the > documentation on the initial thread on the CMake mailing list and this > additional thread here on the CMake developer list. > But if nobody is > inspired to take immediate action on fixing the problem summarized > above (which would largely make the current documentation correct), I will write > up these documentation issues for the current automoc behaviour for > the bugtracker as well. With the above background added to your knowledge, you might want to rethink if you consider this a bug in the automoc implementation. I?ve read the cmake-qt(7) section about automoc several times now. I can?t actually figure out anything inside it that is plain _wrong_. However, I would suggest to change the documentation to: The AUTOMOC target property controls whether cmake(1) inspects the C++ header and implementation files in the target to determine if they require moc to be run, and to create rules to execute moc at the appropriate time. Note that it is recommended to explicitly list header files when declaring a target with add_executable or add_library - even though this is only required when header and corresponding implementation file are in different directories. {1} moc needs to be run, if: - A Q_OBJECT or Q_GADGET macro is found in a header file. In this case, the result will be put into into a file named according to moc_.cpp. Multiple moc outputs generated that way will be added to the target as one translation unit. - The macro is found in a C++ implementation file. Following the Qt conventions, moc output will be put into a file named according to .moc. The implementation file may optionally use a preprocessor #include to include the .moc file (This is typically done at the end of the file). If such an include is omitted, the .moc file will also be added to the aforementioned translation unit. Generated moc_*.cpp and *.moc files are placed in the build directory so it is convenient to set the CMAKE_INCLUDE_CURRENT_DIR variable. {2} The moc command line will consume the COMPILE_DEFINITIONS and INCLUDE_DIRECTORIES target properties from the target it is being invoked for, and for the appropriate build configuration. The AUTOMOC target property may be pre-set for all following targets by setting the CMAKE_AUTOMOC variable. The AUTOMOC_MOC_OPTIONS target property may be populated to set options to pass to moc. The CMAKE_AUTOMOC_MOC_OPTIONS variable may be populated to pre-set the options for all following targets. Cheers Sascha {1} I?d consider this too generic for _that_ part of the documentation, but it could be added: "Header files that are in the same directory as their implementation file will be automatically added to the target?. {2} Maybe this should actually be changed to ?so it might be required to set? From craig.scott at crascit.com Sat Oct 22 03:16:30 2016 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 22 Oct 2016 18:16:30 +1100 Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: <5D9F3509-419A-4C0A-9E38-563773115534@cunz-rad.com> References: <52589C96-718A-431A-BD75-34BAF4B9BE10@cunz-rad.com> <5D9F3509-419A-4C0A-9E38-563773115534@cunz-rad.com> Message-ID: Good background, just a minor correction: On Sat, Oct 22, 2016 at 5:44 PM, Sascha Cunz wrote: > > The problem here is, that once a target is created in CMake, you can?t add > any files to it. So this has to be done that way. > Not actually true, the target_sources() command can do precisely that. The following article shows some reasons why this is particularly useful: https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/ -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From seblist at xwmw.org Sat Oct 22 13:49:44 2016 From: seblist at xwmw.org (Sebastian Holtermann) Date: Sat, 22 Oct 2016 19:49:44 +0200 Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: References: Message-ID: <8ac54358-a98a-1751-325c-af7f79d16489@xwmw.org> Am 21.10.2016 um 13:39 schrieb Alan W. Irwin: > On 2016-10-21 09:42+0200 Sebastian Holtermann wrote: > > [...] >> Hi! >> >> I tried your example. >> It isn't complete, test_q_object.h needs an >> #include >> and a constructor/destructor definition, e.g.: >> MyClass(QObject *parent = 0) {;} >> ~MyClass(){;} > > Hi Sebastian: > > Thanks for that fix which indeed solves the linking issue. > >> >> With regards to automoc the >> #include "moc_test_q_object.cpp" >> in the end should not be neccessary since >> #include "test_q_object.h" >> already references to the header. >> The problem is that this reference is not a direct path from the >> source file but relies on include_directories. >> CMake does not seem to populate automoc's scan list with files >> from include_directories. >> I tried to figure out why but this is quite complex. > > I hope you are able to fix this along the lines I have mentioned > (which includes putting all generated results in the build tree > corresponding to the header) since using #include > "moc_test_q_object.cpp" in main.cpp is currently the only documented > way to use automoc (see, e.g., > ). As Sascha Cunz pointed out well, it is problematic to simply automoc any header found in the include_directories. I think the current behaviour is reasonable good. The documentation could be improved though to mention the fullpath method. > > In sum, I hope you are willing to fix the currently documented automoc > "#include" method so it puts all generated results in the build tree > corresponding to the header, update the automoc documentation so you > also mention the "fullpath" alternative, and also similarly fix that > method so the location of the two generated files is in the build > directory corresponding to the header rather than the build directory > corresponding to the source file. Actually I made an implementation in 3.6.0 that generated the moc files in the a build tree subdirectory correspoding to the header path. But that blew up on some projects because the generated paths got too long for some compi?ers. That implementation was theefore reverted. In 3.7 there is a new approatch that generates the moc files in ${CMAKE_BINARY_DIR}/ ${TARGETNAME}_automoc.dir/ ${HEADERNAME}_${HEADERPATHCHECKSUM}.cpp This ensures that the paths don't get too long and that there won't be any name collisions. > My apologies for making suggestions for improvement without being able > to help you with the implementation (except testing of results), but > my C++ skills and CMake developer skills are just not up to it (as you > could probably tell from the required test_q_object.h fix you had to > suggest.) We'll I'm just a spare time contributor but it's motivating to see that someone cares about these issues as well. -Sebastian From irwin at beluga.phys.uvic.ca Sat Oct 22 16:10:17 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sat, 22 Oct 2016 13:10:17 -0700 (PDT) Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: <5D9F3509-419A-4C0A-9E38-563773115534@cunz-rad.com> References: <52589C96-718A-431A-BD75-34BAF4B9BE10@cunz-rad.com> <5D9F3509-419A-4C0A-9E38-563773115534@cunz-rad.com> Message-ID: On 2016-10-22 07:44+0100 Sascha Cunz wrote: >> Compilers know exactly where the header files are through >> include_directories or the equivalent target PROPERTY so why can't >> automoc find those same header files using similar logic? > > In short: Because you really do not want automoc to do that. > > A bit longer; highlighting the semantic problem: > > The following applies to targets that you define as well as the external ones. The external one that you certainly can?t skip is QtCore, so I?ll explain it in terms of Qt5::Core. > > By adding Qt5::Core to your target?s dependencies at least one -I option is added to the compiler, so it knows where to find Qt5 Core?s header files. At the same time you might have a subdirectory in your source tree that contains some of your header files that you also want to be searched, so you add i.e. ?target_include_directories(MyTgt ${PROJECT_SOURCE_DIR}/FooModule)?. Now, the list of include directories for MyTgt contains two entries: Qt5::Core?s headers and FooModule. They are not distinguishable by any means. The question now is: How should automoc know which files you want to run through moc and which files not? > > There are actually 3+1 scenarios now: > > 1. qcoreapplication.h - If you run automoc on that file, your target ends up defining the meta data for QCoreApplication, which is inefficient and will either lead to undefined behaviour or on most platforms to linker errors. > Independent of the technical things below, the decision to run or not run such headers through moc seems to be impossible to automate - One would need to either white or black list the directories used / not used for automoc. > > 2. FooModule/file1.h, which is included from file1.cpp in MyTgt - You might want to run that through moc, but actually only in the case that the compiler is building MyTgt. If the compiler is building another one of your targets that happens to require this include path, you end up the same as in case 1 above. > > 3. FooModule/file2.h, which does not have a corresponding .cpp file in MyTgt - (if this was on the system level: for example, not all files in /usr/include belong to the same project) This will lead to unresolved symbols in MyTgt (on most platforms) and the inability to actually execute MyTgt, unless it is linked against the library that actually contains the .cpp file (on all platforms). > > Then there is even more obscure cases: > 4. Imagine the files x/x.cpp and x/public/x.hpp (Both belonging to target X). Now, someone decides that the target Y (with code in y/) doesn?t need all the code in target X but just that one class. So, they add the file x/x.cpp to target X and target Y. If x/x.cpp contains the line ?#include ?public/x.hpp?, then target Y doesn?t even need the -I for x/public. How should automoc figure out that the file needs to be run through moc anyway? > > And even longer with a bit of historic and technical background and focus on the technical problem: > > The automoc concept and original implementation had been developed for the KDE project. IIRC, the original purpose was to speed up compilation by reducing the absolute number of translation units (i.e. number of .cpp files == number of compiler runs == number of linker inputs). This was achieved by two mechanism: > > A) All header files that contained Q_OBJECT/GADGET are collected and run through moc, but the results of that were not added as translation units but rather were #include?ed in _one_ translation unit, which then was added to the target. > > b) All source files that contained Q_OBJECT/GADGET needed to include the ?.moc? file - if such an include was spotted, the .cpp file itself was run through moc. > > This tool was implemented outside of cmake and integrated into the build system as an additional target, on which the consuming target had a dependency. Much later, it was integrated into cmake, keeping this concept for various reasons. > > Now back to the cmake implementation of automoc: When automoc is enabled for target T, cmake will add an additional target to the build - let?s call it TAM. T has a dependency on TAM, so TAM is always build _before_ T even starts to scan for its dependencies (in makefile based builds). Note that some generators don?t even have the requirement to scan for dependencies at compile time (i.e. MSBuild / Visual Studio does that by itself). > Scanning for dependencies is basically: ?Run the preprocessor and tell me what files it would read if it were to do the actual work, then create a file with rules to describe these dependencies?. > > Because when the cmake generator is run, it can?t actually know if there are indeed files that need to run through moc, it unconditionally adds the moc_T.cpp file to T (This is a problem for my current customer, because they have 500 targets where automoc is enabled based on whether Qt5::Core is a dependency or not - but only about 100 of these targets need automoc in the first place and it happens that Qt5::Core is a very low level dependency for them). The moc outputs that are #include?ed don?t need to be added to the target. > The problem here is, that once a target is created in CMake, you can?t add any files to it. So this has to be done that way. > > Since the TAM target is build before T?s ?scan for dependencies?, automoc can?t know what files _exactly_ are included in the project (unless given through add_executable/add_library). This makes an informed automatic decision in the above cases 3 and 4 practically impossible. And for case 1, this means: We?d actually have to consider _all_ files in _all_ -I directories, possibly including /usr/include and /usr/local/include. > > So, what we?re left with is the actual command lines to the compiler, the include paths as defined in CMakeLists.txts. This _could_ be used to solve the case 2. But such a solution would be very error prone and still leaves case 1 to be sorted out somehow. > Hi Sascha: I accept what you have said, and I very much appreciate your attempt to educate me (and others here) in these C++/Qt/moc technical considerations. Therefore, subject to some minor corrections such as the subsequent one by Craig Scott I strongly urge you to put this essential background information into the CMake FAQ so it is not lost in the large traffic on this list. > I?ve read the cmake-qt(7) section about automoc several times now. I can?t actually figure out anything inside it that is plain _wrong_. However, I would suggest to change the documentation to: > > The AUTOMOC target property controls whether cmake(1) inspects the C++ header and implementation > files in the target to determine if they require moc to be run, and to create rules to execute moc at the > appropriate time. > > Note that it is recommended to explicitly list header files when declaring a target with add_executable > or add_library - even though this is only required when header and corresponding implementation file > are in different directories. {1} That statement is not true in complete generality so I would suggest the addition of the following qualifier "Note that it is recommended" ==> "Note that to assure consideration for moc processing it is recommended" Also, it sounds from your footnote 1 that you would prefer not to have all the details here about the exact rules for identifying the header files to be scanned so I would suggest the following addition to the above paragraph. When the header is in the same directory as the C++ implementation file there are additional possibilities for identifying it for consideration for moc processing, see the automoc documentation. And then the automoc documentation should be updated with those same-directory possibilities clearly stated. > > moc needs to be run, if: > - A Q_OBJECT or Q_GADGET macro is found in a header file. In this case, the result will be put into > into a file named according to moc_.cpp. Multiple moc outputs generated that way will > be added to the target as one translation unit. > > - The macro is found in a C++ implementation file. Following the Qt conventions, moc output will be > put into a file named according to .moc. > The implementation file may optionally use a preprocessor #include to include the .moc file (This is > typically done at the end of the file). If such an include is omitted, the .moc file will also be added to > the aforementioned translation unit. > > Generated moc_*.cpp and *.moc files are placed in the build directory so it is convenient to set the > CMAKE_INCLUDE_CURRENT_DIR variable. {2} > > The moc command line will consume the COMPILE_DEFINITIONS and INCLUDE_DIRECTORIES > target properties from the target it is being invoked for, and for the appropriate build configuration. > > The AUTOMOC target property may be pre-set for all following targets by setting the > CMAKE_AUTOMOC variable. The AUTOMOC_MOC_OPTIONS target property may be populated > to set options to pass to moc. The CMAKE_AUTOMOC_MOC_OPTIONS variable may be populated > to pre-set the options for all following targets. > {1} I?d consider this too generic for _that_ part of the > documentation, but it could be added: "Header files that are in the same > directory as their implementation file will be automatically added to > the target?. > {2} Maybe this should actually be changed to ?so it might be required > to set? Assuming you have no strong objections to the above further changes, then I plan to wrap up our joint cmake-qt documentation changes into git format-patch form for the convenience of the CMake developers here. And I also plan to work on the automoc documentation using similar language to what you have used above in the cmake-qt case with some additions about the same-directory possibilities for identifying headers that should moc'ed. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From Geoffrey.Viola at asirobots.com Sat Oct 22 15:37:11 2016 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Sat, 22 Oct 2016 19:37:11 +0000 Subject: [cmake-developers] CDash Build Name Change Message-ID: I changed a build configuration for the glv.asi site. Instead of Win64-vs14-dbg-x86, it's named Win64-vs14-dbg-x86_64. This name change is meant to signify a change from "Visual Studio 12 2013" to "Visual Studio 14 2016 Win64" for the generator. Please update Nightly Expected accordingly. [cid:image001.png at 01CE6DA0.CA468FE0] Geoffrey Viola Software Engineer T +1.435.755.2980 ext 1077 asirobots.com This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1910 bytes Desc: image001.png URL: From amubtdx at outlook.fr Sun Oct 23 14:01:41 2016 From: amubtdx at outlook.fr (Alexis Murzeau) Date: Sun, 23 Oct 2016 18:01:41 +0000 Subject: [cmake-developers] Ninja : $subdir/{test, install, package} and $subdir/all targets Message-ID: Hi, When generating ninja build from a `CMakeLists.txt` containing `add_subdirectory(test test_bin)` (see also test_subdir.zip in attachment), I get this warning : ``` CMake Warning (dev): Policy CMP0058 is not set: Ninja requires custom command byproducts to be explicit. Run "cmake --help-policy CMP0058" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This project specifies custom command DEPENDS on files in the build tree that are not specified as the OUTPUT or BYPRODUCTS of any add_custom_command or add_custom_target: test_bin\all [...] ``` This is because cmake generates a `test_bin\package` depending on `test_bin\all` but the generated $subdir\all target is named `test\all`. When generating `$subdir\package` target, the prefix is the current binary directory name [1]. So the target name becomes `test_bin\package`. Likewise, the `$subdir\package` target depends on `$subdir\all` where $subdir is also the current binary directory name [2]. So `$subdir` is `test_bin` and cmake generates a target `test_bin\package` depending on `test_bin\all`. For the `$subdir\all` target, `$subdir` is the current source directory name [3], that is `test` (and not `test_bin`). So the `$subdir\all` target is named `test\all`. So cmake detects that `test_bin\package` depends on `test_bin\all` but there is no `test_bin\all` target (only `test\all`) and outputs the earlier said warning. The consequence in the OLD behavior of CMP0058 is to add a phony target `test_bin\all`. The effect of this is that `ninja test_bin\package` errors like this : ``` CMake Error at .../test_subdir/build-dir/test/cmake_install.cmake:31 (file): file INSTALL cannot find ".../test_subdir/build-dir/test/test_subdir.exe". ``` My though about this is that `$subdir\all` should use the current binary directory and not the current source directory like `$subdir\package` does. It wasn't detected before because in most cases, the current source and binary dirs are the same relatively to the root source and binary dirs respectively. To fix the generation of $subdir\all using the current binary dir, I propose a patch in attachment. This makes "ninja test\package" correctly compile test_subdir.exe via the "test\all" target. [1] https://gitlab.kitware.com/cmake/cmake/blob/v3.7.0-rc2/Source/cmNinjaUtilityTargetGenerator.cxx#L37 [2] https://gitlab.kitware.com/cmake/cmake/blob/v3.7.0-rc2/Source/cmGlobalNinjaGenerator.cxx#L978 [3] https://gitlab.kitware.com/cmake/cmake/blob/v3.7.0-rc2/Source/cmGlobalNinjaGenerator.cxx#L1084 Alexis Murzeau -------------- next part -------------- A non-text attachment was scrubbed... Name: test_subdir.zip Type: application/zip Size: 11586 bytes Desc: test_subdir.zip URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Ninja-Use-current-binary-dir-for-subdir-all.patch Type: application/octet-stream Size: 11174 bytes Desc: 0001-Ninja-Use-current-binary-dir-for-subdir-all.patch URL: From brad.king at kitware.com Mon Oct 24 10:25:35 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 24 Oct 2016 10:25:35 -0400 Subject: [cmake-developers] CDash Build Name Change In-Reply-To: References: Message-ID: <58014920-9e18-b3e2-4bfc-569d24b9d449@kitware.com> On 10/22/2016 03:37 PM, Geoffrey Viola wrote: > I changed a build configuration for the glv.asi site. Instead of > Win64-vs14-dbg-x86, it?s named Win64-vs14-dbg-x86_64. Thanks. I updated the expected build list. -Brad From brad.king at kitware.com Mon Oct 24 10:39:36 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 24 Oct 2016 10:39:36 -0400 Subject: [cmake-developers] Ninja : $subdir/{test, install, package} and $subdir/all targets In-Reply-To: References: Message-ID: On 10/23/2016 02:01 PM, Alexis Murzeau wrote: > `$subdir\all` should use the current > binary directory and not the current source directory like > `$subdir\package` does. Yes, thanks. I've applied the patch: Ninja: Use binary dir for `$subdir/all` targets https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e983bd32 I rewrote the commit message only because your beautiful and detailed explanation of what happened was more about the symptom and analysis than the actual fix. That was useful to have in the mailing list post though! BTW, please see the recently updated `CONTRIBUTING.rst` file for the new preferred contribution path (now through our GitLab instance). Thanks, -Brad From irwin at beluga.phys.uvic.ca Mon Oct 24 23:50:34 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 24 Oct 2016 20:50:34 -0700 (PDT) Subject: [cmake-developers] Current deficiencies of automoc In-Reply-To: <8ac54358-a98a-1751-325c-af7f79d16489@xwmw.org> References: <8ac54358-a98a-1751-325c-af7f79d16489@xwmw.org> Message-ID: On 2016-10-22 19:49+0200 Sebastian Holtermann wrote: > Actually I made an implementation in 3.6.0 that generated the moc files > in the a build tree subdirectory correspoding to the header path. > But that blew up on some projects because the generated paths got too long > for some compi?ers. That implementation was theefore reverted. > In 3.7 there is a new approatch that generates the moc files in > ${CMAKE_BINARY_DIR}/ > ${TARGETNAME}_automoc.dir/ > ${HEADERNAME}_${HEADERPATHCHECKSUM}.cpp > This ensures that the paths don't get too long and that there won't be any > name collisions. Hi Sebastian: Now that I have thought a bit more about this, you do need to distinguish by target since those can have different automoc options, and even if that is the same for the two targets, you would not want multiple moc commands on the same header to generate the same output file at the same time. So this looks like an excellent naming scheme that will avoid all such collisions. However, I see no sign of this new approach in my recent compilation of 3.7.0-rc2, nor in the automoc documentation for the master branch tip (or next branch tip). So is it really going to get into 3.7.0 (including the automoc documentation of this new approach)? Also, I tested the simple test case modified to add an additional target using the same source code and CMake-3.7.0-rc2. That currently does generate the same filename for the two different moc output results, and I was also surprised (considering the 3.7.0-rc2 automoc documentation that states there would be a diagnostic warning of moc output collisions) there was no collision diagnostic for this particular case of two targets in the same directory. But your above approach (once it gets into 3.7) should avoid all such collisions (and thus make collision diagnostics moot). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From rcdailey.lists at gmail.com Tue Oct 25 09:48:52 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 25 Oct 2016 08:48:52 -0500 Subject: [cmake-developers] CMake integration in Gradle (Android Studio) Message-ID: I'm not sure if the CMake mailing lists are the right place to ask this question but I thought I'd ask just in case someone has gone down this path or has experience with what Google/Gradle is actually trying to accomplish with what seems to be a hand-built version of CMake with custom patches that are not in upstream repositories. Prior to switching to Android Studio / Gradle, I was using Eclipse / Ant. The way I did CMake integration was not really integration at all: I generated Ninja build scripts using CMake and implemented custom targets to run "ant release" after all the C++ projects were built. I made sure that CMake copied relevant *.so files to appropriate directories in the Ant structure so they are packaged with built APKs. That's how I did my Android development. Now that I'm integrating CMake into Gradle, first annoyance I noticed is that I can't use CMake 3.7 (or any external installation of CMake) with Android Studio. It requires a version of CMake installed through SDK Manager. This means I can't use the new Android toolchain functionality built into CMake 3.7 (sad face). But this is something I can work around... Next I found out that stuff I'm setting in my CMake scripts, such as CPP flags like `-std=c++14` and `-fexceptions` was not being applied. For whatever reason, Gradle is overriding these from the command line (I'm guessing?). So this requires me to duplicate the toolchain / compiler flag setup I already do in my CMake scripts now in the Gradle build scripts. This seems completely unnecessary and a maintenance burden. What I was expecting Gradle to do was essentially provide me some toolchain file so that CMake can find the compiler and linker to use and then the rest would be determined by CMake itself. Is there a way I can tell Gradle to not take so much control over compiler flags? I want my CMake scripts to do this. I can't imagine they had a good reason to do this. What have others done in this situation with their own Gradle + CMake integration? Looking for advice here, since information is sparse, especially since the Android Studio 2.2 CMake integration is relatively new stuff. From roman.wueger at gmx.at Wed Oct 26 05:27:24 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 26 Oct 2016 11:27:24 +0200 Subject: [cmake-developers] iwyu and clang-tidy not working under mac os Message-ID: <280F26CD-3681-4738-916A-E2C6CABA14C1@gmx.at> Hello, I set CMAKE_CXX_INCLUDE_WHAT_YOU_USE and CMAKE_CXX_CLANG_TIDY. Both work as expected with CMake 3.6.2 under linux. Under Mac OS with the same sources and the same CMake version doesn't produce any output. On Linux clang 3.8 is used, on Mac OS it is AppleClang 7.3.0 with clang-tidy installed from homebrew. Any hints? Thanks in advance Best regards Roman From daniel at pfeifer-mail.de Wed Oct 26 05:50:42 2016 From: daniel at pfeifer-mail.de (Daniel Pfeifer) Date: Wed, 26 Oct 2016 11:50:42 +0200 Subject: [cmake-developers] iwyu and clang-tidy not working under mac os In-Reply-To: <280F26CD-3681-4738-916A-E2C6CABA14C1@gmx.at> References: <280F26CD-3681-4738-916A-E2C6CABA14C1@gmx.at> Message-ID: On Wed, Oct 26, 2016 at 11:27 AM, Roman W?ger wrote: > Hello, > > I set CMAKE_CXX_INCLUDE_WHAT_YOU_USE and CMAKE_CXX_CLANG_TIDY. Both work > as expected with CMake 3.6.2 under linux. Under Mac OS with the same > sources and the same CMake version doesn't produce any output. > > On Linux clang 3.8 is used, on Mac OS it is AppleClang 7.3.0 with > clang-tidy installed from homebrew. > > Any hints? > When you run "make VERBOSE=1" and look at what is executed, do you see any "cmake --iwyu" invocations? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.stuermer at schaeffler.com Wed Oct 26 10:05:45 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Wed, 26 Oct 2016 14:05:45 +0000 Subject: [cmake-developers] gitlab or github? Which should I use for contribution? Message-ID: I know the cmake repositories on github and gitlab are in sync, so I could base my work on any of them. Still I don't want to maintain two forks and would prefer to switch completely to gitlab.kitware instead. Which should I choose for future contributions? My feeling is I could completely abandon the github repository and pull and push only to gitlab.kitware.com. All merge requests are handled there anyway. Is this right? I can't see all the other branches like maint, next, nightly-* etc. on the gitlab repo. Still these branches get regularly updated on github. This makes me feel like the gitlab repo is somehow "incomplete". Is there some kind of a distinction between "official" and "development" repository? I'm just trying to understand . Viele Gr??e Michael St?rmer ?? SZ. Prozessdatenverarbeitung SP/HZA-ZSEP??Tel. +499132 82-86350 ?Mobil.: +49(171)6860010 From brad.king at kitware.com Wed Oct 26 11:13:24 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 26 Oct 2016 11:13:24 -0400 Subject: [cmake-developers] gitlab or github? Which should I use for contribution? In-Reply-To: References: Message-ID: <96152cbf-5b76-c3b9-1407-5c0a0496e583@kitware.com> On 10/26/2016 10:05 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > Which should I choose for future contributions? GitLab, please. We recently updated CONTRIBUTING.rst to prefer it even over patches on this list. > My feeling is I could completely abandon the github repository > and pull and push only to gitlab.kitware.com. Yes. > I can't see all the other branches like maint, next, nightly-* etc. > on the gitlab repo. Still these branches get regularly updated on > github. This makes me feel like the gitlab repo is somehow "incomplete". The `maint` branch has not proven useful and may be dropped one day. The `next` and `nightly` branches are only for the nightly testing infrastructure and not something developers need to use. The GitHub repo is just a mirror of the cmake.org repo and has always had the extra branches and so still does. The GitLab repo is where we are trying to move development so we're populating it only with the branches needed by developers. -Brad From roman.wueger at gmx.at Wed Oct 26 14:27:12 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Wed, 26 Oct 2016 20:27:12 +0200 Subject: [cmake-developers] iwyu and clang-tidy not working under mac os In-Reply-To: References: <280F26CD-3681-4738-916A-E2C6CABA14C1@gmx.at> Message-ID: Ok, I've got it. If anyone is interested, here is my configuration: find_program(iwyu_path NAMES include-what-you-use iwyu PATHS ${CMAKE_SOURCE_DIR}/tools/include-what-you-use/${iwyu_os}/bin) if(NOT iwyu_path) message(STATUS "Program include-what-you-use: Not found") else() message(STATUS "Program include-what-you-use: Found") set(CMAKE_CXX_INCLUDE_WHAT_YOU_USE ${iwyu_path}) endif() find_program(clang_tidy NAMES clang-tidy clang-tidy-3.8) if(NOT clang_tidy) message(STATUS "Program clang-tidy: Not found") else() message(STATUS "Program clang-tidy: Found") set(CMAKE_CXX_CLANG_TIDY "${clang_tidy};-checks=-*,clang-analyzer-*,-clang-analyzer-alpha*,performance-*,cppcoreguidelines-*,cert-*,modernize-*") endif() Regards Roman > Am 26.10.2016 um 11:50 schrieb Daniel Pfeifer : > >> On Wed, Oct 26, 2016 at 11:27 AM, Roman W?ger wrote: >> Hello, >> >> I set CMAKE_CXX_INCLUDE_WHAT_YOU_USE and CMAKE_CXX_CLANG_TIDY. Both work as expected with CMake 3.6.2 under linux. Under Mac OS with the same sources and the same CMake version doesn't produce any output. >> >> On Linux clang 3.8 is used, on Mac OS it is AppleClang 7.3.0 with clang-tidy installed from homebrew. >> >> Any hints? > > When you run "make VERBOSE=1" and look at what is executed, do you see any "cmake --iwyu" invocations? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.stuermer at schaeffler.com Thu Oct 27 02:34:51 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Thu, 27 Oct 2016 06:34:51 +0000 Subject: [cmake-developers] gitlab or github? Which should I use for contribution? In-Reply-To: <96152cbf-5b76-c3b9-1407-5c0a0496e583@kitware.com> References: <96152cbf-5b76-c3b9-1407-5c0a0496e583@kitware.com> Message-ID: <3b318c1ab7d846f2b010247e13969693@DE013666.schaeffler.com> > -----Original Message----- > From: Brad King [mailto:brad.king at kitware.com] > Sent: Wednesday, October 26, 2016 5:13 PM > To: Stuermer, Michael SP/HZA-ZSEP > Cc: cmake-developers at cmake.org > Subject: Re: [cmake-developers] gitlab or github? Which should I use for > contribution? > > On 10/26/2016 10:05 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > > Which should I choose for future contributions? > > GitLab, please. We recently updated CONTRIBUTING.rst to prefer it even > over patches on this list. > > > My feeling is I could completely abandon the github repository and > > pull and push only to gitlab.kitware.com. > > Yes. > > > I can't see all the other branches like maint, next, nightly-* etc. > > on the gitlab repo. Still these branches get regularly updated on > > github. This makes me feel like the gitlab repo is somehow "incomplete". > > The `maint` branch has not proven useful and may be dropped one day. > The `next` and `nightly` branches are only for the nightly testing > infrastructure and not something developers need to use. > > The GitHub repo is just a mirror of the cmake.org repo and has always had > the extra branches and so still does. The GitLab repo is where we are trying > to move development so we're populating it only with the branches needed > by developers. > > -Brad > . thanks for the information, exactly what I needed! From rcdailey.lists at gmail.com Thu Oct 27 17:48:06 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 27 Oct 2016 16:48:06 -0500 Subject: [cmake-developers] CMake integration in Gradle (Android Studio) In-Reply-To: References: Message-ID: I'm at a bit of a loss on finding more information. Can anyone at least confirm that this isn't a reliable place to find the answers I'm looking for? Does anyone have real experience with android + gradle + cmake integration and can provide some pointers? On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey wrote: > I'm not sure if the CMake mailing lists are the right place to ask > this question but I thought I'd ask just in case someone has gone down > this path or has experience with what Google/Gradle is actually trying > to accomplish with what seems to be a hand-built version of CMake with > custom patches that are not in upstream repositories. > > Prior to switching to Android Studio / Gradle, I was using Eclipse / > Ant. The way I did CMake integration was not really integration at > all: I generated Ninja build scripts using CMake and implemented > custom targets to run "ant release" after all the C++ projects were > built. I made sure that CMake copied relevant *.so files to > appropriate directories in the Ant structure so they are packaged with > built APKs. That's how I did my Android development. > > Now that I'm integrating CMake into Gradle, first annoyance I noticed > is that I can't use CMake 3.7 (or any external installation of CMake) > with Android Studio. It requires a version of CMake installed through > SDK Manager. This means I can't use the new Android toolchain > functionality built into CMake 3.7 (sad face). But this is something I > can work around... > > Next I found out that stuff I'm setting in my CMake scripts, such as > CPP flags like `-std=c++14` and `-fexceptions` was not being applied. > For whatever reason, Gradle is overriding these from the command line > (I'm guessing?). So this requires me to duplicate the toolchain / > compiler flag setup I already do in my CMake scripts now in the Gradle > build scripts. This seems completely unnecessary and a maintenance > burden. > > What I was expecting Gradle to do was essentially provide me some > toolchain file so that CMake can find the compiler and linker to use > and then the rest would be determined by CMake itself. > > Is there a way I can tell Gradle to not take so much control over > compiler flags? I want my CMake scripts to do this. I can't imagine > they had a good reason to do this. What have others done in this > situation with their own Gradle + CMake integration? Looking for > advice here, since information is sparse, especially since the Android > Studio 2.2 CMake integration is relatively new stuff. From swel024 at gmail.com Sat Oct 29 11:25:16 2016 From: swel024 at gmail.com (Simon Wells) Date: Sun, 30 Oct 2016 04:25:16 +1300 Subject: [cmake-developers] fixup_bundle with @loader_path In-Reply-To: <1388770192.12590982.1452796004618.JavaMail.zimbra@elemtech.com> References: <5697A744.4020002@kitware.com> <1388770192.12590982.1452796004618.JavaMail.zimbra@elemtech.com> Message-ID: Hello, I think i have finally figured out whats causing the issue.... FindBoost.cmake explicitly lists the dependencies for every version, and therefore provides this information to cmake and getprereqs function(_Boost_COMPONENT_DEPENDENCIES component _ret) As each new version of boost is released the dependency information has to be added manually to FindBoost.cmake. elseif(NOT Boost_VERSION VERSION_LESS 106200 AND Boost_VERSION VERSION_LESS 106300) is the newest line which is in trunk but has yet to be released As such if one has installed a new boost version and not yet got an updated cmake version then it will not be providing the right information as such it seems the getprereqs will then go inspecting the installed boost libraries eg. /usr/local/opt/boost/lib/libboost_context-mt.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/libboost_chrono-mt.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/libboost_thread-mt.dylib (compatibility version 0.0.0, current version 0.0.0) @loader_path/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0) as such will not understand it and will fail at trying to copy @loader_path/libboost_chrono-mt.dylib This explains why the bug has mysteriously disappeared on me a couple of times and why it never fails to make a reappearance thanks Simon On Fri, Jan 15, 2016 at 7:26 AM, wrote: > > ----- On Jan 14, 2016, at 6:48 AM, Brad King brad.king at kitware.com wrote: > >> On 01/13/2016 01:38 AM, Simon Wells wrote: >>> it kept saying that @loader_path/libboost_chrono-mt.dylib was not found >> >> It looks like this was now reported here with a patch: >> >> https://cmake.org/Bug/view.php?id=15918 >> >> We already handle @executable_path, so @loader_path should be handled in >> a similar way but we need to make sure enough information is passed to >> know the loader path. >> > > As far as I know, the information needed is already available, so my initial guess is that we don't need any significant re-engineering. > > Simon, > Would you happen to have a simple example showing the problem without boost, that would be easy to replicate? That could become the basis for a test. > > Clint From craig.scott at crascit.com Sun Oct 30 00:01:35 2016 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 30 Oct 2016 15:01:35 +1100 Subject: [cmake-developers] LINK_FLAGS and STATIC_LIBRARY_FLAGS target properties Message-ID: Looking at the latest CMake docs for the LINK_FLAGS and STATIC_LIBRARY_FLAGS target properties, neither mentions support for generator expressions. This seems to be at odds with other target properties which are documented as having support for generator expressions, particularly the compiler counterparts COMPILE_DEFINITIONS, COMPILE_OPTIONS and INCLUDE_DIRECTORIES. Is it just a case of the linker properties haven't had their documentation updated or do they not yet have generator expression support? The situation for the INTERFACE_LINK_LIBRARIES target property is also a bit odd in that it's documentation doesn't mention support for generator expressions, but that for LINK_LIBRARIES does. Again, is this just docs being out of date or is the interface version of this property still lacking generator expression support? It would seem odd that the non-interface property supports them but the interface property doesn't. For both cases above, if those properties which don't have documented generator expression support indeed don't support them, are there plans to add such support any time soon? Sorry for all the questions, none of this is blocking me on anything, I'm just wanting to clarify the situation to gain a better understanding of what capabilities can be relied on to be available. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From howarth.mailing.lists at gmail.com Sun Oct 30 09:36:56 2016 From: howarth.mailing.lists at gmail.com (Jack Howarth) Date: Sun, 30 Oct 2016 09:36:56 -0400 Subject: [cmake-developers] -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ broken in 3.7.0-rc2 Message-ID: The change... --- cmake-3.6.2/Modules/Platform/Darwin-Initialize.cmake 2016-09-07 10:11:58.000000000 -0400 +++ cmake-3.7.0-rc2/Modules/Platform/Darwin-Initialize.cmake 2016-10-19 09:47:45.000000000 -0400 @@ -125,8 +125,10 @@ set(_CMAKE_OSX_SYSROOT_ORIG "") endif() set(_CMAKE_OSX_SYSROOT_PATH "${CMAKE_OSX_SYSROOT}") - else() - # Transform the sdk name into a path. + endif() + + if(CMAKE_OSX_SYSROOT) + # Transform the (maybe unversioned) sysroot into a versioned path. execute_process( COMMAND xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path OUTPUT_VARIABLE _stdout is an obvious mistake in cmake 3.7.0-rc2. The removal of the 'else()' statement here and the substitution of the ' if(CMAKE_OSX_SYSROOT)' defeats the prior handling of 'if("x${CMAKE_OSX_SYSROOT}" MATCHES "/")'. This causes '-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/' to not be honored and -isysroot to be emitted as a compiler flag universally. https://gitlab.kitware.com/cmake/cmake/issues/16394 From howarth.mailing.lists at gmail.com Sun Oct 30 13:33:01 2016 From: howarth.mailing.lists at gmail.com (Jack Howarth) Date: Sun, 30 Oct 2016 13:33:01 -0400 Subject: [cmake-developers] -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ broken in 3.7.0-rc2 In-Reply-To: References: Message-ID: Gregor, Your commit of... https://cmake.org/gitweb?p=cmake.git;a=log;h=540815eec2b83a8b43689580c54e8950d9f5868b has caused a major regression in cmake 3.7.0 as it no longer properly honors the combination... -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ This is obvious by simple inspection of the code in Modules/Platform/Darwin-Initialize.cmake as the code no longer honors -DCMAKE_OSX_SYSROOT:STRING=/. At the very least, this code needs to be modified to have cmake emit "-isysroot /" in that case. IMHO, this issue should be considered a blocker for the cmake 3,7.0 release on darwin. Jack On Sun, Oct 30, 2016 at 9:36 AM, Jack Howarth wrote: > The change... > > --- cmake-3.6.2/Modules/Platform/Darwin-Initialize.cmake 2016-09-07 > 10:11:58.000000000 -0400 > +++ cmake-3.7.0-rc2/Modules/Platform/Darwin-Initialize.cmake > 2016-10-19 09:47:45.000000000 -0400 > @@ -125,8 +125,10 @@ > set(_CMAKE_OSX_SYSROOT_ORIG "") > endif() > set(_CMAKE_OSX_SYSROOT_PATH "${CMAKE_OSX_SYSROOT}") > - else() > - # Transform the sdk name into a path. > + endif() > + > + if(CMAKE_OSX_SYSROOT) > + # Transform the (maybe unversioned) sysroot into a versioned path. > execute_process( > COMMAND xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path > OUTPUT_VARIABLE _stdout > > is an obvious mistake in cmake 3.7.0-rc2. The removal of the 'else()' > statement here and the substitution of the ' if(CMAKE_OSX_SYSROOT)' > defeats the prior handling of 'if("x${CMAKE_OSX_SYSROOT}" MATCHES > "/")'. This causes '-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" > -DCMAKE_OSX_SYSROOT:STRING=/' to not be honored and -isysroot to be > emitted as a compiler flag universally. > > https://gitlab.kitware.com/cmake/cmake/issues/16394 From howarth.mailing.lists at gmail.com Sun Oct 30 14:04:21 2016 From: howarth.mailing.lists at gmail.com (Jack Howarth) Date: Sun, 30 Oct 2016 14:04:21 -0400 Subject: [cmake-developers] -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ broken in 3.7.0-rc2 In-Reply-To: References: Message-ID: Gregor, This is also a severe regression because if forces the cmake users to build against the 10.12 SDK on 10.11 which is not well tested for backward compatibility on 10.11. Your change makes it impossible to build against the SDK in / installed by the Xcode Command Line Tools package. Jack On Sun, Oct 30, 2016 at 1:33 PM, Jack Howarth wrote: > Gregor, > Your commit of... > > https://cmake.org/gitweb?p=cmake.git;a=log;h=540815eec2b83a8b43689580c54e8950d9f5868b > > has caused a major regression in cmake 3.7.0 as it no longer properly > honors the combination... > > -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ > > This is obvious by simple inspection of the code in > Modules/Platform/Darwin-Initialize.cmake as > the code no longer honors -DCMAKE_OSX_SYSROOT:STRING=/. At the very > least, this code > needs to be modified to have cmake emit "-isysroot /" in that case. > IMHO, this issue should be considered a blocker for the cmake > 3,7.0 release on darwin. > Jack > > > On Sun, Oct 30, 2016 at 9:36 AM, Jack Howarth > wrote: >> The change... >> >> --- cmake-3.6.2/Modules/Platform/Darwin-Initialize.cmake 2016-09-07 >> 10:11:58.000000000 -0400 >> +++ cmake-3.7.0-rc2/Modules/Platform/Darwin-Initialize.cmake >> 2016-10-19 09:47:45.000000000 -0400 >> @@ -125,8 +125,10 @@ >> set(_CMAKE_OSX_SYSROOT_ORIG "") >> endif() >> set(_CMAKE_OSX_SYSROOT_PATH "${CMAKE_OSX_SYSROOT}") >> - else() >> - # Transform the sdk name into a path. >> + endif() >> + >> + if(CMAKE_OSX_SYSROOT) >> + # Transform the (maybe unversioned) sysroot into a versioned path. >> execute_process( >> COMMAND xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path >> OUTPUT_VARIABLE _stdout >> >> is an obvious mistake in cmake 3.7.0-rc2. The removal of the 'else()' >> statement here and the substitution of the ' if(CMAKE_OSX_SYSROOT)' >> defeats the prior handling of 'if("x${CMAKE_OSX_SYSROOT}" MATCHES >> "/")'. This causes '-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" >> -DCMAKE_OSX_SYSROOT:STRING=/' to not be honored and -isysroot to be >> emitted as a compiler flag universally. >> >> https://gitlab.kitware.com/cmake/cmake/issues/16394 From howarth.mailing.lists at gmail.com Sun Oct 30 14:53:45 2016 From: howarth.mailing.lists at gmail.com (Jack Howarth) Date: Sun, 30 Oct 2016 14:53:45 -0400 Subject: [cmake-developers] -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ broken in 3.7.0-rc2 In-Reply-To: References: Message-ID: Gregor, The change in https://cmake.org/gitweb?p=cmake.git;a=patch;h=540815eec2b83a8b43689580c54e8950d9f5868b is logically flawed because it allows... COMMAND xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path to be passed ${CMAKE_OSX_SYSROOT} containing "/" which isn't a valid argument for 'xcodebuild -sdk'... $ xcodebuild -sdk / Build settings from command line: SDKROOT = macosx10.12 This erroneously returns macosx10.12 despite the Xcode 7.3.1 Command Line Tools being installed in / containing the 10.11 SDK files. Jack On Sun, Oct 30, 2016 at 2:04 PM, Jack Howarth wrote: > Gregor, > This is also a severe regression because if forces the cmake > users to build against the 10.12 SDK on 10.11 which is not well tested > for backward compatibility on 10.11. Your change makes it impossible > to build against the SDK in / installed by the Xcode Command Line > Tools package. > Jack > > On Sun, Oct 30, 2016 at 1:33 PM, Jack Howarth > wrote: >> Gregor, >> Your commit of... >> >> https://cmake.org/gitweb?p=cmake.git;a=log;h=540815eec2b83a8b43689580c54e8950d9f5868b >> >> has caused a major regression in cmake 3.7.0 as it no longer properly >> honors the combination... >> >> -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ >> >> This is obvious by simple inspection of the code in >> Modules/Platform/Darwin-Initialize.cmake as >> the code no longer honors -DCMAKE_OSX_SYSROOT:STRING=/. At the very >> least, this code >> needs to be modified to have cmake emit "-isysroot /" in that case. >> IMHO, this issue should be considered a blocker for the cmake >> 3,7.0 release on darwin. >> Jack >> >> >> On Sun, Oct 30, 2016 at 9:36 AM, Jack Howarth >> wrote: >>> The change... >>> >>> --- cmake-3.6.2/Modules/Platform/Darwin-Initialize.cmake 2016-09-07 >>> 10:11:58.000000000 -0400 >>> +++ cmake-3.7.0-rc2/Modules/Platform/Darwin-Initialize.cmake >>> 2016-10-19 09:47:45.000000000 -0400 >>> @@ -125,8 +125,10 @@ >>> set(_CMAKE_OSX_SYSROOT_ORIG "") >>> endif() >>> set(_CMAKE_OSX_SYSROOT_PATH "${CMAKE_OSX_SYSROOT}") >>> - else() >>> - # Transform the sdk name into a path. >>> + endif() >>> + >>> + if(CMAKE_OSX_SYSROOT) >>> + # Transform the (maybe unversioned) sysroot into a versioned path. >>> execute_process( >>> COMMAND xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path >>> OUTPUT_VARIABLE _stdout >>> >>> is an obvious mistake in cmake 3.7.0-rc2. The removal of the 'else()' >>> statement here and the substitution of the ' if(CMAKE_OSX_SYSROOT)' >>> defeats the prior handling of 'if("x${CMAKE_OSX_SYSROOT}" MATCHES >>> "/")'. This causes '-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" >>> -DCMAKE_OSX_SYSROOT:STRING=/' to not be honored and -isysroot to be >>> emitted as a compiler flag universally. >>> >>> https://gitlab.kitware.com/cmake/cmake/issues/16394 From howarth.mailing.lists at gmail.com Sun Oct 30 15:23:40 2016 From: howarth.mailing.lists at gmail.com (Jack Howarth) Date: Sun, 30 Oct 2016 15:23:40 -0400 Subject: [cmake-developers] -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ broken in 3.7.0-rc2 In-Reply-To: References: Message-ID: Gregor, While I still think your hack to obtain the versioned SDK is wrong because it relies on passing invalid arguments to 'xcodebuild -sdk', the following change restores the expected behavior for -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ while allowing your hack to function when -DCMAKE_OSX_DEPLOYMENT_TARGET is not an empty string... --- cmake-3.7.0-rc2/Modules/Platform/Darwin-Initialize.cmake.orig 2016-10-30 09:45:46.000000000 -0400 +++ cmake-3.7.0-rc2/Modules/Platform/Darwin-Initialize.cmake 2016-10-30 15:16:57.000000000 -0400 @@ -116,7 +116,7 @@ set(_CMAKE_OSX_SYSROOT_ORIG "${CMAKE_OSX_SYSROOT}") set(_CMAKE_OSX_SYSROOT_PATH "") if(CMAKE_OSX_SYSROOT) - if("x${CMAKE_OSX_SYSROOT}" MATCHES "/") + if("x${CMAKE_OSX_SYSROOT}" MATCHES "/" AND CMAKE_OSX_DEPLOYMENT_TARGET MATCHES "") # This is a path to the SDK. Make sure it exists. if(NOT IS_DIRECTORY "${CMAKE_OSX_SYSROOT}") message(WARNING "Ignoring CMAKE_OSX_SYSROOT value:\n ${CMAKE_OSX_SYSROOT}\n" @@ -125,10 +125,8 @@ set(_CMAKE_OSX_SYSROOT_ORIG "") endif() set(_CMAKE_OSX_SYSROOT_PATH "${CMAKE_OSX_SYSROOT}") - endif() - - if(CMAKE_OSX_SYSROOT) - # Transform the (maybe unversioned) sysroot into a versioned path. + else() + # Transform the sdk name into a path. execute_process( COMMAND xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path OUTPUT_VARIABLE _stdout Jack On Sun, Oct 30, 2016 at 2:53 PM, Jack Howarth wrote: > Gregor, > The change in > https://cmake.org/gitweb?p=cmake.git;a=patch;h=540815eec2b83a8b43689580c54e8950d9f5868b > is logically flawed because it allows... > > COMMAND xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path > > to be passed ${CMAKE_OSX_SYSROOT} containing "/" which isn't a valid > argument for 'xcodebuild -sdk'... > > $ xcodebuild -sdk / > Build settings from command line: > SDKROOT = macosx10.12 > > This erroneously returns macosx10.12 despite the Xcode 7.3.1 Command > Line Tools being installed in / containing the 10.11 SDK files. > Jack > > > On Sun, Oct 30, 2016 at 2:04 PM, Jack Howarth > wrote: >> Gregor, >> This is also a severe regression because if forces the cmake >> users to build against the 10.12 SDK on 10.11 which is not well tested >> for backward compatibility on 10.11. Your change makes it impossible >> to build against the SDK in / installed by the Xcode Command Line >> Tools package. >> Jack >> >> On Sun, Oct 30, 2016 at 1:33 PM, Jack Howarth >> wrote: >>> Gregor, >>> Your commit of... >>> >>> https://cmake.org/gitweb?p=cmake.git;a=log;h=540815eec2b83a8b43689580c54e8950d9f5868b >>> >>> has caused a major regression in cmake 3.7.0 as it no longer properly >>> honors the combination... >>> >>> -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ >>> >>> This is obvious by simple inspection of the code in >>> Modules/Platform/Darwin-Initialize.cmake as >>> the code no longer honors -DCMAKE_OSX_SYSROOT:STRING=/. At the very >>> least, this code >>> needs to be modified to have cmake emit "-isysroot /" in that case. >>> IMHO, this issue should be considered a blocker for the cmake >>> 3,7.0 release on darwin. >>> Jack >>> >>> >>> On Sun, Oct 30, 2016 at 9:36 AM, Jack Howarth >>> wrote: >>>> The change... >>>> >>>> --- cmake-3.6.2/Modules/Platform/Darwin-Initialize.cmake 2016-09-07 >>>> 10:11:58.000000000 -0400 >>>> +++ cmake-3.7.0-rc2/Modules/Platform/Darwin-Initialize.cmake >>>> 2016-10-19 09:47:45.000000000 -0400 >>>> @@ -125,8 +125,10 @@ >>>> set(_CMAKE_OSX_SYSROOT_ORIG "") >>>> endif() >>>> set(_CMAKE_OSX_SYSROOT_PATH "${CMAKE_OSX_SYSROOT}") >>>> - else() >>>> - # Transform the sdk name into a path. >>>> + endif() >>>> + >>>> + if(CMAKE_OSX_SYSROOT) >>>> + # Transform the (maybe unversioned) sysroot into a versioned path. >>>> execute_process( >>>> COMMAND xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path >>>> OUTPUT_VARIABLE _stdout >>>> >>>> is an obvious mistake in cmake 3.7.0-rc2. The removal of the 'else()' >>>> statement here and the substitution of the ' if(CMAKE_OSX_SYSROOT)' >>>> defeats the prior handling of 'if("x${CMAKE_OSX_SYSROOT}" MATCHES >>>> "/")'. This causes '-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" >>>> -DCMAKE_OSX_SYSROOT:STRING=/' to not be honored and -isysroot to be >>>> emitted as a compiler flag universally. >>>> >>>> https://gitlab.kitware.com/cmake/cmake/issues/16394 From howarth.mailing.lists at gmail.com Sun Oct 30 15:37:18 2016 From: howarth.mailing.lists at gmail.com (Jack Howarth) Date: Sun, 30 Oct 2016 15:37:18 -0400 Subject: [cmake-developers] -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ broken in 3.7.0-rc2 In-Reply-To: References: Message-ID: Proposed fix to restore functionality for -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ while retaining the current hack when CMAKE_OSX_DEPLOYMENT_TARGET is not set to an empty string. On Sun, Oct 30, 2016 at 3:23 PM, Jack Howarth wrote: > Gregor, > While I still think your hack to obtain the versioned SDK is > wrong because it relies on passing invalid arguments to 'xcodebuild > -sdk', the following change restores the expected behavior for > -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ > while allowing your hack to function when > -DCMAKE_OSX_DEPLOYMENT_TARGET is not an empty string... > > --- cmake-3.7.0-rc2/Modules/Platform/Darwin-Initialize.cmake.orig > 2016-10-30 09:45:46.000000000 -0400 > +++ cmake-3.7.0-rc2/Modules/Platform/Darwin-Initialize.cmake > 2016-10-30 15:16:57.000000000 -0400 > @@ -116,7 +116,7 @@ > set(_CMAKE_OSX_SYSROOT_ORIG "${CMAKE_OSX_SYSROOT}") > set(_CMAKE_OSX_SYSROOT_PATH "") > if(CMAKE_OSX_SYSROOT) > - if("x${CMAKE_OSX_SYSROOT}" MATCHES "/") > + if("x${CMAKE_OSX_SYSROOT}" MATCHES "/" AND > CMAKE_OSX_DEPLOYMENT_TARGET MATCHES "") > # This is a path to the SDK. Make sure it exists. > if(NOT IS_DIRECTORY "${CMAKE_OSX_SYSROOT}") > message(WARNING "Ignoring CMAKE_OSX_SYSROOT value:\n > ${CMAKE_OSX_SYSROOT}\n" > @@ -125,10 +125,8 @@ > set(_CMAKE_OSX_SYSROOT_ORIG "") > endif() > set(_CMAKE_OSX_SYSROOT_PATH "${CMAKE_OSX_SYSROOT}") > - endif() > - > - if(CMAKE_OSX_SYSROOT) > - # Transform the (maybe unversioned) sysroot into a versioned path. > + else() > + # Transform the sdk name into a path. > execute_process( > COMMAND xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path > OUTPUT_VARIABLE _stdout > > Jack > > On Sun, Oct 30, 2016 at 2:53 PM, Jack Howarth > wrote: >> Gregor, >> The change in >> https://cmake.org/gitweb?p=cmake.git;a=patch;h=540815eec2b83a8b43689580c54e8950d9f5868b >> is logically flawed because it allows... >> >> COMMAND xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path >> >> to be passed ${CMAKE_OSX_SYSROOT} containing "/" which isn't a valid >> argument for 'xcodebuild -sdk'... >> >> $ xcodebuild -sdk / >> Build settings from command line: >> SDKROOT = macosx10.12 >> >> This erroneously returns macosx10.12 despite the Xcode 7.3.1 Command >> Line Tools being installed in / containing the 10.11 SDK files. >> Jack >> >> >> On Sun, Oct 30, 2016 at 2:04 PM, Jack Howarth >> wrote: >>> Gregor, >>> This is also a severe regression because if forces the cmake >>> users to build against the 10.12 SDK on 10.11 which is not well tested >>> for backward compatibility on 10.11. Your change makes it impossible >>> to build against the SDK in / installed by the Xcode Command Line >>> Tools package. >>> Jack >>> >>> On Sun, Oct 30, 2016 at 1:33 PM, Jack Howarth >>> wrote: >>>> Gregor, >>>> Your commit of... >>>> >>>> https://cmake.org/gitweb?p=cmake.git;a=log;h=540815eec2b83a8b43689580c54e8950d9f5868b >>>> >>>> has caused a major regression in cmake 3.7.0 as it no longer properly >>>> honors the combination... >>>> >>>> -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ >>>> >>>> This is obvious by simple inspection of the code in >>>> Modules/Platform/Darwin-Initialize.cmake as >>>> the code no longer honors -DCMAKE_OSX_SYSROOT:STRING=/. At the very >>>> least, this code >>>> needs to be modified to have cmake emit "-isysroot /" in that case. >>>> IMHO, this issue should be considered a blocker for the cmake >>>> 3,7.0 release on darwin. >>>> Jack >>>> >>>> >>>> On Sun, Oct 30, 2016 at 9:36 AM, Jack Howarth >>>> wrote: >>>>> The change... >>>>> >>>>> --- cmake-3.6.2/Modules/Platform/Darwin-Initialize.cmake 2016-09-07 >>>>> 10:11:58.000000000 -0400 >>>>> +++ cmake-3.7.0-rc2/Modules/Platform/Darwin-Initialize.cmake >>>>> 2016-10-19 09:47:45.000000000 -0400 >>>>> @@ -125,8 +125,10 @@ >>>>> set(_CMAKE_OSX_SYSROOT_ORIG "") >>>>> endif() >>>>> set(_CMAKE_OSX_SYSROOT_PATH "${CMAKE_OSX_SYSROOT}") >>>>> - else() >>>>> - # Transform the sdk name into a path. >>>>> + endif() >>>>> + >>>>> + if(CMAKE_OSX_SYSROOT) >>>>> + # Transform the (maybe unversioned) sysroot into a versioned path. >>>>> execute_process( >>>>> COMMAND xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path >>>>> OUTPUT_VARIABLE _stdout >>>>> >>>>> is an obvious mistake in cmake 3.7.0-rc2. The removal of the 'else()' >>>>> statement here and the substitution of the ' if(CMAKE_OSX_SYSROOT)' >>>>> defeats the prior handling of 'if("x${CMAKE_OSX_SYSROOT}" MATCHES >>>>> "/")'. This causes '-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" >>>>> -DCMAKE_OSX_SYSROOT:STRING=/' to not be honored and -isysroot to be >>>>> emitted as a compiler flag universally. >>>>> >>>>> https://gitlab.kitware.com/cmake/cmake/issues/16394 -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake.patch Type: application/octet-stream Size: 1058 bytes Desc: not available URL: From howarth.mailing.lists at gmail.com Sun Oct 30 15:54:28 2016 From: howarth.mailing.lists at gmail.com (Jack Howarth) Date: Sun, 30 Oct 2016 15:54:28 -0400 Subject: [cmake-developers] -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ broken in 3.7.0-rc2 In-Reply-To: References: Message-ID: One other comment. For new Xcode releases on the prior OS release (eg Xcode 8 on 10.11), the SDK files installed in / by the Command Line Tools are actually those for the 10.11 SDK and *not* those from the 10.12 SDK. This is why the Xcode 8 release lacks a Command Line Tools package for 10.11 (since Swift 3 requires the 10.12 SDK to properly work). So the current code in Modules/Platform/Darwin-Initialize.cmake in cmake 3.7.0-rc2 and proposed patch are both returning non-sensical SDK versions for the SDK in / on 10.11 from 'xcodebuild -sdk'. FYI. On Sun, Oct 30, 2016 at 3:37 PM, Jack Howarth wrote: > Proposed fix to restore functionality for > -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ > while retaining the current hack when CMAKE_OSX_DEPLOYMENT_TARGET is > not set to an empty string. > > On Sun, Oct 30, 2016 at 3:23 PM, Jack Howarth > wrote: >> Gregor, >> While I still think your hack to obtain the versioned SDK is >> wrong because it relies on passing invalid arguments to 'xcodebuild >> -sdk', the following change restores the expected behavior for >> -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ >> while allowing your hack to function when >> -DCMAKE_OSX_DEPLOYMENT_TARGET is not an empty string... >> >> --- cmake-3.7.0-rc2/Modules/Platform/Darwin-Initialize.cmake.orig >> 2016-10-30 09:45:46.000000000 -0400 >> +++ cmake-3.7.0-rc2/Modules/Platform/Darwin-Initialize.cmake >> 2016-10-30 15:16:57.000000000 -0400 >> @@ -116,7 +116,7 @@ >> set(_CMAKE_OSX_SYSROOT_ORIG "${CMAKE_OSX_SYSROOT}") >> set(_CMAKE_OSX_SYSROOT_PATH "") >> if(CMAKE_OSX_SYSROOT) >> - if("x${CMAKE_OSX_SYSROOT}" MATCHES "/") >> + if("x${CMAKE_OSX_SYSROOT}" MATCHES "/" AND >> CMAKE_OSX_DEPLOYMENT_TARGET MATCHES "") >> # This is a path to the SDK. Make sure it exists. >> if(NOT IS_DIRECTORY "${CMAKE_OSX_SYSROOT}") >> message(WARNING "Ignoring CMAKE_OSX_SYSROOT value:\n >> ${CMAKE_OSX_SYSROOT}\n" >> @@ -125,10 +125,8 @@ >> set(_CMAKE_OSX_SYSROOT_ORIG "") >> endif() >> set(_CMAKE_OSX_SYSROOT_PATH "${CMAKE_OSX_SYSROOT}") >> - endif() >> - >> - if(CMAKE_OSX_SYSROOT) >> - # Transform the (maybe unversioned) sysroot into a versioned path. >> + else() >> + # Transform the sdk name into a path. >> execute_process( >> COMMAND xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path >> OUTPUT_VARIABLE _stdout >> >> Jack >> >> On Sun, Oct 30, 2016 at 2:53 PM, Jack Howarth >> wrote: >>> Gregor, >>> The change in >>> https://cmake.org/gitweb?p=cmake.git;a=patch;h=540815eec2b83a8b43689580c54e8950d9f5868b >>> is logically flawed because it allows... >>> >>> COMMAND xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path >>> >>> to be passed ${CMAKE_OSX_SYSROOT} containing "/" which isn't a valid >>> argument for 'xcodebuild -sdk'... >>> >>> $ xcodebuild -sdk / >>> Build settings from command line: >>> SDKROOT = macosx10.12 >>> >>> This erroneously returns macosx10.12 despite the Xcode 7.3.1 Command >>> Line Tools being installed in / containing the 10.11 SDK files. >>> Jack >>> >>> >>> On Sun, Oct 30, 2016 at 2:04 PM, Jack Howarth >>> wrote: >>>> Gregor, >>>> This is also a severe regression because if forces the cmake >>>> users to build against the 10.12 SDK on 10.11 which is not well tested >>>> for backward compatibility on 10.11. Your change makes it impossible >>>> to build against the SDK in / installed by the Xcode Command Line >>>> Tools package. >>>> Jack >>>> >>>> On Sun, Oct 30, 2016 at 1:33 PM, Jack Howarth >>>> wrote: >>>>> Gregor, >>>>> Your commit of... >>>>> >>>>> https://cmake.org/gitweb?p=cmake.git;a=log;h=540815eec2b83a8b43689580c54e8950d9f5868b >>>>> >>>>> has caused a major regression in cmake 3.7.0 as it no longer properly >>>>> honors the combination... >>>>> >>>>> -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ >>>>> >>>>> This is obvious by simple inspection of the code in >>>>> Modules/Platform/Darwin-Initialize.cmake as >>>>> the code no longer honors -DCMAKE_OSX_SYSROOT:STRING=/. At the very >>>>> least, this code >>>>> needs to be modified to have cmake emit "-isysroot /" in that case. >>>>> IMHO, this issue should be considered a blocker for the cmake >>>>> 3,7.0 release on darwin. >>>>> Jack >>>>> >>>>> >>>>> On Sun, Oct 30, 2016 at 9:36 AM, Jack Howarth >>>>> wrote: >>>>>> The change... >>>>>> >>>>>> --- cmake-3.6.2/Modules/Platform/Darwin-Initialize.cmake 2016-09-07 >>>>>> 10:11:58.000000000 -0400 >>>>>> +++ cmake-3.7.0-rc2/Modules/Platform/Darwin-Initialize.cmake >>>>>> 2016-10-19 09:47:45.000000000 -0400 >>>>>> @@ -125,8 +125,10 @@ >>>>>> set(_CMAKE_OSX_SYSROOT_ORIG "") >>>>>> endif() >>>>>> set(_CMAKE_OSX_SYSROOT_PATH "${CMAKE_OSX_SYSROOT}") >>>>>> - else() >>>>>> - # Transform the sdk name into a path. >>>>>> + endif() >>>>>> + >>>>>> + if(CMAKE_OSX_SYSROOT) >>>>>> + # Transform the (maybe unversioned) sysroot into a versioned path. >>>>>> execute_process( >>>>>> COMMAND xcodebuild -sdk ${CMAKE_OSX_SYSROOT} -version Path >>>>>> OUTPUT_VARIABLE _stdout >>>>>> >>>>>> is an obvious mistake in cmake 3.7.0-rc2. The removal of the 'else()' >>>>>> statement here and the substitution of the ' if(CMAKE_OSX_SYSROOT)' >>>>>> defeats the prior handling of 'if("x${CMAKE_OSX_SYSROOT}" MATCHES >>>>>> "/")'. This causes '-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" >>>>>> -DCMAKE_OSX_SYSROOT:STRING=/' to not be honored and -isysroot to be >>>>>> emitted as a compiler flag universally. >>>>>> >>>>>> https://gitlab.kitware.com/cmake/cmake/issues/16394 From gjasny at googlemail.com Sun Oct 30 17:38:17 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Sun, 30 Oct 2016 22:38:17 +0100 Subject: [cmake-developers] -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ broken in 3.7.0-rc2 In-Reply-To: References: Message-ID: <90eba6e6-3cdc-a801-4919-db6defc62f69@googlemail.com> Hello Howarth, I'm sorry that I broke your use case with that patch. The problem I have with maintaining the Xcode / Darwin code is that it is full of backward compatibility and unknown, undocumented use cases. That makes it sometimes hard to foresee consequences. On 30/10/2016 19:04, Jack Howarth wrote: > Gregor, > This is also a severe regression because if forces the cmake > users to build against the 10.12 SDK on 10.11 which is not well tested > for backward compatibility on 10.11. Your change makes it impossible > to build against the SDK in / installed by the Xcode Command Line > Tools package. What do you mean with SDK installed into "/"? I was under the impression that the Command Line Tools package is installed automatically by Xcode after first start. I thought it provides the /usr/bin/clang etc. Thanks, Gregor From gjasny at googlemail.com Sun Oct 30 18:13:09 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Sun, 30 Oct 2016 23:13:09 +0100 Subject: [cmake-developers] -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ broken in 3.7.0-rc2 In-Reply-To: References: Message-ID: On 30/10/2016 20:37, Jack Howarth wrote: > Proposed fix to restore functionality for > -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ > while retaining the current hack when CMAKE_OSX_DEPLOYMENT_TARGET is > not set to an empty string. Thanks for the patch but it is breaking #16323 again: > ~/src/cmake/_build/bin/cmake -DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -DCMAKE_OSX_DEPLOYMENT_TARGET=10.10 -GXcode .. > -- The C compiler identification is AppleClang 8.0.0.8000042 > -- The CXX compiler identification is AppleClang 8.0.0.8000042 > CMake Error at /Users/jasny/src/cmake/Modules/Platform/Darwin.cmake:76 (message): > CMAKE_OSX_DEPLOYMENT_TARGET is '10.10' but CMAKE_OSX_SYSROOT: > > "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk" > > is not set to a MacOSX SDK with a recognized version. Either set > CMAKE_OSX_SYSROOT to a valid SDK or set CMAKE_OSX_DEPLOYMENT_TARGET to > empty. > Call Stack (most recent call first): > /Users/jasny/src/cmake/Modules/CMakeSystemSpecificInformation.cmake:26 (include) > CMakeLists.txt > > > -- Configuring incomplete, errors occurred! > See also "/Users/jasny/tmp/cm/_build/CMakeFiles/CMakeOutput.log". From howarth.mailing.lists at gmail.com Sun Oct 30 18:28:36 2016 From: howarth.mailing.lists at gmail.com (Jack Howarth) Date: Sun, 30 Oct 2016 18:28:36 -0400 Subject: [cmake-developers] -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ broken in 3.7.0-rc2 In-Reply-To: <90eba6e6-3cdc-a801-4919-db6defc62f69@googlemail.com> References: <90eba6e6-3cdc-a801-4919-db6defc62f69@googlemail.com> Message-ID: On Sun, Oct 30, 2016 at 5:38 PM, Gregor Jasny wrote: > Hello Howarth, > > I'm sorry that I broke your use case with that patch. The problem I have > with maintaining the Xcode / Darwin code is that it is full of backward > compatibility and unknown, undocumented use cases. That makes it > sometimes hard to foresee consequences. Gregor, I would just consider this particular corner case as the situation where the user wants to build against the SDK installed at the / level (which is a special case since it obviously doesn't have an OS release version associated with the directory location). Thus the obvious set of cmake options that define that case is... -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" \ -DCMAKE_OSX_SYSROOT:STRING=/ You have two options to satisfy that combination of options. One is the original coding prior to your change or my proposed patch which omits any -isysroot output for that case. The alternative would be to recode for that combination and emit '-isysroot /' The second option is rather redundant so no one ever bothers to do it as the absence of -isysroot assumes '-isysroot /' for the SDK as the default. Jack ps I would at least go ahead and check in the patch I previously attached which restores the proper handle for the case of... -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" \ -DCMAKE_OSX_SYSROOT:STRING=/ which should still do what you want when CMAKE_OSX_DEPLOYMENT_TARGET is set to an non-null string. Jack > > On 30/10/2016 19:04, Jack Howarth wrote: >> Gregor, >> This is also a severe regression because if forces the cmake >> users to build against the 10.12 SDK on 10.11 which is not well tested >> for backward compatibility on 10.11. Your change makes it impossible >> to build against the SDK in / installed by the Xcode Command Line >> Tools package. > > What do you mean with SDK installed into "/"? I was under the impression > that the Command Line Tools package is installed automatically by Xcode > after first start. I thought it provides the /usr/bin/clang etc. > > Thanks, > Gregor -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake.patch Type: application/octet-stream Size: 1058 bytes Desc: not available URL: From gjasny at googlemail.com Sun Oct 30 18:33:00 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Sun, 30 Oct 2016 23:33:00 +0100 Subject: [cmake-developers] -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ broken in 3.7.0-rc2 In-Reply-To: References: Message-ID: On 30/10/2016 20:23, Jack Howarth wrote: > Gregor, > While I still think your hack to obtain the versioned SDK is > wrong because it relies on passing invalid arguments to 'xcodebuild > -sdk', the following change restores the expected behavior for > -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ > while allowing your hack to function when > -DCMAKE_OSX_DEPLOYMENT_TARGET is not an empty string... Some questions: 1) Is "xcodebuild -sdk / -version SDKVersion" returning the proper version? I bet not because you called / an invalid argument. 2) Would it make sense to perform some pre-checks before applying my "hack" in case sdk is a path? For example if it starts with the output of "xcode-select --print-path" Thanks, Gregor From gjasny at googlemail.com Sun Oct 30 19:03:44 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Mon, 31 Oct 2016 00:03:44 +0100 Subject: [cmake-developers] -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ broken in 3.7.0-rc2 In-Reply-To: References: Message-ID: <2d5f8283-e6d3-c710-fd5b-65c551a4c41d@googlemail.com> On 30/10/2016 18:33, Jack Howarth wrote: > Gregor, > Your commit of... > > https://cmake.org/gitweb?p=cmake.git;a=log;h=540815eec2b83a8b43689580c54e8950d9f5868b > > has caused a major regression in cmake 3.7.0 as it no longer properly > honors the combination... > > -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ I think I revert my change and also completely remove the deployment target mismatch because I cannot see a way to query SDK versions for Command Line Tools installs. Thanks, Gregor From davispuh at gmail.com Sun Oct 30 21:06:46 2016 From: davispuh at gmail.com (=?UTF-8?B?RMSBdmlzIE1vc8SBbnM=?=) Date: Mon, 31 Oct 2016 03:06:46 +0200 Subject: [cmake-developers] [PATCH v7] For Windows encode process output to internally used encoding In-Reply-To: <5f7f6a2b-7da8-d74f-e46d-f54941dd6cd0@kitware.com> References: <20160815203421.28064-1-davispuh@gmail.com> <9b10aee6-64fe-55dc-17af-d0fcd6c37a00@kitware.com> <5f7f6a2b-7da8-d74f-e46d-f54941dd6cd0@kitware.com> Message-ID: 2016-08-17 16:47 GMT+03:00 Brad King : > I squashed in one warning fix: > > Windows: Encode child process output to internally-used encoding > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=12924660 > > However, then I had to revert the change from `next` because it > causes the CTest.UpdateGIT test to fail on Windows machines. > I think the problem is that we run Git with a `-z` option to > produce binary output. In such cases we should not do any > encoding conversions. cmProcessTools and RunSingleCommand > will need to gain options for this. While git's `-z` flag caused test to fail it wasn't because of binary output (we're still working with text data like commit messages and file names) but it showed a bug that we would truncate output till first null byte. `-z` option specifies that git will use null bytes as separators between entries and it's independent from used text encoding. We still need to decode git's output (which contains null bytes) to our internal encoding. > Also I noticed that if DecodeText buffers partial characters we > may need a finalize step later to finish them off. Otherwise > invalid byte sequences may be dropped if they appear at the end. > > Please fetch the above version and revise it as needed. > I've fixed it and submitted MR to https://gitlab.kitware.com/cmake/cmake/merge_requests/221 From rcdailey.lists at gmail.com Mon Oct 31 09:31:22 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 31 Oct 2016 08:31:22 -0500 Subject: [cmake-developers] [CMake] CMake integration in Gradle (Android Studio) In-Reply-To: References: Message-ID: Which version of Android Studio? Latest stable is 2.2 IIRC. Are you talking about dev/beta builds? On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey wrote: > The latest release of android studio work with CMAKE well. > > you can create a new project with c++ support to test CMAKE support! > > You can follow https://code.google.com/p/android/issues/detail?id=212007 > to get the details. > > 2016-10-28 5:48 GMT+08:00 Robert Dailey : >> I'm at a bit of a loss on finding more information. Can anyone at >> least confirm that this isn't a reliable place to find the answers I'm >> looking for? Does anyone have real experience with android + gradle + >> cmake integration and can provide some pointers? >> >> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey wrote: >>> I'm not sure if the CMake mailing lists are the right place to ask >>> this question but I thought I'd ask just in case someone has gone down >>> this path or has experience with what Google/Gradle is actually trying >>> to accomplish with what seems to be a hand-built version of CMake with >>> custom patches that are not in upstream repositories. >>> >>> Prior to switching to Android Studio / Gradle, I was using Eclipse / >>> Ant. The way I did CMake integration was not really integration at >>> all: I generated Ninja build scripts using CMake and implemented >>> custom targets to run "ant release" after all the C++ projects were >>> built. I made sure that CMake copied relevant *.so files to >>> appropriate directories in the Ant structure so they are packaged with >>> built APKs. That's how I did my Android development. >>> >>> Now that I'm integrating CMake into Gradle, first annoyance I noticed >>> is that I can't use CMake 3.7 (or any external installation of CMake) >>> with Android Studio. It requires a version of CMake installed through >>> SDK Manager. This means I can't use the new Android toolchain >>> functionality built into CMake 3.7 (sad face). But this is something I >>> can work around... >>> >>> Next I found out that stuff I'm setting in my CMake scripts, such as >>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied. >>> For whatever reason, Gradle is overriding these from the command line >>> (I'm guessing?). So this requires me to duplicate the toolchain / >>> compiler flag setup I already do in my CMake scripts now in the Gradle >>> build scripts. This seems completely unnecessary and a maintenance >>> burden. >>> >>> What I was expecting Gradle to do was essentially provide me some >>> toolchain file so that CMake can find the compiler and linker to use >>> and then the rest would be determined by CMake itself. >>> >>> Is there a way I can tell Gradle to not take so much control over >>> compiler flags? I want my CMake scripts to do this. I can't imagine >>> they had a good reason to do this. What have others done in this >>> situation with their own Gradle + CMake integration? Looking for >>> advice here, since information is sparse, especially since the Android >>> Studio 2.2 CMake integration is relatively new stuff. >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake From congzhangzh at gmail.com Mon Oct 31 09:55:03 2016 From: congzhangzh at gmail.com (Cong Monkey) Date: Mon, 31 Oct 2016 21:55:03 +0800 Subject: [cmake-developers] [CMake] CMake integration in Gradle (Android Studio) In-Reply-To: References: Message-ID: Try to update your Android SDK from android studio? 2016?10?31? 21:31?"Robert Dailey" ??? Which version of Android Studio? Latest stable is 2.2 IIRC. Are you talking about dev/beta builds? On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey wrote: > The latest release of android studio work with CMAKE well. > > you can create a new project with c++ support to test CMAKE support! > > You can follow https://code.google.com/p/android/issues/detail?id=212007 > to get the details. > > 2016-10-28 5:48 GMT+08:00 Robert Dailey : >> I'm at a bit of a loss on finding more information. Can anyone at >> least confirm that this isn't a reliable place to find the answers I'm >> looking for? Does anyone have real experience with android + gradle + >> cmake integration and can provide some pointers? >> >> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey wrote: >>> I'm not sure if the CMake mailing lists are the right place to ask >>> this question but I thought I'd ask just in case someone has gone down >>> this path or has experience with what Google/Gradle is actually trying >>> to accomplish with what seems to be a hand-built version of CMake with >>> custom patches that are not in upstream repositories. >>> >>> Prior to switching to Android Studio / Gradle, I was using Eclipse / >>> Ant. The way I did CMake integration was not really integration at >>> all: I generated Ninja build scripts using CMake and implemented >>> custom targets to run "ant release" after all the C++ projects were >>> built. I made sure that CMake copied relevant *.so files to >>> appropriate directories in the Ant structure so they are packaged with >>> built APKs. That's how I did my Android development. >>> >>> Now that I'm integrating CMake into Gradle, first annoyance I noticed >>> is that I can't use CMake 3.7 (or any external installation of CMake) >>> with Android Studio. It requires a version of CMake installed through >>> SDK Manager. This means I can't use the new Android toolchain >>> functionality built into CMake 3.7 (sad face). But this is something I >>> can work around... >>> >>> Next I found out that stuff I'm setting in my CMake scripts, such as >>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied. >>> For whatever reason, Gradle is overriding these from the command line >>> (I'm guessing?). So this requires me to duplicate the toolchain / >>> compiler flag setup I already do in my CMake scripts now in the Gradle >>> build scripts. This seems completely unnecessary and a maintenance >>> burden. >>> >>> What I was expecting Gradle to do was essentially provide me some >>> toolchain file so that CMake can find the compiler and linker to use >>> and then the rest would be determined by CMake itself. >>> >>> Is there a way I can tell Gradle to not take so much control over >>> compiler flags? I want my CMake scripts to do this. I can't imagine >>> they had a good reason to do this. What have others done in this >>> situation with their own Gradle + CMake integration? Looking for >>> advice here, since information is sparse, especially since the Android >>> Studio 2.2 CMake integration is relatively new stuff. >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/ opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Mon Oct 31 10:13:18 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 31 Oct 2016 09:13:18 -0500 Subject: [cmake-developers] [CMake] CMake integration in Gradle (Android Studio) In-Reply-To: References: Message-ID: I'm sorry but that doesn't really answer my questions. On Mon, Oct 31, 2016 at 8:55 AM, Cong Monkey wrote: > Try to update your Android SDK from android studio? > > > 2016?10?31? 21:31?"Robert Dailey" ??? > > Which version of Android Studio? Latest stable is 2.2 IIRC. Are you > talking about dev/beta builds? > > On Sun, Oct 30, 2016 at 9:04 AM, Cong Monkey wrote: >> The latest release of android studio work with CMAKE well. >> >> you can create a new project with c++ support to test CMAKE support! >> >> You can follow https://code.google.com/p/android/issues/detail?id=212007 >> to get the details. >> >> 2016-10-28 5:48 GMT+08:00 Robert Dailey : >>> I'm at a bit of a loss on finding more information. Can anyone at >>> least confirm that this isn't a reliable place to find the answers I'm >>> looking for? Does anyone have real experience with android + gradle + >>> cmake integration and can provide some pointers? >>> >>> On Tue, Oct 25, 2016 at 8:48 AM, Robert Dailey >>> wrote: >>>> I'm not sure if the CMake mailing lists are the right place to ask >>>> this question but I thought I'd ask just in case someone has gone down >>>> this path or has experience with what Google/Gradle is actually trying >>>> to accomplish with what seems to be a hand-built version of CMake with >>>> custom patches that are not in upstream repositories. >>>> >>>> Prior to switching to Android Studio / Gradle, I was using Eclipse / >>>> Ant. The way I did CMake integration was not really integration at >>>> all: I generated Ninja build scripts using CMake and implemented >>>> custom targets to run "ant release" after all the C++ projects were >>>> built. I made sure that CMake copied relevant *.so files to >>>> appropriate directories in the Ant structure so they are packaged with >>>> built APKs. That's how I did my Android development. >>>> >>>> Now that I'm integrating CMake into Gradle, first annoyance I noticed >>>> is that I can't use CMake 3.7 (or any external installation of CMake) >>>> with Android Studio. It requires a version of CMake installed through >>>> SDK Manager. This means I can't use the new Android toolchain >>>> functionality built into CMake 3.7 (sad face). But this is something I >>>> can work around... >>>> >>>> Next I found out that stuff I'm setting in my CMake scripts, such as >>>> CPP flags like `-std=c++14` and `-fexceptions` was not being applied. >>>> For whatever reason, Gradle is overriding these from the command line >>>> (I'm guessing?). So this requires me to duplicate the toolchain / >>>> compiler flag setup I already do in my CMake scripts now in the Gradle >>>> build scripts. This seems completely unnecessary and a maintenance >>>> burden. >>>> >>>> What I was expecting Gradle to do was essentially provide me some >>>> toolchain file so that CMake can find the compiler and linker to use >>>> and then the rest would be determined by CMake itself. >>>> >>>> Is there a way I can tell Gradle to not take so much control over >>>> compiler flags? I want my CMake scripts to do this. I can't imagine >>>> they had a good reason to do this. What have others done in this >>>> situation with their own Gradle + CMake integration? Looking for >>>> advice here, since information is sparse, especially since the Android >>>> Studio 2.2 CMake integration is relatively new stuff. >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake > > From gjasny at googlemail.com Mon Oct 31 13:26:11 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Mon, 31 Oct 2016 18:26:11 +0100 Subject: [cmake-developers] -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ broken in 3.7.0-rc2 In-Reply-To: <2d5f8283-e6d3-c710-fd5b-65c551a4c41d@googlemail.com> References: <2d5f8283-e6d3-c710-fd5b-65c551a4c41d@googlemail.com> Message-ID: On 31/10/2016 00:03, Gregor Jasny wrote: > On 30/10/2016 18:33, Jack Howarth wrote: >> Gregor, >> Your commit of... >> >> https://cmake.org/gitweb?p=cmake.git;a=log;h=540815eec2b83a8b43689580c54e8950d9f5868b >> >> has caused a major regression in cmake 3.7.0 as it no longer properly >> honors the combination... >> >> -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/ > > I think I revert my change and also completely remove the deployment > target mismatch because I cannot see a way to query SDK versions for > Command Line Tools installs. I put my changes into fix-macos-sysroot topic and merged to next. See: https://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/fix-macos-sysroot Thanks, Gregor From gjasny at googlemail.com Mon Oct 31 14:26:19 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Mon, 31 Oct 2016 19:26:19 +0100 Subject: [cmake-developers] Developer workflow with gitlab Message-ID: <6dc0de7b-57e8-f8b3-36f9-f0f957803a22@googlemail.com> Hello, I wonder what's the recommended workflow for CMake developers with commit access to stage? I'd like to use feature branches in gitlab but wonder how those are best merged into 'next'? Could you please advise or point me to some documentation? Thanks, Gregor From ewmailing at gmail.com Mon Oct 31 14:39:15 2016 From: ewmailing at gmail.com (Eric Wing) Date: Mon, 31 Oct 2016 11:39:15 -0700 Subject: [cmake-developers] [CMake] CMake integration in Gradle (Android Studio) In-Reply-To: References: Message-ID: So I have been using (a custom) CMake + Android Studio/Gradle for some years now. I only recently saw that both official CMake is adding Android support, and that the official Android tools are supporting CMake. I?m actually still confused on the differences between the two and what each offers in terms of features. My custom/jury-rigged CMake is derived from the OpenCV Android toolchain which has forked around for many years. Currently, I have a combination of custom shell scripts + modified toolchain + modified CMake to make things work. My cross-platform requirements have been: - Must generate be able to generate a new Android Studio/Gradle project, like how Xcode, Visual Studio, etc. are generated. - Must handle multiple Android architectures (armv5, armv7, x86, arm64, x86_64) - Must be able to handle both the native code stuff, and the annoying Android specific Java code in order to build a complete/working Android application that can be installed/run through the normal Android Studio/Gradle user interface. - Should work on Mac, Linux, and Android The way it currently works is: - I have a front end scripts you must run which ultimately invoke cmake -G ?Unix Makefiles? for the Android NDK. These scripts feed my android toolchain as well as provide the locations to the Android NDK and SDK. Also, these scripts will generate Gradle and Android Studio projects. (I basically brute force stripped down a real Gradle/Studio project and figured out what values I need to inject into it to use as a template. Many of the injected values are provided from CMake variables I define in my project CMakeLists.txt) - The Gradle/Studio project generated has a custom Groovy script phase that when building, invokes an external shell script as part of the build process. This external script ultimately calls CMake to build the native components of the project. - Because CMake doesn?t handle multiple architectures for Android, my script actually generates multiple CMake projects, one for each architecture, separated into directory structures that try to mimic the official names of the different Android architectures. (This is kind of brute force, and is not currently easy to opt-out of different architectures.) - At the end of the script phase, I use a CMake ?install? to copy the build products for each architecture to the correct location in the Gradle/Studio Java layout, so the Java part of the build will continue on doing the right thing. - The rest of the Gradle/Studio build will continue on and build the Android Java parts of the project. (I have a specific convention for where the Android/Java files go in my project structure. Unlike the annoying thing that Google forced us to do with ndk-build, the Java stuff is no longer at the root of the source tree, but parked in a special Android subdirectory. The former was a stupid/evil requirement for every pre-existing cross-platform project out there, and an arrogant presumption for new projects, so I did away with it.) Here are a few videos that show the workflow (in my SDK called Blurrr) "Workflow" in Swift: The Android Addendum (shows just the Android part) https://www.youtube.com/watch?v=w6FY_qSi8yY Workflow": Cross-platform Dev in Swift (This shows the same project as above, but for the non-Android platforms, showing it is indeed a single, unified CMake project that can drive Linux, OS X, iOS, Windows, and Raspberry Pi (and Android). https://www.youtube.com/watch?v=w8ftI9mpGdY Blurrr Introduction Part 3 (Shows the different build platforms in a little more detail. This video is the oldest, so things have improved a bit.) https://www.youtube.com/watch?v=exPtM-02YRY So my wish list for the new CMake versions is that is handles all of this. (Multi-arch and Gradle/Studio generation especially.) I have not yet investigated how hard it will be to migrate to one of the two other versions of CMake. Since Swift is one of my supported languages, this currently requires me to use a forked CMake I?ve been working on. However, I am happy to work with people who want to try to integrate some of my features directly into CMake if they are still missing (such as the Gradle/Studio generation). Thanks, Eric From ben.boeckel at kitware.com Mon Oct 31 16:44:46 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 31 Oct 2016 16:44:46 -0400 Subject: [cmake-developers] Developer workflow with gitlab In-Reply-To: <6dc0de7b-57e8-f8b3-36f9-f0f957803a22@googlemail.com> References: <6dc0de7b-57e8-f8b3-36f9-f0f957803a22@googlemail.com> Message-ID: <20161031204446.GA27747@megas.kitware.com> On Mon, Oct 31, 2016 at 19:26:19 +0100, Gregor Jasny via cmake-developers wrote: > I wonder what's the recommended workflow for CMake developers with > commit access to stage? I'd like to use feature branches in gitlab but > wonder how those are best merged into 'next'? > > Could you please advise or point me to some documentation? The stage is still separate, so pushing to Gitlab is best for review and discussion. In the coming weeks, there will be a tool to manage the stage from within Gitlab (obsoleting the old stage). --Ben From florent.castelli at gmail.com Mon Oct 31 18:04:54 2016 From: florent.castelli at gmail.com (Florent Castelli) Date: Mon, 31 Oct 2016 23:04:54 +0100 Subject: [cmake-developers] CMake integration in Gradle (Android Studio) In-Reply-To: References: Message-ID: <267ae9a6-d4bb-accc-7617-76d2ded27c46@gmail.com> I tried the Gradle + CMake integration and I'm not really impressed. I would recommend not using it right now until they fix the rough edges. The prime concern is that it is REALLY hard to get the CMake output and compilation output, even within Android Studio. If you compile from command line, you won't see much. This is a no go for CI environments where you need to see what went wrong and also some output once in a while (or builds are usually considered stuck and canceled if they take too long). See the issue: https://code.google.com/p/android/issues/detail?id=210930 Installing CMake within the SDK is not trivial. There's an open bug with a proposed solution, it's not pretty stuff but does the work: https://code.google.com/p/android/issues/detail?id=221907 An alternative would be to repackage your SDK folder after running Android Studio and installing everything you need and distribute that to your CI build machines / developer machines. But essentially, what you want is probably just use their toolchain file, which is much better than the OpenCV one. You can find it bundled in the latest NDK and I guess you could be using that directly with CMake. If it is doing weird things, I guess you could have a look at it and debug it. It's not as complicated as the OpenCV one and I hope you'll find the solution to your issues! As for CMake 3.7, when I asked about it in this mailing list, someone said there will be a compatibility layer to the toolchain to reuse the upstream support when it's available if I remember correctly. /Florent On 25/10/2016 15:48, Robert Dailey wrote: > I'm not sure if the CMake mailing lists are the right place to ask > this question but I thought I'd ask just in case someone has gone down > this path or has experience with what Google/Gradle is actually trying > to accomplish with what seems to be a hand-built version of CMake with > custom patches that are not in upstream repositories. > > Prior to switching to Android Studio / Gradle, I was using Eclipse / > Ant. The way I did CMake integration was not really integration at > all: I generated Ninja build scripts using CMake and implemented > custom targets to run "ant release" after all the C++ projects were > built. I made sure that CMake copied relevant *.so files to > appropriate directories in the Ant structure so they are packaged with > built APKs. That's how I did my Android development. > > Now that I'm integrating CMake into Gradle, first annoyance I noticed > is that I can't use CMake 3.7 (or any external installation of CMake) > with Android Studio. It requires a version of CMake installed through > SDK Manager. This means I can't use the new Android toolchain > functionality built into CMake 3.7 (sad face). But this is something I > can work around... > > Next I found out that stuff I'm setting in my CMake scripts, such as > CPP flags like `-std=c++14` and `-fexceptions` was not being applied. > For whatever reason, Gradle is overriding these from the command line > (I'm guessing?). So this requires me to duplicate the toolchain / > compiler flag setup I already do in my CMake scripts now in the Gradle > build scripts. This seems completely unnecessary and a maintenance > burden. > > What I was expecting Gradle to do was essentially provide me some > toolchain file so that CMake can find the compiler and linker to use > and then the rest would be determined by CMake itself. > > Is there a way I can tell Gradle to not take so much control over > compiler flags? I want my CMake scripts to do this. I can't imagine > they had a good reason to do this. What have others done in this > situation with their own Gradle + CMake integration? Looking for > advice here, since information is sparse, especially since the Android > Studio 2.2 CMake integration is relatively new stuff.