From Marek.Vojtko at firaxis.com Mon Apr 2 18:49:22 2018 From: Marek.Vojtko at firaxis.com (Marek Vojtko (Firaxis)) Date: Mon, 2 Apr 2018 22:49:22 +0000 Subject: [CMake] IMPORTED DLL-only Target on MSVC Message-ID: Hi, Is it not possible to wrap an external DLL-only library in an IMPORTED target? I have an external dependency that is a single DLL (shared library) and a header file, but no LIB (static library) file. When I create an IMPORTED target and depend on it via target_link_libraries() I run into linkage issues, because on MSVC CMake puts the DLL into the linker command (the "Input" text field in the "Linker" settings of the Project Properties). add_library( MyDependency::MyDependency MODULE IMPORTED ) set_target_properties( MyDependency::MyDependency PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${MyDependency_INCLUDE_DIR}" IMPORTED_LOCATION "${MyDependency_SHARED_LIB}" ) [..] add_executable( MyExecutable ... ) target_link_libraries( MyExecutable PRIVATE MyDependency::MyDependency ) I tried changing the library type in my add_library() call: - STATIC obviously didn't work, because I don't have a .lib file and the .dll file in IMPORTED_LOCATION was added to MyExecutable's linker line. - SHARED did not work because CMake expects a .dll in IMPORTED_LOCATION and a .lib in IMPORTED_IMP_LOCATION, so MyExecutable's linker line had a MyDependency::MyDependency-NOTFOUND entry in it. - MODULE seemed like the right choice when reading the documentation, but MyExecutable's linker line still contains the .dll file specified in IMPORTED_LOCATION. What am I doing wrong? Thanks, Marek From michael.stuermer at schaeffler.com Tue Apr 3 00:17:32 2018 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Tue, 3 Apr 2018 04:17:32 +0000 Subject: [CMake] IMPORTED DLL-only Target on MSVC In-Reply-To: References: Message-ID: <9b48e34d3d384eba93096cc9c9efaade@DE013666.schaeffler.com> > -----Urspr?ngliche Nachricht----- > Von: CMake [mailto:cmake-bounces at cmake.org] Im Auftrag von Marek > Vojtko (Firaxis) > Gesendet: Dienstag, 3. April 2018 00:49 > An: cmake at cmake.org > Betreff: [CMake] IMPORTED DLL-only Target on MSVC > > Hi, > > Is it not possible to wrap an external DLL-only library in an IMPORTED target? > Yes it is. > I have an external dependency that is a single DLL (shared library) and a > header file, but no LIB (static library) file. When I create an IMPORTED target How does this work in Visual Studio C++? If I am not completely mistaken you ALWAYS need a .lib file along with your .dll to link to the shared library. And you Need a header with the API as well of course. The only case I know with .dll and without .lib file is when you have managed C++ or C# targets. > and depend on it via target_link_libraries() I run into linkage issues, because > on MSVC CMake puts the DLL into the linker command (the "Input" text field > in the "Linker" settings of the Project Properties). > > add_library( MyDependency::MyDependency MODULE IMPORTED ) > set_target_properties( MyDependency::MyDependency > PROPERTIES > INTERFACE_INCLUDE_DIRECTORIES "${MyDependency_INCLUDE_DIR}" > IMPORTED_LOCATION "${MyDependency_SHARED_LIB}" > ) > [..] > add_executable( MyExecutable ... ) > target_link_libraries( MyExecutable PRIVATE > MyDependency::MyDependency ) > > I tried changing the library type in my add_library() call: > - STATIC obviously didn't work, because I don't have a .lib file and the .dll file > in IMPORTED_LOCATION was added to MyExecutable's linker line. > - SHARED did not work because CMake expects a .dll in > IMPORTED_LOCATION and a .lib in IMPORTED_IMP_LOCATION, so > MyExecutable's linker line had a MyDependency::MyDependency- > NOTFOUND entry in it. > - MODULE seemed like the right choice when reading the documentation, > but MyExecutable's linker line still contains the .dll file specified in > IMPORTED_LOCATION. > > What am I doing wrong? > > Thanks, > Marek > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Tue Apr 3 03:59:03 2018 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Tue, 3 Apr 2018 07:59:03 +0000 Subject: [CMake] IMPORTED DLL-only Target on MSVC In-Reply-To: References: Message-ID: <8D981219EEA621479C112DA9BDC39A8E95873107@EXMBS1.ad.igd.fraunhofer.de> >From the CMake side of things yes, but MSVC requires an import library. You could use a tool such as Digital Mars' implib tool (https://digitalmars.com/ctg/implib.html), or use dumpbin to list all exports, put those in a .def file and use lib to create an import library from the def file. If I am not mistaken, CMake's GNUtoMS switch (for the Mingw Makefiles generator) does something like this automatically, so you could have a look at how it is done there. But I assume it's simply parsing the dumpbin /exports output to write a def file and running lib afterwards. Regards, Johannes Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5? |? 64283 Darmstadt? |? Germany Tel +49 6151 155-606? |? Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de -----Original Message----- From: CMake On Behalf Of Marek Vojtko (Firaxis) Sent: Tuesday, April 3, 2018 00:49 To: cmake at cmake.org Subject: [CMake] IMPORTED DLL-only Target on MSVC Hi, Is it not possible to wrap an external DLL-only library in an IMPORTED target? I have an external dependency that is a single DLL (shared library) and a header file, but no LIB (static library) file. When I create an IMPORTED target and depend on it via target_link_libraries() I run into linkage issues, because on MSVC CMake puts the DLL into the linker command (the "Input" text field in the "Linker" settings of the Project Properties). add_library( MyDependency::MyDependency MODULE IMPORTED ) set_target_properties( MyDependency::MyDependency PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${MyDependency_INCLUDE_DIR}" IMPORTED_LOCATION "${MyDependency_SHARED_LIB}" ) [..] add_executable( MyExecutable ... ) target_link_libraries( MyExecutable PRIVATE MyDependency::MyDependency ) I tried changing the library type in my add_library() call: - STATIC obviously didn't work, because I don't have a .lib file and the .dll file in IMPORTED_LOCATION was added to MyExecutable's linker line. - SHARED did not work because CMake expects a .dll in IMPORTED_LOCATION and a .lib in IMPORTED_IMP_LOCATION, so MyExecutable's linker line had a MyDependency::MyDependency-NOTFOUND entry in it. - MODULE seemed like the right choice when reading the documentation, but MyExecutable's linker line still contains the .dll file specified in IMPORTED_LOCATION. What am I doing wrong? Thanks, Marek -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake From robert.maynard at kitware.com Tue Apr 3 09:14:42 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 3 Apr 2018 09:14:42 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.11.0 available for download In-Reply-To: References: Message-ID: You are correct this doesn't work with ninja and ExternalProjects due to the jobserver work not being upstreamed. There are forks of ninja that do have jobserver support and therefore this would work with those. On Fri, Mar 30, 2018 at 1:27 PM, Isaiah Norton wrote: >> A "CMAKE_JOB_POOLS" variable was added specify a value to use for >> the "JOB_POOLS" property. This enables control over build >> parallelism with command line configuration parameters when using >> the Ninja generator. > > > Does this work with ExternalProject sub-builds? If not, I would suggest a > big warning sign on the flag will save some headache... > > (my limited understanding of ninja's job pool implementation leads me to > think not -- that would need jobserver support, the PR for which has > languished. Would be very happy to learn otherwise!) > > On Wed, Mar 28, 2018 at 2:14 PM, Robert Maynard > wrote: >> >> I am proud to announce that CMake 3.11.0 is now available for download at: >> https://cmake.org/download/ >> >> Documentation is available at: >> https://cmake.org/cmake/help/v3.11 >> >> Release notes appear below and are also published at >> https://cmake.org/cmake/help/v3.11/release/3.11.html >> >> Some of the more significant changes in CMake 3.11 are: >> >> * The Makefile Generators and the "Ninja" generator learned to add >> compiler launcher tools along with the compiler for the "Fortran" >> language ("C", "CXX", and "CUDA" were supported previously). See the >> "CMAKE__COMPILER_LAUNCHER" variable and >> "_COMPILER_LAUNCHER" target property for details. >> >> * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" >> "generator expression" in target-wide "COMPILE_DEFINITIONS", >> "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See >> generator expression documentation for caveats. >> >> * The "Xcode" Generator learned to support the "COMPILE_LANGUAGE" >> "generator expression" in target-wide "COMPILE_DEFINITIONS" and >> "INCLUDE_DIRECTORIES". It previously supported only >> "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression >> documentation for caveats. >> >> * "add_library()" and "add_executable()" commands can now be called >> without any sources and will not complain as long as sources are >> added later via the "target_sources()" command. >> >> * The "target_compile_definitions()" command learned to set the >> "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. >> >> * The "target_compile_features()" command learned to set the >> "INTERFACE_COMPILE_FEATURES" property on Imported Targets. >> >> * The "target_compile_options()" command learned to set the >> "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. >> >> * The "target_include_directories()" command learned to set the >> "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. >> >> * The "target_sources()" command learned to set the >> "INTERFACE_SOURCES" property on Imported Targets. >> >> * The "target_link_libraries()" command learned to set the >> "INTERFACE_LINK_LIBRARIES" property on Imported Targets. >> >> * The "COMPILE_DEFINITIONS" source file property learned to support >> "generator expressions". >> >> * A "COMPILE_OPTIONS" source file property was added to manage list >> of options to pass to the compiler. >> >> * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple >> parallel "moc" or "uic" processes to reduce the build time. A new >> "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target >> property may be set to specify the number of parallel "moc" or "uic" >> processes to start. The default is derived from the number of CPUs >> on the host. >> >> >> CMake 3.11 Release Notes >> ************************ >> >> Changes made since CMake 3.10 include the following. >> >> >> New Features >> ============ >> >> >> Platforms >> --------- >> >> * TI C/C++ compilers are now supported by the "Ninja" generator. >> >> >> Generators >> ---------- >> >> * The "CodeBlocks" extra generator learned to check a >> "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler >> identification value to place in the project file. >> >> * The Makefile Generators and the "Ninja" generator learned to add >> compiler launcher tools along with the compiler for the "Fortran" >> language ("C", "CXX", and "CUDA" were supported previously). See the >> "CMAKE__COMPILER_LAUNCHER" variable and >> "_COMPILER_LAUNCHER" target property for details. >> >> * Visual Studio Generators learned to support the "COMPILE_LANGUAGE" >> "generator expression" in target-wide "COMPILE_DEFINITIONS", >> "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See >> generator expression documentation for caveats. >> >> * The "Xcode" generator learned to support the "COMPILE_LANGUAGE" >> "generator expression" in target-wide "COMPILE_DEFINITIONS" and >> "INCLUDE_DIRECTORIES". It previously supported only >> "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression >> documentation for caveats. >> >> >> Commands >> -------- >> >> * "add_library()" and "add_executable()" commands can now be called >> without any sources and will not complain as long as sources are >> added later via the "target_sources()" command. >> >> * The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC" >> and "NETRC_FILE" options to specify use of a ".netrc" file. >> >> * The "target_compile_definitions()" command learned to set the >> "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets. >> >> * The "target_compile_features()" command learned to set the >> "INTERFACE_COMPILE_FEATURES" property on Imported Targets. >> >> * The "target_compile_options()" command learned to set the >> "INTERFACE_COMPILE_OPTIONS" property on Imported Targets. >> >> * The "target_include_directories()" command learned to set the >> "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets. >> >> * The "target_sources()" command learned to set the >> "INTERFACE_SOURCES" property on Imported Targets. >> >> * The "target_link_libraries()" command learned to set the >> "INTERFACE_LINK_LIBRARIES" property on Imported Targets. >> >> >> Variables >> --------- >> >> * A "CMAKE_GENERATOR_INSTANCE" variable was introduced to hold the >> selected instance of the generator's corresponding native tools if >> multiple are available. This is used by the "Visual Studio 15 2017" >> generator to hold the selected instance of Visual Studio >> persistently. >> >> * A "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added >> to enable setting of default permissions for directories created >> implicitly during installation of files by "install()" and >> "file(INSTALL)", e.g. during "make install". >> >> * A "CMAKE_JOB_POOLS" variable was added specify a value to use for >> the "JOB_POOLS" property. This enables control over build >> parallelism with command line configuration parameters when using >> the Ninja generator. >> >> * The "CMAKE_NETRC" and "CMAKE_NETRC_FILE" variables were added to >> specify use of a ".netrc" file by the "file(DOWNLOAD)" and >> "file(UPLOAD)" commands and the "ExternalProject" module. >> >> * A "CMAKE_CUDA_SEPARABLE_COMPILATION" variable was added to >> initialize the "CUDA_SEPARABLE_COMPILATION" target property on >> targets when they are created. >> >> >> Properties >> ---------- >> >> * The "COMPILE_DEFINITIONS" source file property learned to support >> "generator expressions". >> >> * A "COMPILE_OPTIONS" source file property was added to manage list >> of options to pass to the compiler. >> >> * An "IMPORTED_GLOBAL" target property was added to indicate whether >> an IMPORTED target is globally visible. It is automatically set to a >> true value for targets created with the "GLOBAL" option to >> "add_library()" or "add_executable()". Additionally, project code >> may now *promote* a local imported target to be globally visible by >> setting this property to "TRUE". >> >> * An "INCLUDE_DIRECTORIES" source file property was added to specify >> list of preprocessor include file search directories. >> >> * Source file properties "VS_SHADER_DISABLE_OPTIMIZATIONS" and >> "VS_SHADER_ENABLE_DEBUG" have been added to specify more details of >> ".hlsl" sources with Visual Studio Generators. >> >> >> Modules >> ------- >> >> * The "CheckIncludeFile" module "check_include_file" macro learned >> to honor the "CMAKE_REQUIRED_LIBRARIES" variable. >> >> * The "CheckIncludeFileCXX" module "check_include_file_cxx" macro >> learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable. >> >> * The "CheckIncludeFiles" module "check_include_files" macro learned >> to honor the "CMAKE_REQUIRED_LIBRARIES" variable. >> >> * The "CheckIncludeFiles" module "CHECK_INCLUDE_FILES()" command >> gained a "LANGUAGE" option to specify whether to check using the "C" >> or "CXX" compiler. >> >> * The "CMakePackageConfigHelpers" module >> "write_basic_package_version_file()" command learned a new >> "SameMinorVersion" mode for the "COMPATIBILITY" argument. >> >> * The "ExternalProject" module learned to substitute >> "" in comments, commands, working directory and >> byproducts. >> >> * The "ExternalProject" module gained "NETRC" and "NETRC_FILE" >> options to specify use of a ".netrc" file. >> >> * A new "FetchContent" module was added which supports populating >> content at configure time using any of the download/update methods >> supported by "ExternalProject_Add()". This allows the content to be >> used immediately during the configure stage, such as with >> "add_subdirectory()", etc. Hierarchical project structures are well >> supported, allowing parent projects to override the content details >> of child projects and ensuring content is not populated multiple >> times throughout the whole project tree. >> >> * The "FindBLAS" and "FindLAPACK" modules learned to support FLAME >> "blis" and "libflame". >> >> * The "FindDoxygen" module "doxygen_add_docs()" function now >> supports a new "DOXYGEN_VERBATIM_VARS" list variable. Any >> "DOXYGEN_..." variable contained in that list will bypass the >> automatic quoting logic, leaving its contents untouched when >> transferring them to the output "Doxyfile". >> >> * A "FindIconv" module was added to locate iconv support. >> >> * The "GenerateExportHeader" module "GENERATE_EXPORT_HEADER" command >> gained an "INCLUDE_GUARD_NAME" option to change the name of the >> include guard symbol written to the generated export header. >> Additionally, it now adds a comment after the closing "#endif" on >> the generated export header's include guard. >> >> * The "UseJava" module "add_jar" command gained a >> "GENERATE_NATIVE_HEADERS" option to generate native header files >> using "javac -h" for "javac" 1.8 or above. This supersedes >> "create_javah", which no longer works with JDK 1.10 and above due to >> removal of the "javah" tool by JEP 313. >> >> >> Autogen >> ------- >> >> * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple >> parallel "moc" or "uic" processes to reduce the build time. A new >> "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target >> property may be set to specify the number of parallel "moc" or "uic" >> processes to start. The default is derived from the number of CPUs >> on the host. >> >> >> CTest >> ----- >> >> * The "ctest_start()" command no longer sets >> "CTEST_RUN_CURRENT_SCRIPT" due to issues with scoping if it is >> called from inside a function. Instead, it sets an internal variable >> in CTest. However, setting "CTEST_RUN_CURRENT_SCRIPT" to 0 at the >> global scope still prevents the script from being re-run at the end. >> >> >> CPack >> ----- >> >> * "cpack(1)" gained "--trace" and "--trace-expand" options. >> >> * The "CPackIFW" module gained new >> "CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR" variable to control if the >> target directory should not be deleted when uninstalling. >> >> * The "CPackRPM" module learned to enable enforcing of execute >> privileges on programs and shared libraries. See >> "CPACK_RPM_INSTALL_WITH_EXEC" variable. >> >> * A "CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added >> which serves the same purpose during packaging (e.g. "make package") >> as the "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable serves >> during installation (e.g. "make install"). >> >> >> Other >> ----- >> >> * Alias Targets may now alias Imported Targets that are created with >> the "GLOBAL" option to "add_library()". >> >> * Interface Libraries may now have custom properties set on them if >> they start with either an underscore ("_") or a lowercase ASCII >> character. The original intention was to only allow properties which >> made sense for "INTERFACE" libraries, but it also blocked usage of >> custom properties. >> >> * The "cmake(1)" "--open " command-line option was added to >> open generated IDE projects like Visual Studio solutions or Xcode >> projects. >> >> >> Deprecated and Removed Features >> =============================== >> >> * An explicit deprecation diagnostic was added for policies >> "CMP0037" through "CMP0054" ("CMP0036" and below were already >> deprecated). The "cmake-policies(7)" manual explains that the OLD >> behaviors of all policies are deprecated and that projects should >> port to the NEW behaviors. >> >> * The "KDevelop3" generator has been removed. >> >> >> Other Changes >> ============= >> >> * Policy "CMP0037" no longer reserves target names associated with >> optional features, such as "test" and "package", unless the >> corresponding feature is enabled. >> >> * The "FindOpenGL" module now prefers GLVND libraries if available. >> See policy "CMP0072". >> >> * The minimum deployment target set in the >> "CMAKE_OSX_DEPLOYMENT_TARGET" variable used to be only applied for >> macOS regardless of the selected SDK. It is now properly set for >> the target platform selected by "CMAKE_OSX_SYSROOT". For example, if >> the sysroot variable specifies an iOS SDK then the value in >> "CMAKE_OSX_DEPLOYMENT_TARGET" is interpreted as minimum iOS version. >> >> * The "Xcode" generator behavior of generating one project file per >> "project()" command may now be controlled with the >> "CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY" variable. This could >> be useful to speed up the CMake generation step for large projects >> and to work-around a bug in the "ZERO_CHECK" logic. >> >> * Since the "CMakeCache.txt" format does not support newlines in >> values, values containing newlines are now truncated before writing >> to the file. In addition, a warning comment is written to the cache >> file, and a warning message is displayed to the user on the console. >> >> >> ---------------------------------------------------------------------------- >> Changes made since CMake 3.11.0-rc4: >> >> Brad King (5): >> Features: Record for SunPro 5.15 >> Revert "Remove CTestTestfile.cmake when BUILD_TESTING is OFF" >> cmSystemTools: Fix ParseArguments out-of-bounds read >> ctest_update: Fix crash when handling svn externals >> CMake 3.11.0 >> >> Roger Leigh (1): >> FindBoost: Add support for Boost 1.67 with Python version suffixes >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake > > From alexis.jeandet at member.fsf.org Tue Apr 3 10:01:58 2018 From: alexis.jeandet at member.fsf.org (jeandet) Date: Tue, 03 Apr 2018 16:01:58 +0200 Subject: [CMake] cmake --find-package deprecated? Message-ID: <1522764118.3783.102.camel@member.fsf.org> Hi all, Reading the documentation I can see: https://cmake.org/cmake/help/v3.11/manual/cmake.1.html?highlight=find%2 0package#find-package-tool-mode id="-x-evo-selection-start-marker"> " Note This mode is not well-supported due to some technical limitations. It is kept for compatibility but should not be used in new projects. " Does this means that: 1) We will always support this but it's limited. 2) We will be supported for a long time, but you shouldn't use it. 3) We plan to remove this soon, don't use this! In fact this mode would really be useful outside of CMake, to use libraries/stuff which doesn't provide pc files but only CMake packages. Even if this has limitations, it's better than nothing. Best regards, Alexis. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjm324 at cornell.edu Tue Apr 3 12:38:13 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Tue, 3 Apr 2018 09:38:13 -0700 Subject: [CMake] CMake Version Specific Code and Testing Message-ID: <7B0178FA-E624-454D-B735-2DE7D78CCF43@cornell.edu> Hello, Suppose I have a cmake_minimum_required(VERSION 2.8.12) project I would like to contribute to. So when I am testing code for a v2.8.12 project, but my installed CMake version is say 3.10, if I (accidentally, or through ignorance) write code that would only work in CMake 3.x but not in 2.8.12, will the build fail or should I make sure to install 2.8.12 and test using that? For example, my understanding is that for things like policies, I can do if (POLICY CMP) cmake_policy(SET CMP NEW) endif() and this will mean that an older version of CMake running this code that does not know about policy NNNN will still work. But if I ended up using an entirely new command that did not exist at the time of 2.8.12, but does exist in 3.10 of my installed CMake, should the build fail or succeed? Thanks for any guidance, I?m sorry if this question doesn?t make any sense? -Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From neundorf at kde.org Tue Apr 3 16:00:32 2018 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 03 Apr 2018 22:00:32 +0200 Subject: [CMake] cmake --find-package deprecated? In-Reply-To: <1522764118.3783.102.camel@member.fsf.org> References: <1522764118.3783.102.camel@member.fsf.org> Message-ID: <5479730.WHf7AIsqvu@linux-l7nd> On 2018 M04 3, Tue 16:01:58 CEST jeandet wrote: > Hi all, > > Reading the documentation I can see: > https://cmake.org/cmake/help/v3.11/manual/cmake.1.html?highlight=find%2 > 0package#find-package-tool-mode id="-x-evo-selection-start-marker"> > " > Note > > This mode is not well-supported due to some technical limitations. It > is kept for compatibility but should not be used in new projects. > " > > Does this means that: > 1) We will always support this but it's limited. > 2) We will be supported for a long time, but you shouldn't use it. > 3) We plan to remove this soon, don't use this! I think it's in 2). > In fact this mode would really be useful outside of CMake, to use > libraries/stuff which doesn't provide pc files but only CMake packages. > Even if this has limitations, it's better than nothing. Yes, that was my motivation a few years back. There is even a cmake.m4 which adds a cmake_find_package macro for configure. Since then, there was close to no feedback. I also can't remember any volunteer contributions for this feature. Currently it has more limitations than it had 7 or 8 years ago or so. The idea was to run cmake in script mode, and basically just execute the requested FindFoo.cmake script, which basically searches a set of directories and returns the results. With imported targets, their link interfaces and e.g. generator expressions things got more complicated. I'd be happy if somebody picks up the work and makes this feature work properly. Alex From robert.maynard at kitware.com Tue Apr 3 16:13:08 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 3 Apr 2018 16:13:08 -0400 Subject: [CMake] CMake Version Specific Code and Testing In-Reply-To: <7B0178FA-E624-454D-B735-2DE7D78CCF43@cornell.edu> References: <7B0178FA-E624-454D-B735-2DE7D78CCF43@cornell.edu> Message-ID: > if I (accidentally, or through ignorance) write code that would only work in CMake 3.x but not in 2.8.12, will the build fail or should I make sure to install 2.8.12 and test using that? .... if I ended up using an entirely new command that did not exist at the time of 2.8.12, but does exist in 3.10 of my installed CMake, should the build fail or succeed? The in both cases if you have CMake 3.X installed the configure/generate of your project will succeed. You will need to install CMake 2.8.12 and test with that. > Policy logic You are correct about policy guards allowing older versions of CMake to safely ignore policies from new releases, while people running newer versions of CMake can leverage those ( generally the performance related policies ). On Tue, Apr 3, 2018 at 12:38 PM, Stephen McDowell wrote: > Hello, > > Suppose I have a cmake_minimum_required(VERSION 2.8.12) project I would like > to contribute to. > > So when I am testing code for a v2.8.12 project, but my installed CMake > version is say 3.10, if I (accidentally, or through ignorance) write code > that would only work in CMake 3.x but not in 2.8.12, will the build fail or > should I make sure to install 2.8.12 and test using that? > > For example, my understanding is that for things like policies, I can do > > if (POLICY CMP) > cmake_policy(SET CMP NEW) > endif() > > and this will mean that an older version of CMake running this code that > does not know about policy NNNN will still work. But if I ended up using an > entirely new command that did not exist at the time of 2.8.12, but does > exist in 3.10 of my installed CMake, should the build fail or succeed? > > Thanks for any guidance, I?m sorry if this question doesn?t make any sense? > > -Stephen > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > From sjm324 at cornell.edu Tue Apr 3 16:23:25 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Tue, 3 Apr 2018 13:23:25 -0700 Subject: [CMake] CMake Version Specific Code and Testing In-Reply-To: References: <7B0178FA-E624-454D-B735-2DE7D78CCF43@cornell.edu> Message-ID: Ok cool thank you for explaining! Somewhat related, I really enjoy that I can build CMake 2.8.12 with CMake 3.10 :) From Marek.Vojtko at firaxis.com Tue Apr 3 17:23:47 2018 From: Marek.Vojtko at firaxis.com (Marek Vojtko (Firaxis)) Date: Tue, 3 Apr 2018 21:23:47 +0000 Subject: [CMake] IMPORTED DLL-only Target on MSVC Message-ID: > > Is it not possible to wrap an external DLL-only library in an IMPORTED target? > > > > Yes it is. > > > I have an external dependency that is a single DLL (shared library) and a > > header file, but no LIB (static library) file. > > How does this work in Visual Studio C++? If I am not completely mistaken you > ALWAYS need a .lib file along with your .dll to link to the shared library. And you > Need a header with the API as well of course. > > The only case I know with .dll and without .lib file is when you have managed > C++ or C# targets. > The DLL gets loaded using LoadLibrary("MyDependency.dll") at runtime and its functions are accessed through GetProcAddress(): HINSTANCE hLib = LoadLibrary(DLL_NAME); If(hLib) { typedef int (*DLL_FUNC)(); myFunc = (DLL_FUNC)GetProcAddress(hLib, "DLLFunction"); } Like I said, it's an external dependency and I don't have any control over it. The dependency's include directories have to be added to my executable's include directories and I need to copy the DLL next to the executable. I thought I'd solve (at least the include directories) by creating an IMPORTED target, but no matter what I try, the DLL ends up in the linker command line, wreaking havoc. Of course I can work around this issue by not creating an IMPORTED target and just relying on two variables (MyDependency_INCLUDE_DIR and MyDependency_SHARED_LIB). Before I do, however, I wanted to make sure that CMake does not in fact support a DLL-and-header-only library set up. Thanks, Marek From michael.stuermer at schaeffler.com Wed Apr 4 00:45:49 2018 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Wed, 4 Apr 2018 04:45:49 +0000 Subject: [CMake] IMPORTED DLL-only Target on MSVC In-Reply-To: References: Message-ID: <876659dcf5964d0f9d179ad6cd6ac40e@DE013666.schaeffler.com> > -----Urspr?ngliche Nachricht----- > Von: CMake [mailto:cmake-bounces at cmake.org] Im Auftrag von Marek > Vojtko (Firaxis) > Gesendet: Dienstag, 3. April 2018 23:24 > An: cmake at cmake.org > Betreff: Re: [CMake] IMPORTED DLL-only Target on MSVC > > > > Is it not possible to wrap an external DLL-only library in an IMPORTED > target? > > > > > > > Yes it is. > > > > > I have an external dependency that is a single DLL (shared library) > > > and a header file, but no LIB (static library) file. > > > > How does this work in Visual Studio C++? If I am not completely > > mistaken you ALWAYS need a .lib file along with your .dll to link to > > the shared library. And you Need a header with the API as well of course. > > > > The only case I know with .dll and without .lib file is when you have > > managed > > C++ or C# targets. > > > > The DLL gets loaded using LoadLibrary("MyDependency.dll") at runtime and > its functions are accessed through GetProcAddress(): Ok, I missed this case :-). But in my opinion MyDependency.dll is not a TARGET in the sense of CMake targets. It's just a variable/filename which is used in the project somewhere. This is actually also how Visual Studio treats the .dll: you only pass the filename somewhere, not mentioning "link to this" or something else. If you want to deploy/copy the .dll to your binary directory I'd simply add a POST_BUILD custom command which copies the file over so you don't have to do it manually. > > HINSTANCE hLib = LoadLibrary(DLL_NAME); > If(hLib) > { > typedef int (*DLL_FUNC)(); > myFunc = (DLL_FUNC)GetProcAddress(hLib, "DLLFunction"); } > > Like I said, it's an external dependency and I don't have any control over it. > The dependency's include directories have to be added to my executable's > include directories and I need to copy the DLL next to the executable. I > thought I'd solve (at least the include directories) by creating an IMPORTED > target, but no matter what I try, the DLL ends up in the linker command line, > wreaking havoc. Adding include directories/files only via target could be done by putting the Include files in a INTERFACE library. Not sure if this is an elegant solution for your case but I'd probably start like this. > > Of course I can work around this issue by not creating an IMPORTED target > and just relying on two variables (MyDependency_INCLUDE_DIR and > MyDependency_SHARED_LIB). Before I do, however, I wanted to make sure > that CMake does not in fact support a DLL-and-header-only library set up. > > Thanks, > Marek > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake From zbeekman at gmail.com Wed Apr 4 11:38:28 2018 From: zbeekman at gmail.com (Zaak Beekman) Date: Wed, 04 Apr 2018 15:38:28 +0000 Subject: [CMake] Overloading/shadowing/redefining CMake intrinsic commands Message-ID: I have been moving towards modern CMake where includes/compiler-flags/libraries/etc. are using target properties and transitive usage requirements which has greatly simplified setting up Modern Fortran build systems. In addition, if you're going to vendor all/most of your package's dependencies and just configure them along with your package with a simple `add_subdirectory()` call this allows you to setup projects that may be consumed in this way by parent projects or used on their own. This is super convenient, and IMO, easier to understand and deal with than super builds. The propagation of transitive properties makes this relatively easy and seamless. However, until I/we have time to improve the OpenCoarrays CMake `find_package` support some of the projects my colleagues are writing/using set the OpenCoarrays compiler wrapper script, `caf`, as $FC before invoking CMake. This is fine until it some parent project is using GFortran+OpenCoarrays and a child project may not need Coarrays at all. Everything proceeds find until the tests are run because, at least on some systems, executables will hang when compiled against MPI/Opencoarrays without the MPI job launcher scripts being used to launch the test executable. I realize I can write my own function/macro and just call it from all the projects to decide how the tests should be launched---with `cafrun` if compiled by the `caf` wrapper script or by directly calling the executable if compiled with GFortran. And, yes, I know that the real solution to this problem is to improve the CMake support of OpenCoarrays... but time is scarce at the moment. So, my question is: Can I overload/shadow/redefine the intrinsic `add_test()` cmake command? This way if the child project calls `add_test()` the parent project can redefine it if needed. Otherwise, the child project will run as intended when configured and built on its own (i.e. just with GFortran, w/o coarray support & OpenCoarrays). Thanks, Zaak Izaak "Zaak" Beekman ------------------------------------------------------------------------------- HPC Scientist ParaTools Inc. 5520 Research Park Drive Suite 100 Baltimore, MD 21228 phone: (443) 543-5059 mobile: (917) 797-3239 ------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Apr 4 12:06:29 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 4 Apr 2018 12:06:29 -0400 Subject: [CMake] Overloading/shadowing/redefining CMake intrinsic commands In-Reply-To: References: Message-ID: See https://cmake.org/pipermail/cmake/2011-March/043320.html for a discussion on overloading functions and the dangers that can occur. On Wed, Apr 4, 2018 at 11:38 AM, Zaak Beekman wrote: > I have been moving towards modern CMake where > includes/compiler-flags/libraries/etc. are using target properties and > transitive usage requirements which has greatly simplified setting up Modern > Fortran build systems. In addition, if you're going to vendor all/most of > your package's dependencies and just configure them along with your package > with a simple `add_subdirectory()` call this allows you to setup projects > that may be consumed in this way by parent projects or used on their own. > This is super convenient, and IMO, easier to understand and deal with than > super builds. The propagation of transitive properties makes this relatively > easy and seamless. > > However, until I/we have time to improve the OpenCoarrays CMake > `find_package` support some of the projects my colleagues are writing/using > set the OpenCoarrays compiler wrapper script, `caf`, as $FC before invoking > CMake. This is fine until it some parent project is using > GFortran+OpenCoarrays and a child project may not need Coarrays at all. > Everything proceeds find until the tests are run because, at least on some > systems, executables will hang when compiled against MPI/Opencoarrays > without the MPI job launcher scripts being used to launch the test > executable. > > I realize I can write my own function/macro and just call it from all the > projects to decide how the tests should be launched---with `cafrun` if > compiled by the `caf` wrapper script or by directly calling the executable > if compiled with GFortran. And, yes, I know that the real solution to this > problem is to improve the CMake support of OpenCoarrays... but time is > scarce at the moment. > > So, my question is: Can I overload/shadow/redefine the intrinsic > `add_test()` cmake command? > > This way if the child project calls `add_test()` the parent project can > redefine it if needed. Otherwise, the child project will run as intended > when configured and built on its own (i.e. just with GFortran, w/o coarray > support & OpenCoarrays). > > Thanks, > Zaak > > Izaak "Zaak" Beekman > > ------------------------------------------------------------------------------- > HPC Scientist > ParaTools Inc. > 5520 Research Park Drive > Suite 100 > Baltimore, MD 21228 > phone: (443) 543-5059 > mobile: (917) 797-3239 > ------------------------------------------------------------------------------- > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > From zbeekman at gmail.com Wed Apr 4 12:36:37 2018 From: zbeekman at gmail.com (Zaak Beekman) Date: Wed, 04 Apr 2018 16:36:37 +0000 Subject: [CMake] Overloading/shadowing/redefining CMake intrinsic commands In-Reply-To: References: Message-ID: Hi Robert, Thanks so much for the speedy response. That is certainly dangerous looking. I'm sure everyone will want to buy me a beer/coffee after I crash their machines during configuration. I almost wish you had responded "impossible" because now I have the temptation of trying it out! Thanks, Zaak Izaak "Zaak" Beekman ------------------------------------------------------------------------------- HPC Scientist ParaTools Inc. 5520 Research Park Drive Suite 100 Baltimore, MD 21228 phone: (443) 543-5059 mobile: (917) 797-3239 ------------------------------------------------------------------------------- On Wed, Apr 4, 2018 at 12:07 PM Robert Maynard wrote: > See https://cmake.org/pipermail/cmake/2011-March/043320.html for a > discussion on overloading functions and the dangers that can occur. > > > On Wed, Apr 4, 2018 at 11:38 AM, Zaak Beekman wrote: > > I have been moving towards modern CMake where > > includes/compiler-flags/libraries/etc. are using target properties and > > transitive usage requirements which has greatly simplified setting up > Modern > > Fortran build systems. In addition, if you're going to vendor all/most of > > your package's dependencies and just configure them along with your > package > > with a simple `add_subdirectory()` call this allows you to setup projects > > that may be consumed in this way by parent projects or used on their own. > > This is super convenient, and IMO, easier to understand and deal with > than > > super builds. The propagation of transitive properties makes this > relatively > > easy and seamless. > > > > However, until I/we have time to improve the OpenCoarrays CMake > > `find_package` support some of the projects my colleagues are > writing/using > > set the OpenCoarrays compiler wrapper script, `caf`, as $FC before > invoking > > CMake. This is fine until it some parent project is using > > GFortran+OpenCoarrays and a child project may not need Coarrays at all. > > Everything proceeds find until the tests are run because, at least on > some > > systems, executables will hang when compiled against MPI/Opencoarrays > > without the MPI job launcher scripts being used to launch the test > > executable. > > > > I realize I can write my own function/macro and just call it from all the > > projects to decide how the tests should be launched---with `cafrun` if > > compiled by the `caf` wrapper script or by directly calling the > executable > > if compiled with GFortran. And, yes, I know that the real solution to > this > > problem is to improve the CMake support of OpenCoarrays... but time is > > scarce at the moment. > > > > So, my question is: Can I overload/shadow/redefine the intrinsic > > `add_test()` cmake command? > > > > This way if the child project calls `add_test()` the parent project can > > redefine it if needed. Otherwise, the child project will run as intended > > when configured and built on its own (i.e. just with GFortran, w/o > coarray > > support & OpenCoarrays). > > > > Thanks, > > Zaak > > > > Izaak "Zaak" Beekman > > > > > ------------------------------------------------------------------------------- > > HPC Scientist > > ParaTools Inc. > > 5520 Research Park Drive > > Suite 100 > > Baltimore, MD 21228 > > phone: (443) 543-5059 > > mobile: (917) 797-3239 > > > ------------------------------------------------------------------------------- > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > https://cmake.org/mailman/listinfo/cmake > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From azukaitis at gmail.com Wed Apr 4 12:48:01 2018 From: azukaitis at gmail.com (Anthony Zukaitis) Date: Wed, 4 Apr 2018 10:48:01 -0600 Subject: [CMake] (no subject) Message-ID: On windows I found an issue with Visual studio where intel fortran was attempting to preprocess lowercase .f90 files. Intel's documentation states that it does not preprocess these files. Looking into the cmake source code I found: in Modules/Platform/Windows-Intel-Fortran line 3: set(_COMPILE_Fortran " /fpp") which looks to me like cmake is adding this flag by default to all fortran files not .F90 vs .f90. Also we are using our own preprocessor which would also complicate things. Can you guys remove the setting of this flag? Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Wed Apr 4 23:18:59 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Thu, 05 Apr 2018 03:18:59 +0000 Subject: [CMake] Why isn't target_link_libraries not enough in some cases? Message-ID: Hi, I am fetching and building SDL2 using FetchContent and then using target_link_libraries(MyExe SDL2) in the hopes that the required include directories and libraries will be added populated properly. The example project can be found here: https://github.com/samaursa/cmake_fetch_content_SDL2 Unfortunately, it seems that I have to manually specify the include directories. Although target_link_directories(...) does take care of the linking against the correct libraries. When it comes to my own CMake enabled libraries, I do not have to specify the include directories. This is problematic when installing my libraries or executables that depend on SDL2 because the include directory for SDL is absolute ( https://cmake.org/Bug/view.php?id=15788). Is SDL2 setup incorrectly or is there something I am overlooking? Here is the CMakeLists.txt in the above mentioned example: -------------------------------------------------------------------------------------> cmake_minimum_required(VERSION 3.11) project(testProj) include(FetchContent) FetchContent_Declare( SDL2 GIT_REPOSITORY "https://github.com/spurious/SDL-mirror" ) FetchContent_GetProperties(SDL2) if(NOT sdl2_POPULATED) FetchContent_Populate(SDL2) message(STATUS "Catch source dir: ${sdl2_SOURCE_DIR}") message(STATUS "Catch binary dir: ${sdl2_BINARY_DIR}") add_subdirectory(${sdl2_SOURCE_DIR} ${sdl2_BINARY_DIR}) endif() add_executable(testExe main.cpp ) message(STATUS "Catch include dir: ${sdl2_SOURCE_DIR}/include") target_link_libraries(testExe SDL2) # the following line is necessary, target_link_libraries for SDL2 # does not automatically set the correct include directories target_include_directories(testExe PUBLIC ${sdl2_SOURCE_DIR}/include) <------------------------------------------------------------------------------------- Regards, Saad -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Wed Apr 4 23:23:12 2018 From: ewmailing at gmail.com (Eric Wing) Date: Wed, 4 Apr 2018 20:23:12 -0700 Subject: [CMake] How to build CMake so it works on an older Linux? Message-ID: I just discovered that CMake no longer builds on my Ubuntu 12.04. I need to build binaries that are compatible with that ABI. I see that your binary distribution of CMake 3.11 still works on Ubuntu 12.04. Can you tell me what you do to achieve this? What are you doing for your official builds? Are you just using -static-libstdc++ -static-libgcc for CMAKE_CXX_FLAGS, or is there more? (I just noticed that ldd shows that you don't have dependencies on libssl, libcrypto, and libz, whereas I do.) Thanks, Eric From bo.schwarzstein at gmail.com Thu Apr 5 00:05:36 2018 From: bo.schwarzstein at gmail.com (Bo Zhou) Date: Thu, 5 Apr 2018 13:05:36 +0900 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: References: Message-ID: The latest CMake requires C++11 compiler, so what you need is just a newer GCC which supports C++11 at your platform, that's it. Usually the ABI is not the problem but the libstdc++, you can use a old Ubuntu with old libstdc++ but build CMake with new compiler and make sure it links with old libstdc++. This is the trick. I don't know how to do this on Ubuntu, but on CentOS, it's possible to build CMake in that way, so the CMake would be portable at older CentOS platform with old libstdc++ . Good luck. On Thu, Apr 5, 2018 at 12:23 PM, Eric Wing wrote: > I just discovered that CMake no longer builds on my Ubuntu 12.04. I > need to build binaries that are compatible with that ABI. > > I see that your binary distribution of CMake 3.11 still works on > Ubuntu 12.04. Can you tell me what you do to achieve this? What are > you doing for your official builds? > > Are you just using -static-libstdc++ -static-libgcc for > CMAKE_CXX_FLAGS, or is there more? > > (I just noticed that ldd shows that you don't have dependencies on > libssl, libcrypto, and libz, whereas I do.) > > Thanks, > Eric > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpsuzuki at hiroshima-u.ac.jp Thu Apr 5 00:22:26 2018 From: mpsuzuki at hiroshima-u.ac.jp (suzuki toshiya) Date: Thu, 05 Apr 2018 13:22:26 +0900 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: References: Message-ID: <5AC5A482.1080800@hiroshima-u.ac.jp> Dear Bo Zhou, Thank you for the info! Now I'm checking Ubuntu 12.04 in LXC. So, gcc-4.8.5 or later would be needed for C++11, it seems that the last version of gcc officially provided for Ubuntu-12 was 4.7. oh. According to https://clang.llvm.org/cxx_status.html , clang-3.3 supports C++11, and the last version of clang officially provided for Ubuntu-12 was 3.4. ooh. I will check if clang-3.4 for Ubuntu-12.04 can compile cmake (or any other dependency problems would arise). > Usually the ABI is not the problem but the libstdc++, you can use a old Ubuntu with old libstdc++ but build CMake with new compiler and make sure it links with old libstdc++. This is the trick. Indeed. Regards, mpsuzuki Bo Zhou wrote: > The latest CMake requires C++11 compiler, so what you need is just a newer GCC which supports C++11 at your platform, that's it. > > Usually the ABI is not the problem but the libstdc++, you can use a old Ubuntu with old libstdc++ but build CMake with new compiler and make sure it links with old libstdc++. This is the trick. > > I don't know how to do this on Ubuntu, but on CentOS, it's possible to build CMake in that way, so the CMake would be portable at older CentOS platform with old libstdc++ . > > Good luck. > > On Thu, Apr 5, 2018 at 12:23 PM, Eric Wing > wrote: > I just discovered that CMake no longer builds on my Ubuntu 12.04. I > need to build binaries that are compatible with that ABI. > > I see that your binary distribution of CMake 3.11 still works on > Ubuntu 12.04. Can you tell me what you do to achieve this? What are > you doing for your official builds? > > Are you just using -static-libstdc++ -static-libgcc for > CMAKE_CXX_FLAGS, or is there more? > > (I just noticed that ldd shows that you don't have dependencies on > libssl, libcrypto, and libz, whereas I do.) > > Thanks, > Eric > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > > From mpsuzuki at hiroshima-u.ac.jp Thu Apr 5 00:33:49 2018 From: mpsuzuki at hiroshima-u.ac.jp (suzuki toshiya) Date: Thu, 05 Apr 2018 13:33:49 +0900 Subject: [CMake] [FYI] clang-3.4 vs cmake-3.11.0 (How to build CMake so it works on an older Linux?) In-Reply-To: References: Message-ID: <5AC5A72D.7040908@hiroshima-u.ac.jp> $ clang++ --version Ubuntu clang version 3.4-1ubuntu3~precise2 (tags/RELEASE_34/final) (based on LLVM 3.4) Target: x86_64-pc-linux-gnu Thread model: posix But I got following abort: cmake-3.11.0/Source/cmLocalGenerator.cxx:553:36: error: no member named 'emplace' in 'std::unordered_map, cmGeneratorTarget *, std::hash, std::equal_to >, std::allocator, cmGeneratorTarget *> > >' this->GeneratorTargetSearchIndex.emplace(gt->GetName(), gt); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ Grrrr.... X-D Regards, mpsuzuki suzuki toshiya wrote: > Dear Bo Zhou, > > Thank you for the info! Now I'm checking Ubuntu 12.04 in LXC. > So, gcc-4.8.5 or later would be needed for C++11, it seems that the last version > of gcc officially provided for Ubuntu-12 was 4.7. oh. > According to https://clang.llvm.org/cxx_status.html , clang-3.3 supports C++11, > and the last version of clang officially provided for Ubuntu-12 was 3.4. ooh. > I will check if clang-3.4 for Ubuntu-12.04 can compile cmake (or any other > dependency problems would arise). > >> Usually the ABI is not the problem but the libstdc++, you can use a old Ubuntu with old libstdc++ but build CMake with new compiler and make sure it links with old libstdc++. This is the trick. > > Indeed. > > Regards, > mpsuzuki > > Bo Zhou wrote: >> The latest CMake requires C++11 compiler, so what you need is just a newer GCC which supports C++11 at your platform, that's it. >> >> Usually the ABI is not the problem but the libstdc++, you can use a old Ubuntu with old libstdc++ but build CMake with new compiler and make sure it links with old libstdc++. This is the trick. >> >> I don't know how to do this on Ubuntu, but on CentOS, it's possible to build CMake in that way, so the CMake would be portable at older CentOS platform with old libstdc++ . >> >> Good luck. >> >> On Thu, Apr 5, 2018 at 12:23 PM, Eric Wing > wrote: >> I just discovered that CMake no longer builds on my Ubuntu 12.04. I >> need to build binaries that are compatible with that ABI. >> >> I see that your binary distribution of CMake 3.11 still works on >> Ubuntu 12.04. Can you tell me what you do to achieve this? What are >> you doing for your official builds? >> >> Are you just using -static-libstdc++ -static-libgcc for >> CMAKE_CXX_FLAGS, or is there more? >> >> (I just noticed that ldd shows that you don't have dependencies on >> libssl, libcrypto, and libz, whereas I do.) >> >> Thanks, >> Eric >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake >> >> >> > From bo.schwarzstein at gmail.com Thu Apr 5 00:40:52 2018 From: bo.schwarzstein at gmail.com (Bo Zhou) Date: Thu, 5 Apr 2018 13:40:52 +0900 Subject: [CMake] [FYI] clang-3.4 vs cmake-3.11.0 (How to build CMake so it works on an older Linux?) In-Reply-To: <5AC5A72D.7040908@hiroshima-u.ac.jp> References: <5AC5A72D.7040908@hiroshima-u.ac.jp> Message-ID: The emplace() is new API from C++11. Be aware that GCC suite actually is independent from the libstdc++, so if you have a newer compiler, the compiler might still pick the older libstdc++ without the new API. This issue doesn't exist at Windows, since Visual Studio is a complete sytem. This issue happens on OSX also, so user must give the compiler a proper MacOS SDK for the new header files etc. On Thu, Apr 5, 2018 at 1:33 PM, suzuki toshiya wrote: > $ clang++ --version > Ubuntu clang version 3.4-1ubuntu3~precise2 (tags/RELEASE_34/final) (based > on > LLVM 3.4) > Target: x86_64-pc-linux-gnu > Thread model: posix > > But I got following abort: > > cmake-3.11.0/Source/cmLocalGenerator.cxx:553:36: error: no member named > 'emplace' in > 'std::unordered_map, cmGeneratorTarget *, > std::hash, std::equal_to >, > std::allocator, > cmGeneratorTarget > *> > >' > this->GeneratorTargetSearchIndex.emplace(gt->GetName(), gt); > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ > > Grrrr.... X-D > > Regards, > mpsuzuki > > suzuki toshiya wrote: > > Dear Bo Zhou, > > > > Thank you for the info! Now I'm checking Ubuntu 12.04 in LXC. > > So, gcc-4.8.5 or later would be needed for C++11, it seems that the last > version > > of gcc officially provided for Ubuntu-12 was 4.7. oh. > > According to https://clang.llvm.org/cxx_status.html , clang-3.3 > supports C++11, > > and the last version of clang officially provided for Ubuntu-12 was 3.4. > ooh. > > I will check if clang-3.4 for Ubuntu-12.04 can compile cmake (or any > other > > dependency problems would arise). > > > >> Usually the ABI is not the problem but the libstdc++, you can use a old > Ubuntu with old libstdc++ but build CMake with new compiler and make sure > it links with old libstdc++. This is the trick. > > > > Indeed. > > > > Regards, > > mpsuzuki > > > > Bo Zhou wrote: > >> The latest CMake requires C++11 compiler, so what you need is just a > newer GCC which supports C++11 at your platform, that's it. > >> > >> Usually the ABI is not the problem but the libstdc++, you can use a old > Ubuntu with old libstdc++ but build CMake with new compiler and make sure > it links with old libstdc++. This is the trick. > >> > >> I don't know how to do this on Ubuntu, but on CentOS, it's possible to > build CMake in that way, so the CMake would be portable at older CentOS > platform with old libstdc++ . > >> > >> Good luck. > >> > >> On Thu, Apr 5, 2018 at 12:23 PM, Eric Wing ewmailing at gmail.com>> wrote: > >> I just discovered that CMake no longer builds on my Ubuntu 12.04. I > >> need to build binaries that are compatible with that ABI. > >> > >> I see that your binary distribution of CMake 3.11 still works on > >> Ubuntu 12.04. Can you tell me what you do to achieve this? What are > >> you doing for your official builds? > >> > >> Are you just using -static-libstdc++ -static-libgcc for > >> CMAKE_CXX_FLAGS, or is there more? > >> > >> (I just noticed that ldd shows that you don't have dependencies on > >> libssl, libcrypto, and libz, whereas I do.) > >> > >> Thanks, > >> Eric > >> -- > >> > >> Powered by www.kitware.com > >> > >> Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > >> > >> Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > >> > >> CMake Support: http://cmake.org/cmake/help/support.html > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > >> Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> https://cmake.org/mailman/listinfo/cmake > >> > >> > >> > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpsuzuki at hiroshima-u.ac.jp Thu Apr 5 01:04:16 2018 From: mpsuzuki at hiroshima-u.ac.jp (suzuki toshiya) Date: Thu, 05 Apr 2018 14:04:16 +0900 Subject: [CMake] [FYI] clang-3.4 vs cmake-3.11.0 (How to build CMake so it works on an older Linux?) In-Reply-To: <16ab44e818bb441884097d8f07ff5347@OS2PR01MB1147.jpnprd01.prod.outlook.com> References: <5AC5A72D.7040908@hiroshima-u.ac.jp> <16ab44e818bb441884097d8f07ff5347@OS2PR01MB1147.jpnprd01.prod.outlook.com> Message-ID: <5AC5AE50.9020401@hiroshima-u.ac.jp> Dear Bo Zhou, Thank you for prompt reply. > Be aware that GCC suite actually is independent from the libstdc++, so if you have a newer compiler, the compiler might still pick the older libstdc++ without the new API. Oh, so, even if I installed clang-3.4, still it uses older (maybe C++03) libraries are referred by it? Regards, mpsuzuki Bo Zhou wrote: > The emplace() is new API from C++11. > > Be aware that GCC suite actually is independent from the libstdc++, so if you have a newer compiler, the compiler might still pick the older libstdc++ without the new API. > > This issue doesn't exist at Windows, since Visual Studio is a complete sytem. > > This issue happens on OSX also, so user must give the compiler a proper MacOS SDK for the new header files etc. > > On Thu, Apr 5, 2018 at 1:33 PM, suzuki toshiya > wrote: > $ clang++ --version > Ubuntu clang version 3.4-1ubuntu3~precise2 (tags/RELEASE_34/final) (based on > LLVM 3.4) > Target: x86_64-pc-linux-gnu > Thread model: posix > > But I got following abort: > > cmake-3.11.0/Source/cmLocalGenerator.cxx:553:36: error: no member named 'emplace' in > 'std::unordered_map, cmGeneratorTarget *, > std::hash, std::equal_to >, > std::allocator, cmGeneratorTarget > *> > >' > this->GeneratorTargetSearchIndex.emplace(gt->GetName(), gt); > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ > > Grrrr.... X-D > > Regards, > mpsuzuki > > suzuki toshiya wrote: >> Dear Bo Zhou, >> >> Thank you for the info! Now I'm checking Ubuntu 12.04 in LXC. >> So, gcc-4.8.5 or later would be needed for C++11, it seems that the last version >> of gcc officially provided for Ubuntu-12 was 4.7. oh. >> According to https://clang.llvm.org/cxx_status.html , clang-3.3 supports C++11, >> and the last version of clang officially provided for Ubuntu-12 was 3.4. ooh. >> I will check if clang-3.4 for Ubuntu-12.04 can compile cmake (or any other >> dependency problems would arise). >> >>> Usually the ABI is not the problem but the libstdc++, you can use a old Ubuntu with old libstdc++ but build CMake with new compiler and make sure it links with old libstdc++. This is the trick. >> Indeed. >> >> Regards, >> mpsuzuki >> >> Bo Zhou wrote: >>> The latest CMake requires C++11 compiler, so what you need is just a newer GCC which supports C++11 at your platform, that's it. >>> >>> Usually the ABI is not the problem but the libstdc++, you can use a old Ubuntu with old libstdc++ but build CMake with new compiler and make sure it links with old libstdc++. This is the trick. >>> >>> I don't know how to do this on Ubuntu, but on CentOS, it's possible to build CMake in that way, so the CMake would be portable at older CentOS platform with old libstdc++ . >>> >>> Good luck. >>> >>> On Thu, Apr 5, 2018 at 12:23 PM, Eric Wing >> wrote: >>> I just discovered that CMake no longer builds on my Ubuntu 12.04. I >>> need to build binaries that are compatible with that ABI. >>> >>> I see that your binary distribution of CMake 3.11 still works on >>> Ubuntu 12.04. Can you tell me what you do to achieve this? What are >>> you doing for your official builds? >>> >>> Are you just using -static-libstdc++ -static-libgcc for >>> CMAKE_CXX_FLAGS, or is there more? >>> >>> (I just noticed that ldd shows that you don't have dependencies on >>> libssl, libcrypto, and libz, whereas I do.) >>> >>> Thanks, >>> Eric >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> https://cmake.org/mailman/listinfo/cmake >>> >>> >>> > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > From mpsuzuki at hiroshima-u.ac.jp Thu Apr 5 01:14:55 2018 From: mpsuzuki at hiroshima-u.ac.jp (suzuki toshiya) Date: Thu, 05 Apr 2018 14:14:55 +0900 Subject: [CMake] [FYI] clang-3.4 vs cmake-3.11.0 (How to build CMake so it works on an older Linux?) In-Reply-To: <2f9737519c1943dbb1db683b8ae5187a@OS2PR01MB1147.jpnprd01.prod.outlook.com> References: <5AC5A72D.7040908@hiroshima-u.ac.jp> <16ab44e818bb441884097d8f07ff5347@OS2PR01MB1147.jpnprd01.prod.outlook.com> <2f9737519c1943dbb1db683b8ae5187a@OS2PR01MB1147.jpnprd01.prod.outlook.com> Message-ID: <5AC5B0CF.50303@hiroshima-u.ac.jp> Dear Bo Zhou, Sorry, I've confirmed by myself. By default, clang-3.4 for Ubuntu prioritizes old g++ header files, and clang header files are searched as a fallback. I can customize the searching order by -nostdinc++... Regards, mpsuzuki suzuki toshiya wrote: > Dear Bo Zhou, > > Thank you for prompt reply. > >> Be aware that GCC suite actually is independent from the libstdc++, so if you have a newer compiler, the compiler might still pick the older libstdc++ without the new API. > > Oh, so, even if I installed clang-3.4, still it uses older (maybe C++03) > libraries are referred by it? > > Regards, > mpsuzuki > > Bo Zhou wrote: >> The emplace() is new API from C++11. >> >> Be aware that GCC suite actually is independent from the libstdc++, so if you have a newer compiler, the compiler might still pick the older libstdc++ without the new API. >> >> This issue doesn't exist at Windows, since Visual Studio is a complete sytem. >> >> This issue happens on OSX also, so user must give the compiler a proper MacOS SDK for the new header files etc. >> >> On Thu, Apr 5, 2018 at 1:33 PM, suzuki toshiya > wrote: >> $ clang++ --version >> Ubuntu clang version 3.4-1ubuntu3~precise2 (tags/RELEASE_34/final) (based on >> LLVM 3.4) >> Target: x86_64-pc-linux-gnu >> Thread model: posix >> >> But I got following abort: >> >> cmake-3.11.0/Source/cmLocalGenerator.cxx:553:36: error: no member named 'emplace' in >> 'std::unordered_map, cmGeneratorTarget *, >> std::hash, std::equal_to >, >> std::allocator, cmGeneratorTarget >> *> > >' >> this->GeneratorTargetSearchIndex.emplace(gt->GetName(), gt); >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ >> >> Grrrr.... X-D >> >> Regards, >> mpsuzuki >> >> suzuki toshiya wrote: >>> Dear Bo Zhou, >>> >>> Thank you for the info! Now I'm checking Ubuntu 12.04 in LXC. >>> So, gcc-4.8.5 or later would be needed for C++11, it seems that the last version >>> of gcc officially provided for Ubuntu-12 was 4.7. oh. >>> According to https://clang.llvm.org/cxx_status.html , clang-3.3 supports C++11, >>> and the last version of clang officially provided for Ubuntu-12 was 3.4. ooh. >>> I will check if clang-3.4 for Ubuntu-12.04 can compile cmake (or any other >>> dependency problems would arise). >>> >>>> Usually the ABI is not the problem but the libstdc++, you can use a old Ubuntu with old libstdc++ but build CMake with new compiler and make sure it links with old libstdc++. This is the trick. >>> Indeed. >>> >>> Regards, >>> mpsuzuki >>> >>> Bo Zhou wrote: >>>> The latest CMake requires C++11 compiler, so what you need is just a newer GCC which supports C++11 at your platform, that's it. >>>> >>>> Usually the ABI is not the problem but the libstdc++, you can use a old Ubuntu with old libstdc++ but build CMake with new compiler and make sure it links with old libstdc++. This is the trick. >>>> >>>> I don't know how to do this on Ubuntu, but on CentOS, it's possible to build CMake in that way, so the CMake would be portable at older CentOS platform with old libstdc++ . >>>> >>>> Good luck. >>>> >>>> On Thu, Apr 5, 2018 at 12:23 PM, Eric Wing >> wrote: >>>> I just discovered that CMake no longer builds on my Ubuntu 12.04. I >>>> need to build binaries that are compatible with that ABI. >>>> >>>> I see that your binary distribution of CMake 3.11 still works on >>>> Ubuntu 12.04. Can you tell me what you do to achieve this? What are >>>> you doing for your official builds? >>>> >>>> Are you just using -static-libstdc++ -static-libgcc for >>>> CMAKE_CXX_FLAGS, or is there more? >>>> >>>> (I just noticed that ldd shows that you don't have dependencies on >>>> libssl, libcrypto, and libz, whereas I do.) >>>> >>>> Thanks, >>>> Eric >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> https://cmake.org/mailman/listinfo/cmake >>>> >>>> >>>> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake >> >> > From mpsuzuki at hiroshima-u.ac.jp Thu Apr 5 01:29:31 2018 From: mpsuzuki at hiroshima-u.ac.jp (suzuki toshiya) Date: Thu, 05 Apr 2018 14:29:31 +0900 Subject: [CMake] [FYI] clang-3.4 vs cmake-3.11.0 (How to build CMake so it works on an older Linux?) In-Reply-To: References: <5AC5A72D.7040908@hiroshima-u.ac.jp> <16ab44e818bb441884097d8f07ff5347@OS2PR01MB1147.jpnprd01.prod.outlook.com> <2f9737519c1943dbb1db683b8ae5187a@OS2PR01MB1147.jpnprd01.prod.outlook.com> Message-ID: <5AC5B43B.7060900@hiroshima-u.ac.jp> Sorry for bothering subscribers for posting about C++11 environment instead of cmake itself. Now I understand building gcc >= 4.8.5 manually might be easier, in comparison with the quest of libc++ for clang-3.4. https://stackoverflow.com/questions/39332406/install-libc-on-ubuntu Regards, mpsuzuki suzuki toshiya wrote: > Dear Bo Zhou, > > Sorry, I've confirmed by myself. > By default, clang-3.4 for Ubuntu prioritizes old g++ header files, and clang > header files are searched as a fallback. > I can customize the searching order by -nostdinc++... > > Regards, > mpsuzuki > > suzuki toshiya wrote: >> Dear Bo Zhou, >> >> Thank you for prompt reply. >> >>> Be aware that GCC suite actually is independent from the libstdc++, so if you have a newer compiler, the compiler might still pick the older libstdc++ without the new API. >> Oh, so, even if I installed clang-3.4, still it uses older (maybe C++03) >> libraries are referred by it? >> >> Regards, >> mpsuzuki >> >> Bo Zhou wrote: >>> The emplace() is new API from C++11. >>> >>> Be aware that GCC suite actually is independent from the libstdc++, so if you have a newer compiler, the compiler might still pick the older libstdc++ without the new API. >>> >>> This issue doesn't exist at Windows, since Visual Studio is a complete sytem. >>> >>> This issue happens on OSX also, so user must give the compiler a proper MacOS SDK for the new header files etc. >>> >>> On Thu, Apr 5, 2018 at 1:33 PM, suzuki toshiya > wrote: >>> $ clang++ --version >>> Ubuntu clang version 3.4-1ubuntu3~precise2 (tags/RELEASE_34/final) (based on >>> LLVM 3.4) >>> Target: x86_64-pc-linux-gnu >>> Thread model: posix >>> >>> But I got following abort: >>> >>> cmake-3.11.0/Source/cmLocalGenerator.cxx:553:36: error: no member named 'emplace' in >>> 'std::unordered_map, cmGeneratorTarget *, >>> std::hash, std::equal_to >, >>> std::allocator, cmGeneratorTarget >>> *> > >' >>> this->GeneratorTargetSearchIndex.emplace(gt->GetName(), gt); >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ >>> >>> Grrrr.... X-D >>> >>> Regards, >>> mpsuzuki >>> >>> suzuki toshiya wrote: >>>> Dear Bo Zhou, >>>> >>>> Thank you for the info! Now I'm checking Ubuntu 12.04 in LXC. >>>> So, gcc-4.8.5 or later would be needed for C++11, it seems that the last version >>>> of gcc officially provided for Ubuntu-12 was 4.7. oh. >>>> According to https://clang.llvm.org/cxx_status.html , clang-3.3 supports C++11, >>>> and the last version of clang officially provided for Ubuntu-12 was 3.4. ooh. >>>> I will check if clang-3.4 for Ubuntu-12.04 can compile cmake (or any other >>>> dependency problems would arise). >>>> >>>>> Usually the ABI is not the problem but the libstdc++, you can use a old Ubuntu with old libstdc++ but build CMake with new compiler and make sure it links with old libstdc++. This is the trick. >>>> Indeed. >>>> >>>> Regards, >>>> mpsuzuki >>>> >>>> Bo Zhou wrote: >>>>> The latest CMake requires C++11 compiler, so what you need is just a newer GCC which supports C++11 at your platform, that's it. >>>>> >>>>> Usually the ABI is not the problem but the libstdc++, you can use a old Ubuntu with old libstdc++ but build CMake with new compiler and make sure it links with old libstdc++. This is the trick. >>>>> >>>>> I don't know how to do this on Ubuntu, but on CentOS, it's possible to build CMake in that way, so the CMake would be portable at older CentOS platform with old libstdc++ . >>>>> >>>>> Good luck. >>>>> >>>>> On Thu, Apr 5, 2018 at 12:23 PM, Eric Wing >> wrote: >>>>> I just discovered that CMake no longer builds on my Ubuntu 12.04. I >>>>> need to build binaries that are compatible with that ABI. >>>>> >>>>> I see that your binary distribution of CMake 3.11 still works on >>>>> Ubuntu 12.04. Can you tell me what you do to achieve this? What are >>>>> you doing for your official builds? >>>>> >>>>> Are you just using -static-libstdc++ -static-libgcc for >>>>> CMAKE_CXX_FLAGS, or is there more? >>>>> >>>>> (I just noticed that ldd shows that you don't have dependencies on >>>>> libssl, libcrypto, and libz, whereas I do.) >>>>> >>>>> Thanks, >>>>> Eric >>>>> -- >>>>> >>>>> Powered by www.kitware.com >>>>> >>>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>>> >>>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>>> >>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>> >>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> https://cmake.org/mailman/listinfo/cmake >>>>> >>>>> >>>>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> https://cmake.org/mailman/listinfo/cmake >>> >>> > From ewmailing at gmail.com Thu Apr 5 03:09:34 2018 From: ewmailing at gmail.com (Eric Wing) Date: Thu, 5 Apr 2018 00:09:34 -0700 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: <5AC5A482.1080800@hiroshima-u.ac.jp> References: <5AC5A482.1080800@hiroshima-u.ac.jp> Message-ID: Thanks for the responses. Yes, I just need this to run on Ubuntu 12.04 (and some other old Linux's in that era). Yes, I think the probably is the libstdc++ dependency. As pointed out, it is really hard to get a newer compiler on Ubuntu 12.04. I've been down this road before, and if memory serves, the gcc bootstrapping process to get a newer compiler doesn't seem to work with a compiler older than gcc 4.8. Same goes for clang, which also weirdly relies on gcc 4.8 to bootstrap itself. Anyway, CMake seems to already know how to ship binaries that work across Linux distros. I'm pretty sure they just statically linked libstdc++ and libgcc. In fact, I just built it with -static-libstdc++ -static-libgcc on a newer Linux and tested it on 12.04 and it seemed to work. But I wanted to know for sure how CMake is building their own binaries in case there are subtle problems with what I did, and they have a completely different way of building it, e.g. statically libmusl for C and libc++ for C++, avoiding gcc entirely. Also, I did not take care of the libssl, libcrypto, and libz dependencies. I'm curious in practice how much trouble these are. (My recollection with zlib is that it is extremely stable and they care a great deal about not breaking backwards compatibility. I don't know about the others.) Thanks, Eric From mpsuzuki at hiroshima-u.ac.jp Thu Apr 5 03:15:17 2018 From: mpsuzuki at hiroshima-u.ac.jp (suzuki toshiya) Date: Thu, 05 Apr 2018 16:15:17 +0900 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: <398abda25ca544e28a25de222ccf8d97@OS2PR01MB1147.jpnprd01.prod.outlook.com> References: <5AC5A482.1080800@hiroshima-u.ac.jp> <398abda25ca544e28a25de222ccf8d97@OS2PR01MB1147.jpnprd01.prod.outlook.com> Message-ID: <5AC5CD05.5020709@hiroshima-u.ac.jp> Dear Eric, # if anybody think "how C++11 environment should be prepared # on legacy GNU/Linux" is off-topic and should be discussed # in off-list, please let me know. I will do so. Eric Wing wrote: > Thanks for the responses. Yes, I just need this to run on Ubuntu 12.04 > (and some other old Linux's in that era). Yes, I think the probably is > the libstdc++ dependency. > > As pointed out, it is really hard to get a newer compiler on Ubuntu > 12.04. I've been down this road before, and if memory serves, the gcc > bootstrapping process to get a newer compiler doesn't seem to work > with a compiler older than gcc 4.8. Same goes for clang, which also > weirdly relies on gcc 4.8 to bootstrap itself. At least, gcc-4.6.3, the last official gcc for Ubuntu-12.04, could build gcc-4.8.5 manually (without shared libstdc++, so confused dependency could be avoided). And, I could build cmake-3.11.0 by it. Now I'm checking "make test". If you can give the preferred prefix to install gcc-4.8.5 + cmake-3.11.0, I would be able to a tarball of the binaries. but please prepare some virus + malware checking :-) Regards, mpsuzuki > Anyway, CMake seems to already know how to ship binaries that work > across Linux distros. I'm pretty sure they just statically linked > libstdc++ and libgcc. In fact, I just built it with -static-libstdc++ > -static-libgcc on a newer Linux and tested it on 12.04 and it seemed > to work. > > But I wanted to know for sure how CMake is building their own binaries > in case there are subtle problems with what I did, and they have a > completely different way of building it, e.g. statically libmusl for C > and libc++ for C++, avoiding gcc entirely. > > Also, I did not take care of the libssl, libcrypto, and libz > dependencies. I'm curious in practice how much trouble these are. (My > recollection with zlib is that it is extremely stable and they care a > great deal about not breaking backwards compatibility. I don't know > about the others.) > > Thanks, > Eric > From loose at astron.nl Thu Apr 5 04:00:23 2018 From: loose at astron.nl (Marcel Loose) Date: Thu, 5 Apr 2018 10:00:23 +0200 Subject: [CMake] [FYI] clang-3.4 vs cmake-3.11.0 (How to build CMake so it works on an older Linux?) In-Reply-To: <5AC5B43B.7060900@hiroshima-u.ac.jp> References: <5AC5A72D.7040908@hiroshima-u.ac.jp> <16ab44e818bb441884097d8f07ff5347@OS2PR01MB1147.jpnprd01.prod.outlook.com> <2f9737519c1943dbb1db683b8ae5187a@OS2PR01MB1147.jpnprd01.prod.outlook.com> <5AC5B43B.7060900@hiroshima-u.ac.jp> Message-ID: Hi Suzuki, Sorry for chiming in late, but you may want to try the PPA for Ubuntu Toolchain test builds, which contains compiler builds up to gcc-8 for Ubuntu version as old as 10.04. Much less of a hassle than building GCC yourself, I can tell from experience. Check out https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test Cheers, Marcel. On 05/04/18 07:29, suzuki toshiya wrote: > Sorry for bothering subscribers for posting about C++11 environment > instead of cmake itself. Now I understand building gcc >= 4.8.5 > manually might be easier, in comparison with the quest of libc++ > for clang-3.4. > > https://stackoverflow.com/questions/39332406/install-libc-on-ubuntu > > Regards, > mpsuzuki > > suzuki toshiya wrote: >> Dear Bo Zhou, >> >> Sorry, I've confirmed by myself. >> By default, clang-3.4 for Ubuntu prioritizes old g++ header files, and clang >> header files are searched as a fallback. >> I can customize the searching order by -nostdinc++... >> >> Regards, >> mpsuzuki >> >> suzuki toshiya wrote: >>> Dear Bo Zhou, >>> >>> Thank you for prompt reply. >>> >>>> Be aware that GCC suite actually is independent from the libstdc++, so if you have a newer compiler, the compiler might still pick the older libstdc++ without the new API. >>> Oh, so, even if I installed clang-3.4, still it uses older (maybe C++03) >>> libraries are referred by it? >>> >>> Regards, >>> mpsuzuki >>> >>> Bo Zhou wrote: >>>> The emplace() is new API from C++11. >>>> >>>> Be aware that GCC suite actually is independent from the libstdc++, so if you have a newer compiler, the compiler might still pick the older libstdc++ without the new API. >>>> >>>> This issue doesn't exist at Windows, since Visual Studio is a complete sytem. >>>> >>>> This issue happens on OSX also, so user must give the compiler a proper MacOS SDK for the new header files etc. >>>> >>>> On Thu, Apr 5, 2018 at 1:33 PM, suzuki toshiya > wrote: >>>> $ clang++ --version >>>> Ubuntu clang version 3.4-1ubuntu3~precise2 (tags/RELEASE_34/final) (based on >>>> LLVM 3.4) >>>> Target: x86_64-pc-linux-gnu >>>> Thread model: posix >>>> >>>> But I got following abort: >>>> >>>> cmake-3.11.0/Source/cmLocalGenerator.cxx:553:36: error: no member named 'emplace' in >>>> 'std::unordered_map, cmGeneratorTarget *, >>>> std::hash, std::equal_to >, >>>> std::allocator, cmGeneratorTarget >>>> *> > >' >>>> this->GeneratorTargetSearchIndex.emplace(gt->GetName(), gt); >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ >>>> >>>> Grrrr.... X-D >>>> >>>> Regards, >>>> mpsuzuki >>>> >>>> suzuki toshiya wrote: >>>>> Dear Bo Zhou, >>>>> >>>>> Thank you for the info! Now I'm checking Ubuntu 12.04 in LXC. >>>>> So, gcc-4.8.5 or later would be needed for C++11, it seems that the last version >>>>> of gcc officially provided for Ubuntu-12 was 4.7. oh. >>>>> According to https://clang.llvm.org/cxx_status.html , clang-3.3 supports C++11, >>>>> and the last version of clang officially provided for Ubuntu-12 was 3.4. ooh. >>>>> I will check if clang-3.4 for Ubuntu-12.04 can compile cmake (or any other >>>>> dependency problems would arise). >>>>> >>>>>> Usually the ABI is not the problem but the libstdc++, you can use a old Ubuntu with old libstdc++ but build CMake with new compiler and make sure it links with old libstdc++. This is the trick. >>>>> Indeed. >>>>> >>>>> Regards, >>>>> mpsuzuki >>>>> >>>>> Bo Zhou wrote: >>>>>> The latest CMake requires C++11 compiler, so what you need is just a newer GCC which supports C++11 at your platform, that's it. >>>>>> >>>>>> Usually the ABI is not the problem but the libstdc++, you can use a old Ubuntu with old libstdc++ but build CMake with new compiler and make sure it links with old libstdc++. This is the trick. >>>>>> >>>>>> I don't know how to do this on Ubuntu, but on CentOS, it's possible to build CMake in that way, so the CMake would be portable at older CentOS platform with old libstdc++ . >>>>>> >>>>>> Good luck. >>>>>> >>>>>> On Thu, Apr 5, 2018 at 12:23 PM, Eric Wing >> wrote: >>>>>> I just discovered that CMake no longer builds on my Ubuntu 12.04. I >>>>>> need to build binaries that are compatible with that ABI. >>>>>> >>>>>> I see that your binary distribution of CMake 3.11 still works on >>>>>> Ubuntu 12.04. Can you tell me what you do to achieve this? What are >>>>>> you doing for your official builds? >>>>>> >>>>>> Are you just using -static-libstdc++ -static-libgcc for >>>>>> CMAKE_CXX_FLAGS, or is there more? >>>>>> >>>>>> (I just noticed that ldd shows that you don't have dependencies on >>>>>> libssl, libcrypto, and libz, whereas I do.) >>>>>> >>>>>> Thanks, >>>>>> Eric >>>>>> -- >>>>>> >>>>>> Powered by www.kitware.com >>>>>> >>>>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>>>> >>>>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>>>> >>>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>>> >>>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>>>> >>>>>> Follow this link to subscribe/unsubscribe: >>>>>> https://cmake.org/mailman/listinfo/cmake >>>>>> >>>>>> >>>>>> >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> https://cmake.org/mailman/listinfo/cmake >>>> >>>> -------------- next part -------------- A non-text attachment was scrubbed... Name: loose.vcf Type: text/x-vcard Size: 292 bytes Desc: not available URL: From mpsuzuki at hiroshima-u.ac.jp Thu Apr 5 04:29:19 2018 From: mpsuzuki at hiroshima-u.ac.jp (suzuki toshiya) Date: Thu, 05 Apr 2018 17:29:19 +0900 Subject: [CMake] [FYI] clang-3.4 vs cmake-3.11.0 (How to build CMake so it works on an older Linux?) In-Reply-To: References: <5AC5A72D.7040908@hiroshima-u.ac.jp> <16ab44e818bb441884097d8f07ff5347@OS2PR01MB1147.jpnprd01.prod.outlook.com> <2f9737519c1943dbb1db683b8ae5187a@OS2PR01MB1147.jpnprd01.prod.outlook.com> <5AC5B43B.7060900@hiroshima-u.ac.jp> Message-ID: <5AC5DE5F.4010707@hiroshima-u.ac.jp> Dear Marcel, Oh, I slipped to remind the exist of launchpad... Thanks! at least, gcc-6.2.0 seems to be available for 12.04. Regards, mpsuzuki Marcel Loose wrote: > Hi Suzuki, > > Sorry for chiming in late, but you may want to try the PPA for Ubuntu > Toolchain test builds, which contains compiler builds up to gcc-8 for > Ubuntu version as old as 10.04. Much less of a hassle than building GCC > yourself, I can tell from experience. Check out > https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test > > Cheers, > Marcel. > > > On 05/04/18 07:29, suzuki toshiya wrote: >> Sorry for bothering subscribers for posting about C++11 environment >> instead of cmake itself. Now I understand building gcc >= 4.8.5 >> manually might be easier, in comparison with the quest of libc++ >> for clang-3.4. >> >> https://stackoverflow.com/questions/39332406/install-libc-on-ubuntu >> >> Regards, >> mpsuzuki >> >> suzuki toshiya wrote: >>> Dear Bo Zhou, >>> >>> Sorry, I've confirmed by myself. >>> By default, clang-3.4 for Ubuntu prioritizes old g++ header files, and clang >>> header files are searched as a fallback. >>> I can customize the searching order by -nostdinc++... >>> >>> Regards, >>> mpsuzuki >>> >>> suzuki toshiya wrote: >>>> Dear Bo Zhou, >>>> >>>> Thank you for prompt reply. >>>> >>>>> Be aware that GCC suite actually is independent from the libstdc++, so if you have a newer compiler, the compiler might still pick the older libstdc++ without the new API. >>>> Oh, so, even if I installed clang-3.4, still it uses older (maybe C++03) >>>> libraries are referred by it? >>>> >>>> Regards, >>>> mpsuzuki >>>> >>>> Bo Zhou wrote: >>>>> The emplace() is new API from C++11. >>>>> >>>>> Be aware that GCC suite actually is independent from the libstdc++, so if you have a newer compiler, the compiler might still pick the older libstdc++ without the new API. >>>>> >>>>> This issue doesn't exist at Windows, since Visual Studio is a complete sytem. >>>>> >>>>> This issue happens on OSX also, so user must give the compiler a proper MacOS SDK for the new header files etc. >>>>> >>>>> On Thu, Apr 5, 2018 at 1:33 PM, suzuki toshiya > wrote: >>>>> $ clang++ --version >>>>> Ubuntu clang version 3.4-1ubuntu3~precise2 (tags/RELEASE_34/final) (based on >>>>> LLVM 3.4) >>>>> Target: x86_64-pc-linux-gnu >>>>> Thread model: posix >>>>> >>>>> But I got following abort: >>>>> >>>>> cmake-3.11.0/Source/cmLocalGenerator.cxx:553:36: error: no member named 'emplace' in >>>>> 'std::unordered_map, cmGeneratorTarget *, >>>>> std::hash, std::equal_to >, >>>>> std::allocator, cmGeneratorTarget >>>>> *> > >' >>>>> this->GeneratorTargetSearchIndex.emplace(gt->GetName(), gt); >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ >>>>> >>>>> Grrrr.... X-D >>>>> >>>>> Regards, >>>>> mpsuzuki >>>>> >>>>> suzuki toshiya wrote: >>>>>> Dear Bo Zhou, >>>>>> >>>>>> Thank you for the info! Now I'm checking Ubuntu 12.04 in LXC. >>>>>> So, gcc-4.8.5 or later would be needed for C++11, it seems that the last version >>>>>> of gcc officially provided for Ubuntu-12 was 4.7. oh. >>>>>> According to https://clang.llvm.org/cxx_status.html , clang-3.3 supports C++11, >>>>>> and the last version of clang officially provided for Ubuntu-12 was 3.4. ooh. >>>>>> I will check if clang-3.4 for Ubuntu-12.04 can compile cmake (or any other >>>>>> dependency problems would arise). >>>>>> >>>>>>> Usually the ABI is not the problem but the libstdc++, you can use a old Ubuntu with old libstdc++ but build CMake with new compiler and make sure it links with old libstdc++. This is the trick. >>>>>> Indeed. >>>>>> >>>>>> Regards, >>>>>> mpsuzuki >>>>>> >>>>>> Bo Zhou wrote: >>>>>>> The latest CMake requires C++11 compiler, so what you need is just a newer GCC which supports C++11 at your platform, that's it. >>>>>>> >>>>>>> Usually the ABI is not the problem but the libstdc++, you can use a old Ubuntu with old libstdc++ but build CMake with new compiler and make sure it links with old libstdc++. This is the trick. >>>>>>> >>>>>>> I don't know how to do this on Ubuntu, but on CentOS, it's possible to build CMake in that way, so the CMake would be portable at older CentOS platform with old libstdc++ . >>>>>>> >>>>>>> Good luck. >>>>>>> >>>>>>> On Thu, Apr 5, 2018 at 12:23 PM, Eric Wing >> wrote: >>>>>>> I just discovered that CMake no longer builds on my Ubuntu 12.04. I >>>>>>> need to build binaries that are compatible with that ABI. >>>>>>> >>>>>>> I see that your binary distribution of CMake 3.11 still works on >>>>>>> Ubuntu 12.04. Can you tell me what you do to achieve this? What are >>>>>>> you doing for your official builds? >>>>>>> >>>>>>> Are you just using -static-libstdc++ -static-libgcc for >>>>>>> CMAKE_CXX_FLAGS, or is there more? >>>>>>> >>>>>>> (I just noticed that ldd shows that you don't have dependencies on >>>>>>> libssl, libcrypto, and libz, whereas I do.) >>>>>>> >>>>>>> Thanks, >>>>>>> Eric >>>>>>> -- >>>>>>> >>>>>>> Powered by www.kitware.com >>>>>>> >>>>>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>>>>> >>>>>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>>>>> >>>>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>>>> >>>>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>>>>> >>>>>>> Follow this link to subscribe/unsubscribe: >>>>>>> https://cmake.org/mailman/listinfo/cmake >>>>>>> >>>>>>> >>>>>>> >>>>> -- >>>>> >>>>> Powered by www.kitware.com >>>>> >>>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>>> >>>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>>> >>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>> >>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> https://cmake.org/mailman/listinfo/cmake >>>>> >>>>> > From sjm324 at cornell.edu Thu Apr 5 09:01:18 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Thu, 5 Apr 2018 06:01:18 -0700 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: <5AC5CD05.5020709@hiroshima-u.ac.jp> References: <5AC5A482.1080800@hiroshima-u.ac.jp> <398abda25ca544e28a25de222ccf8d97@OS2PR01MB1147.jpnprd01.prod.outlook.com> <5AC5CD05.5020709@hiroshima-u.ac.jp> Message-ID: Hi Suzuki, (Note: to other CMake mailing list readers, this pertains very little to CMake itself. I?m sending it to the mailing list so that future users with this issue may also have a possible solution). Getting a newer version of GCC is quite challenging by yourself indeed, but you may be interested in the Spack package manager: http://spack.readthedocs.io/en/latest/getting_started.html It?s designed for high performance computing, but has a special emphasis on supporting older distributions (since updating HPC cluster operating systems is the devil). Some quick tips: 1. Once you start installing things, you cannot move the spack directory. So decide where you want it and clone it there. For example, I keep all of my installations in /opt/spack cd /opt sudo git clone https://github.com/spack/spack.git Assuming you are `user` on this system (echo $USER) sudo chown -R user spack/ Then proceed with the getting started tutorial. 2. You have many possible newer versions of GCC available, by default `spack install gcc` installs the newest one. Run `spack info gcc` to see the versions available. Suppose you installed gcc at 6.4.0 (which will as you know take a while). You will want to make this available as a compiler, so you `spack load gcc at 6.4.0` (it might tell you to source a script, so do that) and run `spack compiler find`. When `spack compiler list` shows your shiny new GCC compiler, you can now `spack install cmake %gcc at 6.4.0` to use GCC 6.4.0 to compile Cmake! Note you don?t need to install GCC 6.4.0, that was purely an example. I know there have been some issues with really old GCC versions compiling newer versions, but I think we fixed the underlying problem that caused that. AKA my hope is this works seamlessly, but you may run into trouble. If you do, you might try installing an older version of GCC (in this example, say 6.4.0 didn?t work, maybe try GCC 5.5.0). I hope this is helpful for you! There?s a lot more to spack, but if you get stuck raise an issue on GitHub. The spack user community is very helpful and friendly to newcomers :) Good luck! -Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Apr 5 09:15:08 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 5 Apr 2018 09:15:08 -0400 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: References: <5AC5A482.1080800@hiroshima-u.ac.jp> Message-ID: The official CMake binaries do the same thing as you and build with a static libstdc++ and libgcc. As far as dependencies we use static builds of those too, with most being the version provided inside CMake, and an external openssl. You can find the more information on the exact flags we are using at: https://gitlab.kitware.com/cmake/cmake/blob/master/Utilities/Release/linux64_release.cmake On Thu, Apr 5, 2018 at 3:09 AM, Eric Wing wrote: > Thanks for the responses. Yes, I just need this to run on Ubuntu 12.04 > (and some other old Linux's in that era). Yes, I think the probably is > the libstdc++ dependency. > > As pointed out, it is really hard to get a newer compiler on Ubuntu > 12.04. I've been down this road before, and if memory serves, the gcc > bootstrapping process to get a newer compiler doesn't seem to work > with a compiler older than gcc 4.8. Same goes for clang, which also > weirdly relies on gcc 4.8 to bootstrap itself. > > Anyway, CMake seems to already know how to ship binaries that work > across Linux distros. I'm pretty sure they just statically linked > libstdc++ and libgcc. In fact, I just built it with -static-libstdc++ > -static-libgcc on a newer Linux and tested it on 12.04 and it seemed > to work. > > But I wanted to know for sure how CMake is building their own binaries > in case there are subtle problems with what I did, and they have a > completely different way of building it, e.g. statically libmusl for C > and libc++ for C++, avoiding gcc entirely. > > Also, I did not take care of the libssl, libcrypto, and libz > dependencies. I'm curious in practice how much trouble these are. (My > recollection with zlib is that it is extremely stable and they care a > great deal about not breaking backwards compatibility. I don't know > about the others.) > > Thanks, > Eric > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake From patrick.griffiths at gmail.com Thu Apr 5 09:43:03 2018 From: patrick.griffiths at gmail.com (Patrick Griffiths) Date: Thu, 5 Apr 2018 07:43:03 -0600 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: References: <5AC5A482.1080800@hiroshima-u.ac.jp> Message-ID: I had a similar problem on 14.04 and solved it by installing gcc 4.9 (other version are also available) from the ubuntu-toolchain-r PPA. This worked for me. YMMV: $ sudo add-apt-repository ppa:ubuntu-toolchain-r/test $ sudo apt-get update $ sudo apt-get install gcc-4.9 $ sudo apt-get install g++-4.9 When building CMake I set the CXX and CC variables at the command line $ CXX=g++-4.9 CC=gcc-4.9 ../path/to/bootstrap ...etc .. $ CXX=g++-4.9 CC=gcc-4.9 make install HTH Patrick On Thu, Apr 5, 2018 at 7:15 AM, Robert Maynard wrote: > The official CMake binaries do the same thing as you and build with a > static libstdc++ and libgcc. > As far as dependencies we use static builds of those too, with most > being the version provided inside CMake, and an external openssl. > > You can find the more information on the exact flags we are using at: > https://gitlab.kitware.com/cmake/cmake/blob/master/ > Utilities/Release/linux64_release.cmake > > On Thu, Apr 5, 2018 at 3:09 AM, Eric Wing wrote: > > Thanks for the responses. Yes, I just need this to run on Ubuntu 12.04 > > (and some other old Linux's in that era). Yes, I think the probably is > > the libstdc++ dependency. > > > > As pointed out, it is really hard to get a newer compiler on Ubuntu > > 12.04. I've been down this road before, and if memory serves, the gcc > > bootstrapping process to get a newer compiler doesn't seem to work > > with a compiler older than gcc 4.8. Same goes for clang, which also > > weirdly relies on gcc 4.8 to bootstrap itself. > > > > Anyway, CMake seems to already know how to ship binaries that work > > across Linux distros. I'm pretty sure they just statically linked > > libstdc++ and libgcc. In fact, I just built it with -static-libstdc++ > > -static-libgcc on a newer Linux and tested it on 12.04 and it seemed > > to work. > > > > But I wanted to know for sure how CMake is building their own binaries > > in case there are subtle problems with what I did, and they have a > > completely different way of building it, e.g. statically libmusl for C > > and libc++ for C++, avoiding gcc entirely. > > > > Also, I did not take care of the libssl, libcrypto, and libz > > dependencies. I'm curious in practice how much trouble these are. (My > > recollection with zlib is that it is extremely stable and they care a > > great deal about not breaking backwards compatibility. I don't know > > about the others.) > > > > Thanks, > > Eric > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > https://cmake.org/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.e.sanchez at gmail.com Thu Apr 5 10:57:18 2018 From: juan.e.sanchez at gmail.com (Juan E. Sanchez) Date: Thu, 5 Apr 2018 09:57:18 -0500 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: References: Message-ID: Hello, SHORT VERSION: BTW, Ubuntu 12 is officially End of Life on April 28, 2017 http://releases.ubuntu.com/12.04/ So unless you are paying them for support, you should really upgrade to Ubuntu 14. LONG VERSION: I recommend starting a docker image of centos 6 in a newer version of Ubuntu. This would be a virtual machine environment you can build a version with a newer compiler, g++, but with an older glibc. The libstdc++ you link against would then be compatible with most modern distributions. This is by getting the devtoolset-6 or devtoolset-7 tools provided by redhat. You can communicate with me offline on how to do this, but in principle the installation of the compiler is this: yum install -y centos-release-scl yum install -y devtoolset-6-gcc devtoolset-6-gcc-c++ devtoolset-6-libquadmath-devel devtoolset-6-gcc-gfortran Docker is freely available and used across the open source community to build for multiple linux versions. It can be installed directly from ubuntu as a standard package. You can then package the application, and it would more than likely run on your system. Regards, Juan On 4/4/18 10:23 PM, Eric Wing wrote: > I just discovered that CMake no longer builds on my Ubuntu 12.04. I > need to build binaries that are compatible with that ABI. > > I see that your binary distribution of CMake 3.11 still works on > Ubuntu 12.04. Can you tell me what you do to achieve this? What are > you doing for your official builds? > > Are you just using -static-libstdc++ -static-libgcc for > CMAKE_CXX_FLAGS, or is there more? > > (I just noticed that ldd shows that you don't have dependencies on > libssl, libcrypto, and libz, whereas I do.) > > Thanks, > Eric > From neundorf at kde.org Thu Apr 5 15:24:40 2018 From: neundorf at kde.org (Alexander Neundorf) Date: Thu, 05 Apr 2018 21:24:40 +0200 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: <5AC5CD05.5020709@hiroshima-u.ac.jp> References: <398abda25ca544e28a25de222ccf8d97@OS2PR01MB1147.jpnprd01.prod.outlook.com> <5AC5CD05.5020709@hiroshima-u.ac.jp> Message-ID: <1738636.9bkYWmIbxA@linux-l7nd> On 2018 M04 5, Thu 16:15:17 CEST suzuki toshiya wrote: > Dear Eric, > > # if anybody think "how C++11 environment should be prepared > # on legacy GNU/Linux" is off-topic and should be discussed > # in off-list, please let me know. I will do so. > > Eric Wing wrote: > > Thanks for the responses. Yes, I just need this to run on Ubuntu 12.04 > > (and some other old Linux's in that era). Yes, I think the probably is > > the libstdc++ dependency. > > > > As pointed out, it is really hard to get a newer compiler on Ubuntu > > 12.04. I've been down this road before, and if memory serves, the gcc > > bootstrapping process to get a newer compiler doesn't seem to work > > with a compiler older than gcc 4.8. Same goes for clang, which also > > weirdly relies on gcc 4.8 to bootstrap itself. > > At least, gcc-4.6.3, the last official gcc for Ubuntu-12.04, could > build gcc-4.8.5 manually (without shared libstdc++, so confused > dependency could be avoided). And, I could build cmake-3.11.0 by it. > Now I'm checking "make test". I have recently built a gcc 4.9.5 on Centos 5, i.e. gcc 4.1. There were no issues after getting the configure flags right. Alex From neundorf at kde.org Thu Apr 5 15:30:57 2018 From: neundorf at kde.org (Alexander Neundorf) Date: Thu, 05 Apr 2018 21:30:57 +0200 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: <1738636.9bkYWmIbxA@linux-l7nd> References: <5AC5CD05.5020709@hiroshima-u.ac.jp> <1738636.9bkYWmIbxA@linux-l7nd> Message-ID: <1662887.mc15567AFR@linux-l7nd> On 2018 M04 5, Thu 21:24:40 CEST Alexander Neundorf wrote: > On 2018 M04 5, Thu 16:15:17 CEST suzuki toshiya wrote: > > Dear Eric, > > > > # if anybody think "how C++11 environment should be prepared > > # on legacy GNU/Linux" is off-topic and should be discussed > > # in off-list, please let me know. I will do so. > > > > Eric Wing wrote: > > > Thanks for the responses. Yes, I just need this to run on Ubuntu 12.04 > > > (and some other old Linux's in that era). Yes, I think the probably is > > > the libstdc++ dependency. > > > > > > As pointed out, it is really hard to get a newer compiler on Ubuntu > > > 12.04. I've been down this road before, and if memory serves, the gcc > > > bootstrapping process to get a newer compiler doesn't seem to work > > > with a compiler older than gcc 4.8. Same goes for clang, which also > > > weirdly relies on gcc 4.8 to bootstrap itself. > > > > At least, gcc-4.6.3, the last official gcc for Ubuntu-12.04, could > > build gcc-4.8.5 manually (without shared libstdc++, so confused > > dependency could be avoided). And, I could build cmake-3.11.0 by it. > > Now I'm checking "make test". > > I have recently built a gcc 4.9.5 on Centos 5, i.e. gcc 4.1. There were no > issues after getting the configure flags right. 4.9.4 I mean. You can see the flags here: https://hub.docker.com/r/aneundorf/docker-centos5-build-svn-gcc/~/dockerfile/ (but the docker image didn't build, it was killed by a dockerhub timeout). Alex From bsferrazza at avnera.com Thu Apr 5 15:50:04 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Thu, 5 Apr 2018 12:50:04 -0700 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: <1662887.mc15567AFR@linux-l7nd> References: <5AC5CD05.5020709@hiroshima-u.ac.jp> <1738636.9bkYWmIbxA@linux-l7nd> <1662887.mc15567AFR@linux-l7nd> Message-ID: On Thu, Apr 5, 2018 at 12:30 PM, Alexander Neundorf wrote: > On 2018 M04 5, Thu 21:24:40 CEST Alexander Neundorf wrote: > > On 2018 M04 5, Thu 16:15:17 CEST suzuki toshiya wrote: > > > Dear Eric, > > > > > > # if anybody think "how C++11 environment should be prepared > > > # on legacy GNU/Linux" is off-topic and should be discussed > > > # in off-list, please let me know. I will do so. > > > > > > Eric Wing wrote: > > > > Thanks for the responses. Yes, I just need this to run on Ubuntu > 12.04 > > > > (and some other old Linux's in that era). Yes, I think the probably > is > > > > the libstdc++ dependency. > > > > > > > > As pointed out, it is really hard to get a newer compiler on Ubuntu > > > > 12.04. I've been down this road before, and if memory serves, the gcc > > > > bootstrapping process to get a newer compiler doesn't seem to work > > > > with a compiler older than gcc 4.8. Same goes for clang, which also > > > > weirdly relies on gcc 4.8 to bootstrap itself. > > > > > > At least, gcc-4.6.3, the last official gcc for Ubuntu-12.04, could > > > build gcc-4.8.5 manually (without shared libstdc++, so confused > > > dependency could be avoided). And, I could build cmake-3.11.0 by it. > > > Now I'm checking "make test". > > > > I have recently built a gcc 4.9.5 on Centos 5, i.e. gcc 4.1. There were > no > > issues after getting the configure flags right. > > 4.9.4 I mean. > You can see the flags here: > https://hub.docker.com/r/aneundorf/docker-centos5- > build-svn-gcc/~/dockerfile/ > (but the docker image didn't build, it was killed by a dockerhub timeout). > > Alex > Were you able to actually build the newer versions of Cmake that require c++11 on Centos 5? I have built up a bootstrapped toolchain, following much of the guidance found in Linux From Scratch, on a Centos 5 system at work (which unfortunately cannot be upgrade due to the support of legacy software). The toolchain uses the latest gcc 7.3.0, binutils 2.30, and glibc 2.19 (the latest version of glibc supported by the 2.6.18 kernel of Centos 5). Yet cmake complains that my toolchain does not support c++11. Which kernel and glibc version do you have on your Centos 5 box? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.e.sanchez at gmail.com Thu Apr 5 16:13:18 2018 From: juan.e.sanchez at gmail.com (Juan E. Sanchez) Date: Thu, 5 Apr 2018 15:13:18 -0500 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: References: <5AC5CD05.5020709@hiroshima-u.ac.jp> <1738636.9bkYWmIbxA@linux-l7nd> <1662887.mc15567AFR@linux-l7nd> Message-ID: <4a61ab61-e300-4c19-7043-0e03499398cb@gmail.com> Hello, Centos 5, Redhat 5 is EOL as of March 31, 2017. Building cmake in docker: cd /root; curl -L -O https://cmake.org/files/v3.11/cmake-3.11.0.tar.gz; tar xzvf cmake-3.11.0.tar.gz; yum install -y centos-release-scl; yum install -y devtoolset-6-gcc devtoolset-6-gcc-c++ devtoolset-6-libquadmath-devel devtoolset-6-gcc-gfortran; source /opt/rh/devtoolset-6/enable; cd cmake-3.11.0; ./bootstrap --prefix=/root/cmake --parallel=4; make -j4; make install; cd /root; tar czvf cmake.tgz; Please note that cmake will silently ignore features for packages that haven't been installed into the image, (ncurses, curl). Regards, Juan On 4/5/18 2:50 PM, Ben Sferrazza wrote: > > > On Thu, Apr 5, 2018 at 12:30 PM, Alexander Neundorf > wrote: > > On 2018 M04 5, Thu 21:24:40 CEST Alexander Neundorf wrote: > > On 2018 M04 5, Thu 16:15:17 CEST suzuki toshiya wrote: > > > Dear Eric, > > > > > > # if anybody think "how C++11 environment should be prepared > > > # on legacy GNU/Linux" is off-topic and should be discussed > > > # in off-list, please let me know. I will do so. > > > > > > Eric Wing wrote: > > > > Thanks for the responses. Yes, I just need this to run on Ubuntu 12.04 > > > > (and some other old Linux's in that era). Yes, I think the probably is > > > > the libstdc++ dependency. > > > > > > > > As pointed out, it is really hard to get a newer compiler on Ubuntu > > > > 12.04. I've been down this road before, and if memory serves, the gcc > > > > bootstrapping process to get a newer compiler doesn't seem to work > > > > with a compiler older than gcc 4.8. Same goes for clang, which also > > > > weirdly relies on gcc 4.8 to bootstrap itself. > > > > > > At least, gcc-4.6.3, the last official gcc for Ubuntu-12.04, could > > > build gcc-4.8.5 manually (without shared libstdc++, so confused > > > dependency could be avoided). And, I could build cmake-3.11.0 by it. > > > Now I'm checking "make test". > > > > I have recently built a gcc 4.9.5 on Centos 5, i.e. gcc 4.1. There were no > > issues after getting the configure flags right. > > 4.9.4 I mean. > You can see the flags here: > https://hub.docker.com/r/aneundorf/docker-centos5-build-svn-gcc/~/dockerfile/ > > (but the docker image didn't build, it was killed by a dockerhub > timeout). > > Alex > > > Were you able to actually build the newer versions of Cmake that require > c++11 on Centos 5? I have built up a bootstrapped toolchain, following > much of the guidance found in Linux From Scratch, on a Centos 5 system > at work (which unfortunately cannot be upgrade due to the support of > legacy software). The toolchain uses the latest gcc 7.3.0, binutils > 2.30, and glibc 2.19 (the latest version of glibc supported by the > 2.6.18 kernel of Centos 5). Yet cmake complains that my toolchain does > not support c++11. Which kernel and glibc version do you have on your > Centos 5 box? Thank you. > > From juan.e.sanchez at gmail.com Thu Apr 5 16:15:21 2018 From: juan.e.sanchez at gmail.com (Juan E. Sanchez) Date: Thu, 5 Apr 2018 15:15:21 -0500 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: <4a61ab61-e300-4c19-7043-0e03499398cb@gmail.com> References: <5AC5CD05.5020709@hiroshima-u.ac.jp> <1738636.9bkYWmIbxA@linux-l7nd> <1662887.mc15567AFR@linux-l7nd> <4a61ab61-e300-4c19-7043-0e03499398cb@gmail.com> Message-ID: The example I just sent was for building in centos 6, because 5 is gone. docker run -it --name centos6 centos:6 /bin/bash Regards, Juan On 4/5/18 3:13 PM, Juan E. Sanchez wrote: > Hello, > > Centos 5, Redhat 5 is EOL as of March 31, 2017. > > Building cmake in docker: > > cd /root; > curl -L -O https://cmake.org/files/v3.11/cmake-3.11.0.tar.gz; > tar xzvf cmake-3.11.0.tar.gz; > yum install -y centos-release-scl; > yum install -y devtoolset-6-gcc devtoolset-6-gcc-c++ > devtoolset-6-libquadmath-devel devtoolset-6-gcc-gfortran; > source /opt/rh/devtoolset-6/enable; > cd cmake-3.11.0; > ./bootstrap --prefix=/root/cmake --parallel=4; > make -j4; > make install; > cd /root; > tar czvf cmake.tgz; > > Please note that cmake will silently ignore features for packages that > haven't been installed into the image, (ncurses, curl). > > Regards, > > Juan > > On 4/5/18 2:50 PM, Ben Sferrazza wrote: >> >> >> On Thu, Apr 5, 2018 at 12:30 PM, Alexander Neundorf > > wrote: >> >> ??? On 2018 M04 5, Thu 21:24:40 CEST Alexander Neundorf wrote: >> ??? > On 2018 M04 5, Thu 16:15:17 CEST suzuki toshiya wrote: >> ??? > > Dear Eric, >> ??? > > >> ??? > > # if anybody think "how C++11 environment should be prepared >> ??? > > # on legacy GNU/Linux" is off-topic and should be discussed >> ??? > > # in off-list, please let me know. I will do so. >> ??? > > >> ??? > > Eric Wing wrote: >> ??? > > > Thanks for the responses. Yes, I just need this to run on >> Ubuntu 12.04 >> ??? > > > (and some other old Linux's in that era). Yes, I think the >> probably is >> ??? > > > the libstdc++ dependency. >> ??? > > > >> ??? > > > As pointed out, it is really hard to get a newer compiler on >> Ubuntu >> ??? > > > 12.04. I've been down this road before, and if memory >> serves, the gcc >> ??? > > > bootstrapping process to get a newer compiler doesn't seem >> to work >> ??? > > > with a compiler older than gcc 4.8. Same goes for clang, >> which also >> ??? > > > weirdly relies on gcc 4.8 to bootstrap itself. >> ??? > > >> ??? > > At least, gcc-4.6.3, the last official gcc for Ubuntu-12.04, >> could >> ??? > > build gcc-4.8.5 manually (without shared libstdc++, so confused >> ??? > > dependency could be avoided). And, I could build cmake-3.11.0 >> by it. >> ??? > > Now I'm checking "make test". >> ??? > >> ??? > I have recently built a gcc 4.9.5 on Centos 5, i.e. gcc 4.1. >> There were no >> ??? > issues after getting the configure flags right. >> >> ??? 4.9.4 I mean. >> ??? You can see the flags here: >> >> https://hub.docker.com/r/aneundorf/docker-centos5-build-svn-gcc/~/dockerfile/ >> >> >> >> >> ??? (but the docker image didn't build, it was killed by a dockerhub >> ??? timeout). >> >> ??? Alex >> >> >> Were you able to actually build the newer versions of Cmake that >> require c++11 on Centos 5? I have built up a bootstrapped toolchain, >> following much of the guidance found in Linux From Scratch, on a >> Centos 5 system at work (which unfortunately cannot be upgrade due to >> the support of legacy software). The toolchain uses the latest gcc >> 7.3.0, binutils 2.30, and glibc 2.19 (the latest version of glibc >> supported by the 2.6.18 kernel of Centos 5). Yet cmake complains that >> my toolchain does not support c++11. Which kernel and glibc version do >> you have on your Centos 5 box? Thank you. >> >> > From neundorf at kde.org Thu Apr 5 17:09:15 2018 From: neundorf at kde.org (Alexander Neundorf) Date: Thu, 05 Apr 2018 23:09:15 +0200 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: References: <1662887.mc15567AFR@linux-l7nd> Message-ID: <7655162.eR8czFM7A9@linux-l7nd> On 2018 M04 5, Thu 12:50:04 CEST Ben Sferrazza wrote: > > Were you able to actually build the newer versions of Cmake that require > c++11 on Centos 5? I didn't try that. Alex From neundorf at kde.org Thu Apr 5 17:13:55 2018 From: neundorf at kde.org (Alexander Neundorf) Date: Thu, 05 Apr 2018 23:13:55 +0200 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: References: <4a61ab61-e300-4c19-7043-0e03499398cb@gmail.com> Message-ID: <1541985.SyzxkG7t1J@linux-l7nd> On 2018 M04 5, Thu 15:15:21 CEST Juan E. Sanchez wrote: > The example I just sent was for building in centos 6, because 5 is gone. not really gone, it's still in vault.centos.org :-) https://hub.docker.com/r/aneundorf/centos5-build-base/~/dockerfile/ Alex From bo.schwarzstein at gmail.com Thu Apr 5 22:33:23 2018 From: bo.schwarzstein at gmail.com (Bo Zhou) Date: Fri, 6 Apr 2018 11:33:23 +0900 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: <1541985.SyzxkG7t1J@linux-l7nd> References: <4a61ab61-e300-4c19-7043-0e03499398cb@gmail.com> <1541985.SyzxkG7t1J@linux-l7nd> Message-ID: When use Devtoolset of CentOS, don't forget to install the *binutils* from that devtoolset, or else, the compilation might generate strange error. On Fri, Apr 6, 2018 at 6:13 AM, Alexander Neundorf wrote: > On 2018 M04 5, Thu 15:15:21 CEST Juan E. Sanchez wrote: > > The example I just sent was for building in centos 6, because 5 is gone. > > not really gone, it's still in vault.centos.org :-) > https://hub.docker.com/r/aneundorf/centos5-build-base/~/dockerfile/ > > Alex > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Fri Apr 6 05:49:16 2018 From: ewmailing at gmail.com (Eric Wing) Date: Fri, 6 Apr 2018 02:49:16 -0700 Subject: [CMake] How to build CMake so it works on an older Linux? In-Reply-To: References: <5AC5A482.1080800@hiroshima-u.ac.jp> Message-ID: On 4/5/18, Robert Maynard wrote: > The official CMake binaries do the same thing as you and build with a > static libstdc++ and libgcc. > As far as dependencies we use static builds of those too, with most > being the version provided inside CMake, and an external openssl. > > You can find the more information on the exact flags we are using at: > https://gitlab.kitware.com/cmake/cmake/blob/master/Utilities/Release/linux64_release.cmake > Thank you. From andrew.e.brownsword at gmail.com Sat Apr 7 11:32:53 2018 From: andrew.e.brownsword at gmail.com (Andrew Brownsword) Date: Sat, 7 Apr 2018 08:32:53 -0700 Subject: [CMake] Failure to build CMake 3.11.0 on ARMv7 Ubuntu 16.04 due to std::size undefined In-Reply-To: References: Message-ID: <7F8856AA-732D-4344-BDB6-5D3B903EECF6@gmail.com> I have managed to get CMake 3.11.0 to build by hacking the CLang-CXX file to specify -std=c++1y instead of 1z. With 1z the __cplusplus define is set to a 2017 date such that the CMake code presumes the existence of std::size, which isn?t actually defined in the headers I have (presumably because the system gcc is 5.4.0, circa C++14). Is there a proper way to specify the -std= to use when running the cmake bootstrap or make? > I am attempting to build the latest release of CMake on my ARM-based Ubuntu system. The bootstrap works fine, however the make fails with a bunch of error messages which all look like variations on this one: > > > In file included from /home/andrew/cmake/cmake-3.11.0/Source/cmCryptoHash.cxx:5: > /home/andrew/cmake/cmake-3.11.0/Source/cmAlgorithms.h:407:7: error: no member named 'size' in > namespace 'std'; did you mean 'std::seed_seq::size'? > using std::size; > ^~~~~~~~~ > std::seed_seq::size > > > > Looking at the source the compiler is checking the __cplusplus macro to see if it is 2017-something, and it apparently passes this test when I make CMake. If I just write a trivial program that prints this define, it outputs 201500L. The compiler in use is the system gcc compiler, version 5.4.0. I?ve tried it with the CLang 7.0 compiler I just built and get the same errors. > > Any suggestions? > From andrew.e.brownsword at gmail.com Sat Apr 7 12:46:56 2018 From: andrew.e.brownsword at gmail.com (Andrew Brownsword) Date: Sat, 7 Apr 2018 09:46:56 -0700 Subject: [CMake] find_package not finding Threads In-Reply-To: References: Message-ID: I updated to CMake 3.11.0, but still got the same error. I have gotten around the problem by removing the find_package and forcing -pthread on the C/C++ command line, however this is an unsatisfying resolution to the problem. > On Mar 30, 2018, at 12:06 PM, Andrew Brownsword wrote: > > I have an Ubuntu 16.04 ARMv7 system upon which I have built CLang 7.0 and am now trying to use it to build my CMake-based project that was previously working with the CLang 3.8.0 that I had installed via apt-get. The new compiler does appear to be selected correctly when I run cmake. The run fails when it tries this find_package call: > > set(THREADS_PREFER_PTHREAD_FLAG ON) > find_package(Threads REQUIRED) > > > With this error: > > CMake Error at /usr/local/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:137 (message): > Could NOT find Threads (missing: Threads_FOUND) > Call Stack (most recent call first): > /usr/local/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE) > /usr/local/share/cmake-3.8/Modules/FindThreads.cmake:212 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) > src/libraries/civetweb/CMakeLists.txt:8 (find_package) > > > > The libpthread.so resides in /usr/lib/arm-linux-gnueabihf/ on this system. I am *not* cross-compiling, and I built CLang on the system itself. I?ve looked at the REGEX that CMake is supposed to use to find this subdirectory and it looks correct (and it did work with CLang 3.8.0). > > Any suggestions? > > > > > > > The CMakeError.log file contains this: > > Determining if the pthread_create exist failed with the following output: > Change Dir: ~/CMakeFiles/CMakeTmp > > Run Build Command:"/usr/bin/make" "cmTC_1d4b8/fast" > /usr/bin/make -f CMakeFiles/cmTC_1d4b8.dir/build.make CMakeFiles/cmTC_1d4b8.dir/build > make[1]: Entering directory '~/CMakeFiles/CMakeTmp' > Building C object CMakeFiles/cmTC_1d4b8.dir/CheckSymbolExists.c.o > /usr/bin/clang -Wall -fno-strict-aliasing -o CMakeFiles/cmTC_1d4b8.dir/CheckSymbolExists.c.o -c ~/CMakeFiles/CMakeTmp/CheckSymbolExists.c > Linking C executable cmTC_1d4b8 > /usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_1d4b8.dir/link.txt --verbose=1 > /usr/bin/clang -Wall -fno-strict-aliasing CMakeFiles/cmTC_1d4b8.dir/CheckSymbolExists.c.o -o cmTC_1d4b8 > CMakeFiles/cmTC_1d4b8.dir/CheckSymbolExists.c.o: In function `main': > ~/CMakeFiles/CMakeTmp/CheckSymbolExists.c:(.text+0x4): undefined reference to `pthread_create' > ~/CMakeFiles/CMakeTmp/CheckSymbolExists.c:(.text+0x8): undefined reference to `pthread_create' > ~/CMakeFiles/CMakeTmp/CheckSymbolExists.c:(.text+0x24): undefined reference to `pthread_create' > ~/CMakeFiles/CMakeTmp/CheckSymbolExists.c:(.text+0x28): undefined reference to `pthread_create' > clang: error: linker command failed with exit code 1 (use -v to see invocation) > CMakeFiles/cmTC_1d4b8.dir/build.make:97: recipe for target 'cmTC_1d4b8' failed > make[1]: *** [cmTC_1d4b8] Error 1 > make[1]: Leaving directory '~/CMakeFiles/CMakeTmp' > Makefile:126: recipe for target 'cmTC_1d4b8/fast' failed > make: *** [cmTC_1d4b8/fast] Error 2 > > File ~/CMakeFiles/CMakeTmp/CheckSymbolExists.c: > /* */ > #include > > int main(int argc, char** argv) > { > (void)argv; > #ifndef pthread_create > return ((int*)(&pthread_create))[argc]; > #else > (void)argc; > return 0; > #endif > } > > Determining if the function pthread_create exists in the pthreads failed with the following output: > Change Dir: ~/CMakeFiles/CMakeTmp > > Run Build Command:"/usr/bin/make" "cmTC_81507/fast" > /usr/bin/make -f CMakeFiles/cmTC_81507.dir/build.make CMakeFiles/cmTC_81507.dir/build > make[1]: Entering directory '~/CMakeFiles/CMakeTmp' > Building C object CMakeFiles/cmTC_81507.dir/CheckFunctionExists.c.o > /usr/bin/clang -Wall -fno-strict-aliasing -DCHECK_FUNCTION_EXISTS=pthread_create -o CMakeFiles/cmTC_81507.dir/CheckFunctionExists.c.o -c /usr/local/share/cmake-3.8/Modules/CheckFunctionExists.c > Linking C executable cmTC_81507 > /usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_81507.dir/link.txt --verbose=1 > /usr/bin/clang -Wall -fno-strict-aliasing -DCHECK_FUNCTION_EXISTS=pthread_create CMakeFiles/cmTC_81507.dir/CheckFunctionExists.c.o -o cmTC_81507 -lpthreads > /usr/bin/ld: cannot find -lpthreads > clang: error: linker command failed with exit code 1 (use -v to see invocation) > CMakeFiles/cmTC_81507.dir/build.make:97: recipe for target 'cmTC_81507' failed > make[1]: *** [cmTC_81507] Error 1 > make[1]: Leaving directory '~/CMakeFiles/CMakeTmp' > Makefile:126: recipe for target 'cmTC_81507/fast' failed > make: *** [cmTC_81507/fast] Error 2 > > > Determining if the include file pthread.h exists failed with the following output: > Change Dir: ~/CMakeFiles/CMakeTmp > > Run Build Command:"/usr/bin/make" "cmTC_83cc7/fast" > /usr/bin/make -f CMakeFiles/cmTC_83cc7.dir/build.make CMakeFiles/cmTC_83cc7.dir/build > make[1]: Entering directory '~/CMakeFiles/CMakeTmp' > Building C object CMakeFiles/cmTC_83cc7.dir/CheckIncludeFile.c.o > /usr/local/bin/clang -Wall -fno-strict-aliasing -o CMakeFiles/cmTC_83cc7.dir/CheckIncludeFile.c.o -c ~/CMakeFiles/CMakeTmp/CheckIncludeFile.c > In file included from ~/CMakeFiles/CMakeTmp/CheckIncludeFile.c:1: > In file included from /usr/include/pthread.h:23: > /usr/include/sched.h:28:10: fatal error: 'stddef.h' file not found > #include > ^~~~~~~~~~ > 1 error generated. > CMakeFiles/cmTC_83cc7.dir/build.make:65: recipe for target 'CMakeFiles/cmTC_83cc7.dir/CheckIncludeFile.c.o' failed > make[1]: *** [CMakeFiles/cmTC_83cc7.dir/CheckIncludeFile.c.o] Error 1 > make[1]: Leaving directory '~/CMakeFiles/CMakeTmp' > Makefile:126: recipe for target 'cmTC_83cc7/fast' failed > make: *** [cmTC_83cc7/fast] Error 2 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfsworks at gmail.com Sat Apr 7 17:35:05 2018 From: cfsworks at gmail.com (Sam Edwards) Date: Sat, 7 Apr 2018 15:35:05 -0600 Subject: [CMake] Generator expression for "is in list"? Message-ID: Hello list! I'm trying to write a generator expression that only evaluates if my target is directly (not transitively) linked into the consuming target. I figured the easiest way to do that would be to test if the target's name appears in $, however I'm not seeing a generator expression for substring or "string in list" tests. What is the preferred way to accomplish this? Best, Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at sap.com Mon Apr 9 03:00:19 2018 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Mon, 9 Apr 2018 07:00:19 +0000 Subject: [CMake] Generator expression for "is in list"? In-Reply-To: References: Message-ID: Operator IN_LIST in generator expressions will be available in CMake version 3.12, (i.e. the next version). In the meantime, I am afraid there is no solution in the context of generator expressions. However, you can directly use the contents of the property in your CMakeLists.txt. Example: get_property (link_libs TARGET mytarget PROPERTY LINK_LIBRARIES) if (?mylib? IN_LIST link_libs) ? endif() The only difference is the evaluation time: * Generator expressions are evaluated after all CMakeLists.txt processing, so any changes to the target done AFTER the use of $ will be taken into account. * Using get_property: evaluation is done at the point where the command is used, so any changes done AFTER will NOT be taken into account From: CMake on behalf of Sam Edwards Date: Saturday 7 April 2018 at 23:35 To: "cmake at cmake.org" Subject: [CMake] Generator expression for "is in list"? Hello list! I'm trying to write a generator expression that only evaluates if my target is directly (not transitively) linked into the consuming target. I figured the easiest way to do that would be to test if the target's name appears in $, however I'm not seeing a generator expression for substring or "string in list" tests. What is the preferred way to accomplish this? Best, Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: From nolange79 at gmail.com Mon Apr 9 10:00:16 2018 From: nolange79 at gmail.com (Norbert Lange) Date: Mon, 9 Apr 2018 16:00:16 +0200 Subject: [CMake] CMake import targets, recommended Naming scheme and static/shared libraries Message-ID: Hello, I would like to add support for some software components, that have not been compiled with CMake. There are 2 options, either write a Find script or generate configs. Later option would be more robust, as substantial changes could be ironed out when the config is version-specific. *) Import Name scheme CMake seems to prefer CamelCase for their inbuilt find modules, but this is troublesome, as usually libraries are lowercase. eg.: add_library(foo SHARED) install(TARGETS foo EXPORT foo-targets LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} COMPONENT foo ) install(EXPORT foo-targets "${CMAKE_INSTALL_LIBDIR}/cmake" NAMESPACE Foo:: ) would result in Foo::foo. Not ideal, from the standpoint of using the CMake automatisms, lowercase ("library-case") would be best. *) Static + Shared libraries often both are available. is there a recommended suffix (prefix), and would static and non-static versions be the same COMPONENT or a different one? add_library(foo-static STATIC) install(TARGETS foo-static EXPORT foo-targets ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR} COMPONENT foo-static ) install(EXPORT foo-targets "${CMAKE_INSTALL_LIBDIR}/cmake" NAMESPACE Foo:: ) So is there any resource describing and weighting these options? CMake doesnt seem to be particularly well equipped to allow a choice between static/shared dependencies. Norbert From sin.pecado at gmail.com Mon Apr 9 11:24:37 2018 From: sin.pecado at gmail.com (=?UTF-8?B?U3ppbMOhcmQgUMOhbGw=?=) Date: Mon, 9 Apr 2018 17:24:37 +0200 Subject: [CMake] passing a URL to cmake on the command line Message-ID: Hi, I'm trying to pass a URL (that's used in ExternalProject_Add), and I'm having trouble convincing bash + cmake to cooperate. No matter what I've done, one fo the "/" gets dropped from "http://". Any ideas how can I construct an invocation similar to the one below that will actually work? cmake . -DMY_CUSTOM_URL='http://my-server.com/foobar.tar.gz' Thanks, -- Szil?rd From haocheng.liu at kitware.com Mon Apr 9 11:44:07 2018 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Mon, 9 Apr 2018 11:44:07 -0400 Subject: [CMake] passing a URL to cmake on the command line In-Reply-To: References: Message-ID: Hi Szilard, I tried it in CMake 3.10 and it works fine(No slash is dropped). Which version of CMake are you using? On Mon, Apr 9, 2018 at 11:24 AM, Szil?rd P?ll wrote: > Hi, > > I'm trying to pass a URL (that's used in ExternalProject_Add), and I'm > having trouble convincing bash + cmake to cooperate. No matter what > I've done, one fo the "/" gets dropped from "http://". > > Any ideas how can I construct an invocation similar to the one below > that will actually work? > > cmake . -DMY_CUSTOM_URL='http://my-server.com/foobar.tar.gz' > > > Thanks, > -- > Szil?rd > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zbeekman at gmail.com Mon Apr 9 12:12:38 2018 From: zbeekman at gmail.com (Zaak Beekman) Date: Mon, 09 Apr 2018 16:12:38 +0000 Subject: [CMake] Transitive linker flags Message-ID: Hi, I'm defining a static library target and, conditionally, when on windows, I need to pass a whole bunch of windows system libraries and tell Visual Studio that any target linking against this static library should pass additional linker flags ( `\NODEFAULTLIB:libcd \INCREMENTAL:NO` ). I tried setting the LINKER_FLAGS property on the target with + set_property(TARGET ECI_C + PROPERTY + APPEND + LINK_FLAGS "${prefix}NODEFAULTLIB${colon}\"libcd\"") + set_property(TARGET ECI_C + PROPERTY + APPEND + LINK_FLAGS "${prefix}INCREMENTAL${colon}NO") however, these flags did not seem to get transitively propagated to the executable linking against this ECI_C static library. Am I doing something wrong, or should I just specify the flags through the `target_link_libraries( ECI_C INTERFACE FLAG1 FLAG2 )` command? What's the "right"/canonical way to do this? Also, I'm extremely new to developing on Windows with MSVS, and I'm writing CMake files to generate visual studio projects to more or less match some that have been manually written. Without ignoring the `libcd` library I get linker errors like error LNK2019: unresolved external symbol __imp_fopen Which seems strange that I should have to ignore the standard C debug library to fix. Without the `\INCREMENTAL:NO` flag I get warnings like warning LNK4217: locally defined symbol malloc imported in function inittask Are the manually written VS solution files or source code that I've inherited doing something silly that requires these MSVS linker flags to be set? It feels like this, along with the sheer quantity of system libraries that are being passed to the linker may be a bit of a cludge. I'm wondering, if it's worth spending my limited time investigating this further or is this expected/common-practice/acceptable usage? Thanks, Zaak Izaak "Zaak" Beekman ------------------------------------------------------------------------------- HPC Scientist ParaTools Inc. 1509 16th St, NW Washington, DC 20036 mobile: (917) 797-3239 ------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From sin.pecado at gmail.com Mon Apr 9 12:26:17 2018 From: sin.pecado at gmail.com (=?UTF-8?B?U3ppbMOhcmQgUMOhbGw=?=) Date: Mon, 9 Apr 2018 18:26:17 +0200 Subject: [CMake] passing a URL to cmake on the command line In-Reply-To: References: Message-ID: Hi, My bad, looks like we had an offending line in our CMake scripts, something like set(MY_URL "http://default-url.com/foobar.tar.gz" CACHE PATH "URL from where to download") The PATH type seems to have caused the issue rather than the mechanism of passing the URL to on the bash command line to cmake. Thanks for the quick feedback! Cheers, -- Szil?rd On Mon, Apr 9, 2018 at 5:44 PM, Haocheng Liu wrote: > Hi Szilard, > > I tried it in CMake 3.10 and it works fine(No slash is dropped). Which > version of CMake are you using? > > On Mon, Apr 9, 2018 at 11:24 AM, Szil?rd P?ll wrote: >> >> Hi, >> >> I'm trying to pass a URL (that's used in ExternalProject_Add), and I'm >> having trouble convincing bash + cmake to cooperate. No matter what >> I've done, one fo the "/" gets dropped from "http://". >> >> Any ideas how can I construct an invocation similar to the one below >> that will actually work? >> >> cmake . -DMY_CUSTOM_URL='http://my-server.com/foobar.tar.gz' >> >> >> Thanks, >> -- >> Szil?rd >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake > > > > > -- > Best regards > Haocheng > > Haocheng LIU > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4421 From saadrustam at gmail.com Mon Apr 9 21:56:03 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Tue, 10 Apr 2018 01:56:03 +0000 Subject: [CMake] Can find_package(...) distinguish between debug and release installs? Message-ID: Hi, When find_package(LibA) sets the LibA_FOUND variable, is it possible to know if the package found is the Debug or Release build (or both)? I have a fairly complex build setup where I need to be able to distinguish if find_package(LibA) found a Debug or Release build. - Saad -------------- next part -------------- An HTML attachment was scrubbed... URL: From bo.schwarzstein at gmail.com Mon Apr 9 23:02:39 2018 From: bo.schwarzstein at gmail.com (Bo Zhou) Date: Tue, 10 Apr 2018 12:02:39 +0900 Subject: [CMake] Can find_package(...) distinguish between debug and release installs? In-Reply-To: References: Message-ID: Hi, Generally speaking, no, you might have to use the suffix or special name to distinguish the different library, such as with the "_d" suffix. The Boost module of CMake is a considerable example, since it could generate different names for Debug and Release libraries on Windows. At POSIX(UNIX, OSX, Linux), sometimes user mixes the library, it still works well. On Windows, it's dangerous or even won't work with mixed libraries which were built by different Visual Studios with different runtime libraries. Cheers. On Tue, Apr 10, 2018 at 10:56 AM, Saad Khattak wrote: > Hi, > > When find_package(LibA) sets the LibA_FOUND variable, is it possible to > know if the package found is the Debug or Release build (or both)? I have a > fairly complex build setup where I need to be able to distinguish if > find_package(LibA) found a Debug or Release build. > > - Saad > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Tue Apr 10 08:59:15 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Tue, 10 Apr 2018 12:59:15 +0000 Subject: [CMake] Can find_package(...) distinguish between debug and release installs? In-Reply-To: References: Message-ID: Thanks Bo. I have added the suffix to my libraries already, however with some 3rd party libraries that I am getting with FetchContent, I have no control over how they name their libraries. Now, their Config.cmake files have release targets that are globbed by one of the CMake config files (which is part of the install process). So CMake 'can' figure out which configuration has been installed and I was hoping that there was a built-in way to distinguish that rather than me writing some custom scripts for it (where the scripts will search for the debug/release target files). On Mon, Apr 9, 2018 at 11:03 PM Bo Zhou wrote: > Hi, > > Generally speaking, no, you might have to use the suffix or special name > to distinguish the different library, such as with the "_d" suffix. > > The Boost module of CMake is a considerable example, since it could > generate different names for Debug and Release libraries on Windows. > > At POSIX(UNIX, OSX, Linux), sometimes user mixes the library, it still > works well. On Windows, it's dangerous or even won't work with mixed > libraries which were built by different Visual Studios with different > runtime libraries. > > Cheers. > > On Tue, Apr 10, 2018 at 10:56 AM, Saad Khattak > wrote: > >> Hi, >> >> When find_package(LibA) sets the LibA_FOUND variable, is it possible to >> know if the package found is the Debug or Release build (or both)? I have a >> fairly complex build setup where I need to be able to distinguish if >> find_package(LibA) found a Debug or Release build. >> >> - Saad >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Tue Apr 10 09:07:56 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Tue, 10 Apr 2018 13:07:56 +0000 Subject: [CMake] FetchContent and find_package Message-ID: Hi, My project is setup in such a way that I perform a FetchContent 'only if' my find_package fails. This works very well until I start building different configurations. Let's say I generate and build Debug for my project. My project tries to find_package(LibA QUIET) and cannot find it. So, it performs a FetchContent(...) step, builds the dependency and my library and installs everything. This works flawlessly. Now I start building a Release version with different build and install folders. Unfortunately, find_package(LibA QUIET) finds the Debug libraries and does not perform a FetchContent(...) step and in turn doesn't build the Release version of the dependent library. Consequently, the linking step fails. Is there an easy way around this issue? I say 'easy' because I could write some CMake scripts to search for the libraries after a successful find_package(...) and if it only finds libraries for Debug when it really wants Release, it performs a FetchContent(...). However, this could be quite fragile. It would be nice if CMake has a way of knowing if an installed library, found through find_package(...) is Debug, Release, RelWithDebInfo etc. - Saad -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Tue Apr 10 10:23:54 2018 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 11 Apr 2018 00:23:54 +1000 Subject: [CMake] FetchContent and find_package In-Reply-To: References: Message-ID: On Tue, Apr 10, 2018 at 11:07 PM, Saad Khattak wrote: > Hi, > > My project is setup in such a way that I perform a FetchContent 'only if' > my find_package fails. > > This works very well until I start building different configurations. > Let's say I generate and build Debug for my project. My project tries to > find_package(LibA QUIET) and cannot find it. So, it performs a > FetchContent(...) step, builds the dependency and my library and installs > everything. This works flawlessly. > > Now I start building a Release version with different build and install > folders. Unfortunately, find_package(LibA QUIET) finds the Debug libraries > and does not perform a FetchContent(...) step and in turn doesn't build the > Release version of the dependent library. Consequently, the linking step > fails. > > Is there an easy way around this issue? > > I say 'easy' because I could write some CMake scripts to search for the > libraries after a successful find_package(...) and if it only finds > libraries for Debug when it really wants Release, it performs a > FetchContent(...). However, this could be quite fragile. > > It would be nice if CMake has a way of knowing if an installed library, > found through find_package(...) is Debug, Release, RelWithDebInfo etc. > If the package found by find_package() is picking up a config file generated by CMake, then you can check the IMPORTED_CONFIGURATIONS property of its imported target(s). This will give you a list of configurations the package provides. Ideally, a single package should cover all relevant build types, not one package per build type. This is up to the project itself though and how it builds/installs its package. If the found package only provides variables instead of imported targets, then you'll have to work harder and go through whatever variables it provides to see if you can work out what the package can give you. Imported targets are definitely more preferable though. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Tue Apr 10 12:28:33 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Tue, 10 Apr 2018 16:28:33 +0000 Subject: [CMake] FetchContent and find_package In-Reply-To: References: Message-ID: Thank you Craig. >> Imported targets are definitely more preferable though Can you please elaborate on this? On Tue, Apr 10, 2018 at 10:23 AM Craig Scott wrote: > > On Tue, Apr 10, 2018 at 11:07 PM, Saad Khattak > wrote: > >> Hi, >> >> My project is setup in such a way that I perform a FetchContent 'only if' >> my find_package fails. >> >> This works very well until I start building different configurations. >> Let's say I generate and build Debug for my project. My project tries to >> find_package(LibA QUIET) and cannot find it. So, it performs a >> FetchContent(...) step, builds the dependency and my library and installs >> everything. This works flawlessly. >> >> Now I start building a Release version with different build and install >> folders. Unfortunately, find_package(LibA QUIET) finds the Debug libraries >> and does not perform a FetchContent(...) step and in turn doesn't build the >> Release version of the dependent library. Consequently, the linking step >> fails. >> >> Is there an easy way around this issue? >> >> I say 'easy' because I could write some CMake scripts to search for the >> libraries after a successful find_package(...) and if it only finds >> libraries for Debug when it really wants Release, it performs a >> FetchContent(...). However, this could be quite fragile. >> >> It would be nice if CMake has a way of knowing if an installed library, >> found through find_package(...) is Debug, Release, RelWithDebInfo etc. >> > > If the package found by find_package() is picking up a config file > generated by CMake, then you can check the IMPORTED_CONFIGURATIONS property > of its imported target(s). This will give you a list of configurations the > package provides. Ideally, a single package should cover all relevant build > types, not one package per build type. This is up to the project itself > though and how it builds/installs its package. If the found package only > provides variables instead of imported targets, then you'll have to work > harder and go through whatever variables it provides to see if you can work > out what the package can give you. Imported targets are definitely more > preferable though. > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From esinowitz at bloomberg.net Tue Apr 10 13:50:13 2018 From: esinowitz at bloomberg.net (Ephi Sinowitz (BLOOMBERG/ 919 3RD A)) Date: Tue, 10 Apr 2018 17:50:13 -0000 Subject: [CMake] =?utf-8?q?Order_of_IMPORTED_target_include_directories?= Message-ID: <5ACCF955021C06DA00390820_0_79932@msllnjpmsgsv06> Hi, I would like to ensure that all include directories propagated from IMPORTED targets come after the include directories propagated from non-imported targets. On gcc the includes from IMPORTED targets are marked with -isystem which effectively moves these directories to the end of the include search path. Unfortunately not all compilers have an analagous compiler switch. Is there something else I can do to get the imported targets includes moved to the end? Thanks -ephi -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Tue Apr 10 17:37:17 2018 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 11 Apr 2018 07:37:17 +1000 Subject: [CMake] FetchContent and find_package In-Reply-To: References: Message-ID: On Wed, Apr 11, 2018 at 2:28 AM, Saad Khattak wrote: > Thank you Craig. > > >> Imported targets are definitely more preferable though > > Can you please elaborate on this? > Variables are the old way of passing details about a target to a consuming target. It was customary to provide one variable listing the library that consuming projects would link to, then another variable would provide header search paths, maybe yet another for compiler defines, and so on. This is fragile and doesn't provide transitive dependencies (also sometimes called usage requirements), so the consuming project may then have to work out what other libraries it had to link to as well, what other header search paths it might need and so on. Imported targets address all of those problems. They act just like a regular target in the sense that they support usage requirements, so anything that links to them also gets the information about what other libraries to link against, what header search paths to add, etc. CMake automatically uses those details to augment the necessary command lines without you having to do anything. Basically you just link against the imported target and that's job done from the project's perspective. Much more robust, way easier to use. > On Tue, Apr 10, 2018 at 10:23 AM Craig Scott > wrote: > >> >> On Tue, Apr 10, 2018 at 11:07 PM, Saad Khattak >> wrote: >> >>> Hi, >>> >>> My project is setup in such a way that I perform a FetchContent 'only >>> if' my find_package fails. >>> >>> This works very well until I start building different configurations. >>> Let's say I generate and build Debug for my project. My project tries to >>> find_package(LibA QUIET) and cannot find it. So, it performs a >>> FetchContent(...) step, builds the dependency and my library and installs >>> everything. This works flawlessly. >>> >>> Now I start building a Release version with different build and install >>> folders. Unfortunately, find_package(LibA QUIET) finds the Debug libraries >>> and does not perform a FetchContent(...) step and in turn doesn't build the >>> Release version of the dependent library. Consequently, the linking step >>> fails. >>> >>> Is there an easy way around this issue? >>> >>> I say 'easy' because I could write some CMake scripts to search for the >>> libraries after a successful find_package(...) and if it only finds >>> libraries for Debug when it really wants Release, it performs a >>> FetchContent(...). However, this could be quite fragile. >>> >>> It would be nice if CMake has a way of knowing if an installed library, >>> found through find_package(...) is Debug, Release, RelWithDebInfo etc. >>> >> >> If the package found by find_package() is picking up a config file >> generated by CMake, then you can check the IMPORTED_CONFIGURATIONS property >> of its imported target(s). This will give you a list of configurations the >> package provides. Ideally, a single package should cover all relevant build >> types, not one package per build type. This is up to the project itself >> though and how it builds/installs its package. If the found package only >> provides variables instead of imported targets, then you'll have to work >> harder and go through whatever variables it provides to see if you can work >> out what the package can give you. Imported targets are definitely more >> preferable though. >> > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tiagomacarios at gmail.com Tue Apr 10 18:23:16 2018 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Tue, 10 Apr 2018 15:23:16 -0700 Subject: [CMake] use analyze with visual studio Message-ID: I am trying to pass the analyze flags to cl.exe, but I cannot figure out how to get it working, example: cmake_minimum_required (VERSION 2.8.11) set (CMAKE_VERBOSE_MAKEFILE ON) project (cppcore) add_executable (const const.cpp) target_compile_options (const analyze -analyze:plugin EspXEngine.dll) how to have cmake to respect that last line? I tried adding quotes, but that seems not to work -------------- next part -------------- An HTML attachment was scrubbed... URL: From bo.schwarzstein at gmail.com Tue Apr 10 21:10:00 2018 From: bo.schwarzstein at gmail.com (Bo Zhou) Date: Wed, 11 Apr 2018 10:10:00 +0900 Subject: [CMake] Can find_package(...) distinguish between debug and release installs? In-Reply-To: References: Message-ID: Hi, Since you're using FetchContent/ExternalProject_Add, you could create a special stage installation folder for those external projects, organize them by different configurations, for example. 3rdParty/Debug/zlib/include+lib 3rdParty/Release/zlib/include+lib So with this way, the name from the external libraries is not that important, we just take care the specific name for specific platform. >From the project needs these libraries, you could set the XXX_ROOT to tell CMake built-in module where to locate the dependency, or locate the include folder and library manually for the different configurations, it would work for both VisualStudio-based project and GCC/Clang projects. Good luck. On Tue, Apr 10, 2018 at 9:59 PM, Saad Khattak wrote: > Thanks Bo. > > I have added the suffix to my libraries already, however with some 3rd > party libraries that I am getting with FetchContent, I have no control over > how they name their libraries. > > Now, their Config.cmake files have release targets that are > globbed by one of the CMake config files (which is part of the install > process). So CMake 'can' figure out which configuration has been installed > and I was hoping that there was a built-in way to distinguish that rather > than me writing some custom scripts for it (where the scripts will search > for the debug/release target files). > > On Mon, Apr 9, 2018 at 11:03 PM Bo Zhou wrote: > >> Hi, >> >> Generally speaking, no, you might have to use the suffix or special name >> to distinguish the different library, such as with the "_d" suffix. >> >> The Boost module of CMake is a considerable example, since it could >> generate different names for Debug and Release libraries on Windows. >> >> At POSIX(UNIX, OSX, Linux), sometimes user mixes the library, it still >> works well. On Windows, it's dangerous or even won't work with mixed >> libraries which were built by different Visual Studios with different >> runtime libraries. >> >> Cheers. >> >> On Tue, Apr 10, 2018 at 10:56 AM, Saad Khattak >> wrote: >> >>> Hi, >>> >>> When find_package(LibA) sets the LibA_FOUND variable, is it possible to >>> know if the package found is the Debug or Release build (or both)? I have a >>> fairly complex build setup where I need to be able to distinguish if >>> find_package(LibA) found a Debug or Release build. >>> >>> - Saad >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/ >>> opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> https://cmake.org/mailman/listinfo/cmake >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Wed Apr 11 03:29:16 2018 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 11 Apr 2018 09:29:16 +0200 Subject: [CMake] use analyze with visual studio In-Reply-To: References: Message-ID: Hi, I've never used the CL feature, but as far as CMake syntax is concerned, I believe you're looking for this: target_compile_options(const PRIVATE /analyze /analyze:plugin EspXEngine.dll) Petr On 11 April 2018 at 00:23, Tiago Macarios wrote: > I am trying to pass the analyze flags to cl.exe, but I cannot figure out > how to get it working, example: > > cmake_minimum_required (VERSION 2.8.11) > set (CMAKE_VERBOSE_MAKEFILE ON) > project (cppcore) > add_executable (const const.cpp) > target_compile_options (const analyze -analyze:plugin EspXEngine.dll) > > how to have cmake to respect that last line? I tried adding quotes, but > that seems not to work > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From borous at gmail.com Wed Apr 11 09:24:42 2018 From: borous at gmail.com (Ales Borovicka) Date: Wed, 11 Apr 2018 15:24:42 +0200 Subject: [CMake] Custom platform with MSVC Message-ID: Hi, I am having issues after upgrading cmake to 3.10.2. We have a custom platform that does require to set properties in vcxproj like: $(PLATFORM_SDK_ROOT) For regular projects we set this through user files, so it works for the generated projects. (it worked with cmake 3.7.0) Now in the new cmake version when I generate a project with VS 14 generator selected it fails, because I have enabled the languages C/C++. The problem is, that cmake does try to build a project to determine the toolset (calling FindVCTargetsPath). This does generate a project VCTargetsPath.vcxproj which is not compile-able for the custom platform since the properties required for that platform are not defined and there is no way how to set them. Please what can I do here to disable the toolset check or get around it? Thanks a lot, Ales -------------- next part -------------- An HTML attachment was scrubbed... URL: From somux at freemail.hu Wed Apr 11 10:36:38 2018 From: somux at freemail.hu (Somux) Date: Wed, 11 Apr 2018 16:36:38 +0200 (CEST) Subject: [CMake] Dependencies scanning for non-c/c++ files Message-ID: Hi, I ran into a CMake problem and I found a very informative answer at https://cmake.org/pipermail/cmake/2011-April/043758.html. Still, 7 years has passed. Is any easier solution for dependency scanning for an proprietary language? BR, SoMux From brad.king at kitware.com Wed Apr 11 13:12:45 2018 From: brad.king at kitware.com (Brad King) Date: Wed, 11 Apr 2018 13:12:45 -0400 Subject: [CMake] Custom platform with MSVC In-Reply-To: References: Message-ID: On 04/11/2018 09:24 AM, Ales Borovicka wrote: > We have a custom platform that does require to set properties in vcxproj like: > $(PLATFORM_SDK_ROOT) > > For regular projects we set this through user files, so it works for the > generated projects. (it worked with cmake 3.7.0) We don't currently support that officially. CMake generates temporary project files in several places, e.g. try_compile, that would not get user-set properties from the project code. In order to support a custom platform SDK CMake would need to be taught a corresponding abstraction. The VS generators already support similar abstractions: * CMAKE_GENERATOR_TOOLSET = v141 or some other toolset * CMAKE_GENERATOR_PLATFORM = Win32, x64, etc. * CMAKE_GENERATOR_INSTANCE = Which VS 2017 to use on local machine All of these affect the way .vcxproj files are generated. If a .vcxproj file needs an additional field for MSBuild to be able to find the SDK then a similar abstraction will be needed. I'd need to understand the use case better before recommending an approach to such an abstraction. -Brad From zbeekman at gmail.com Wed Apr 11 13:44:44 2018 From: zbeekman at gmail.com (Zaak Beekman) Date: Wed, 11 Apr 2018 17:44:44 +0000 Subject: [CMake] CMake 3.11 Fortran submodule parallel compilation fails for a single target Message-ID: I thought that CMake had Fortran submodule support as of 3.8 or 3.10. However, when compiling a single library target with submodules in parallel on macOS with GFortran trunk (or GFortran 7.3) I get: f951: Fatal Error: Module file 'mylib.smod' has not been generated, either because the module does not contain a MODULE PROCEDURE or there is an error in the module. Compilation terminated make[2]: *** [src/MyLib/CMakeFiles/MyLib.dir/MyLib_implementation.f90.o] Error 1 So it seems that CMake is not generating a Makefile in such a way that it requires MyLib_interface.f90 containing the interface top level module mylib.mod to be processed/compiled *before* MyLib_interface.f90. Because of this, there is no mylib.mod file generated from MyLib_interface.f90 before MyLib_implementation.f90 is compiled. Am I missing something? Is there a way to express this dependency in such a way that CMake will generate a make file that ensures the source files are processed in the correct order, even with `make -j`? Thanks, Zaak Izaak "Zaak" Beekman ------------------------------------------------------------------------------- HPC Scientist ParaTools Inc. 1509 16th St, NW Washington, DC 20036 mobile: (917) 797-3239 ------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From esinowitz at bloomberg.net Thu Apr 12 08:22:07 2018 From: esinowitz at bloomberg.net (Ephi Sinowitz (BLOOMBERG/ 919 3RD A)) Date: Thu, 12 Apr 2018 12:22:07 -0000 Subject: [CMake] =?utf-8?q?Ninja_Fortran_on_XL?= Message-ID: <5ACF4F6F0298014C00F50443_0_921356@msclnjpmsgsv04> Trying to get this to work by setting a proper CMAKE_Fortran_PREPROCESS_SOURCE variable. Here is GNU_Fortran for reference. set(CMAKE_Fortran_PREPROCESS_SOURCE " -cpp -E -o ") The analogous switch for -E in XL is -d -qnoobject. However, CMake expects the PREPROCESSED_SOURCE output to be in the form -pp.f and XL does not allow you to control that. The output is always of the form F.f Is there anything I can do here like putting redirection or two commands inside the CMAKE_Fortran_PREPROCESS_SOURCE variable? Here is a relevant snippet from the XL compiler documentation on this switch. ?To call cpp for a particular file, use a file suffix of .F, .F77, .F90, .F95, .F03, or .F08. If you specify the -d option, each .F* file filename.F* is preprocessed into an intermediate file Ffilename.f, which is then compiled. ... If you only want to preprocess and do not want to produce object or executable files, specify the -qnoobject option also.? -ephi -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Apr 12 09:22:25 2018 From: brad.king at kitware.com (Brad King) Date: Thu, 12 Apr 2018 09:22:25 -0400 Subject: [CMake] CMake 3.11 Fortran submodule parallel compilation fails for a single target In-Reply-To: References: Message-ID: <861da411-5deb-3b53-0d1d-99e85907eefb@kitware.com> On 04/11/2018 01:44 PM, Zaak Beekman wrote: > I thought that CMake had Fortran submodule support as of 3.8 or 3.10. CMake 3.7 added support to the Fortran dependency scanner to tolerate the *syntax* of submodules. Only the main modules are handled for dependencies though. Unfortunately we still don't support the actual `.smod` dependencies. See also: https://gitlab.kitware.com/cmake/cmake/issues/17017 -Brad From zbeekman at gmail.com Thu Apr 12 09:37:26 2018 From: zbeekman at gmail.com (Zaak Beekman) Date: Thu, 12 Apr 2018 13:37:26 +0000 Subject: [CMake] CMake 3.11 Fortran submodule parallel compilation fails for a single target In-Reply-To: <861da411-5deb-3b53-0d1d-99e85907eefb@kitware.com> References: <861da411-5deb-3b53-0d1d-99e85907eefb@kitware.com> Message-ID: Just FYI. I found an OK work around in that issue. On Thu, Apr 12, 2018 at 9:22 AM Brad King wrote: > On 04/11/2018 01:44 PM, Zaak Beekman wrote: > > I thought that CMake had Fortran submodule support as of 3.8 or 3.10. > > CMake 3.7 added support to the Fortran dependency scanner to tolerate > the *syntax* of submodules. Only the main modules are handled for > dependencies though. > > Unfortunately we still don't support the actual `.smod` dependencies. > See also: > > https://gitlab.kitware.com/cmake/cmake/issues/17017 > > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Apr 12 09:42:55 2018 From: brad.king at kitware.com (Brad King) Date: Thu, 12 Apr 2018 09:42:55 -0400 Subject: [CMake] Ninja Fortran on XL In-Reply-To: <5ACF4F6F0298014C00F50443_0_921356@msclnjpmsgsv04> References: <5ACF4F6F0298014C00F50443_0_921356@msclnjpmsgsv04> Message-ID: <1456e042-2ad1-42bd-a249-38c115e72002@kitware.com> On 04/12/2018 08:22 AM, Ephi Sinowitz (BLOOMBERG/ 919 3RD A) wrote: > CMake expects the PREPROCESSED_SOURCE output to be in the form > -pp.f and XL does not allow you to control that. The output> is always of the form F.f > > Is there anything I can do here like putting redirection or two > commands inside the CMAKE_Fortran_PREPROCESS_SOURCE variable? One can put two commands, e.g. something like: ``` set(CMAKE_Fortran_PREPROCESS_SOURCE " ... -d -qnoobject " "mv " ) ``` Filling in `` may be difficult. I've observed: * `/path/to/foo.F` ==> `./Ffoo.f` * `/path/to/foo.F90` ==> `./Ffoo.f90` CMake would need to be taught to produce a `` for this value, and it would need to know the mapping that xlf uses for extensions. Does xlf have a way to control in what directory the file is placed? -Brad From brad.king at kitware.com Thu Apr 12 11:52:51 2018 From: brad.king at kitware.com (Brad King) Date: Thu, 12 Apr 2018 11:52:51 -0400 Subject: [CMake] .d dependency files for ninja In-Reply-To: <589B881801F60778003907FC_0_99979@msllnjpmsgsv06> References: <589B881801F60778003907FC_0_99979@msllnjpmsgsv06> Message-ID: <8ee58983-4fb1-5b4c-5775-38bd0b649ba0@kitware.com> On 02/08/2017 04:05 PM, Ephi Sinowitz (BLOOMBERG/ 731 LEX) wrote: > cmake creates these files for gcc compiler using the -MMD -MMF > compiler flags but does not do so for AIX xlc and Sun CC > Is this a known issue? Is there a workaround? This simply means no one has added support for these compilers. Ninja requires the compiler to support depfile generation. CMake's Modules/Compiler/*.cmake modules set CMAKE_DEPFILE_FLAGS_ variables to record the flags for each compiler. -Brad From brad.king at kitware.com Thu Apr 12 11:58:33 2018 From: brad.king at kitware.com (Brad King) Date: Thu, 12 Apr 2018 11:58:33 -0400 Subject: [CMake] Order of IMPORTED target include directories In-Reply-To: <5ACCF955021C06DA00390820_0_79932@msllnjpmsgsv06> References: <5ACCF955021C06DA00390820_0_79932@msllnjpmsgsv06> Message-ID: <892c276c-a223-8ee8-9bc3-50c2502a4ba3@kitware.com> On 04/10/2018 01:50 PM, Ephi Sinowitz (BLOOMBERG/ 919 3RD A) wrote: > I would like to ensure that all include directories propagated from > IMPORTED targets come after the include directories propagated from > non-imported targets. On gcc the includes from IMPORTED targets are > marked with -isystem which effectively moves these directories to the > end of the include search path. Unfortunately not all compilers have > an analagous compiler switch. Is there something else I can do to get > the imported targets includes moved to the end? CMake would have to be taught how to change the order during generation. It would make sense to do that even for compilers that do not have -isystem since that would make the directory ordering consistent with compilers that do have -isystem. If you want to work on this, look at IsSystemIncludeDirectory and its call sites. -Brad From esinowitz at bloomberg.net Thu Apr 12 15:06:35 2018 From: esinowitz at bloomberg.net (Ephi Sinowitz (BLOOMBERG/ 919 3RD A)) Date: Thu, 12 Apr 2018 19:06:35 -0000 Subject: [CMake] =?utf-8?q?Ninja_Fortran_on_XL?= Message-ID: <5ACFAE3B0215052200390868_0_79727@msllnjpmsgsv06> Unfortunately there is no way I can see to control the output directory. It is always the current working directory. From: brad.king at kitware.com At: 04/12/18 09:42:58To: Ephi Sinowitz (BLOOMBERG/ 919 3RD A ) , cmake at cmake.org Subject: Re: [CMake] Ninja Fortran on XL On 04/12/2018 08:22 AM, Ephi Sinowitz (BLOOMBERG/ 919 3RD A) wrote: > CMake expects the PREPROCESSED_SOURCE output to be in the form > -pp.f and XL does not allow you to control that. The output> is always of the form F.f > > Is there anything I can do here like putting redirection or two > commands inside the CMAKE_Fortran_PREPROCESS_SOURCE variable? One can put two commands, e.g. something like: ``` set(CMAKE_Fortran_PREPROCESS_SOURCE " ... -d -qnoobject " "mv " ) ``` Filling in `` may be difficult. I've observed: * `/path/to/foo.F` ==> `./Ffoo.f` * `/path/to/foo.F90` ==> `./Ffoo.f90` CMake would need to be taught to produce a `` for this value, and it would need to know the mapping that xlf uses for extensions. Does xlf have a way to control in what directory the file is placed? -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Thu Apr 12 19:06:24 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Thu, 12 Apr 2018 23:06:24 +0000 Subject: [CMake] FetchContent and multiple CMake projects Message-ID: Hi, I have many independent CMake projects and most projects have external dependencies. Most of the projects have the same dependency e.g. Catch testing library. Each library uses FetchContent so that it can be built independently by simply cloning its github repository, configuring and generating through CMake and then building. However, I would also like the ability for these projects to share the same dependency to save disk space (and compile time) if they detect that another project already has done FetchContent on a particular dependency. Again, note that all projects are independent where their own repositories. ------------------------------------------ EXAMPLE ---------------------------------------------- To illustrate the setup: I have LibA, LibB, LibC, LibD, LibE etc. where each may have a dependency that is found to be the same. So, when LibA is the only one that is cloned, it uses FetchContent to clone the dependencies, build them, install them and the test executable linked to the dependencies properly. Now LibB is cloned and it has some dependencies that LibA doesn't have but other dependencies that LibA 'does' use. Assuming LibA is already built successfully, I would like LibB to rely on LibA's dependencies, if found, otherwise LibB clones, generates and builds its own dependencies. It is also possible that LibA was never cloned/built and thus LibB must clone/generate/build all dependencies. ------------------------------------------ END EXAMPLE ---------------------------------------------- To solve this issue, I am using a combination of find_package(...) and FetchContent, however the whole setup is starting to show cracks, is fragile and difficult to test and maintain. So now I am wondering whether there is a better way to about solving the issue. Thank you, Saad -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Thu Apr 12 23:29:21 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Fri, 13 Apr 2018 03:29:21 +0000 Subject: [CMake] find_package and get_target_property Message-ID: Hi, I am successfully able to find a package using find_package(LibA) but I cannot do a get_target_property on the package as I get the error: get_target_property() called with non-existent target "LibA" How do I go about the target properties for a package? - Saad -------------- next part -------------- An HTML attachment was scrubbed... URL: From w.clodius at icloud.com Thu Apr 12 22:33:46 2018 From: w.clodius at icloud.com (William Clodius) Date: Thu, 12 Apr 2018 20:33:46 -0600 Subject: [CMake] Testing with multiple Fortran compilers Message-ID: <2020CBB9-1ABD-462D-AA29-07D6008BF77D@icloud.com> I have been using CMake with gfortran for a number of years, and now want test my code with ifort. I want to switch easily switch between compilers. My CMakeLists.txt file is based on the fortran example from make.org an appears to have most of the infrastructure needed, but I don?t understand how the line get_filename_component (Fortran_COMPILER_NAME ${CMAKE_Fortran_COMPILER} NAME) determines the Fortran compiler to be used. Does it examine the FC system variable? Does it require the full pathname to the compiler executable? Do I have to delete the CMakeCache.txt, Makefile, and cmake_install.cmake each time I change compilers? From aluaces at udc.es Fri Apr 13 02:59:35 2018 From: aluaces at udc.es (Alberto Luaces) Date: Fri, 13 Apr 2018 08:59:35 +0200 Subject: [CMake] Testing with multiple Fortran compilers References: <2020CBB9-1ABD-462D-AA29-07D6008BF77D@icloud.com> Message-ID: <87sh7z8uco.fsf@eps142.cdf.udc.es> William Clodius writes: > I have been using CMake with gfortran for a number of years, and now > want test my code with ifort. I want to switch easily switch between > compilers. My CMakeLists.txt file is based on the fortran example from > make.org an appears to have most of the infrastructure needed, but I > don?t understand how the line > > get_filename_component (Fortran_COMPILER_NAME ${CMAKE_Fortran_COMPILER} NAME) > > determines the Fortran compiler to be used. Does it examine the FC > system variable? The easiest way is to export the FC variable with the name of the compiler before any call to cmake. It just has to be in the path, so you do not have to worry about specifying the absolute filename. > Does it require the full pathname to the compiler executable? Do I > have to delete the CMakeCache.txt, Makefile, and cmake_install.cmake > each time I change compilers? Absolutely. Those need to be separate build directories, one for each different compiler/settings. Remember that you can have as many of these as you want. -- Alberto From Arjen.Markus at deltares.nl Fri Apr 13 03:02:31 2018 From: Arjen.Markus at deltares.nl (Arjen Markus) Date: Fri, 13 Apr 2018 07:02:31 +0000 Subject: [CMake] Testing with multiple Fortran compilers In-Reply-To: <2020CBB9-1ABD-462D-AA29-07D6008BF77D@icloud.com> References: <2020CBB9-1ABD-462D-AA29-07D6008BF77D@icloud.com> Message-ID: Hi William, The compiler is not determined via this line - that merely retrieves the name component from the full path to the actual compiler executable. CMake uses a number of methods, if I may express it that way, to determine which compiler (Fortran or otherwise to use). One of them is the FC environment variable. If that is not set, it searches through a list of possible compiler commands. As for CMakeCache.txt and the like: it is best to start a build in a clean directory. Left-overs from a previous build may confuse the configuration and actual building of the program or programs. (As for get_file_component: In the PLplot project the PATH part of the full path to the compiler is used to fine-tune the directories where the compiler libraries are to be found.) Regards, Arjen Arjen Markus Sr. Adviseur/Onderzoeker T +31(0)88 335 8559 E Arjen.Markus at deltares.nl [Logo] www.deltares.com Postbus 177 2600 MH Delft [Deltares Twitter] [Deltares LinkedIn] [Deltares Facebook] [Think before printing]Please consider the environment before printing this email > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of William Clodius > Sent: Friday, April 13, 2018 4:34 AM > To: cmake at cmake.org > Subject: [CMake] Testing with multiple Fortran compilers > > I have been using CMake with gfortran for a number of years, and now want test > my code with ifort. I want to switch easily switch between compilers. My > CMakeLists.txt file is based on the fortran example from make.org an appears to > have most of the infrastructure needed, but I don't understand how the line > > get_filename_component (Fortran_COMPILER_NAME > ${CMAKE_Fortran_COMPILER} NAME) > > determines the Fortran compiler to be used. Does it examine the FC system > variable? Does it require the full pathname to the compiler executable? Do I have to > delete the CMakeCache.txt, Makefile, and cmake_install.cmake each time I change > compilers? > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5083 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 665 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 640 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 560 bytes Desc: image004.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 624 bytes Desc: image005.png URL: From marc.chevrier at sap.com Fri Apr 13 03:05:41 2018 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Fri, 13 Apr 2018 07:05:41 +0000 Subject: [CMake] find_package and get_target_property In-Reply-To: References: Message-ID: The creation of ?imported? target is the responsibility of the package. May be the package ?LibA? does not create a such target. In this case, you have to rely on variables (like LibA_LIBRARIES and so on?). The documentation of the package, if any, generally describe how to use the package. From: CMake on behalf of Saad Khattak Date: Friday 13 April 2018 at 05:29 To: Cmake Mailing List Subject: [CMake] find_package and get_target_property Hi, I am successfully able to find a package using find_package(LibA) but I cannot do a get_target_property on the package as I get the error: get_target_property() called with non-existent target "LibA" How do I go about the target properties for a package? - Saad -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Fri Apr 13 08:49:47 2018 From: saadrustam at gmail.com (Saad Khattak) Date: Fri, 13 Apr 2018 12:49:47 +0000 Subject: [CMake] find_package and get_target_property In-Reply-To: References: Message-ID: Thanks Marc. I assume you mean the library does not export its targets properly? Something like this: # https://cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets install(TARGETS generator DESTINATION lib/myproj/generators EXPORT myproj-targets) install(EXPORT myproj-targets DESTINATION lib/myproj) On Fri, Apr 13, 2018 at 3:05 AM CHEVRIER, Marc wrote: > The creation of ?imported? target is the responsibility of the package. > May be the package ?LibA? does not create a such target. > > In this case, you have to rely on variables (like LibA_LIBRARIES and so > on?). The documentation of the package, if any, generally describe how to > use the package. > > > > > > *From: *CMake on behalf of Saad Khattak < > saadrustam at gmail.com> > *Date: *Friday 13 April 2018 at 05:29 > *To: *Cmake Mailing List > *Subject: *[CMake] find_package and get_target_property > > > > Hi, > > > > I am successfully able to find a package using find_package(LibA) but I > cannot do a get_target_property on the package as I get the error: > > > > get_target_property() called with non-existent target "LibA" > > > > How do I go about the target properties for a package? > > > > - Saad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at sap.com Fri Apr 13 09:10:52 2018 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Fri, 13 Apr 2018 13:10:52 +0000 Subject: [CMake] find_package and get_target_property In-Reply-To: References: <7029E954-8C75-4A39-B05D-5E972B87AC9A@sap.com> Message-ID: <034CA965-29D7-47A6-B0D6-AE5F153F2486@sap.com> Using ?install(EXPORT ?)? you can generate required files to manage imported targets BUT building and exporting targets must be done in a different build environment from the one which imports the targets. From: Saad Khattak Date: Friday 13 April 2018 at 15:02 To: "CHEVRIER, Marc" Subject: Re: [CMake] find_package and get_target_property Ah I see. In this case, the Libraries I'm depending on are generated, built and installed using CMake. I'm hoping that CMake is able to generate the Find.cmake for me with the appropriate imported targets, as long as INSTALL(export...) was used properly...? On Fri, Apr 13, 2018 at 8:58 AM CHEVRIER, Marc > wrote: Not necessarily. It depends how the package was created. Using EXPORT is a possibility to generate a Config file for the package. Another possibility is to have a FindLibA.cmake file which creates an imported target by using command ?add_library (LibA SHARED IMPORTED)?. From: Saad Khattak > Date: Friday 13 April 2018 at 14:50 To: "CHEVRIER, Marc" > Cc: Cmake Mailing List > Subject: Re: [CMake] find_package and get_target_property Thanks Marc. I assume you mean the library does not export its targets properly? Something like this: # https://cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets install(TARGETS generator DESTINATION lib/myproj/generators EXPORT myproj-targets) install(EXPORT myproj-targets DESTINATION lib/myproj) On Fri, Apr 13, 2018 at 3:05 AM CHEVRIER, Marc > wrote: The creation of ?imported? target is the responsibility of the package. May be the package ?LibA? does not create a such target. In this case, you have to rely on variables (like LibA_LIBRARIES and so on?). The documentation of the package, if any, generally describe how to use the package. From: CMake > on behalf of Saad Khattak > Date: Friday 13 April 2018 at 05:29 To: Cmake Mailing List > Subject: [CMake] find_package and get_target_property Hi, I am successfully able to find a package using find_package(LibA) but I cannot do a get_target_property on the package as I get the error: get_target_property() called with non-existent target "LibA" How do I go about the target properties for a package? - Saad -------------- next part -------------- An HTML attachment was scrubbed... URL: From Banshee999 at gmx.de Fri Apr 13 10:19:20 2018 From: Banshee999 at gmx.de (=?UTF-8?Q?=22Benedikt_F=C3=BChrer=22?=) Date: Fri, 13 Apr 2018 16:19:20 +0200 Subject: [CMake] How to extract compile flags from setting CMAKE_CXX_STANDARD Message-ID: An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Fri Apr 13 15:48:10 2018 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 13 Apr 2018 12:48:10 -0700 (PDT) Subject: [CMake] Is it possible for CMake to generate unescaped quotes on the (bash) command line as a result of add_custom_command? Message-ID: Hi Nils: I am asking this question directly of you because in the past (at ) you stated "To pass quotes directly to the command either [["foo"]] or \"foo\" should work." But that doesn't work for me (using make and the bash command-line on Linux), and instead with either of those two methods I get escaped quotes on the command-line. My use case (for add_custom_command with VERBATIM and cmake 3.6.2 or higher) is as follows: COMMAND test-drv-info ${LIBRARY_TARGET_PREFIX} ${SOURCE_ROOT_NAME} > ${CMAKE_CURRENT_BINARY_DIR}/test_dyndrivers_dir/${SOURCE_ROOT_NAME}.driver_info that translates to ./test-drv-info temporary_target_ ps > /home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info on the command line which is correct for the case when LIBRARY_TARGET_PREFIX has been set to "temporary_target_". But when LIBRARY_TARGET_PREFIX is set to the empty string the result is ./test-drv-info ps > /home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info However, that is wrong since that command currently needs two arguments even if one of them is empty. So instead I need the generated command to be ./test-drv-info "temporary_target_" ps > /home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info or ./test-drv-info "" ps > /home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info depending on how LIBRARY_TARGET_PREFIX is set. Is it possible to implement that? If I try your (historical) suggestion above, I get instead ./test-drv-info \"temporary_target_\" ps > /home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info or ./test-drv-info \"\" ps > /home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info which isn't correct since unescaped quotes are needed on the generated command line rather than escaped ones. If the answer is unescaped quotes are not possible on the generated command line, that is fine since there are multiple ways to work around that CMake limitation (e.g., by changing the test-drv-info executable to check the number of arguments and act differently if one of them is missing). But in light of your quote above, I just want to make sure I am not missing some obvious way that CMake can generate unescaped quotes on the command-line. 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 nilsgladitz at gmail.com Fri Apr 13 17:02:07 2018 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 13 Apr 2018 23:02:07 +0200 Subject: [CMake] Is it possible for CMake to generate unescaped quotes on the (bash) command line as a result of add_custom_command? In-Reply-To: References: Message-ID: On 13.04.2018 21:48, Alan W. Irwin wrote: > [...] > However, that is wrong since that command currently needs two > arguments even if > one of them is empty.? So instead I need the generated command to be > > ./test-drv-info "temporary_target_" ps > > /home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info > > or > > ./test-drv-info "" ps > > /home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info > > depending on how LIBRARY_TARGET_PREFIX is set. > > Is it possible to implement that? Hi Alan, with VERBATIM just using regular unescaped quotes (which are cmake syntax and not part of the value) around the argument should work e.g. ??? COMMAND test-drv-info "${LIBRARY_TARGET_PREFIX}" ${SOURCE_ROOT_NAME} ${CMAKE_CURRENT_BINARY_DIR}/test_dyndrivers_dir/${SOURCE_ROOT_NAME}.driver_info That way even when ${LIBRARY_TARGET_PREFIX} expands empty add_custom_command() will receive an argument which it will escape / quote as required by the build system. Nils From irwin at beluga.phys.uvic.ca Fri Apr 13 18:02:54 2018 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 13 Apr 2018 15:02:54 -0700 (PDT) Subject: [CMake] Is it possible for CMake to generate unescaped quotes on the (bash) command line as a result of add_custom_command? In-Reply-To: References: Message-ID: On 2018-04-13 23:02+0200 Nils Gladitz wrote: > On 13.04.2018 21:48, Alan W. Irwin wrote: >> [...] >> However, that is wrong since that command currently needs two arguments >> even if >> one of them is empty.? So instead I need the generated command to be >> >> ./test-drv-info "temporary_target_" ps > >> /home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info >> >> or >> >> ./test-drv-info "" ps > >> /home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info >> >> depending on how LIBRARY_TARGET_PREFIX is set. >> >> Is it possible to implement that? > > Hi Alan, > > with VERBATIM just using regular unescaped quotes (which are cmake syntax and > not part of the value) around the argument should work e.g. > > ??? COMMAND test-drv-info "${LIBRARY_TARGET_PREFIX}" ${SOURCE_ROOT_NAME} > ${CMAKE_CURRENT_BINARY_DIR}/test_dyndrivers_dir/${SOURCE_ROOT_NAME}.driver_info > > > That way even when ${LIBRARY_TARGET_PREFIX} expands empty > add_custom_command() will receive an argument which it will escape / quote as > required by the build system. Hi Nils: When starting fresh with a clean cache using "${LIBRARY_TARGET_PREFIX}" in the COMMAND worked perfectly, i.e., propagated as "" to the command line when ${LIBRARY_TARGET_PREFIX} expands empty. Thanks for that suggestion! The strange thing is I am virtually positive I tried that exact idea earlier today, and it did not work, but maybe that was due to another issue such as a dirty cache. 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 cameron at promon.no Sat Apr 14 01:51:34 2018 From: cameron at promon.no (Cameron Palmer) Date: Sat, 14 Apr 2018 05:51:34 +0000 Subject: [CMake] Rolling up Object libraries into a final product Message-ID: <5A912A9F-AA2D-463F-B185-35D0E5F64A49@promon.no> I?m using object libraries to put together a project composed of numerous modules. When putting together the static library (deliverable) at the end I have used libtool to assemble final product. I?ve been trying to adopt the use of OBJECT type libraries to avoid the libtool call and it mostly works with the exception that OpenSSL and Boost static libraries are not included in the result. This means I?ll still need libtool to add them to the archive. 1) Does this look like I?m using this correctly? 2) Can the .a files be handled by CMake in a better way than using libtool? It is a collection of objects after all. When this is built, other libraries will add this library in the target_link_libraries( another_interface INTERFACE common ) ### Library - objects add_library( common_objects OBJECT ${HEADER_FILES} ${SOURCE_FILES} ) set_target_properties( common_objects PROPERTIES POSITION_INDEPENDENT_CODE on ) target_include_directories( common_objects PUBLIC include iOS/include ${BOOST_INCLUDE_DIR} ) ### Library - dependencies add_library( common_interface INTERFACE ) target_link_libraries( common_interface INTERFACE prefs ${BOOST_STATIC_LIBS} ) target_include_directories( common_interface INTERFACE $ $ $ $ ) ### Library - interface add_library( common INTERFACE ) target_sources( common INTERFACE $ ) target_link_libraries( common INTERFACE common_interface ) ### Library is assembled into static and shared as well if( BUILD_STATIC_LIB ) add_library( common_static STATIC "" ) set_target_properties( common_static PROPERTIES OUTPUT_NAME common ) target_link_libraries( common_static PRIVATE common ) endif() if( BUILD_SHARED_LIB ) add_library( common_shared SHARED "" ) set_target_properties( common_shared PROPERTIES OUTPUT_NAME common ) target_link_libraries( common_shared PRIVATE common ) endif() -------------- next part -------------- An HTML attachment was scrubbed... URL: From object.rexx at gmail.com Sat Apr 14 13:00:40 2018 From: object.rexx at gmail.com (Rick McGuire) Date: Sat, 14 Apr 2018 13:00:40 -0400 Subject: [CMake] Error doing a test compile on Windows Message-ID: I'm in the process of moving all of my work to a new computer and I'm encountering a puzzling error using cmake for my projects. When I try to set up the project, I'm getting an error when cmake tries to do a test compile using the Visual Studio compiler. According to the error log, the problem was with locating Kernel32.lib. I see others on this list have encountered this problem, but none of the solutions suggested have been any help. I've completely uninstalled visual studio and the Windows SDK and reinstalled every thing. I've tried manually adding the directory with the correct Kernel32.lib to the LIBPATH. It still fails. I've done a comparison between my old machine and my new machine and everything looks the same, even the environment variables set by vcvarsall. I've run out of ideas here. My old machine was bricked by a Windows update back in January and I was forced to reinstall everything on the machine without encountering any problems like this. Any suggestions? Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dvir.Yitzchaki at ceva-dsp.com Sun Apr 15 08:56:35 2018 From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki) Date: Sun, 15 Apr 2018 12:56:35 +0000 Subject: [CMake] [Digital Signature Failure] FetchContent and multiple CMake projects In-Reply-To: References: Message-ID: <1046276817d54c01bf8b55fbd5e8a122@ceva-dsp.com> Check out Hunter package manager: https://github.com/ruslo/hunter Regards, Dvir From: CMake On Behalf Of Saad Khattak Sent: Friday, April 13, 2018 02:06 To: Cmake Mailing List Subject: [Digital Signature Failure] [CMake] FetchContent and multiple CMake projects Hi, I have many independent CMake projects and most projects have external dependencies. Most of the projects have the same dependency e.g. Catch testing library. Each library uses FetchContent so that it can be built independently by simply cloning its github repository, configuring and generating through CMake and then building. However, I would also like the ability for these projects to share the same dependency to save disk space (and compile time) if they detect that another project already has done FetchContent on a particular dependency. Again, note that all projects are independent where their own repositories. ------------------------------------------ EXAMPLE ---------------------------------------------- To illustrate the setup: I have LibA, LibB, LibC, LibD, LibE etc. where each may have a dependency that is found to be the same. So, when LibA is the only one that is cloned, it uses FetchContent to clone the dependencies, build them, install them and the test executable linked to the dependencies properly. Now LibB is cloned and it has some dependencies that LibA doesn't have but other dependencies that LibA 'does' use. Assuming LibA is already built successfully, I would like LibB to rely on LibA's dependencies, if found, otherwise LibB clones, generates and builds its own dependencies. It is also possible that LibA was never cloned/built and thus LibB must clone/generate/build all dependencies. ------------------------------------------ END EXAMPLE ---------------------------------------------- To solve this issue, I am using a combination of find_package(...) and FetchContent, however the whole setup is starting to show cracks, is fragile and difficult to test and maintain. So now I am wondering whether there is a better way to about solving the issue. Thank you, Saad -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ryan.H.Kawicki at boeing.com Mon Apr 16 11:18:37 2018 From: Ryan.H.Kawicki at boeing.com (Kawicki (US), Ryan H) Date: Mon, 16 Apr 2018 15:18:37 +0000 Subject: [CMake] Testing with multiple Fortran compilers In-Reply-To: References: <2020CBB9-1ABD-462D-AA29-07D6008BF77D@icloud.com> Message-ID: I just wanted to chime in and say we are having the same issue. In an e-mail (defined below) to colleagues, I was under the impression that setting the environment variable 'FC' would do the trick. It wasn't until after looking through the installed CMake modules that 'FC' is completely ignored on Windows when using a Visual Studio generator. First E-mail to colleagues: I did a little research this morning during the planning, and it appears you only need to set the environment variable 'FC' to point to ifort.exe. I assume your systems already have this variable based on what is installed by Intel, so all that really needs to be done is set the path internally. Here is an example that you should be able to plug into your CMakeLists.txt for BigTac for testing. Just update the paths to the required ifort.exe for the appropriate generator. cmake_minimum_required(VERSION 3.5.2 FATAL_ERROR) # this must be performed before calling project # to set the fortran compiler... for intel, FC # is used to identify the fortran compiler that # cmake will pick up on and use to determine abi if (CMAKE_GENERATOR MATCHES "^Visual Studio") if (CMAKE_GENERATOR MATCHES "^Visual Studio 10") # set the path to the fortran compiler for vs2010 set(ENV{FC} "C:/Path/To/VS2010/ifort.exe") elseif (CMAKE_GENERATOR MATCHES "^Visual Studio 14") # set the path to the fortran compiler for vs2015 set(ENV{FC} "C:/Path/To/VS2015/ifort.exe") else ( ) # remove from the environment just in case one is set unset(ENV{FC}) endif ( ) if (NOT EXISTS "$ENV{FC}") # indicate to the user that the fortran library could not be found # but allow the process to continue, as it should still generate c / c++ / c# message(AUTHOR_WARNING "Unable to set the Intel Fortran compiler for " "the specified MSVC generator '${CMAKE_GENERATOR}'!!!") else ( ) # message the path to the compiler to use message(STATUS "Fortran compiler: '$ENV{FC}'") endif ( ) endif ( ) project(cmake-fortran-test) --------------------- First E-mail to colleagues End --------------------------------- Second E-mail to colleagues: So, I did a bit more looking into this and this appears to be an issue with how Intel integrates with Visual Studio. I would say if you create a simple Fortran project that the wrong version of the Intel compiler will be used to compile the project. Please do try the statements below to see if this corrects the issue; though, I am not optimistic it will based on my research. I overlooked the internal files related to the FC environment variable, as it is used if Visual Studio is not used. I'll pose the question to CMake, as I am not finding good information on this. >From what I see, the try compile of a temp project sets a post build command that sets the compiler path. for %%i in (ifort.exe) do @echo CMAKE_Fortran_COMPILER=%%~$PATH:i Modifying the PATH environment variable will not work because visual studio appends to the front of the PATH certain paths, one of them being the location of the Fortran compiler. This path appears to be associated to the registry variable HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Intel\Compilers\Fortran\121.258\IA32\VSNet2010\BinDir. To be able to help here more, I would need to get a machine with both compilers (VS and Intel) installed on a system to test some ideas out. It may be as easy as making sure that when you install to your system the Intel compilers, make sure to install the older Intel compiler first to make the association to VS2010 and then install the newer Intel compiler making only the association to VS2015. It sounds like there should be the capabilities to indicate which version to integrate with based on the following article: https://software.intel.com/en-us/articles/using-older-intel-visual-fortran-versions-in-different-microsoft-visual-studio-versions It may be possible to just reset the registry variable for VS2010. I am assuming that it is getting messed up, but I cannot tell without having both on a system to play around with. I'll post the question to the CMake forum tomorrow to see if anyone can help with this situation. This cannot be unique to us. I'll keep you apprised, but if you have a machine I may be able to test with, please let me know. Thanks and good day guys. --------------------- Second E-mail to colleagues End --------------------------------- I have not sat down to try and figure this out any further, but I would be very interested in knowing what is the best solution. For our case, there is a project that builds under VS2010 and Intel's VS2010 compatible Fortran compiler. Installing VS2015 on the same machine with Intel's VS2015 compatible Fortran compiler causes issues when trying to generate a VS2010 version of the solution, as Intel's VS2015 compatible Fortran compiler is always selected. In the article posted, there is a way to preserve older compiler versions within older visual studio versions, but I have not looked into that as an option yet. I hope to get there one day. It would be nice if this was a bit more configurable from within CMake so that such operations are not required to be performed. Ryan H. Kawicki From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Arjen Markus Sent: Friday, April 13, 2018 2:03 AM To: William Clodius ; cmake at cmake.org Subject: Re: [CMake] Testing with multiple Fortran compilers Hi William, The compiler is not determined via this line - that merely retrieves the name component from the full path to the actual compiler executable. CMake uses a number of methods, if I may express it that way, to determine which compiler (Fortran or otherwise to use). One of them is the FC environment variable. If that is not set, it searches through a list of possible compiler commands. As for CMakeCache.txt and the like: it is best to start a build in a clean directory. Left-overs from a previous build may confuse the configuration and actual building of the program or programs. (As for get_file_component: In the PLplot project the PATH part of the full path to the compiler is used to fine-tune the directories where the compiler libraries are to be found.) Regards, Arjen Arjen Markus Sr. Adviseur/Onderzoeker T +31(0)88 335 8559 E Arjen.Markus at deltares.nl [Logo] www.deltares.com Postbus 177 2600 MH Delft [Deltares Twitter] [Deltares LinkedIn] [Deltares Facebook] [Think before printing]Please consider the environment before printing this email > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of William Clodius > Sent: Friday, April 13, 2018 4:34 AM > To: cmake at cmake.org > Subject: [CMake] Testing with multiple Fortran compilers > > I have been using CMake with gfortran for a number of years, and now want test > my code with ifort. I want to switch easily switch between compilers. My > CMakeLists.txt file is based on the fortran example from make.org an appears to > have most of the infrastructure needed, but I don't understand how the line > > get_filename_component (Fortran_COMPILER_NAME > ${CMAKE_Fortran_COMPILER} NAME) > > determines the Fortran compiler to be used. Does it examine the FC system > variable? Does it require the full pathname to the compiler executable? Do I have to > delete the CMakeCache.txt, Makefile, and cmake_install.cmake each time I change > compilers? > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 5083 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 665 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 640 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 560 bytes Desc: image004.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 624 bytes Desc: image005.png URL: From markand at malikania.fr Tue Apr 17 05:58:12 2018 From: markand at malikania.fr (David Demelier) Date: Tue, 17 Apr 2018 11:58:12 +0200 Subject: [CMake] Recommandations for public custom macro/functions installation Message-ID: <1523959092.25176.8.camel@malikania.fr> Hello, In my application I have some custom functions that help the process of creating executable, libraries, plugins and such. They don't do magic things but they mostly build, provide installation to specific place and optionally build the documentation and install them as well. This happens in my project. Since the project is extensible, I want to install the libraries **and** those macros so users will be able to use them so their plugins get installed in the correct place alongside the documentation without much effort. Example, the user will just write: irccd_define_plugin( SOURCES main.cpp DOCS myplugin.md ) The problem with that macro, is that it has a conditional to build the documentation depending on an option. This is fine in my project since the user may build or not build the documentation by setting WITH_DOCS to Off. Now I wonder how I should handle this option when the macro is publicliy installed. The most problematic question is that variables do not have namespaces so if the user of my macro also have an option WITH_DOCS in its own CMakeLists.txt, this will interfer with the installed macro. What are your recommandations over this? I personally do not want to prefix all my options in my project with the project name prefix, I think that would be a bit ugly, and I do want this macro to build and install the documentation. Any advice/comment is welcome. Regards, -- David From johannes.zarl-zierl at jku.at Tue Apr 17 06:25:06 2018 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Tue, 17 Apr 2018 12:25:06 +0200 Subject: [CMake] Recommandations for public custom macro/functions installation In-Reply-To: <1523959092.25176.8.camel@malikania.fr> References: <1523959092.25176.8.camel@malikania.fr> Message-ID: <1737743.vKVSAZYPUk@ersa> Hi David, On Dienstag, 17. April 2018 11:58:12 CEST David Demelier wrote: > I personally do not want to prefix all my options in my project with > the project name prefix, I think that would be a bit ugly, and I do > want this macro to build and install the documentation. Just replying to this topic of your message: you may want to reconsider. The cmake gui allows you to group options automatically by prefix. This de-clutters the options considerably. On a related note: even without grouping, looking through the options of a project in ccmake or cmake-gui is so much easier when they are prefixed (and therefore easily identifiable). Cheers, Johannes From markand at malikania.fr Tue Apr 17 07:48:39 2018 From: markand at malikania.fr (David Demelier) Date: Tue, 17 Apr 2018 13:48:39 +0200 Subject: [CMake] Recommandations for public custom macro/functions installation In-Reply-To: <1737743.vKVSAZYPUk@ersa> References: <1523959092.25176.8.camel@malikania.fr> <1737743.vKVSAZYPUk@ersa> Message-ID: <1523965719.25176.10.camel@malikania.fr> On Tue, 2018-04-17 at 12:25 +0200, Johannes Zarl-Zierl wrote: > Just replying to this topic of your message: you may want to > reconsider. The > cmake gui allows you to group options automatically by prefix. This > de-clutters > the options considerably. I didn't know that! Nice catch. I'll reconsider using prefix then. I've usually named my options WITH_FOO, do you recommend to use PROJECT_WITH_FOO or WITH_PROJECT_FOO then? -- David From craig.scott at crascit.com Tue Apr 17 08:07:59 2018 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 17 Apr 2018 22:07:59 +1000 Subject: [CMake] Recommandations for public custom macro/functions installation In-Reply-To: <1523965719.25176.10.camel@malikania.fr> References: <1523959092.25176.8.camel@malikania.fr> <1737743.vKVSAZYPUk@ersa> <1523965719.25176.10.camel@malikania.fr> Message-ID: On Tue, Apr 17, 2018 at 9:48 PM, David Demelier wrote: > On Tue, 2018-04-17 at 12:25 +0200, Johannes Zarl-Zierl wrote: > > Just replying to this topic of your message: you may want to > > reconsider. The > > cmake gui allows you to group options automatically by prefix. This > > de-clutters > > the options considerably. > > I didn't know that! Nice catch. I'll reconsider using prefix then. I've > usually named my options WITH_FOO, do you recommend to use > PROJECT_WITH_FOO or WITH_PROJECT_FOO then? > Definitely go with PROJECT_WITH_FOO. Only the letters up to the first underscore are used for the grouping in cmake-gui. For larger hierarchical projects, this grouping feature is pretty important if you want any chance of keeping the variables manageable in the GUI. The project-specific prefix is also good protection against name clashes with other parts of the build (always consider the possibility that your project may one day be used as part of some larger parent project, pulled in by add_subdirectory()). -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Tue Apr 17 08:09:50 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 17 Apr 2018 14:09:50 +0200 Subject: [CMake] Recommandations for public custom macro/functions installation In-Reply-To: <1523959092.25176.8.camel@malikania.fr> References: <1523959092.25176.8.camel@malikania.fr> Message-ID: 2018-04-17 11:58 GMT+02:00 David Demelier : > Hello, > > In my application I have some custom functions that help the process of > creating executable, libraries, plugins and such. > > They don't do magic things but they mostly build, provide installation > to specific place and optionally build the documentation and install > them as well. This happens in my project. Since the project is > extensible, I want to install the libraries **and** those macros so > users will be able to use them so their plugins get installed in the > correct place alongside the documentation without much effort. > > Example, the user will just write: > > irccd_define_plugin( > SOURCES main.cpp > DOCS myplugin.md > ) > > The problem with that macro, is that it has a conditional to build the > documentation depending on an option. This is fine in my project since > the user may build or not build the documentation by setting WITH_DOCS > to Off. > Now I wonder how I should handle this option when the macro is > publicliy installed. The most problematic question is that variables do > not have namespaces so if the user of my macro also have an option > WITH_DOCS in its own CMakeLists.txt, this will interfer with the > installed macro. > Add an optional BUILD_DOCS option parameter to your macro with default to "False" if not present so that user cannot call it without knowing. i.e. You will call: irccd_define_plugin( SOURCES main.cpp DOCS myplugin.md BUILD_DOCS ${WITH_DOC} ) your user may safely call: irccd_define_plugin( SOURCES main.cpp DOCS userplugin.md ) Another option would be to carry "doc generation option" as a target level custom property you can attach to each target (exe, plugins , etc...) created by your macro. Then your macro may decide to generate doc iff the chosen property is defined on a per-target basis. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.zarl-zierl at jku.at Tue Apr 17 08:10:13 2018 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Tue, 17 Apr 2018 14:10:13 +0200 Subject: [CMake] Recommandations for public custom macro/functions installation In-Reply-To: <1523965719.25176.10.camel@malikania.fr> References: <1523959092.25176.8.camel@malikania.fr> <1737743.vKVSAZYPUk@ersa> <1523965719.25176.10.camel@malikania.fr> Message-ID: <2829422.ZYLljkYPYC@ersa> On Dienstag, 17. April 2018 13:48:39 CEST David Demelier wrote: > On Tue, 2018-04-17 at 12:25 +0200, Johannes Zarl-Zierl wrote: > > Just replying to this topic of your message: you may want to > > reconsider. The > > cmake gui allows you to group options automatically by prefix. This > > de-clutters > > the options considerably. > > I didn't know that! Nice catch. I'll reconsider using prefix then. I've > usually named my options WITH_FOO, do you recommend to use > PROJECT_WITH_FOO or WITH_PROJECT_FOO then? Personally, I prefer PROJECT_WITH_FOO because it also works when I have additional options PROJECT_ADDITIONAL_OPTION... Cheers, Johannes From robert.maynard at kitware.com Tue Apr 17 11:35:41 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 17 Apr 2018 11:35:41 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.11.1 available for download Message-ID: We are pleased to announce that CMake 3.11.1 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.11.1 since 3.11.0: Brad King (5): Revert "CheckIncludeFiles: Honor CMAKE_REQUIRED_LIBRARIES" CPack: Fix crash on invalid generator name Restore support for explicitly referenced CMakeLists.txt sources Exclude "libgcc_eh" library files from implicit link libraries CMake 3.11.1 Daniel Filipe (1): Features: Record for VS 2017 through 15.6 Kirill Erofeev (2): Explicitly require LibUV 1.10 or higher to build CMake bootstrap: Add option to enable/disable usage of system libuv R2RT (1): Fix crash with --trace-expand --warn-uninitialized together Roland Schulz (1): FindOpenMP: Fix support for Intel on Windows Sebastian Holtermann (7): Autogen: Protected calls to cmSystemTools::CollapseCombinedPath Autogen: Protected calls to cmSystemTools::Split/JoinPath Autogen: Protected calls to cmSystemTools::GetFilenameWithoutLastExtension Autogen: Protected calls to cmQtAutoGen::SubDirPrefix Autogen: Protected calls to cmFilePathChecksum Autogen: Use std::istreambuf_iterator for file so string reading Autogen: Print moc/uic/rcc output to stdout From zbeekman at gmail.com Thu Apr 19 11:46:26 2018 From: zbeekman at gmail.com (Zaak Beekman) Date: Thu, 19 Apr 2018 15:46:26 +0000 Subject: [CMake] Generating MSVS solution files that can be passed around Message-ID: Greetings fellow CMake users! While I know this topic has been discussed intermittently over the years I was wondering if anyone had any further insight. The situation is that we have a client who works with other contractors who use almost exclusively windows and MSVS. This client wants to distribute MSVS solution files with the source code so that other contractors don?t have to install cmake. (There are some restrictions/red tape for installing additional software on the contractor machines?) I know the official party line is ?CMake must use absolute paths, rerun CMake to regenerate the MSVS solution files.? I also know that CMAKE_USE_RELATIVE_PATHS was abandoned. Does anyone have any updated insight on this issue? Is there any mechanism, other than either manually or automatically editing the solution files to cause them to use relative paths? Another thought might be to include a statically linked CMake windows binary with the source, but I need to investigate whether the CMake licensing allows for that. Thanks, Zaak Izaak "Zaak" Beekman ------------------------------------------------------------------------------- HPC Scientist ParaTools Inc. ibeekman at paratools.com 1509 16th St, NW Washington, DC 20036 mobile: (917) 797-3239 ------------------------------------------------------------------------------- ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Thu Apr 19 11:50:59 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 19 Apr 2018 18:50:59 +0300 Subject: [CMake] Generating MSVS solution files that can be passed around In-Reply-To: References: Message-ID: <131161524153059@web7j.yandex.ru> 19.04.2018, 18:46, "Zaak Beekman" : > Greetings fellow CMake users! > > While I know this topic has been discussed intermittently over the years I was wondering if anyone had any further insight. > > The situation is that we have a client who works with other contractors who use almost exclusively windows and MSVS. This client wants to distribute MSVS solution files with the source code so that other contractors don?t have to install cmake. (There are some restrictions/red tape for installing additional software on the contractor machines?) Then your best choice is probably Premake (http://premake.github.io/) > > I know the official party line is ?CMake must use absolute paths, rerun CMake to regenerate the MSVS solution files.? I also know that CMAKE_USE_RELATIVE_PATHS was abandoned. > > Does anyone have any updated insight on this issue? Is there any mechanism, other than either manually or automatically editing the solution files to cause them to use relative paths? > > Another thought might be to include a statically linked CMake windows binary with the source, but I need to investigate whether the CMake licensing allows for that. > > Thanks, > Zaak > > Izaak "Zaak" Beekman > > ------------------------------------------------------------------------------- > HPC Scientist > ParaTools Inc. > ibeekman at paratools.com > 1509 16th St, NW > Washington, DC 20036 > mobile: (917) 797-3239 > ------------------------------------------------------------------------------- > ? > > ,-- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake --? Regards, Konstantin From zbeekman at gmail.com Thu Apr 19 12:30:11 2018 From: zbeekman at gmail.com (Zaak Beekman) Date: Thu, 19 Apr 2018 16:30:11 +0000 Subject: [CMake] Generating MSVS solution files that can be passed around In-Reply-To: <131161524153059@web7j.yandex.ru> References: <131161524153059@web7j.yandex.ru> Message-ID: On Thu, Apr 19, 2018 at 11:51 AM Konstantin Tokarev wrote: > Then your best choice is probably Premake (http://premake.github.io/) > No. Big project. Have build system. CMake has 1st class language support for Fortran. I can't introduce a LUA dependency. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristian.adam at gmail.com Thu Apr 19 12:52:20 2018 From: cristian.adam at gmail.com (Cristian Adam) Date: Thu, 19 Apr 2018 18:52:20 +0200 Subject: [CMake] Generating MSVS solution files that can be passed around In-Reply-To: References: Message-ID: On Thu, Apr 19, 2018 at 5:46 PM, Zaak Beekman wrote: > The situation is that we have a client who works with other contractors > who use almost exclusively windows and MSVS. This client wants to > distribute MSVS solution files with the source code so that other > contractors don?t have to install cmake. (There are some restrictions/red > tape for installing additional software on the contractor machines?) > Why not distribute CMake as source code? Compile it so that they don't have to "install" it. On the other hand Visual Studio 2017 comes with their own version of CMake! Just make sure your contractors use VS2017 :D Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zbeekman at gmail.com Thu Apr 19 12:55:03 2018 From: zbeekman at gmail.com (Zaak Beekman) Date: Thu, 19 Apr 2018 16:55:03 +0000 Subject: [CMake] Generating MSVS solution files that can be passed around In-Reply-To: References: Message-ID: Ha, yeah that?s an option. The problem is that they?re not ?my? contractors. They are the client?s contractors. We?ll see. On Thu, Apr 19, 2018 at 12:52 PM Cristian Adam wrote: > On Thu, Apr 19, 2018 at 5:46 PM, Zaak Beekman wrote: > >> The situation is that we have a client who works with other contractors >> who use almost exclusively windows and MSVS. This client wants to >> distribute MSVS solution files with the source code so that other >> contractors don?t have to install cmake. (There are some restrictions/red >> tape for installing additional software on the contractor machines?) >> > > Why not distribute CMake as source code? Compile it so that they don't > have to "install" it. > > On the other hand Visual Studio 2017 comes with their own version of > CMake! Just make sure your contractors use VS2017 :D > > Cheers, > Cristian. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.svitok at gmail.com Thu Apr 19 17:33:47 2018 From: jan.svitok at gmail.com (Jano Svitok) Date: Thu, 19 Apr 2018 23:33:47 +0200 Subject: [CMake] Generating MSVS solution files that can be passed around In-Reply-To: References: Message-ID: You don't have to install cmake. Just get the zip version, unzip in somewhere along your sources and you are done. I'm not sure whether any runtime dlls are needed, but I suppose not. We use cmake like that. We've committed a copy in our git repo, and have a simple means to update cmake for everyone in the team at once. Jano On Thu, Apr 19, 2018 at 6:55 PM, Zaak Beekman wrote: > Ha, yeah that?s an option. The problem is that they?re not ?my? > contractors. They are the client?s contractors. We?ll see. > On Thu, Apr 19, 2018 at 12:52 PM Cristian Adam > wrote: > >> On Thu, Apr 19, 2018 at 5:46 PM, Zaak Beekman wrote: >> >>> The situation is that we have a client who works with other contractors >>> who use almost exclusively windows and MSVS. This client wants to >>> distribute MSVS solution files with the source code so that other >>> contractors don?t have to install cmake. (There are some restrictions/red >>> tape for installing additional software on the contractor machines?) >>> >> >> Why not distribute CMake as source code? Compile it so that they don't >> have to "install" it. >> >> On the other hand Visual Studio 2017 comes with their own version of >> CMake! Just make sure your contractors use VS2017 :D >> >> Cheers, >> Cristian. >> >> > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zbeekman at gmail.com Thu Apr 19 17:37:09 2018 From: zbeekman at gmail.com (Zaak Beekman) Date: Thu, 19 Apr 2018 21:37:09 +0000 Subject: [CMake] Generating MSVS solution files that can be passed around In-Reply-To: References: Message-ID: Thanks Jano, that's the work flow I was considering. On Thu, Apr 19, 2018 at 5:33 PM Jano Svitok wrote: > You don't have to install cmake. Just get the zip version, unzip in > somewhere along your sources and you are done. > I'm not sure whether any runtime dlls are needed, but I suppose not. > > We use cmake like that. We've committed a copy in our git repo, and have a > simple means to update cmake for everyone > in the team at once. > > Jano > > On Thu, Apr 19, 2018 at 6:55 PM, Zaak Beekman wrote: > >> Ha, yeah that?s an option. The problem is that they?re not ?my? >> contractors. They are the client?s contractors. We?ll see. >> On Thu, Apr 19, 2018 at 12:52 PM Cristian Adam >> wrote: >> >>> On Thu, Apr 19, 2018 at 5:46 PM, Zaak Beekman >>> wrote: >>> >>>> The situation is that we have a client who works with other contractors >>>> who use almost exclusively windows and MSVS. This client wants to >>>> distribute MSVS solution files with the source code so that other >>>> contractors don?t have to install cmake. (There are some restrictions/red >>>> tape for installing additional software on the contractor machines?) >>>> >>> >>> Why not distribute CMake as source code? Compile it so that they don't >>> have to "install" it. >>> >>> On the other hand Visual Studio 2017 comes with their own version of >>> CMake! Just make sure your contractors use VS2017 :D >>> >>> Cheers, >>> Cristian. >>> >>> >> >> -- >> > >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dblaikie at gmail.com Thu Apr 19 20:39:32 2018 From: dblaikie at gmail.com (David Blaikie) Date: Fri, 20 Apr 2018 00:39:32 +0000 Subject: [CMake] Experiments in CMake support for Clang (header & standard) modules Message-ID: Hi there, I'm experimenting with creating examples (& potential changes to CMake itself, if needed/useful) of building clang modules (currently using the semi-backwards compatible "header modules", with the intent of also/moving towards supporting pre-standard C++ modules in development in Clang). The basic commands required are: clang++ -fmodules -xc++ -Xclang -emit-module -Xclang -fmodules-codegen -fmodule-name=foo foo.modulemap -o foo.pcm clang++ -fmodules -c -fmodule-file=foo.pcm use.cpp clang++ -c foo.pcm clang++ foo.o use.o -o a.out My current very simplistic prototype, to build a module file, its respective module object file, and include those in the library/link for anything that depends on this library: add_custom_command( COMMAND ${CMAKE_CXX_COMPILER} ${CMAKE_CXX_FLAGS} -xc++ -c -Xclang -emit-module -fmodules -fmodule-name=Hello ${CMAKE_CURRENT_SOURCE_DIR}/module.modulemap -o ${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm -Xclang -fmodules-codegen DEPENDS module.modulemap hello.h OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm COMMENT "Generating hello_module.pcm" ) add_library (Hello hello.cxx ${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm) target_include_directories(Hello PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}) target_compile_options(Hello PUBLIC -fmodules -Xclang -fmodule-file=${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm) (this is based on the example in the CMake docs using Hello/Demo) This also required one modification to CMake itself to classify a pcm file as a C++ file that needs to be compiled (to execute the 3rd line in the basic command list shown above). But this isn't ideal - I don't /think/ I've got the dependencies quite right & things might not be rebuilding at the right times. Also it involves hardcoding a bunch of things like the pcm file names, header files, etc. Ideally, at least for a simplistic build, I wouldn't mind generating a modulemap from all the .h files (& have those headers listed in the add_library command - perhaps splitting public and private headers in some way, only including the public headers in the module file, likely). Eventually for the standards-proposal version, it's expected that there won't be any modulemap file, but maybe all headers are included in the module compilation (just pass the headers directly to the compiler). This also doesn't start to approach the issue of how to build modules for external libraries - which I'm happy to discuss/prototype too, though interested in working to streamline the inter-library but intra-project (not inter-project) case first. Stephen - I saw you were asking some questions about this here ( https://groups.google.com/a/isocpp.org/forum/#!topic/modules/sDIYoU8Uljw & https://github.com/steveire/ModulesExperiments - didn't really understand how this example applied/worked, though - I guess maybe it's a prototype syntax proposal?) Basically: What do folks think about supporting these sort of features in CMake C++ Builds? Any pointers on how I might best implement this with or without changes to CMake? Thanks a bunch, - Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From kiril at inkbit.xyz Fri Apr 20 22:21:54 2018 From: kiril at inkbit.xyz (=?UTF-8?Q?Kiril_Vidim=C4=8De?=) Date: Fri, 20 Apr 2018 22:21:54 -0400 Subject: [CMake] Disable dependency on a specific shared library Message-ID: I have a shared library that always rebuilds to pick up some build-specific information (including a build time stamp). I would like to make all targets that depend on this library not to relink against it every time that library rebuilds. I am aware of the existence of LINK_DEPENDS_NO_SHARED but it appears that using this property will disable the dependency on ALL shared library for that target. I only want to disable the dependency on the "special" library that gets rebuilt every single time. Furthermore, as far as I can tell, even though LINK_DEPENDS_NO_SHARED prevents relinking of the immediate target that depends on the always-rebuilding-library, targets one level above in the dependency chain are still relinking all of the time. To be clear, here is the dependency chain: AlwaysRebuildingLibrary (ARL) -> PublicLibraryThatPublishesInfoFromARL -> Libraries/Binaries Is there a way to do this without resorting to crazy hacks? Thanks! Kiril -------------- next part -------------- An HTML attachment was scrubbed... URL: From ranjeet.kuruvilla at yahoo.com Sat Apr 21 01:41:59 2018 From: ranjeet.kuruvilla at yahoo.com (Ranjeet Kuruvilla) Date: Sat, 21 Apr 2018 05:41:59 +0000 (UTC) Subject: [CMake] link_libraries References: <824722499.4441323.1524289319420.ref@mail.yahoo.com> Message-ID: <824722499.4441323.1524289319420@mail.yahoo.com> I have read that link_libraries command has gotten deprecated for version 3.10 and instead one needs to use link_librariestarget_link_libraries has one major disadvantage, in that it is required to put that statement after add_executable. I have here a CMake file for many different projects with the same folder structure, that scans a subfolder for files ending with .cmake. Those .cmake files can contain extra includes, definitions and libraries. With link_libraries I can put all statements inside one .cmake file. With target_link_libraries statement however I need 2 .cmake files, one before add_executable and one after for all the libraries. So I ask you to keep link_libraries alive! cmake_minimum_required( VERSION 3.10.0 ) project( ${PROJ_NAME} ${CXX} )enable_language(CXX) set( CMAKE_VERBOSE_MAKEFILE ON) set( OPTIMIZING_FLAGS -O2) set( CUSTOMBUILD "customBuild" ) ...include_directories( BEFORE "/usr/local/include/x86_64-linux-gnu") link_directories( BEFORE "/usr/lib")link_directories( BEFORE "/usr/lib/boost"?... IF(EXISTS ${ CUSTOMBUILD})? ? message("Found custom cmake to build")? ? file( GLOB_RECURSE CMAKE_ITEMS LIST_DIRECTORIES false ${CONST_BASE_PATH_CUSTOMBUILD}*${CMAKE_SUFFIX})? ? foreach(CMAKE_ITEM ${CMAKE_ITEMS})? ? ? ? message("Add cmake file " ${CMAKE_ITEM})? ? ? ? include(${CMAKE_ITEM})? ? endforeach(CMAKE_ITEM)endif()...link_libraries( -lqpidclient -lqpidmessaging) link_libraries( -ljsoncpp)link_libraries( -lpistache)link_libraries( -lboost_system -lboost_thread -lboost_regex -lboost_filesystem -lboost_random -lboost_date_time -lboost_log -lboost_program_options -lboost_signals)link_libraries( -lpulse-simple -lpulse)link_libraries( -lcrypto -lpthread -lcurl)link_libraries( -lgstreamer-1.0 -lgstrtp-1.0 -lgstrtsp-1.0 -lgstsdp-1.0 -lgstbase-1.0 )link_libraries( -lgobject-2.0 -lsigc-2.0)link_libraries( -lssl -levent_openssl)link_libraries( -lcassandra)link_libraries( -lwebsockets)link_libraries( -levent -levent_pthreads -lcrypto -lcrypto++ )link_libraries( -lm -lrt -lz -ldl -lva -lX11 -lm)link_libraries( ${SEASTAR_DIR_LIBS}) add_executable( ${PROJ_NAME} ${SOURCES} ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Sat Apr 21 02:54:59 2018 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sat, 21 Apr 2018 08:54:59 +0200 Subject: [CMake] link_libraries In-Reply-To: <824722499.4441323.1524289319420@mail.yahoo.com> References: <824722499.4441323.1524289319420.ref@mail.yahoo.com> <824722499.4441323.1524289319420@mail.yahoo.com> Message-ID: <12396669.sBU92O8Y9J@daneel.sf-tec.de> Ranjeet Kuruvilla wrote: > I have read that link_libraries command has gotten deprecated for version > 3.10 and instead one needs to use link_librariestarget_link_libraries has > one major disadvantage, in that it is required to put that statement after > add_executable. I have here a CMake file for many different projects with > the same folder structure, that scans a subfolder for files ending with > .cmake. Those .cmake files can contain extra includes, definitions and > libraries. With link_libraries I can put all statements inside one .cmake > file. With target_link_libraries statement however I need 2 .cmake files, > one before add_executable and one after for all the libraries. So I ask you > to keep link_libraries alive! tl;dr: no, surely not, it just adds libraries to probably unrelated targets. > cmake_minimum_required( VERSION 3.10.0 ) > > project( ${PROJ_NAME} ${CXX} )enable_language(CXX) > set( CMAKE_VERBOSE_MAKEFILE ON) > > set( OPTIMIZING_FLAGS -O2) > > set( CUSTOMBUILD "customBuild" ) > ...include_directories( BEFORE "/usr/local/include/x86_64-linux-gnu") That is a compiler specific include, that should never be needed. The compiler adds that anyway, and if you use a different compiler this will probably badly screw things up. > link_directories( BEFORE "/usr/lib") That is a default link directory and is not needed. > link_directories( BEFORE > "/usr/lib/boost" ... > IF(EXISTS ${ CUSTOMBUILD}) > message("Found custom cmake to build") > file( GLOB_RECURSE CMAKE_ITEMS LIST_DIRECTORIES false > ${CONST_BASE_PATH_CUSTOMBUILD}*${CMAKE_SUFFIX}) > foreach(CMAKE_ITEM ${CMAKE_ITEMS}) > message("Add cmake file " ${CMAKE_ITEM}) > include(${CMAKE_ITEM}) > endforeach(CMAKE_ITEM) > endif()... If you like it that way, fine? > link_libraries(-lqpidclient -lqpidmessaging) > link_libraries( -ljsoncpp) > link_libraries( -lpistache) > link_libraries( -lboost_system -lboost_thread -lboost_regex > -lboost_filesystem -lboost_random -lboost_date_time -lboost_log > -lboost_program_options -lboost_signals)link_libraries( -lpulse-simple > -lpulse) > link_libraries( -lcrypto -lpthread -lcurl) > link_libraries(-lgstreamer-1.0 -lgstrtp-1.0 -lgstrtsp-1.0 -lgstsdp-1.0 - lgstbase-1.0) > link_libraries( -lgobject-2.0 -lsigc-2.0) > link_libraries( -lssl -levent_openssl) > link_libraries( -lcassandra) > link_libraries( -lwebsockets) > link_libraries( -levent -levent_pthreads -lcrypto -lcrypto++) > link_libraries( -lm -lrt -lz -ldl -lva -lX11 -lm) > link_libraries(${SEASTAR_DIR_LIBS}) but this is just broken. This will break -when you update one of those libraries and it needs new dependencies -when the libraries have different names e.g. because of a custom build -probably just when you leave your own Linux distro -for sure if you ever go to any other system (*BSD, Mac, Windows) > add_executable( ${PROJ_NAME} ${SOURCES} ) When you use the modern version with (imported) targets you can even skip the include_directories things. I will reduce my example to 2 libraries for clarity, but it will work with the whole bunch also: find_library(OpenSSL REQUIRED) find_library(Boost REQUIRED regex) add_library(foo ...) target_link_libraries(foo # the usage of SSL is buried inside the lib and just an implementation # detail PRIVATE OpenSSL::SSL # a Boost Regex is part of the API, so everyone using this library needs # to get the headers and link to Boost PUBLIC Boost:regex ) add_executable(bar ...) target_link_libraries(bar foo) So bar also links to Boost, it get's all the headers and more needed to use Boost. For the very same reason people started using include-what-you-use one should not use link_libraries: explicitely specify what you need, otherwise you very likely break your build system if any of your dependencies changes and suddenly does not drag in one of your needed pieces anymore. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From andrew.e.brownsword at gmail.com Sat Apr 21 22:39:20 2018 From: andrew.e.brownsword at gmail.com (Andrew Brownsword) Date: Sat, 21 Apr 2018 19:39:20 -0700 Subject: [CMake] Spaces in var=value list in *_command Message-ID: <10CAB6E1-B364-4941-A8A6-696372969F0F@gmail.com> I?m using the externalproject_add command to build a non-cmake project. To the build I am passing CXXFLAGS=value, but I cannot manage to get any spaces into the value no matter how I quote, use variables, use escapes, etc. Searching turns up other people with the same problem and no particularly good solutions. One example was to use cmake_command -E echo to create a wrapper script that contains the desired string, however this isn?t working for me either (its seems to behave as if the cmake_command variable is empty or undefined). This seems WAY harder than it should be... From andrew.e.brownsword at gmail.com Sat Apr 21 22:53:54 2018 From: andrew.e.brownsword at gmail.com (Andrew Brownsword) Date: Sat, 21 Apr 2018 19:53:54 -0700 Subject: [CMake] find_library disobeying NO_DEFAULT_PATH? Message-ID: <0B7B5384-34F0-4300-8029-750C646BAA08@gmail.com> I?m using this command: find_library(LIBPQXX_LIBRARY NAMES libpqxx.a libpqxx PATHS ${LIBPQXX_DEPS_DIR}/src/src PATH_SUFFIXES .libs NO_DEFAULT_PATH) message(STATUS "libpqxx @ " ${LIBPQXX_LIBRARY}) This prints a path to where an older version is installed in /usr/local/lib/. My understanding is that NO_DEFAULT_PATH should limit the search to the supplied PATHS. What am I doing wrong? From andrew.e.brownsword at gmail.com Sun Apr 22 16:20:09 2018 From: andrew.e.brownsword at gmail.com (Andrew Brownsword) Date: Sun, 22 Apr 2018 13:20:09 -0700 Subject: [CMake] find_library disobeying NO_DEFAULT_PATH? In-Reply-To: <0B7B5384-34F0-4300-8029-750C646BAA08@gmail.com> References: <0B7B5384-34F0-4300-8029-750C646BAA08@gmail.com> Message-ID: <8B11DED8-60E0-48FF-9409-9B048AD54A9C@gmail.com> I solved this problem by discovering that found libraries are one of the things cached between runs of cmake. Deleting CMakeCache.txt solves the problem. Hopefully this serves as a warning to people having the same issue. > On Apr 21, 2018, at 7:53 PM, Andrew Brownsword wrote: > > I?m using this command: > > find_library(LIBPQXX_LIBRARY > NAMES libpqxx.a libpqxx > PATHS ${LIBPQXX_DEPS_DIR}/src/src > PATH_SUFFIXES .libs > NO_DEFAULT_PATH) > message(STATUS "libpqxx @ " ${LIBPQXX_LIBRARY}) > > This prints a path to where an older version is installed in /usr/local/lib/. My understanding is that NO_DEFAULT_PATH should limit the search to the supplied PATHS. What am I doing wrong? > From yves.frederix+cmake at gmail.com Mon Apr 23 07:07:59 2018 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Mon, 23 Apr 2018 13:07:59 +0200 Subject: [CMake] Generator expressions containing spaces Message-ID: Hi, I recently learned that the COMMAND line in a custom command supports generator expressions. In particular, what makes this powerful is that if the expression evaluates to the empty string, no corresponding code will be added to the target (as documented in the docs ). While this works very nicely for single-string command, I fail to make it work for commands consisting of multiple space-separated strings: ``` ~/tmp/genex_with_spaces$ cat CMakeLists.txt cmake_minimum_required(VERSION 3.6) add_custom_target(foo) add_custom_command(TARGET foo POST_BUILD COMMAND $<1:echo bar> ) ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make "\$$<1:echo" bar> ``` As can be seen, the generator expression is not expanded. My question is now whether I am doing something wrong (is there a correct way of dealing with spaces in the context of generator expressions?) or might this be an inherent limitation of generator expression in general? As a workaround, the only thing that seems to work is to put each of the space-separated components of the command in (typically identical) genexes: ``` ~/tmp/genex_with_spaces$ cat CMakeLists.txt cmake_minimum_required(VERSION 3.6) add_custom_target(foo) add_custom_command(TARGET foo POST_BUILD COMMAND $<1:echo> $<1:bar> ) ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make echo bar ``` Of course, while this works, things becomes very unreadable if the genex is more complex. Other things that I have tried but failed: - escape the space with a backslash -> this quotes the entire expression inside the genex. - define the command directly as a list inside the genex -> this removes spaces between the different components of the command and quotes that result. - treat the command as a list, perform string operations to wrap each element in the desired regex and convert semicolon to spaces -> again results in the command being quoted as a whole. Any advice is highly appreciated. Thanks, Yves -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at sap.com Mon Apr 23 08:11:25 2018 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Mon, 23 Apr 2018 12:11:25 +0000 Subject: [CMake] Generator expressions containing spaces In-Reply-To: References: Message-ID: <27940B72-D874-4345-A3F5-35A0C51E83F3@sap.com> The space is used to separate arguments passed to COMMAND. So your generator expression is splitted before evaluation and elements are no longer valid generator expression. So, to solve your problem, encapsulate the generator expression inside quotes. And apply the following advices for correct result: * Separate command from args * Use variable to list your arguments and add option COMMAND_EXPAND_LISTS (available with version 3.8) to avoid ?spurious? semi-colons in the result Your example reworked: Set (args foo bar) add_custom_target(foo) add_custom_command(TARGET foo POST_BUILD COMMAND $<1:echo> "$<1 :${args}>" COMMAND_EXPAND_LISTS ) From: CMake on behalf of Yves Frederix Date: Monday 23 April 2018 at 13:08 To: "cmake at cmake.org" Subject: [CMake] Generator expressions containing spaces Hi, I recently learned that the COMMAND line in a custom command supports generator expressions. In particular, what makes this powerful is that if the expression evaluates to the empty string, no corresponding code will be added to the target (as documented in the docs). While this works very nicely for single-string command, I fail to make it work for commands consisting of multiple space-separated strings: ``` ~/tmp/genex_with_spaces$ cat CMakeLists.txt cmake_minimum_required(VERSION 3.6) add_custom_target(foo) add_custom_command(TARGET foo POST_BUILD COMMAND $<1:echo bar> ) ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make "\$$<1:echo" bar> ``` As can be seen, the generator expression is not expanded. My question is now whether I am doing something wrong (is there a correct way of dealing with spaces in the context of generator expressions?) or might this be an inherent limitation of generator expression in general? As a workaround, the only thing that seems to work is to put each of the space-separated components of the command in (typically identical) genexes: ``` ~/tmp/genex_with_spaces$ cat CMakeLists.txt cmake_minimum_required(VERSION 3.6) add_custom_target(foo) add_custom_command(TARGET foo POST_BUILD COMMAND $<1:echo> $<1:bar> ) ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make echo bar ``` Of course, while this works, things becomes very unreadable if the genex is more complex. Other things that I have tried but failed: * escape the space with a backslash -> this quotes the entire expression inside the genex. * define the command directly as a list inside the genex -> this removes spaces between the different components of the command and quotes that result. * treat the command as a list, perform string operations to wrap each element in the desired regex and convert semicolon to spaces -> again results in the command being quoted as a whole. Any advice is highly appreciated. Thanks, Yves -------------- next part -------------- An HTML attachment was scrubbed... URL: From yves.frederix+cmake at gmail.com Mon Apr 23 10:12:50 2018 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Mon, 23 Apr 2018 16:12:50 +0200 Subject: [CMake] Generator expressions containing spaces In-Reply-To: <27940B72-D874-4345-A3F5-35A0C51E83F3@sap.com> References: <27940B72-D874-4345-A3F5-35A0C51E83F3@sap.com> Message-ID: It seems COMMAND_EXPAND_LISTS was indeed the key here. Thanks a lot! Yves On Mon, Apr 23, 2018 at 2:11 PM, CHEVRIER, Marc wrote: > The space is used to separate arguments passed to COMMAND. So your > generator expression is splitted before evaluation and elements are no > longer valid generator expression. > > > > So, to solve your problem, encapsulate the generator expression inside > quotes. And apply the following advices for correct result: > > - Separate command from args > - Use variable to list your arguments and add option > COMMAND_EXPAND_LISTS (available with version 3.8) to avoid ?spurious? > semi-colons in the result > > > > Your example reworked: > > > > Set (args foo bar) > > add_custom_target(foo) > > add_custom_command(TARGET foo POST_BUILD > > COMMAND $<1:echo> "$<1 :${args}>" > > COMMAND_EXPAND_LISTS > > ) > > > > > > *From: *CMake on behalf of Yves Frederix < > yves.frederix+cmake at gmail.com> > *Date: *Monday 23 April 2018 at 13:08 > *To: *"cmake at cmake.org" > *Subject: *[CMake] Generator expressions containing spaces > > > > Hi, > > > > I recently learned that the COMMAND line in a custom command supports > generator expressions. In particular, what makes this powerful is that if > the expression evaluates to the empty string, no corresponding code will be > added to the target (as documented in the docs > > ). > > > > While this works very nicely for single-string command, I fail to make it > work for commands consisting of multiple space-separated strings: > > > > ``` > > ~/tmp/genex_with_spaces$ cat CMakeLists.txt > > cmake_minimum_required(VERSION 3.6) > > > > add_custom_target(foo) > > add_custom_command(TARGET foo POST_BUILD > > COMMAND $<1:echo bar> > > ) > > > > ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make > "\$$<1:echo" bar> > > ``` > > > > As can be seen, the generator expression is not expanded. > > > > My question is now whether I am doing something wrong (is there a correct > way of dealing with spaces in the context of generator expressions?) or > might this be an inherent limitation of generator expression in general? > > > > As a workaround, the only thing that seems to work is to put each of the > space-separated components of the command in (typically identical) genexes: > > > > ``` > > ~/tmp/genex_with_spaces$ cat CMakeLists.txt > > cmake_minimum_required(VERSION 3.6) > > > > add_custom_target(foo) > > add_custom_command(TARGET foo POST_BUILD > > COMMAND $<1:echo> $<1:bar> > > ) > > > > ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make > echo bar > > ``` > > > Of course, while this works, things becomes very unreadable if the genex > is more complex. > > > > Other things that I have tried but failed: > > - escape the space with a backslash -> this quotes the entire > expression inside the genex. > - define the command directly as a list inside the genex -> this > removes spaces between the different components of the command and quotes > that result. > - treat the command as a list, perform string operations to wrap each > element in the desired regex and convert semicolon to spaces -> again > results in the command being quoted as a whole. > > > > Any advice is highly appreciated. > > > > Thanks, > > Yves > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Mon Apr 23 12:54:31 2018 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon, 23 Apr 2018 12:54:31 -0400 Subject: [CMake] Generating MSVS solution files that can be passed around In-Reply-To: References: Message-ID: <9751401a-882b-d7fd-77c4-044fbfebbbe5@kitware.com> One thing to consider is that MS is now shipping CMake as part of VS.? So, if you can get your project to work with that version of VS, you should be all set. In fact you can have people just open the project and MS VS will run CMake for you. -Bill From robert.maynard at kitware.com Mon Apr 23 15:15:11 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 23 Apr 2018 15:15:11 -0400 Subject: [CMake] Spaces in var=value list in *_command In-Reply-To: <10CAB6E1-B364-4941-A8A6-696372969F0F@gmail.com> References: <10CAB6E1-B364-4941-A8A6-696372969F0F@gmail.com> Message-ID: Are you trying to construct a BUILD_COMMAND line that looks like CXXFLAGS=-g -02 -w && ./configure? If so, you should be able to do that with the CMake -E env command option like this ( Starting in CMake 3.1 ): set(cxx_flags "-g -O2 -w") set(command_to_run ${CMAKE_COMMAND} -E environment) ExternalProject_Add(MyProject DOWNLOAD_COMMAND "" CONFIGURE_COMMAND "" BUILD_COMMAND ${CMAKE_COMMAND} -E env CXXFLAGS=${cxx_flags} ${command_to_run} ) On Sat, Apr 21, 2018 at 10:39 PM, Andrew Brownsword < andrew.e.brownsword at gmail.com> wrote: > I?m using the externalproject_add command to build a non-cmake project. > To the build I am passing CXXFLAGS=value, but I cannot manage to get any > spaces into the value no matter how I quote, use variables, use escapes, > etc. Searching turns up other people with the same problem and no > particularly good solutions. One example was to use cmake_command -E echo > to create a wrapper script that contains the desired string, however this > isn?t working for me either (its seems to behave as if the cmake_command > variable is empty or undefined). This seems WAY harder than it should be... > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtrescott at gmail.com Mon Apr 23 17:06:54 2018 From: matthewtrescott at gmail.com (Matthew Trescott) Date: Mon, 23 Apr 2018 17:06:54 -0400 Subject: [CMake] UNKNOWN IMPORTED vs INTERFACE IMPORTED for non-CMake library Message-ID: Hi, I somewhat recently filed a bug report regarding target_link_libraries favoring target names over library names (https://gitlab.kitware.com/cmake/cmake/issues/17911). Brad King suggested also that I switch to UNKNOWN instead of INTERFACE for the IMPORTed targets created by my find-modules. In my case, it seems that an INTERFACE library would be less fragile since it can make use of pkg-config instead of manually calling find_library and find_file. But is INTERFACE considered bad? I have the impression from the add_library documentation that INTERFACE libraries are meant for non-compiled things that are part of the project, but if that is the case, why is there an INTERFACE IMPORTED option? I'm looking for clarification on the difference between INTERFACE IMPORTED and UNKNOWN IMPORTED and whether I should switch my own library to the latter. Matthew Trescott From cristian.adam at gmail.com Tue Apr 24 01:03:22 2018 From: cristian.adam at gmail.com (Cristian Adam) Date: Tue, 24 Apr 2018 07:03:22 +0200 Subject: [CMake] CMake Checks Cache Message-ID: Hi, If you use CMake in a CI you should probably have a look at how to speed up your CMake build: https://github.com/cristianadam/cmake-checks-cache In the case of LLVM + Clang on a Windows box the speed up was either 2.66x or 3.32x, depending on the CMake generator. Even if you don't use CMake Check macros you might want to cache the initial compiler detection, which could take a few seconds :) Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dominique.Ledit at PDGM.com Tue Apr 24 10:19:34 2018 From: Dominique.Ledit at PDGM.com (Dominique Ledit) Date: Tue, 24 Apr 2018 14:19:34 +0000 Subject: [CMake] CDash to report Peforce update Message-ID: Hi I've tried for some time now, to figure out how to configure properly my CDash project to get in the "Update" column of the Dashboard something else than 0, using P4Web as Repository Viewer. First let me give you some details. Our build system is based on cmake 3.9.4. We use ctest to run a set of unit tests (on Both Linux and Windows platforms) in our Continuous Integration system. Our SCM is Perforce I installed some time ago a CDash 2.5.0 Linux server to display the results of the Update, configure, build steps of our Continuous integration. A CtestConfig.cmake is generated in the build directory. ## The following are required to uses Dart and the Cdash dashboard. set(CTEST_PROJECT_NAME "") set(CTEST_NIGHTLY_START_TIME "01:00:00 UTC") set(CTEST_DROP_METHOD "http") set(CTEST_DROP_SITE "") set(CTEST_DROP_LOCATION "/submit.php?project=") set(CTEST_DROP_SITE_CDASH TRUE) # Maximum time allowed before CTest will kill the test. set(CTEST_TEST_TIMEOUT 600) A CTestTestfile.cmake contains the list of Unit Tests to run Finally the ctest script I passed to ctest using the -S option to proceed with the update, the build and run the tests: ctest -D Continuous -S MyCtest.cmake,Continuous --verbose --output-on-failure --timeout 900 -C Release Set: * CTEST_SITE * CTEST_BUILD_NAME * CTEST_PROJECT_NAME * CTEST_NOTES_FILE * CTEST_P4_CLIENT * CTEST_P4_COMMAND to the full path of the p4 command * CTEST_UPDATE_COMMAND to ${ CTEST_P4_COMMAND} * CTEST_SOURCE_DIRECTORY * CTEST_BINARY_DIRECTORY * CTEST_BUILD_COMMAND And run * ctest_start (${CTEST_SCRIPT_ARG}) * ctest_update (SOURCE "${CTEST_SOURCE_DIRECTORY}" RETURN_VALUE update_code) * ctest_build (BUILD "${CTEST_SOURCE_DIRECTORY}/library" RETURN_VALUE build_code) * ctest_test (BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE test_code) * ctest_submit () I got all what I wish in the CDash Dashboard for my Project excepted for the "Update" "Files" column that systematically contains "0" Clicking on the "0" link open a page containing: Files changed on (Build_name ) as of Revision: (/@md=d&cd=&rt=s&thv=d&c=igy@/epos/?ac=43&mx=50&sr= Prior Revision: (/@md=d&cd=&rt=s&thv=d&c=igy@/epos/?ac=43&mx=50&sr= Show Activity Graph Expand All | Collapse all [http://vm-pau-cdash/img/Minus.gif][http://vm-pau-cdash/img/Open.gif] DMP Updated files (0) [http://vm-pau-cdash/img/Minus.gif][http://vm-pau-cdash/img/Open.gif] Modified files (0) [http://vm-pau-cdash/img/Minus.gif][http://vm-pau-cdash/img/Open.gif] Conflicting files (0) Expand All | Collapse All But to get this result I had to modify the /include/repository.php file to make the two "Revision" and "Prior Revision" html links open a page on the P4Web. I modified the get_p4web_revision_url function (use the action code 43 instead of the 64 one and set a max number of CL to 50) function get_p4web_revision_url($projecturl, $revision, $priorrevision) { //$revision_url = $projecturl . '?ac=64&sr=' . $revision; $revision_url = $projecturl . '?ac=43&mx=50&sr=' . $revision; return make_cdash_url($revision_url); } And The get_p4web_diff_url function where the action code 207 leads to an incorrect link function get_p4web_diff_url($projecturl, $directory, $file, $revision) { $diff_url = rtrim($projecturl, '/') . ($directory ? ('/' . $directory) : '') . '/' . $file; if ($revision != '') { $prev_revision = get_previous_revision($revision); if ($prev_revision != $revision) { //$diff_url .= '?ac=207&sr1=' . $prev_revision . '&sr2=' . $revision; $diff_url .= '?ac=64&sr=' . $prev_revision . '&sr2=' . $revision; } else { $diff_url .= '?ac=64&sr=' . $revision; } } return make_cdash_url($diff_url); } I really would like to succeed in setting correctly my CDash project, but still don't find how to set properly for a P4Web Repository Viewer, the following text fields: * Repository Viewer URL * The Repository * The branch * The Username * Password And to fix this always "0" result in the Update column This will be great if someone could give me some advices or tell me what I miss to correctly set the Update column in CDash and have access to the modified files when clicking on the number in the Update column Thank you Dominique Dominique Ledit | Sr. DevOps, Paradigm | Exploration and Production Software Emerson Automation Solutions | 2 av. Pr?sident Pierre Angot | 64000 | Pau | France T 011-33-(0)5-59-72-79-14 dominique.ledit at pdgm.com [cid:image001.jpg at 01D374EE.E75BD4F0] ------------------- This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2426 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 70 bytes Desc: image002.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 787 bytes Desc: image005.png URL: From zbeekman at gmail.com Tue Apr 24 10:30:30 2018 From: zbeekman at gmail.com (Zaak Beekman) Date: Tue, 24 Apr 2018 14:30:30 +0000 Subject: [CMake] Generating MSVS solution files that can be passed around In-Reply-To: References: Message-ID: Hi Bill, Thanks for your response! Yes, I am aware of that MSVS has CMake integration starting in MSVS 2017, but for various reasons, the pace of upgrading or installing new software with the other contractors on the project is limited. Some are stuck with MSVS 2015 which does not yet have native CMake support. I have included CMake binaries for Windows in a vendor subdirectory of the project and wrote a batch file to allow one-click generation of Visual Studio project files using the CMake binary now included with the source code. With one click, the version of MSVS available is queried through registry keys, the machine arch is queried and the included CMake is launched with the correct MSVS version and arch specified to the -G generator flag. Thanks to all for all your help and suggestions! Best, Zaak On Thu, Apr 19, 2018 at 5:37 PM Zaak Beekman wrote: > Thanks Jano, that's the work flow I was considering. > > On Thu, Apr 19, 2018 at 5:33 PM Jano Svitok wrote: > >> You don't have to install cmake. Just get the zip version, unzip in >> somewhere along your sources and you are done. >> I'm not sure whether any runtime dlls are needed, but I suppose not. >> >> We use cmake like that. We've committed a copy in our git repo, and have >> a simple means to update cmake for everyone >> in the team at once. >> >> Jano >> >> On Thu, Apr 19, 2018 at 6:55 PM, Zaak Beekman wrote: >> >>> Ha, yeah that?s an option. The problem is that they?re not ?my? >>> contractors. They are the client?s contractors. We?ll see. >>> On Thu, Apr 19, 2018 at 12:52 PM Cristian Adam >>> wrote: >>> >>>> On Thu, Apr 19, 2018 at 5:46 PM, Zaak Beekman >>>> wrote: >>>> >>>>> The situation is that we have a client who works with other >>>>> contractors who use almost exclusively windows and MSVS. This client wants >>>>> to distribute MSVS solution files with the source code so that other >>>>> contractors don?t have to install cmake. (There are some restrictions/red >>>>> tape for installing additional software on the contractor machines?) >>>>> >>>> >>>> Why not distribute CMake as source code? Compile it so that they don't >>>> have to "install" it. >>>> >>>> On the other hand Visual Studio 2017 comes with their own version of >>>> CMake! Just make sure your contractors use VS2017 :D >>>> >>>> Cheers, >>>> Cristian. >>>> >>>> >>> >>> -- >>> >> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> https://cmake.org/mailman/listinfo/cmake >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Tue Apr 24 12:58:21 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 24 Apr 2018 18:58:21 +0200 Subject: [CMake] Generator expressions containing spaces In-Reply-To: <27940B72-D874-4345-A3F5-35A0C51E83F3@sap.com> References: <27940B72-D874-4345-A3F5-35A0C51E83F3@sap.com> Message-ID: 2018-04-23 14:11 GMT+02:00 CHEVRIER, Marc : > The space is used to separate arguments passed to COMMAND. So your generator > expression is splitted before evaluation and elements are no longer valid > generator expression. > > > > So, to solve your problem, encapsulate the generator expression inside > quotes. And apply the following advices for correct result: > > Separate command from args > Use variable to list your arguments and add option COMMAND_EXPAND_LISTS > (available with version 3.8) to avoid ?spurious? semi-colons in the result > > > > Your example reworked: > > > > Set (args foo bar) > > add_custom_target(foo) > > add_custom_command(TARGET foo POST_BUILD > > COMMAND $<1:echo> "$<1 :${args}>" > > COMMAND_EXPAND_LISTS > > ) > Interesting thread. I was sort of in the same boat, having a add_compile_options( "$<$:-Wall>" "$<$:-Wextra>" "$<$:-Werror>" "$<$:-Wall>" "$<$:-Wextra>" "$<$:-Werror>" "$<$:-Wall>" "$<$:-Wextra>" "$<$:-Werror>" ) and of course wishing I could just write something like add_compile_options( $<$:-Wall -Wextra -Werror> $<$:-Wall -Wextra -Werror> $<$:-Wall -Wextra -Werror> ) instead. I can't depend on CMake 3.8+ just yet, but I'll remember your solution for when I can. I don't quite like having to introduce variables though. Is there no way to solve this without having to first stuff the elements in a list and use that? Cheers, Elvis > > > > > From: CMake on behalf of Yves Frederix > > Date: Monday 23 April 2018 at 13:08 > To: "cmake at cmake.org" > Subject: [CMake] Generator expressions containing spaces > > > > Hi, > > > > I recently learned that the COMMAND line in a custom command supports > generator expressions. In particular, what makes this powerful is that if > the expression evaluates to the empty string, no corresponding code will be > added to the target (as documented in the docs). > > > > While this works very nicely for single-string command, I fail to make it > work for commands consisting of multiple space-separated strings: > > > > ``` > > ~/tmp/genex_with_spaces$ cat CMakeLists.txt > cmake_minimum_required(VERSION 3.6) > > > > add_custom_target(foo) > > add_custom_command(TARGET foo POST_BUILD > > COMMAND $<1:echo bar> > > ) > > > > ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make > "\$$<1:echo" bar> > > ``` > > > > As can be seen, the generator expression is not expanded. > > > > My question is now whether I am doing something wrong (is there a correct > way of dealing with spaces in the context of generator expressions?) or > might this be an inherent limitation of generator expression in general? > > > > As a workaround, the only thing that seems to work is to put each of the > space-separated components of the command in (typically identical) genexes: > > > > ``` > > ~/tmp/genex_with_spaces$ cat CMakeLists.txt > cmake_minimum_required(VERSION 3.6) > > > > add_custom_target(foo) > > add_custom_command(TARGET foo POST_BUILD > > COMMAND $<1:echo> $<1:bar> > > ) > > > > ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make > echo bar > > ``` > > > Of course, while this works, things becomes very unreadable if the genex is > more complex. > > > > Other things that I have tried but failed: > > escape the space with a backslash -> this quotes the entire expression > inside the genex. > define the command directly as a list inside the genex -> this removes > spaces between the different components of the command and quotes that > result. > treat the command as a list, perform string operations to wrap each element > in the desired regex and convert semicolon to spaces -> again results in the > command being quoted as a whole. > > > > Any advice is highly appreciated. > > > > Thanks, > > Yves > > > > > > > > > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > From elvis.stansvik at orexplore.com Tue Apr 24 13:03:31 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 24 Apr 2018 19:03:31 +0200 Subject: [CMake] Generator expressions containing spaces In-Reply-To: References: <27940B72-D874-4345-A3F5-35A0C51E83F3@sap.com> Message-ID: 2018-04-24 18:58 GMT+02:00 Elvis Stansvik : > 2018-04-23 14:11 GMT+02:00 CHEVRIER, Marc : >> The space is used to separate arguments passed to COMMAND. So your generator >> expression is splitted before evaluation and elements are no longer valid >> generator expression. >> >> >> >> So, to solve your problem, encapsulate the generator expression inside >> quotes. And apply the following advices for correct result: >> >> Separate command from args >> Use variable to list your arguments and add option COMMAND_EXPAND_LISTS >> (available with version 3.8) to avoid ?spurious? semi-colons in the result >> >> >> >> Your example reworked: >> >> >> >> Set (args foo bar) >> >> add_custom_target(foo) >> >> add_custom_command(TARGET foo POST_BUILD >> >> COMMAND $<1:echo> "$<1 :${args}>" >> >> COMMAND_EXPAND_LISTS >> >> ) >> > > Interesting thread. I was sort of in the same boat, having a > > add_compile_options( > "$<$:-Wall>" > "$<$:-Wextra>" > "$<$:-Werror>" > > "$<$:-Wall>" > "$<$:-Wextra>" > "$<$:-Werror>" > > "$<$:-Wall>" > "$<$:-Wextra>" > "$<$:-Werror>" > ) Sidenote: I know that in this case, since I want the same flags for all three of these compilers, I could "simplify" it using an $, but that's a separate thing (and I decided against it since it gives such long unreadable lines). Elvis > > and of course wishing I could just write something like > > add_compile_options( > $<$:-Wall -Wextra -Werror> > $<$:-Wall -Wextra -Werror> > $<$:-Wall -Wextra -Werror> > ) > > instead. > > I can't depend on CMake 3.8+ just yet, but I'll remember your solution > for when I can. > > I don't quite like having to introduce variables though. Is there no > way to solve this without having to first stuff the elements in a list > and use that? > > Cheers, > Elvis > >> >> >> >> >> From: CMake on behalf of Yves Frederix >> >> Date: Monday 23 April 2018 at 13:08 >> To: "cmake at cmake.org" >> Subject: [CMake] Generator expressions containing spaces >> >> >> >> Hi, >> >> >> >> I recently learned that the COMMAND line in a custom command supports >> generator expressions. In particular, what makes this powerful is that if >> the expression evaluates to the empty string, no corresponding code will be >> added to the target (as documented in the docs). >> >> >> >> While this works very nicely for single-string command, I fail to make it >> work for commands consisting of multiple space-separated strings: >> >> >> >> ``` >> >> ~/tmp/genex_with_spaces$ cat CMakeLists.txt >> cmake_minimum_required(VERSION 3.6) >> >> >> >> add_custom_target(foo) >> >> add_custom_command(TARGET foo POST_BUILD >> >> COMMAND $<1:echo bar> >> >> ) >> >> >> >> ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make >> "\$$<1:echo" bar> >> >> ``` >> >> >> >> As can be seen, the generator expression is not expanded. >> >> >> >> My question is now whether I am doing something wrong (is there a correct >> way of dealing with spaces in the context of generator expressions?) or >> might this be an inherent limitation of generator expression in general? >> >> >> >> As a workaround, the only thing that seems to work is to put each of the >> space-separated components of the command in (typically identical) genexes: >> >> >> >> ``` >> >> ~/tmp/genex_with_spaces$ cat CMakeLists.txt >> cmake_minimum_required(VERSION 3.6) >> >> >> >> add_custom_target(foo) >> >> add_custom_command(TARGET foo POST_BUILD >> >> COMMAND $<1:echo> $<1:bar> >> >> ) >> >> >> >> ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make >> echo bar >> >> ``` >> >> >> Of course, while this works, things becomes very unreadable if the genex is >> more complex. >> >> >> >> Other things that I have tried but failed: >> >> escape the space with a backslash -> this quotes the entire expression >> inside the genex. >> define the command directly as a list inside the genex -> this removes >> spaces between the different components of the command and quotes that >> result. >> treat the command as a list, perform string operations to wrap each element >> in the desired regex and convert semicolon to spaces -> again results in the >> command being quoted as a whole. >> >> >> >> Any advice is highly appreciated. >> >> >> >> Thanks, >> >> Yves >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake >> From rcdailey.lists at gmail.com Tue Apr 24 14:25:21 2018 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 24 Apr 2018 13:25:21 -0500 Subject: [CMake] How to make RUN_TESTS build projects first? Message-ID: I'd like RUN_TESTS to build the executable targets that are tied to add_test() commands prior to running the tests themselves. Note I'm doing this from within Visual Studio. Is there a way I can set up CMake to do this? From yves.frederix+cmake at gmail.com Tue Apr 24 15:37:57 2018 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Tue, 24 Apr 2018 21:37:57 +0200 Subject: [CMake] Generator expressions containing spaces In-Reply-To: References: <27940B72-D874-4345-A3F5-35A0C51E83F3@sap.com> Message-ID: There is no real need to go through an intermediate variable. The following should work: add_compile_options( "$<$:-Wall;-Wextra;-Werror>" ) Yves On Tue, Apr 24, 2018 at 6:58 PM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > 2018-04-23 14:11 GMT+02:00 CHEVRIER, Marc : > > The space is used to separate arguments passed to COMMAND. So your > generator > > expression is splitted before evaluation and elements are no longer valid > > generator expression. > > > > > > > > So, to solve your problem, encapsulate the generator expression inside > > quotes. And apply the following advices for correct result: > > > > Separate command from args > > Use variable to list your arguments and add option COMMAND_EXPAND_LISTS > > (available with version 3.8) to avoid ?spurious? semi-colons in the > result > > > > > > > > Your example reworked: > > > > > > > > Set (args foo bar) > > > > add_custom_target(foo) > > > > add_custom_command(TARGET foo POST_BUILD > > > > COMMAND $<1:echo> "$<1 :${args}>" > > > > COMMAND_EXPAND_LISTS > > > > ) > > > > Interesting thread. I was sort of in the same boat, having a > > add_compile_options( > "$<$:-Wall>" > "$<$:-Wextra>" > "$<$:-Werror>" > > "$<$:-Wall>" > "$<$:-Wextra>" > "$<$:-Werror>" > > "$<$:-Wall>" > "$<$:-Wextra>" > "$<$:-Werror>" > ) > > and of course wishing I could just write something like > > add_compile_options( > $<$:-Wall -Wextra -Werror> > $<$:-Wall -Wextra -Werror> > $<$:-Wall -Wextra -Werror> > ) > > instead. > > I can't depend on CMake 3.8+ just yet, but I'll remember your solution > for when I can. > > I don't quite like having to introduce variables though. Is there no > way to solve this without having to first stuff the elements in a list > and use that? > > Cheers, > Elvis > > > > > > > > > > > From: CMake on behalf of Yves Frederix > > > > Date: Monday 23 April 2018 at 13:08 > > To: "cmake at cmake.org" > > Subject: [CMake] Generator expressions containing spaces > > > > > > > > Hi, > > > > > > > > I recently learned that the COMMAND line in a custom command supports > > generator expressions. In particular, what makes this powerful is that if > > the expression evaluates to the empty string, no corresponding code will > be > > added to the target (as documented in the docs). > > > > > > > > While this works very nicely for single-string command, I fail to make it > > work for commands consisting of multiple space-separated strings: > > > > > > > > ``` > > > > ~/tmp/genex_with_spaces$ cat CMakeLists.txt > > cmake_minimum_required(VERSION 3.6) > > > > > > > > add_custom_target(foo) > > > > add_custom_command(TARGET foo POST_BUILD > > > > COMMAND $<1:echo bar> > > > > ) > > > > > > > > ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make > > "\$$<1:echo" bar> > > > > ``` > > > > > > > > As can be seen, the generator expression is not expanded. > > > > > > > > My question is now whether I am doing something wrong (is there a correct > > way of dealing with spaces in the context of generator expressions?) or > > might this be an inherent limitation of generator expression in general? > > > > > > > > As a workaround, the only thing that seems to work is to put each of the > > space-separated components of the command in (typically identical) > genexes: > > > > > > > > ``` > > > > ~/tmp/genex_with_spaces$ cat CMakeLists.txt > > cmake_minimum_required(VERSION 3.6) > > > > > > > > add_custom_target(foo) > > > > add_custom_command(TARGET foo POST_BUILD > > > > COMMAND $<1:echo> $<1:bar> > > > > ) > > > > > > > > ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make > > echo bar > > > > ``` > > > > > > Of course, while this works, things becomes very unreadable if the genex > is > > more complex. > > > > > > > > Other things that I have tried but failed: > > > > escape the space with a backslash -> this quotes the entire expression > > inside the genex. > > define the command directly as a list inside the genex -> this removes > > spaces between the different components of the command and quotes that > > result. > > treat the command as a list, perform string operations to wrap each > element > > in the desired regex and convert semicolon to spaces -> again results in > the > > command being quoted as a whole. > > > > > > > > Any advice is highly appreciated. > > > > > > > > Thanks, > > > > Yves > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > https://cmake.org/mailman/listinfo/cmake > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Wed Apr 25 01:53:18 2018 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 25 Apr 2018 07:53:18 +0200 Subject: [CMake] Generator expressions containing spaces In-Reply-To: References: <27940B72-D874-4345-A3F5-35A0C51E83F3@sap.com> Message-ID: 2018-04-24 21:37 GMT+02:00 Yves Frederix : > There is no real need to go through an intermediate variable. The following > should work: > > add_compile_options( > "$<$:-Wall;-Wextra;-Werror>" > ) Ah, of course. Thanks. Elvis > > Yves > > > On Tue, Apr 24, 2018 at 6:58 PM, Elvis Stansvik > wrote: >> >> 2018-04-23 14:11 GMT+02:00 CHEVRIER, Marc : >> > The space is used to separate arguments passed to COMMAND. So your >> > generator >> > expression is splitted before evaluation and elements are no longer >> > valid >> > generator expression. >> > >> > >> > >> > So, to solve your problem, encapsulate the generator expression inside >> > quotes. And apply the following advices for correct result: >> > >> > Separate command from args >> > Use variable to list your arguments and add option COMMAND_EXPAND_LISTS >> > (available with version 3.8) to avoid ?spurious? semi-colons in the >> > result >> > >> > >> > >> > Your example reworked: >> > >> > >> > >> > Set (args foo bar) >> > >> > add_custom_target(foo) >> > >> > add_custom_command(TARGET foo POST_BUILD >> > >> > COMMAND $<1:echo> "$<1 :${args}>" >> > >> > COMMAND_EXPAND_LISTS >> > >> > ) >> > >> >> Interesting thread. I was sort of in the same boat, having a >> >> add_compile_options( >> "$<$:-Wall>" >> "$<$:-Wextra>" >> "$<$:-Werror>" >> >> "$<$:-Wall>" >> "$<$:-Wextra>" >> "$<$:-Werror>" >> >> "$<$:-Wall>" >> "$<$:-Wextra>" >> "$<$:-Werror>" >> ) >> >> and of course wishing I could just write something like >> >> add_compile_options( >> $<$:-Wall -Wextra -Werror> >> $<$:-Wall -Wextra -Werror> >> $<$:-Wall -Wextra -Werror> >> ) >> >> instead. >> >> I can't depend on CMake 3.8+ just yet, but I'll remember your solution >> for when I can. >> >> I don't quite like having to introduce variables though. Is there no >> way to solve this without having to first stuff the elements in a list >> and use that? >> >> Cheers, >> Elvis >> >> > >> > >> > >> > >> > From: CMake on behalf of Yves Frederix >> > >> > Date: Monday 23 April 2018 at 13:08 >> > To: "cmake at cmake.org" >> > Subject: [CMake] Generator expressions containing spaces >> > >> > >> > >> > Hi, >> > >> > >> > >> > I recently learned that the COMMAND line in a custom command supports >> > generator expressions. In particular, what makes this powerful is that >> > if >> > the expression evaluates to the empty string, no corresponding code will >> > be >> > added to the target (as documented in the docs). >> > >> > >> > >> > While this works very nicely for single-string command, I fail to make >> > it >> > work for commands consisting of multiple space-separated strings: >> > >> > >> > >> > ``` >> > >> > ~/tmp/genex_with_spaces$ cat CMakeLists.txt >> > cmake_minimum_required(VERSION 3.6) >> > >> > >> > >> > add_custom_target(foo) >> > >> > add_custom_command(TARGET foo POST_BUILD >> > >> > COMMAND $<1:echo bar> >> > >> > ) >> > >> > >> > >> > ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make >> > "\$$<1:echo" bar> >> > >> > ``` >> > >> > >> > >> > As can be seen, the generator expression is not expanded. >> > >> > >> > >> > My question is now whether I am doing something wrong (is there a >> > correct >> > way of dealing with spaces in the context of generator expressions?) or >> > might this be an inherent limitation of generator expression in general? >> > >> > >> > >> > As a workaround, the only thing that seems to work is to put each of the >> > space-separated components of the command in (typically identical) >> > genexes: >> > >> > >> > >> > ``` >> > >> > ~/tmp/genex_with_spaces$ cat CMakeLists.txt >> > cmake_minimum_required(VERSION 3.6) >> > >> > >> > >> > add_custom_target(foo) >> > >> > add_custom_command(TARGET foo POST_BUILD >> > >> > COMMAND $<1:echo> $<1:bar> >> > >> > ) >> > >> > >> > >> > ~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make >> > echo bar >> > >> > ``` >> > >> > >> > Of course, while this works, things becomes very unreadable if the genex >> > is >> > more complex. >> > >> > >> > >> > Other things that I have tried but failed: >> > >> > escape the space with a backslash -> this quotes the entire expression >> > inside the genex. >> > define the command directly as a list inside the genex -> this removes >> > spaces between the different components of the command and quotes that >> > result. >> > treat the command as a list, perform string operations to wrap each >> > element >> > in the desired regex and convert semicolon to spaces -> again results in >> > the >> > command being quoted as a whole. >> > >> > >> > >> > Any advice is highly appreciated. >> > >> > >> > >> > Thanks, >> > >> > Yves >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > -- >> > >> > Powered by www.kitware.com >> > >> > Please keep messages on-topic and check the CMake FAQ at: >> > http://www.cmake.org/Wiki/CMake_FAQ >> > >> > Kitware offers various services to support the CMake community. For more >> > information on each offering, please visit: >> > >> > CMake Support: http://cmake.org/cmake/help/support.html >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> > CMake Training Courses: http://cmake.org/cmake/help/training.html >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > https://cmake.org/mailman/listinfo/cmake >> > > > From alfred at huji.fr Wed Apr 25 07:03:06 2018 From: alfred at huji.fr (Alfred Sawaya) Date: Wed, 25 Apr 2018 11:03:06 +0000 Subject: [CMake] [CMAKE] make package works but ninja package does not Message-ID: Hello folks, I ran into an issue today and I think it is an unexpected behaviour. I have a CMake project that build an external project (autotools) and pack it into a .deb. It works when I use the Makefile generator (cmake /my/path) but it does not when I use the Ninja generator (cmake -G Ninja /my/path) -> it produces an valid but empty package. I expected that the behaviour would be the same regardless the generator I use. Is that correct ? *Here is the complete CMakeLists.txt : * project(sqlcipher) cmake_minimum_required (VERSION 2.8) include(ExternalProject) ExternalProject_Add( lsqlcipher GIT_REPOSITORY https://github.com/sqlcipher/sqlcipher.git BUILD_IN_SOURCE true CONFIGURE_COMMAND ./configure --enable-tempstore=yes "CFLAGS=-DSQLITE_HAS_CODEC" ) SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libssl1.0.2,libssl-dev") SET(CPACK_DEBIAN_PACKAGE_PROVIDES "libqlcipher0, libsqlcipher-dev, sqlcipher") SET(CPACK_DEBIAN_PACKAGE_REPLACES ${CPACK_DEBIAN_PACKAGE_PROVIDES}) SET(CPACK_GENERATOR "DEB") SET(CPACK_PACKAGE_NAME "my-sqlcipher") SET(CPACK_PACKAGE_VERSION "3.20.1") SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Me") SET(CPACK_DEBIAN_PACKAGE_DESCRIPTION "Install the last version of sqlcipher") SET(CPACK_DEBIAN_PACKAGE_ARCHITECTURE "all") SET(CPACK_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}_${CPACK_PACKAGE_VERSION}_${CPACK_DEBIAN_PACKAGE_ARCHITECTURE}") INCLUDE(CPack) *To reproduce : * 1. Copy the CMakeLists.txt content to a file 2. mkdir build 3. cd build 4. cmake .. 5. make package 6. dpkg -c *.deb # => there is contents 7. rm -rf * 8. cmake -G Ninja .. 9. ninja package 10. dpkg -c *.deb # => it is empty... Any idea of what I am doing wrong ? Or is it a bug in CMake/CPack ? Thank you, Alfred -- Cordialement, Alfred Sawaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfred at huji.fr Wed Apr 25 08:03:42 2018 From: alfred at huji.fr (Alfred Sawaya) Date: Wed, 25 Apr 2018 12:03:42 +0000 Subject: [CMake] [CMAKE] make package works but ninja package does not In-Reply-To: References: Message-ID: The only difference is about the usage of preinstall target. The Ninja generator does not use it, and it should because it need to build sqlcipher before packaging it... the interesting part of vimdiff of cpack --trace : * Unix Makefiles | Ninja* CPack: Install projects | CPack: Install projects ---------------------------------------------- --------| CPack: - Run preinstall target for: sqlcipher CPack: - Install project: sqlcipher | CPack: - Install project: sqlcipher Regards, Le mer. 25 avr. 2018 ? 13:03, Alfred Sawaya a ?crit : > Hello folks, > > I ran into an issue today and I think it is an unexpected behaviour. > > I have a CMake project that build an external project (autotools) and pack > it into a .deb. > It works when I use the Makefile generator (cmake /my/path) but it does > not when I use the Ninja generator (cmake -G Ninja /my/path) -> it produces > an valid but empty package. > > I expected that the behaviour would be the same regardless the generator I > use. Is that correct ? > > *Here is the complete CMakeLists.txt : * > > project(sqlcipher) > cmake_minimum_required (VERSION 2.8) > include(ExternalProject) > > ExternalProject_Add( > lsqlcipher > GIT_REPOSITORY https://github.com/sqlcipher/sqlcipher.git > BUILD_IN_SOURCE true > CONFIGURE_COMMAND ./configure --enable-tempstore=yes > "CFLAGS=-DSQLITE_HAS_CODEC" > ) > > SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libssl1.0.2,libssl-dev") > SET(CPACK_DEBIAN_PACKAGE_PROVIDES "libqlcipher0, libsqlcipher-dev, > sqlcipher") > SET(CPACK_DEBIAN_PACKAGE_REPLACES ${CPACK_DEBIAN_PACKAGE_PROVIDES}) > SET(CPACK_GENERATOR "DEB") > SET(CPACK_PACKAGE_NAME "my-sqlcipher") > SET(CPACK_PACKAGE_VERSION "3.20.1") > SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Me") > SET(CPACK_DEBIAN_PACKAGE_DESCRIPTION "Install the last version of > sqlcipher") > SET(CPACK_DEBIAN_PACKAGE_ARCHITECTURE "all") > SET(CPACK_PACKAGE_FILE_NAME > "${CPACK_PACKAGE_NAME}_${CPACK_PACKAGE_VERSION}_${CPACK_DEBIAN_PACKAGE_ARCHITECTURE}") > INCLUDE(CPack) > > *To reproduce : * > > 1. Copy the CMakeLists.txt content to a file > 2. mkdir build > 3. cd build > 4. cmake .. > 5. make package > 6. dpkg -c *.deb # => there is contents > 7. rm -rf * > 8. cmake -G Ninja .. > 9. ninja package > 10. dpkg -c *.deb # => it is empty... > > Any idea of what I am doing wrong ? Or is it a bug in CMake/CPack ? > > Thank you, > > Alfred > -- > Cordialement, > Alfred Sawaya > -- Cordialement, Alfred Sawaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From sancelot at numalliance.com Wed Apr 25 09:40:45 2018 From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=) Date: Wed, 25 Apr 2018 15:40:45 +0200 Subject: [CMake] swig module add -fPIC flag Message-ID: <6b99e269-cce7-6edb-182a-45a5ee81f3d4@numalliance.com> Hi, I have not found how to add -fPIC link flag to a SWIG module. Regards S.Ancelot From marc.chevrier at sap.com Wed Apr 25 10:03:39 2018 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Wed, 25 Apr 2018 14:03:39 +0000 Subject: [CMake] swig module add -fPIC flag In-Reply-To: <6b99e269-cce7-6edb-182a-45a5ee81f3d4@numalliance.com> References: <6b99e269-cce7-6edb-182a-45a5ee81f3d4@numalliance.com> Message-ID: <2d6011d61c4541d58846fb8c2e68e1df@sap.com> swig modules created with command SWIG_ADD_LIBRARY are "standard" CMake targets so, same approach apply. >From convenience, you can use command SWIG_LINK_LIBRARIES (same semantic as TARGET_LINK_LIBRARIES) to manage custom link flags. Now, regarding specifically flag -fPIC you can manage more easily and in a portable way the 'Position Independent Code' generation by setting variable CMAKE_POSITION_INDEPENDENT_CODE=ON. And I think this flag is for the compiler, not the linker... ________________________________ From: CMake on behalf of St?phane Ancelot Sent: Wednesday, April 25, 2018 3:40:45 PM To: cmake at cmake.org Subject: [CMake] swig module add -fPIC flag Hi, I have not found how to add -fPIC link flag to a SWIG module. Regards S.Ancelot -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From neundorf at kde.org Thu Apr 26 17:23:43 2018 From: neundorf at kde.org (Alexander Neundorf) Date: Thu, 26 Apr 2018 23:23:43 +0200 Subject: [CMake] How to handle dependencies of protobuf files ? Message-ID: <52580760.EqS8eMovER@linux-l7nd> Hi, I stumbled upon a problem with protobuf files, I attached a testcase. There is a MyBase.proto, which is "imported" by Complex.proto. If MyBase.proto is modified, protoc is run again in MyBase.proto, but not on Complex.proto, although it should. You can have a look at the attached example. The message MyData (in Complex.proto) has a member MyBase b1. If I rename the message MyBase (in MyBase.proto) e.g. to MyBaseXYZ, then the build fails, because Complex.pb.h was not regenerated, so it still refered to the now not existing class MyBase. Is there already a solution to handle this ? I think to do it properly, there would have to be a dependency scanning for proto files like there is for C/C++ headers. Parsing at the proto-files at cmake time wouldn't be good enough (since editing a proto file doesn't trigger a cmake run). Comments ? Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: protodeps.tar.gz Type: application/x-compressed-tar Size: 897 bytes Desc: not available URL: From sjm324 at cornell.edu Fri Apr 27 03:49:23 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Fri, 27 Apr 2018 00:49:23 -0700 Subject: [CMake] Help Accommodating Ninja when including CMAKE_CURRENT_BINARY_DIR Message-ID: <0608528B-90C0-4FCE-915D-8398D202DD14@cornell.edu> Hello, I have looked around and seen a few issues discussing this, but have not seen any solutions. It seems related to this: https://gitlab.kitware.com/cmake/cmake/issues/17450 In the sense that absolute paths are desired. 1. Previously, we were generating a file called `${CMAKE_CURRENT_BINARY_DIR}/nanogui_resources.h` and performing `include_directories(${CMAKE_CURRENT_BINARY_DIR})`. This **works correctly**. 2. The setup was changed to generate the file `${CMAKE_CURRENT_BINARY_DIR}/nanogui/resources.h`. That is, the introduction of a new folder `nanogui`. With the same `include_directories(${CMAKE_CURRENT_BINARY_DIR})`, there is now a failure being unable to find ``. Strangely, building with `ninja || ninja` (just building again after first failure) will succeed. I was reading this discussion: https://public.kitware.com/pipermail/cmake-developers/2013-March/018398.html and the underlying cause seems to be the that Ninja wants relative paths. Why is creating this sub-directory causing this issue? Is there a way to keep generating ${CMAKE_CURRENT_BINARY_DIR}/nanogui and be able to include it with Ninja? I tried forcing a add_definitions(-I${CMAKE_CURRENT_BINARY_DIR}) just for shiggles, but that resulted in the same scenario. So it seems like I need a way to force a verbatim include path ?after? the Ninja generator makes things relative? Reverting to the old version is not ideal, since it creates installation problems (the reason the subdirectory nanogui was created). Thank you for any advice! -Stephen P.S. This is with CMake 3.11.1 and ninja 1.8.2 if it matters. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjm324 at cornell.edu Fri Apr 27 05:19:45 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Fri, 27 Apr 2018 02:19:45 -0700 Subject: [CMake] Help Accommodating Ninja when including CMAKE_CURRENT_BINARY_DIR In-Reply-To: <0608528B-90C0-4FCE-915D-8398D202DD14@cornell.edu> References: <0608528B-90C0-4FCE-915D-8398D202DD14@cornell.edu> Message-ID: <2124A2DE-7EB1-4856-9720-BC524137B9CE@cornell.edu> Upon further inspection, it seems more related to PRE_BUILD. The step to generating the files is through a add_custom_command call, which from the docs apparently may end up being PRE_LINK. I tried generating into the ${CMAKE_CURRENT_SOURCE}/include/nanogui, which will work for Makefiles but not for Ninja. So it seems that maybe this is not a pathing issue at all, but instead an order of operations issue. If the Ninja generator ends up having this as PRE_LINK, the files haven?t been generated yet. That doesn?t quite explain why it worked previously, but perhaps the original setup was inherently flawed by relying on PRE_BUILD which is not a guaranteed order. Does anybody have thoughts on how to change things? The files cannot be compiled on their own, but maybe I should instead create a fake target and make it a dependency of the real (object) library that needs them. I keep messing that up, but this seems the most promising. -Stephen From alexis.jeandet at member.fsf.org Fri Apr 27 10:31:03 2018 From: alexis.jeandet at member.fsf.org (Jeandet Alexis) Date: Fri, 27 Apr 2018 16:31:03 +0200 Subject: [CMake] cmake --find-package deprecated? In-Reply-To: <5479730.WHf7AIsqvu@linux-l7nd> References: <1522764118.3783.102.camel@member.fsf.org> <5479730.WHf7AIsqvu@linux-l7nd> Message-ID: Hi Alexander, all, here is a WIP patch https://gitlab.kitware.com/cmake/cmake/merge_requests/2017 Any advise, help on how to improve this is welcome. Alexis. On Tue, 2018-04-03 at 22:00 +0200, Alexander Neundorf wrote: > On 2018 M04 3, Tue 16:01:58 CEST jeandet wrote: > > Hi all, > > > > Reading the documentation I can see: > > https://cmake.org/cmake/help/v3.11/manual/cmake.1.html?highlight=fi > > nd%2 > > 0package#find-package-tool-mode id="-x-evo-selection-start-marker"> > > " > > Note > > > > This mode is not well-supported due to some technical limitations. > > It > > is kept for compatibility but should not be used in new projects. > > " > > > > Does this means that: > > 1) We will always support this but it's limited. > > 2) We will be supported for a long time, but you shouldn't use > > it. > > 3) We plan to remove this soon, don't use this! > > I think it's in 2). > > > In fact this mode would really be useful outside of CMake, to use > > libraries/stuff which doesn't provide pc files but only CMake > > packages. > > Even if this has limitations, it's better than nothing. > > Yes, that was my motivation a few years back. > There is even a cmake.m4 which adds a cmake_find_package macro for > configure. > > Since then, there was close to no feedback. > I also can't remember any volunteer contributions for this feature. > Currently it has more limitations than it had 7 or 8 years ago or so. > > The idea was to run cmake in script mode, and basically just execute > the > requested FindFoo.cmake script, which basically searches a set of > directories > and returns the results. > With imported targets, their link interfaces and e.g. generator > expressions > things got more complicated. > > I'd be happy if somebody picks up the work and makes this feature > work > properly. > > Alex > From robert.maynard at kitware.com Fri Apr 27 11:22:58 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 27 Apr 2018 11:22:58 -0400 Subject: [CMake] Help Accommodating Ninja when including CMAKE_CURRENT_BINARY_DIR In-Reply-To: <2124A2DE-7EB1-4856-9720-BC524137B9CE@cornell.edu> References: <0608528B-90C0-4FCE-915D-8398D202DD14@cornell.edu> <2124A2DE-7EB1-4856-9720-BC524137B9CE@cornell.edu> Message-ID: I recommend going with the custom target / custom command route. On Fri, Apr 27, 2018 at 5:19 AM, Stephen McDowell wrote: > Upon further inspection, it seems more related to PRE_BUILD. The step to > generating the files is through a add_custom_command call, which from the > docs apparently may end up being PRE_LINK. > > I tried generating into the ${CMAKE_CURRENT_SOURCE}/include/nanogui, > which will work for Makefiles but not for Ninja. > > So it seems that maybe this is not a pathing issue at all, but instead an > order of operations issue. If the Ninja generator ends up having this as > PRE_LINK, the files haven?t been generated yet. > > That doesn?t quite explain why it worked previously, but perhaps the > original setup was inherently flawed by relying on PRE_BUILD which is not a > guaranteed order. > > Does anybody have thoughts on how to change things? The files cannot be > compiled on their own, but maybe I should instead create a fake target and > make it a dependency of the real (object) library that needs them. I keep > messing that up, but this seems the most promising. > > -Stephen > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Fri Apr 27 18:06:45 2018 From: scott at towel42.com (Scott Bloom) Date: Fri, 27 Apr 2018 22:06:45 +0000 Subject: [CMake] Multiple "projects" one directory Message-ID: I have a rather complicated Qt based project. We are looking at rolling out a subset tool, and it will be significantly smaller in functionality. For that mode, I would like to set a CMake variable LITEVERSION that builds the tool with -DLITEVERSION defined. however, one (or two) folders, the main executable (and possibly the main window folder), and I would like include into the tool with this turned on, and with it turned off Is that possible? Other times I have done this, I just have two build areas.. But 90% of this code base is the same, and will be built independent of the flag. So Id rather not build it twice Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Apr 27 22:42:38 2018 From: d3ck0r at gmail.com (J Decker) Date: Fri, 27 Apr 2018 19:42:38 -0700 Subject: [CMake] Multiple "projects" one directory In-Reply-To: References: Message-ID: You can solve this by treating those local projects as external projects; then they can be built with independant flags.... include( ExternalProject ) https://github.com/d3x0r/SACK/blob/master/CMakeLists.txt#L1769 ExternalProject_Add( ppc_portable SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/makefiles/prog/ppc BINARY_DIR ppc_portable INSTALL_DIR ${CMAKE_INSTALL_PREFIX} BUILD_ALWAYS 1 CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH= ...... .... (more args...) ) I find, because it's a local project; the build_always is kinda required, if you make changes to the sources it doesn't even check to see if it needs to build without BUILD_ALWAYS. On Fri, Apr 27, 2018 at 3:06 PM, Scott Bloom wrote: > I have a rather complicated Qt based project. > > > > We are looking at rolling out a subset tool, and it will be significantly > smaller in functionality. > > > > For that mode, I would like to set a CMake variable LITEVERSION that > builds the tool with -DLITEVERSION defined. > > however, one (or two) folders, the main executable (and possibly the main > window folder), and I would like include into the tool with this turned on, > and with it turned off > > > > Is that possible? > > > > Other times I have done this, I just have two build areas.. But 90% of > this code base is the same, and will be built independent of the flag. So > Id rather not build it twice > > > > Scott > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Sat Apr 28 04:07:03 2018 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sat, 28 Apr 2018 01:07:03 -0700 (PDT) Subject: [CMake] Multiple "projects" one directory In-Reply-To: References: Message-ID: On 2018-04-27 22:06-0000 Scott Bloom wrote: > I have a rather complicated Qt based project. > > We are looking at rolling out a subset tool, and it will be significantly smaller in functionality. > > For that mode, I would like to set a CMake variable LITEVERSION that builds the tool with -DLITEVERSION defined. > > however, one (or two) folders, the main executable (and possibly the main window folder), and I would like include into the tool with this turned on, and with it turned off > > Is that possible? > > Other times I have done this, I just have two build areas.. But 90% of this code base is the same, and will be built independent of the flag. So Id rather not build it twice Hi Scott: My opinion is two build areas is actually the way to go. Also, have you considered using ccache? With that software (see , rebuild costs tend to be negligible so that two build areas which build largely the same code will not cost that much more to build than one build area. 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 gans138 at rediffmail.com Sat Apr 28 03:40:15 2018 From: gans138 at rediffmail.com (Ganesh S) Date: 28 Apr 2018 07:40:15 -0000 Subject: [CMake] =?utf-8?q?error_during_bootstrap_in_cygwin?= Message-ID: <20180428074015.5702.qmail@f4mail-235-187.rediffmail.com> hi All,I'm trying to run bootstrap in cygwin. I get the following error:19: error: ‘environ’ undeclared (first use in this function)   return ((int*)(&environ))[argc];                   ^~~~~~~What am I supposed to do?  -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjm324 at cornell.edu Sat Apr 28 05:02:41 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Sat, 28 Apr 2018 02:02:41 -0700 Subject: [CMake] Help Accommodating Ninja when including CMAKE_CURRENT_BINARY_DIR In-Reply-To: References: <0608528B-90C0-4FCE-915D-8398D202DD14@cornell.edu> <2124A2DE-7EB1-4856-9720-BC524137B9CE@cornell.edu> Message-ID: ?After much deliberation, I was never successful in getting a synthetic target to work as expected. The dilemma is that `add_custom_command` cannot specify both `TARGET` and `OUTPUT`, the work flow was something like add_custom_target(resource-dependency) add_custom_command(TARGET resource-dependency ... PRE_BUILD) add_custom_command(OUTPUT DEPENDS resource-dependency) ... add_library(actual-obj-library OBJECt ... others ...) add_dependencies(actual-obj-library resource-dependency) I'm sure that's a flawed approach, but in the end I realized I can actually generate these files at *configure* time <3 The add_custom_command was just a call to ${CMAKE_COMMAND} ... resources/bin2c.cmake. So in the end, it's actually a lot cleaner for us to just include(resources/bin2c.cmake). I doubt this solution will be widely applicable to many projects, but if you ever find yourself in a situation where you are doing add_custom_command, where the custom command is calling ${CMAKE_COMMAND}, don't rely on PRE_BUILD because it's not a guarantee. If you can, just execute the script at configure time via an include(...) call. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Sat Apr 28 11:17:41 2018 From: scott at towel42.com (Scott Bloom) Date: Sat, 28 Apr 2018 15:17:41 +0000 Subject: [CMake] Multiple "projects" one directory In-Reply-To: References: , Message-ID: Thanks I'll look into it. ~~Scott -------- Original message -------- From: "Alan W. Irwin" Date: 4/28/18 01:07 (GMT-08:00) To: Scott Bloom Cc: cmake at cmake.org Subject: Re: [CMake] Multiple "projects" one directory On 2018-04-27 22:06-0000 Scott Bloom wrote: > I have a rather complicated Qt based project. > > We are looking at rolling out a subset tool, and it will be significantly smaller in functionality. > > For that mode, I would like to set a CMake variable LITEVERSION that builds the tool with -DLITEVERSION defined. > > however, one (or two) folders, the main executable (and possibly the main window folder), and I would like include into the tool with this turned on, and with it turned off > > Is that possible? > > Other times I have done this, I just have two build areas.. But 90% of this code base is the same, and will be built independent of the flag. So Id rather not build it twice Hi Scott: My opinion is two build areas is actually the way to go. Also, have you considered using ccache? With that software (see , rebuild costs tend to be negligible so that two build areas which build largely the same code will not cost that much more to build than one build area. 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 -------------- An HTML attachment was scrubbed... URL: From gartung at fnal.gov Mon Apr 30 17:44:08 2018 From: gartung at fnal.gov (Patrick E Gartung) Date: Mon, 30 Apr 2018 21:44:08 +0000 Subject: [CMake] Memory usage and configuration time for large project Message-ID: Hi, We have a large c/c++/fortran project, CMSSW, that is built with a custom tool, scram. ? https://github.com/cms-sw/cmssw The project might move to a cmake based build in the future. The scripts to convert to CmakeLists.tx has been written https://github.com/cms-sw/cmssw2cmake Tests show that with the cmake files generated with this script, configuring the project uses up to 1.5GB of ram and takes 11 minutes when using -GMakefiles. Using -GNinja and using the latest cmake, this time can be reduced to 8 minutes. The project builds 14k object files, 2.2k libraries, ~600 binaries, 500 generated source files with links to ~100 external libraries. Is this amount of memory usage and time typical for a project of this size? Patrick Gartung Fermilab -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2799 bytes Desc: not available URL: From r030t1 at gmail.com Mon Apr 30 17:55:44 2018 From: r030t1 at gmail.com (R0b0t1) Date: Mon, 30 Apr 2018 16:55:44 -0500 Subject: [CMake] Memory usage and configuration time for large project In-Reply-To: References: Message-ID: On Mon, Apr 30, 2018 at 4:44 PM, Patrick E Gartung wrote: > Hi, > > We have a large c/c++/fortran project, CMSSW, that is built with a custom tool, scram. ? > > https://github.com/cms-sw/cmssw > > The project might move to a cmake based build in the future. The scripts to convert to CmakeLists.tx has been written > > https://github.com/cms-sw/cmssw2cmake > > Tests show that with the cmake files generated with this script, configuring the project uses up to 1.5GB of ram and takes 11 minutes when using -GMakefiles. Using -GNinja and using the latest cmake, this time can be reduced to 8 minutes. > > The project builds 14k object files, 2.2k libraries, ~600 binaries, 500 generated source files with links to ~100 external libraries. > > Is this amount of memory usage and time typical for a project of this size? > I'm inclined to say "yes" as many builds such as Firefox, its supporting libraries, and Chrome all take lots of time and memory. Chrome uses Ninja, I might add. But the issue is not CMake itself. CMake tends to produce better builds. As I am not intimately familiar with your project, I can't make good concrete suggestions. You may enjoy reading https://news.ycombinator.com/item?id=14733829 and searching for build optimization strategies. Keep in mind a lot of the blame falls on C++ and Windows, should you be using Windows. If you aren't using Windows, then the advice in the comments above should still be relevant, and give you something to go on. Cheers, R0b0t1 > Patrick Gartung > Fermilab > From steveire at gmail.com Mon Apr 30 18:30:43 2018 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 30 Apr 2018 23:30:43 +0100 Subject: [CMake] Experiments in CMake support for Clang (header & standard) modules In-Reply-To: References: Message-ID: <2a2abd48-dee2-dc1a-b5e6-33e89d9b1472@gmail.com> On 04/20/2018 01:39 AM, David Blaikie wrote: > Hi there, > > I'm experimenting with creating examples (& potential changes to CMake > itself, if needed/useful) of building clang modules (currently using > the semi-backwards compatible "header modules", with the intent of > also/moving towards supporting pre-standard C++ modules in development > in Clang). Great! Thanks for reaching out. Sorry it has taken me a while to respond. Have you had other response off-list? > The basic commands required are: > > ? clang++ -fmodules -xc++ -Xclang -emit-module -Xclang > -fmodules-codegen -fmodule-name=foo foo.modulemap -o foo.pcm > ? clang++ -fmodules -c -fmodule-file=foo.pcm use.cpp > ? clang++ -c foo.pcm > ? clang++ foo.o use.o -o a.out Ok. Fundamentally, I am suspicious of having to have a -fmodule-file=foo.pcm for every 'import foo' in each cpp file. I shouldn't have to manually add that each time I add a new import to my cpp file. Even if it can be automated (eg by CMake), I shouldn't have to have my buildsystem be regenerated each time I add an import to my cpp file either. That's something I mentioned in the google groups post I made which you linked to. How will that work when using Qt or any other library? Today, a beginner can find a random C++ book, type in a code example from chapter one and put `g++ -I/opt/book_examples prog1.cpp` into a terminal and get something compiling and running. With modules, they'll potentially have to pass a whole list of module files too. Lots of people manually maintain Makefile-based buildsystems today, and most other companies I've been inside of have their own custom tool or bunch of python scripts, or both. Manually changing such buildsystems to add -fmodule-file or -fmodule-map-file each time an import is added is a significant barrier. Will my project have to compile the modules files for all of my dependencies? Even more complication for my buildsystem. Do I have to wait for my dependencies to modularize bottom-up before I can benefit from modules? If my dependency does add 'module foo' to their header files, or whatever the current syntax is, can I continue to #include or is that a source incompatible change? I raised some of these issues a few years ago regarding the clang implementation with files named exactly module.modulemap: http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946.html http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946i20.html Interestingly, GCC is taking a directory-centric approach in the driver (-fmodule-path=) as opposed to the 'add a file to your compile line for each import' that Clang and MSVC are taking: ?http://gcc.gnu.org/wiki/cxx-modules Why is Clang not doing a directory-centric driver-interface? It seems to obviously solve problems. I wonder if modules can be a success without coordination between major compiler and buildsystem developers. That's why I made the git repo - to help work on something more concrete to see how things scale. Having just read all of my old posts again, I still worry things like this will hinder modules 'too much' to be successful. The more (small) barriers exist, the less chance of success. If modules aren't successful, then they'll become a poisoned chalice and no one will be able to work on fixing them. That's actually exactly what I expect to happen, but I also still hope I'm just missing something :). I really want to see a committee document from the people working on modules which actually explores the problems and barriers to adoption and concludes with 'none of those things matter'. I think it's fixable, but I haven't seen anyone interested enough to fix the problems (or even to find out what they are). Anyway, you are not here for my rants. > My current very simplistic prototype, to build a module file, its > respective module object file, and include those in the library/link > for anything that depends on this library: > > ? add_custom_command( > ? ? ? ? ? COMMAND ${CMAKE_CXX_COMPILER} ${CMAKE_CXX_FLAGS} -xc++ -c > -Xclang -emit-module -fmodules -fmodule-name=Hello > ${CMAKE_CURRENT_SOURCE_DIR}/module.modulemap -o > ${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm -Xclang -fmodules-codegen > ? ? ? ? ? DEPENDS module.modulemap hello.h Why does this command depend on hello.h? If that is changed and module.modulemap is not, what will happen? > ? ? ? ? ? OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm > ? ? ? ? ? COMMENT "Generating hello_module.pcm" > ? ) > ? add_library (Hello hello.cxx > ${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm) > ? target_include_directories(Hello PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}) > ? target_compile_options(Hello PUBLIC -fmodules -Xclang > -fmodule-file=${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm) > > (this is based on the example in the CMake docs using Hello/Demo) Good that you got something working. > This also required one modification to CMake itself to classify a pcm > file as a C++ file that needs to be compiled (to execute the 3rd line > in the basic command list shown above). An alternative to patching CMake might be ?set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm PROPERTIES LANGUAGE CXX) though hopefully that is also temporary. > But this isn't ideal - I don't /think/ I've got the dependencies quite > right & things might not be rebuilding at the right times. > Also it involves hardcoding a bunch of things like the pcm file names, > header files, etc. Indeed. I think part of that comes from the way modules have been designed. The TS has similar issues. > Ideally, at least for a simplistic build, I wouldn't mind generating a > modulemap from all the .h files (& have those headers listed in the > add_library command - perhaps splitting public and private headers in > some way, only including the public headers in the module file, > likely). Eventually for the standards-proposal version, it's expected > that there won't be any modulemap file, but maybe all headers are > included in the module compilation (just pass the headers directly to > the compiler). In a design based on passing directories instead of files, would those directories be redundant with the include directories? One of the problems modules adoption will hit is that all the compilers are designing fundamentally different command line interfaces for them. Buildsystems will have to be rewritten to take advantage of modules, and they will be annoying to use and adopt. > This also doesn't start to approach the issue of how to build modules > for external libraries - which I'm happy to discuss/prototype too, > though interested in working to streamline the inter-library but > intra-project (not inter-project) case first. Yes, there are many aspects to consider. Are you interested in design of a CMake abstraction for this stuff? I have thoughts on that, but I don't know if your level of interest stretches that far. > Stephen - I saw you were asking some questions about this here > (?https://groups.google.com/a/isocpp.org/forum/#!topic/modules/sDIYoU8Uljw > ?& > https://github.com/steveire/ModulesExperiments?- didn't really > understand how this example applied/worked, though - I guess maybe > it's a prototype syntax proposal?) It is a set of pre-modules libraries, some of which depend on one another and with some transitive dependencies in the headers. I made it to be 'a few steps above trivial' in the hope that someone would show me how to port it to modules-ts (even if the result does not build). So far, no one has. Can you help? It would really help my understanding of where things currently stand with modules. For example, is there only one way to port the contents of the cpp files? After that, is there one importable module per class or one per shared library (which I think would make more sense for Qt)? And is transitive dependency expressed in the header files after porting? I think that last one is dealt with by the 'export import' syntax The git repo is an attempt to make the discussion concrete because it would show how multiple classes and multiple libraries with dependencies could interact in a modules world. I'm interested in what it would look like ported to modules-ts, because as far as I know, clang-modules and module maps would not need porting of the cpp files at all. > Basically: What do folks think about supporting these sort of features > in CMake C++ Builds? Any pointers on how I might best implement this > with or without changes to CMake? I think some design is needed up front. I expect CMake would want to have a first-class (on equal footing with include directories or compile definitions and with particular handling) concept for modules, extending the install(TARGET) command to install module binary files etc. To do that kind of design, I at least would need to be able to experiment or conceptualize examples which are not totally trivial, such as the starting point in my repo. On the CMake side, I think something like this should be the target (note that no compiler command line interface works like this today, which I think is a barrier to adoption): ?add_library(foo foo.cpp) ?# Target property to enable modules for the target ?set_property(TARGET foo PROPERTY USE_CXX_MODULES ON) ?# Note: Use target_include_directories to specify module search ?# paths (how GCC and MSVC work) ?# Also note: compilers should use the -I paths as a module path search list so ?# that CMake does not have to pass the same list as both -I and as -fmodule-path= ?# or similar entries. ?# Also note: This is source compatible with the cmake code that already exists! ?# The existance of /opt/bar/bing. makes 'import bing;' work. ?target_include_directories(foo PRIVATE /opt/bar) ?# Possibly need a new command to specify headers (there is ?# other motivation for this in CMake, so use a generic name without 'modules' in it) ?# Because foo has USE_CXX_MODULES ON, foo.h is processed as a module ?# and a binary representation is created for import. Other properties can ?# be set on foo.h with set_source_files_properties() to pass other command line ?# options when generating the module. ?target_headers(foo PRIVATE foo.h) Also - in the right design, CMake does not have to regenerate -fmodule-file or whatever into the compile line any time the user adds 'import something;', which is the case with clang now afaik. Please correct me if that is not correct. I know some people at Kitware have been thinking about modules though, so I'd be interested in any other insights from there. Brad, can you comment? Here's some other reading material for anyone else following along: https://izzys.casa/posts/millennials-are-killing-the-modules-ts.html https://build2.org/article/cxx-modules-misconceptions.xhtml Thanks, Stephen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Mon Apr 30 19:37:57 2018 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 1 May 2018 00:37:57 +0100 Subject: [CMake] Experiments in CMake support for Clang (header & standard) modules In-Reply-To: <2a2abd48-dee2-dc1a-b5e6-33e89d9b1472@gmail.com> References: <2a2abd48-dee2-dc1a-b5e6-33e89d9b1472@gmail.com> Message-ID: On 04/30/2018 11:30 PM, Stephen Kelly wrote: > Interestingly, GCC is taking a directory-centric approach in the > driver (-fmodule-path=) as opposed to the 'add a file to your > compile line for each import' that Clang and MSVC are taking: > > ?http://gcc.gnu.org/wiki/cxx-modules > > Why is Clang not doing a directory-centric driver-interface? It seems > to obviously solve problems. I just discovered `-fprebuilt-module-path=`. I'm glad it exists (is it 'new'?), but why don't you just use the -I paths? Thanks, Steve.