From jamil.appa at zenotech.com Wed Nov 1 11:16:40 2017 From: jamil.appa at zenotech.com (Jamil Appa) Date: Wed, 01 Nov 2017 15:16:40 +0000 Subject: [CMake] FindCUDA Separable Compilation and cublas_device Message-ID: Hi When using FindCUDA with separable compilation combined with device code that uses cublas_device I get missing symbols when linking the intermediate file at line 1758 FindCUDA.cmake If I change line 1758 to include the cublas_device library the symbols are resolved correctly. COMMAND ${CUDA_NVCC_EXECUTABLE} ${nvcc_flags} -dlink ${object_files} -o ${output_file} -lcublas_device Is there a way to pass through a library to the CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS function that I am missing? Thanks Jamil *Jamil Appa* | Co-Founder and Director | Zenotech [image: Papercut] [image: Tel:] +44 (0)7747 606 788 [image: Zenotech LTD - Simulation Unlimited] [image: Email:] jamil.appa at zenotech.com [image: Web:] www.zenotech.com [image: Papercut] [image: linkedin:] [image: Twitter:] [image: Location:] Company Registration No : 07926926 | VAT No : 128198591 Registered Office : 1 Larkfield Grove, Chepstow, Monmouthshire, NP16 5UF, UK Address : Bristol & Bath Science Park, Dirac Cres, Emersons Green, Bristol BS16 7FR -------------- next part -------------- An HTML attachment was scrubbed... URL: From azukaitis at gmail.com Wed Nov 1 14:09:26 2017 From: azukaitis at gmail.com (Anthony Zukaitis) Date: Wed, 1 Nov 2017 12:09:26 -0600 Subject: [CMake] ctest and label time summary Message-ID: Is there a way to turn off the label timing information after ctest is run with ctest -L mytest I have appoximately 100 tests that depend on a SETUP test. The setup test has 100s of labels and this screws up the print out of the label timing summary at the end of the ctest run. This is due to the want of having dependencies of tests being run automatically. All of my tests depend on a SETUP test. Using the label method: https://stackoverflow.com/questions/30808963/cmake-and-ctest-automatically-run-tests-dependencies my SETUP test now has 100s of labels Thanks, Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Nov 1 15:55:39 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 1 Nov 2017 15:55:39 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.10.0-rc4 is now ready for testing Message-ID: I am proud to announce the fourth CMake 3.10 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.10 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.10/release/3.10.html Some of the more significant changes in CMake 3.10 are: * The flang Fortran compiler is now supported, with compiler id "Flang". * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * "FindMPI" received a major overhaul. It now features language specific components, better Fortran support, and support for statically linked MPI implementations. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module underwent numerous improvements. It has gained support for GLVND and EGL on Linux. It now has import targets that separate the OpenGL library and OpenGL contexts. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". CMake 3.10 Release Notes ************************ Changes made since CMake 3.9 include the following. New Features ============ Platforms --------- * The flang Fortran compiler is now supported, with compiler id "Flang". * A new minimal platform file for "Midipix" was added. * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * Support for the IAR ARM Compiler was improved. Generators ---------- * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools like ccache along with the compiler for the "CUDA" language ("C" and "CXX" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * The "CodeBlocks" extra generator learned to optionally exclude files from outside the project root directory from the generated project. See the "CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES" variable. Commands -------- * The "cmake_host_system_information()" command learned more keys to get information about the processor capabilities and the host OS version. * The "configure_file()" command learned to support indented "# cmakedefine" and "# cmakedefine01". Spaces and/or tabs between the "#" character and the "cmakedefine"/"cmakedefine01" words are now understood and preserved in the output. * The "execute_process()" command gained a "RESULTS_VARIABLE" option to collect a list of results from all children in a pipeline of processes when multiple "COMMAND" arguments are given. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * The "string()" command learned a new "PREPEND" subcommand. * The "string(TIMESTAMP)" command now supports "%A" for full weekday name and "%B" for full month name. Variables --------- * A "CMAKE_DIRECTORY_LABELS" variable was added to specify labels for all tests in a directory. Properties ---------- * A "_CPPCHECK" target property and supporting "CMAKE__CPPCHECK" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "cppcheck" with the compiler for "C" and "CXX" languages. * A "LABELS" directory property was added to specify labels for all targets and tests in a directory. * A "TEST_INCLUDE_FILES" directory property was added to list any number of files to be included when running tests with "ctest(1)". This generalizes the "TEST_INCLUDE_FILE" property. * The "VS_DOTNET_REFERENCEPROP__TAG_" target property was added to support custom XML tags for reference assemblies in C# targets. * Source file properties "VS_SHADER_OUTPUT_HEADER_FILE" and "VS_SHADER_VARIABLE_NAME" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "FindCurses" module gained a "CURSES_NEED_WIDE" option to request the wide-character variant. * The "FindEXPAT" module now provides imported targets. * The "FindFreetype" module now provides imported targets. * "FindMPI" gained a number of new features, including: * Language-specific components have been added to the module. * Many more MPI environments are now supported. * The environmental support for Fortran has been improved. * A user now has fine-grained control over the MPI selection process, including passing custom parameters to the MPI compiler. * The version of the implemented MPI standard is now being exposed. * MPI-2 C++ bindings can now be detected and also suppressed if so desired. * The available Fortran bindings are now being detected and verified. * Various MPI-3 information can be requested, including the library version and Fortran capabilities of the individual bindings. * Statically linked MPI implementations are supported. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module gained support for GLVND on Linux. * The "FindOpenMP" module gained support for language-specific components. * A "FindPatch" module was added to find the "patch" command-line executable. * The "FindProtobuf" module "protobuf_generate_cpp()" command gained a "DESCRIPTORS" option to generate descriptor files. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. Unlike the source parsing approach, dynamic discovery executes the test (in 'list available tests' mode) at build time to discover tests. This is robust against unusual ways of labeling tests, provides much better support for advanced features such as parameterized tests, and does not require re-running CMake to discover added or removed tests within a test executable. * The "InstallRequiredSystemLibraries" module gained support for installing Intel compiler runtimes. Autogen ------- * When using "AUTOMOC" or "AUTOUIC" with a multi configuration generator (e.g. "Xcode"), included "*.moc", "moc_*.cpp" and "ui_*.h" files are generated in "/include_" instead of "/include". * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * When using "AUTOMOC", CMake searches for the strings "Q_OBJECT", "Q_GADGET" or "Q_NAMESPACE" in a source file to determine if it needs to be "moc" processed. The new "CMAKE_AUTOMOC_MACRO_NAMES" variable and "AUTOMOC_MACRO_NAMES" target property may be set to register additional strings (macro names) to search for. * When using "AUTOMOC", the new "CMAKE_AUTOMOC_COMPILER_PREDEFINES" variable and "AUTOMOC_COMPILER_PREDEFINES" target property specify whether to enable or disable the generation of the compiler pre definitions file "moc_predefs.h". CTest ----- * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. CPack ----- * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "CPackDeb" module learned to set package release version in "Version" info property. See the "CPACK_DEBIAN_PACKAGE_RELEASE" variable. * The "CPackDeb" module learned more strict package version checking that complies with Debian rules. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "REPLACES" and "CHECKABLE" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_FILE_EXTENSION" variable to customize target binary format. * The "CPackIFW" module gained new "CPACK_IFW_REPOSITORIES_DIRECTORIES" variable to specify additional repositories dirs that will be used to resolve and repack dependent components. This feature is only available when using QtIFW 3.1 or later. * Modules "CPackRPM" and "CPackDeb" learned to set package epoch version. See "CPACK_RPM_PACKAGE_EPOCH" and "CPACK_DEBIAN_PACKAGE_EPOCH" variables. Other ----- * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The graphviz output now distinguishes among the different dependency types "PUBLIC", "PRIVATE" and "INTERFACE" and represents them in the output graph as solid, dashed and dotted edges. Deprecated and Removed Features =============================== * Support for building CMake itself with C++98 compilers was dropped. CMake is now implemented using C++11. * Support for building CMake on HP-UX has been dropped pending better support for C++11 and a port of libuv. See CMake Issue 17137. Use CMake 3.9 or lower instead for HP-UX support. Other Changes ============= * On FreeBSD the C++ compiler named "c++" is now the preferred default. * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". * The "get_filename_component()" "PROGRAM" mode semantics have been revised to not tolerate unquoted spaces in the path to the program while also accepting arguments. While technically incompatible with the old behavior, it is expected that behavior under typical use cases with properly-quoted command-lines has not changed. ---------------------------------------------------------------------------- Changes made since CMake 3.10.0-rc3: Brad King (7): Clang: Use -TP flag for C++ sources with clang-cl CMP0040: Clarify policy warning to match documentation cmcmd: Rename loop iteration variable for clarity cmcmd: Convert lint handlers to file-static functions cmcmd: Restore support for running multiple lint tools Record C compile features flags for MinGW Clang on Windows CMake 3.10.0-rc4 Christian Pfeiffer (5): Flang: Remove unsupported fbounds-check flag Help: Correct _STANDARD help w.r.t. MSVC GNUInstallDirs: Enable CMP0054 FindMPI: Use physical cores for MPIEXEC_MAX_NUMPROCS Find{OpenMP,OpenACC}: Fix detection with -Werror=return-type Domen Vrankar (1): CPack/RPM: DIST-MONOLITHIC-type subtest fix Henry Schreiner (1): FindOpenCL: Add detection of OpenCL 2.1 and 2.2 Sebastian Holtermann (6): Autogen: Don't add STATIC_LIBRARY cycle targets to the _autogen dependencies Autogen: Tests: Add test for STATIC_LIBRARY cycles Autogen: RCC: Append checksum suffix to wrapped file name Autogen: Make rcc output file suffix static (instead of pseudo-random) Autogen: Don't use AUTOMOC_MOC_OPTIONS in moc-predefs command Autogen: Tests: Set AUTOMOC_MOC_OPTIONS in a simple test From craig.scott at crascit.com Wed Nov 1 16:31:03 2017 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 2 Nov 2017 07:31:03 +1100 Subject: [CMake] ctest and label time summary In-Reply-To: References: Message-ID: On Thu, Nov 2, 2017 at 5:09 AM, Anthony Zukaitis wrote: > Is there a way to turn off the label timing information after ctest is run > with > > ctest -L mytest > > I have appoximately 100 tests that depend on a SETUP test. The setup test > has 100s of labels and this screws up the print out of the label timing > summary at the end of the ctest run. This is due to the want of having > dependencies of tests being run automatically. All of my tests depend on a > SETUP test. Using the label method: > > https://stackoverflow.com/questions/30808963/cmake-and- > ctest-automatically-run-tests-dependencies > > my SETUP test now has 100s of labels > > Thanks, Tony > I added an answer to that stackoverflow link. The test fixtures feature added in CMake 3.7 provides the behaviour you want. It doesn't rely on using test labels, so you'd be able to avoid the label clutter in your test report. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From azukaitis at gmail.com Wed Nov 1 16:41:18 2017 From: azukaitis at gmail.com (Anthony Zukaitis) Date: Wed, 1 Nov 2017 14:41:18 -0600 Subject: [CMake] ctest and label time summary In-Reply-To: References: Message-ID: I found my error.... I wasn't setting my labels correctly.... i was setting one big string and not a list..... user error :/. On Wed, Nov 1, 2017 at 2:31 PM, Craig Scott wrote: > > On Thu, Nov 2, 2017 at 5:09 AM, Anthony Zukaitis > wrote: > >> Is there a way to turn off the label timing information after ctest is >> run with >> >> ctest -L mytest >> >> I have appoximately 100 tests that depend on a SETUP test. The setup >> test has 100s of labels and this screws up the print out of the label >> timing summary at the end of the ctest run. This is due to the want of >> having dependencies of tests being run automatically. All of my tests >> depend on a SETUP test. Using the label method: >> >> https://stackoverflow.com/questions/30808963/cmake-and-ctest >> -automatically-run-tests-dependencies >> >> my SETUP test now has 100s of labels >> >> Thanks, Tony >> > > > I added an answer to that stackoverflow link. The test fixtures feature > added in CMake 3.7 provides the behaviour you want. It doesn't rely on > using test labels, so you'd be able to avoid the label clutter in your test > report. > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greenc at fnal.gov Wed Nov 1 18:35:40 2017 From: greenc at fnal.gov (Chris Green) Date: Wed, 1 Nov 2017 17:35:40 -0500 Subject: [CMake] Custom Command OUTPUTs to understand geenrator expressions? Message-ID: <9adb7a44-7cea-feae-0eae-99a52e4129c6@fnal.gov> Hi, I have a case where a custom command produces multiple outputs, at least some of which depend on a property of a library target, viz: if (BD_WANT_PCM) set(PCM_OUTPUT $/${CMAKE_SHARED_LIBRARY_PREFIX}${dictname}_dict_rdict.pcm) if (GD_PCM_OUTPUT_VAR) set(${GD_PCM_OUTPUT_VAR} ${PCM_OUTPUT} PARENT_SCOPE) endif() endif() add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${dictname}_dict.cpp # Extra outputs commented out until custom_command OUTPUT supports # generator flags. ${SOURCE_OUTPUT} # ${GD_ROOTMAP_OUTPUT} ${PCM_OUTPUT} ... Here, ${PCM_OUTPUT} needs to be specified to be put in the same directory as the library produced for the target ${dictname}_dict, which may be something particular to that target rather than its defaulted value of ${CMAKE_LIBRARY_OUTPUT_DIRECTORY} or ${LIBRARY_OUTPUT_PATH}. Unfortunately, this fails to work as of CMake 3.9.2. Is this something which is reasonable to want and/or easy to do. Is there some other way to have the desired flexibility? Thanks for any help, Chris. From maria.dimitrova at helsinki.fi Thu Nov 2 06:10:17 2017 From: maria.dimitrova at helsinki.fi (Dimitrova, Maria) Date: Thu, 2 Nov 2017 10:10:17 +0000 Subject: [CMake] Cmake not finding the Python libraries Message-ID: Hello, I am trying to compile a program based on a setup script calling Cmake but I end up with a strange situation where it complains that it cannot find PYTHON_LIBRARIES and PYTHON_INCLUDE_DIRS. I double checked that indeed "which python" returns the one from Anaconda, and that all the environmental variables for it are exported: export PATH=/MYPATH/anaconda2/bin:${PATH} export PYTHON_LIBRARY=/MYPATH/anaconda2/lib/libpython2.7.so export PYTHON_INCLUDE_DIR=/MYPATH/anaconda2/include/python2.7 export PYTHON_LIBRARIES="/MYPATH/anaconda2/lib/libpython2.7.so" export PYTHON_INCLUDE_DIRS="/MYPATH/anaconda2/include/python2.7" export PYTHON_EXECUTABLE="/MYPATH/anaconda2/bin/python" (MYPATH stands for my home directory in this email) "echo $PYTHON_LIBRARIES" and "echo $PYTHON_INCLUDE_DIRS" are giving the correct paths, as well. Cmake is evoked through a ./setup script which can also accept the following arguments: --cmake-executable= Set the CMake executable [default: cmake]. --cmake-options= Define options to CMake [default: '']. and I have tried passing the variables there: ./setup --fc=ifort --extra-fc-flags='-xAVX -axCORE-AVX2,CORE-AVX-I' --cc=icc --extra-cc-flags='-xAVX -axCORE-AVX2,CORE-AVX-I' --cxx=icc --extra-cxx-flags='-xAVX -axCORE-AVX2,CORE-AVX-I' --cmake-options='-DPYTHON_LIBRARIES=/MYPATH/anaconda2/lib/libpython2.7.so -DPYTHON_INCLUDE_DIRS=/MYPATH/anaconda2/include/python2.7' Yet it crashes with the following output: CMake Error at /MYPATH/cmake-3.9.4-Linux-x86_64/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find PythonLibs (missing: PYTHON_LIBRARIES PYTHON_INCLUDE_DIRS) (Required is at least version "2.7") Call Stack (most recent call first): /MYPATHcmake-3.9.4-Linux-x86_64/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE) /MYPATH/cmake-3.9.4-Linux-x86_64/share/cmake-3.9/Modules/FindPythonLibs.cmake:262 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:23 (find_package) Could the problem be caused by a bug in the setup script or something that I have misunderstood about Cmake? Best regards, Maria -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Nov 2 09:53:09 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 2 Nov 2017 09:53:09 -0400 Subject: [CMake] FindCUDA Separable Compilation and cublas_device In-Reply-To: References: Message-ID: Hi, Have you tried using the 'CUDA_ADD_CUBLAS_TO_TARGET' command on the target that has FindCUDA separable compilation enabled? On Wed, Nov 1, 2017 at 11:16 AM, Jamil Appa wrote: > Hi > > When using FindCUDA with separable compilation combined with device > code that uses cublas_device I get missing symbols when linking the > intermediate file at line 1758 > > FindCUDA.cmake > > If I change line 1758 to include the cublas_device library the symbols > are resolved correctly. > > COMMAND ${CUDA_NVCC_EXECUTABLE} ${nvcc_flags} -dlink ${object_files} -o > ${output_file} -lcublas_device > > Is there a way to pass through a library to the CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS > function that I am missing? > > Thanks > > Jamil > > *Jamil Appa* | Co-Founder and Director | Zenotech > [image: Papercut] > [image: Tel:] +44 (0)7747 606 788 <+44%207747%20606788> [image: Zenotech > LTD - Simulation Unlimited] > [image: Email:] jamil.appa at zenotech.com > [image: Web:] www.zenotech.com > [image: Papercut] > [image: linkedin:] [image: > Twitter:] [image: Location:] > > > Company Registration No : 07926926 | VAT No : 128198591 > > Registered Office : 1 Larkfield Grove, Chepstow, Monmouthshire, NP16 5UF, > UK > > Address : Bristol & Bath Science Park, Dirac Cres, Emersons Green, Bristol > BS16 7FR > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Thu Nov 2 10:05:13 2017 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Thu, 2 Nov 2017 09:05:13 -0500 Subject: [CMake] Custom Command OUTPUTs to understand geenrator expressions? In-Reply-To: <9adb7a44-7cea-feae-0eae-99a52e4129c6@fnal.gov> References: <9adb7a44-7cea-feae-0eae-99a52e4129c6@fnal.gov> Message-ID: Hi Chris, you're definitely not the first to want this (see https://gitlab.kitware.com/cmake/cmake/issues/12877). However, as per the comment in that issue, it's not something we can expect in any foreseeable future. Petr On 1 November 2017 at 17:35, Chris Green wrote: > Hi, > > I have a case where a custom command produces multiple outputs, at least > some of which depend on a property of a library target, viz: > > if (BD_WANT_PCM) > set(PCM_OUTPUT > $ > /${CMAKE_SHARED_LIBRARY_PREFIX}${dictname}_dict_rdict.pcm) > if (GD_PCM_OUTPUT_VAR) > set(${GD_PCM_OUTPUT_VAR} ${PCM_OUTPUT} PARENT_SCOPE) > endif() > endif() > add_custom_command( > OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${dictname}_dict.cpp > # Extra outputs commented out until custom_command OUTPUT supports > # generator flags. > ${SOURCE_OUTPUT} # ${GD_ROOTMAP_OUTPUT} ${PCM_OUTPUT} > ... > > Here, ${PCM_OUTPUT} needs to be specified to be put in the same directory > as the library produced for the target ${dictname}_dict, which may be > something particular to that target rather than its defaulted value of > ${CMAKE_LIBRARY_OUTPUT_DIRECTORY} or ${LIBRARY_OUTPUT_PATH}. > Unfortunately, this fails to work as of CMake 3.9.2. Is this something > which is reasonable to want and/or easy to do. Is there some other way to > have the desired flexibility? > > Thanks for any help, > > Chris. > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Thu Nov 2 22:09:18 2017 From: saadrustam at gmail.com (Saad Khattak) Date: Fri, 03 Nov 2017 02:09:18 +0000 Subject: [CMake] Using find_package on CMake projects added through ExternalProject_Add Message-ID: Hi, I have a SuperBuild where I am adding dependencies using ExternalProject_Add. I am also using the same mechanism to add my projects (which are subprojects). The dependencies are being cloned into a directory in the root of the project called "Dep" and installed in the "Install" directory, also in root. All the dependencies have their own CMakeLists.txt and when installed, generate their respective xxxConfig.cmake and xxxTargets.cmake (among a few other files generated by CMake). I am using: find_package(dep_name HINTS "path_to_install_folder") and my assumption/hope was that find_package will find the autogenerated files and since the dependencies are built and installed through CMake, the include and library directories and the library names will be picked up automatically. Now find_package 'is' able to find the dependencies i.e. if I am trying to find SDL2, it is able to do so and SDL2_FOUND is set. However, nothing else is picked up by find_package, including the include directories, library directories nor the name of the library (e.g. in SDL's case, it is called libSDL2.so). I am also not sure which variables are set by find_package. For example, if the SDL2 library is found by find_package, what do I pass to target_include_directories and target_link_libraries? My first thought was to use "message(STATUS variable_set_by_find_package)" but I don't know what the variables are called. Here's the project folder structure in case it helps visualize everything: - CMakeLists.txt (root level, superbuild that adds all deps and subprojs) - Dep/ (folder where dependencies are cloned) - Install/ (folder where dependencies are installed) -- SubProject1/CMakeLists.txt (subproject1 dependent on above deps) -- SubProject2/CMakeLists.txt (subproject2 dependent on above deps) Here's the auto-generated files by one of the dependencies, SDL2 (all dependencies generate similar files which are put in one of the nested directores inside the root "Install" directory): - SDL2Config.cmake - SDL2ConfigVersion.cmake - SDL2Targets.cmake - SDL2Targets-noconfig.cmake Hopefully I have explained the issue properly. Thanks, Saad -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.appa at zenotech.com Fri Nov 3 07:39:35 2017 From: jamil.appa at zenotech.com (Jamil Appa) Date: Fri, 03 Nov 2017 11:39:35 +0000 Subject: [CMake] FindCUDA Separable Compilation and cublas_device In-Reply-To: References: Message-ID: Hi Robert I am using CUDA_ADD_CUBLAS_TO_TARGET but the error happens during the prelink phase when using separable compilation. (nvcc -dlink phase) My guess is that Nvidia have not included cublas_device.a in their dlink phase as you don't have to provide any other libraries. I have asked the Nvidia team if that is the case, but no reply yet. The general fix seems to be to modify lines 1759/1772 of FindCUDA.cmake (in gitlab master) to include CUBLAS_LIBRARIES COMMAND ${CUDA_NVCC_EXECUTABLE} ${nvcc_flags} -dlink ${object_files} ${CUDA_CUBLAS_LIBRARIES} -o ${output_file} This will have no impact if the cublas symbols are not used in the object files. If you are happy with this I can submit the change for review. Jamil On Thu, 2 Nov 2017 at 13:53 Robert Maynard wrote: > Hi, > > Have you tried using the 'CUDA_ADD_CUBLAS_TO_TARGET' command on the target > that has FindCUDA separable compilation enabled? > > On Wed, Nov 1, 2017 at 11:16 AM, Jamil Appa > wrote: > >> Hi >> >> When using FindCUDA with separable compilation combined with device >> code that uses cublas_device I get missing symbols when linking the >> intermediate file at line 1758 >> >> FindCUDA.cmake >> >> If I change line 1758 to include the cublas_device library the >> symbols are resolved correctly. >> >> COMMAND ${CUDA_NVCC_EXECUTABLE} ${nvcc_flags} -dlink ${object_files} >> -o ${output_file} -lcublas_device >> >> Is there a way to pass through a library to >> the CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS function that I am missing? >> >> Thanks >> >> Jamil >> >> *Jamil Appa* | Co-Founder and Director | Zenotech >> [image: Papercut] >> [image: Tel:] +44 (0)7747 606 788 <+44%207747%20606788> [image: Zenotech >> LTD - Simulation Unlimited] >> [image: Email:] jamil.appa at zenotech.com >> [image: Web:] www.zenotech.com >> [image: Papercut] >> [image: linkedin:] [image: >> Twitter:] [image: Location:] >> >> >> Company Registration No : 07926926 | VAT No : 128198591 >> >> Registered Office : 1 Larkfield Grove, Chepstow, Monmouthshire, NP16 >> 5UF, UK >> >> >> Address : Bristol & Bath Science Park, Dirac Cres, Emersons Green, >> Bristol BS16 7FR >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From belliott at kuttatech.com Fri Nov 3 12:26:52 2017 From: belliott at kuttatech.com (Bruce Elliott) Date: Fri, 3 Nov 2017 09:26:52 -0700 Subject: [CMake] CMake targeting Android with "Visual Studio 15 2017" generator issue Message-ID: <00ae01d354c0$8eacf530$ac06df90$@kuttatech.com> We are trying to port a C++/OpenGL project from MS Windows to Android. The project is using CMake to generate solution and project files for Visual Studio 2017. All attempts to create solution and project files for VS2017 when targeting Android have failed with the CMake GUI generating the following error message: >CMake Error at CMakeLists.txt:100 (project): > CMAKE_SYSTEM_NAME is 'Android' but 'NVIDIA Nsight Tegra Visual Studio > Edition' is not installed. > >Configuring incomplete, errors occurred! >See also "C:/SVN/Nexus_Android/Build_Android_vs2017/CMakeFiles/CMakeOutput.log". Line 100 of the CMakeLists.txt is: "project(${PROJECT_NAME} C CXX)" The log file contains: The target system is: Android - 23 - The host system is: Windows - 10.0.16299 - AMD64 I have tried toolchain files from OpenCV, Taka-No-Me as well as a simple toolchain file as follows: set(CMAKE_SYSTEM_NAME Android) set(CMAKE_SYSTEM_VERSION 23) # API level set(CMAKE_ANDROID_API 23) set(CMAKE_ANDROID_API_MIN 16) set(CMAKE_ANDROID_NDK C:/ProgramData/Microsoft/AndroidNDK/android-ndk-r15c) set(CMAKE_ANDROID_ARCH arm64-v8a) set(CMAKE_ANDROID_ARCH_ABI arm64-v8a) All result in the CMake GUI generating the error above. I have created a Native-Activity Application(Android) test project in VS2017 and have been able to build/deploy/debug the native C++ on both emulated targets for Android and a USB connected Android tablet target. VS2017 does not require ''NVIDIA Nsight Tegra Visual Studio Edition'. Is there a work around for CMake to get it to generate native C++ Android projects for VS2017? Tool versions being used: Visual Studio 15 2017 CMake 3.10.0-rc3 Android NDK r15c Regards, Bruce Elliott From robert.maynard at kitware.com Fri Nov 3 14:07:40 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 3 Nov 2017 14:07:40 -0400 Subject: [CMake] FindCUDA Separable Compilation and cublas_device In-Reply-To: References: Message-ID: HI Jamil, If you are interested in submitting a fix I can review, but I would like to also make sure that this issue doesn't exist inside the new cmake support for CUDA as a first class language. Can you produce a minimal test case that we can rework to use the new support and add to CMake's test suite. You will also need to track down what version of CUDA first added cublas_device so that we properly guard the inclusion. On Fri, Nov 3, 2017 at 7:39 AM, Jamil Appa wrote: > Hi Robert > > I am using CUDA_ADD_CUBLAS_TO_TARGET but the error happens during the > prelink phase when using separable compilation. (nvcc -dlink phase) > > My guess is that Nvidia have not included cublas_device.a in their > dlink phase as you don't have to provide any other libraries. I have asked > the Nvidia team if that is the case, but no reply yet. > > The general fix seems to be to modify lines 1759/1772 of FindCUDA.cmake > (in gitlab master) to include CUBLAS_LIBRARIES > > COMMAND ${CUDA_NVCC_EXECUTABLE} ${nvcc_flags} -dlink ${object_files} > ${CUDA_CUBLAS_LIBRARIES} -o ${output_file} > > This will have no impact if the cublas symbols are not used in the object > files. > > If you are happy with this I can submit the change for review. > > Jamil > > > On Thu, 2 Nov 2017 at 13:53 Robert Maynard > wrote: > >> Hi, >> >> Have you tried using the 'CUDA_ADD_CUBLAS_TO_TARGET' command on the >> target that has FindCUDA separable compilation enabled? >> >> On Wed, Nov 1, 2017 at 11:16 AM, Jamil Appa >> wrote: >> >>> Hi >>> >>> When using FindCUDA with separable compilation combined with device >>> code that uses cublas_device I get missing symbols when linking the >>> intermediate file at line 1758 >>> >>> FindCUDA.cmake >>> >>> If I change line 1758 to include the cublas_device library the >>> symbols are resolved correctly. >>> >>> COMMAND ${CUDA_NVCC_EXECUTABLE} ${nvcc_flags} -dlink ${object_files} >>> -o ${output_file} -lcublas_device >>> >>> Is there a way to pass through a library to the CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS >>> function that I am missing? >>> >>> Thanks >>> >>> Jamil >>> >>> *Jamil Appa* | Co-Founder and Director | Zenotech >>> [image: Papercut] >>> [image: Tel:] +44 (0)7747 606 788 <+44%207747%20606788> [image: >>> Zenotech LTD - Simulation Unlimited] >>> [image: Email:] jamil.appa at zenotech.com >>> [image: Web:] www.zenotech.com >>> [image: Papercut] >>> [image: linkedin:] [image: >>> Twitter:] [image: Location:] >>> >>> >>> Company Registration No : 07926926 | VAT No : 128198591 >>> >>> Registered Office : 1 Larkfield Grove, Chepstow, Monmouthshire, NP16 >>> 5UF, UK >>> >>> >>> Address : Bristol & Bath Science Park, Dirac Cres, Emersons Green, >>> Bristol BS16 7FR >>> >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/ >>> opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Fri Nov 3 15:01:11 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 3 Nov 2017 15:01:11 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.9.5 available for download Message-ID: We are pleased to announce that CMake 3.9.5 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.9.5 since 3.9.4: Brad King (1): CMake 3.9.5 Sebastian Holtermann (1): Autogen: Don't add AUTOMOC_MOC_OPTIONS to moc-predefs command From jamil.appa at zenotech.com Fri Nov 3 17:00:55 2017 From: jamil.appa at zenotech.com (Jamil Appa) Date: Fri, 03 Nov 2017 21:00:55 +0000 Subject: [CMake] FindCUDA Separable Compilation and cublas_device In-Reply-To: References: Message-ID: Hi Robert I will put a minimal case together using one of the CUDA samples and sent it through for testing with the new cmake support. On your second point, CUDA_CUBLAS_LIBRARIES should be empty if no cublas libraries are present so that use case should be automatically handled unless I am missing something. I will create a fork and topic branch with the change and submit it for review. Thanks Jamil On Fri, 3 Nov 2017 at 18:08 Robert Maynard wrote: > HI Jamil, > > If you are interested in submitting a fix I can review, but I would like > to also make sure that this issue doesn't exist inside the new cmake > support for CUDA as a first class language. Can you produce a minimal test > case that we can rework to use the new support and add to CMake's test > suite. > > You will also need to track down what version of CUDA first added cublas_device > so that we properly guard the inclusion. > > On Fri, Nov 3, 2017 at 7:39 AM, Jamil Appa > wrote: > >> Hi Robert >> >> I am using CUDA_ADD_CUBLAS_TO_TARGET but the error happens during the >> prelink phase when using separable compilation. (nvcc -dlink phase) >> >> My guess is that Nvidia have not included cublas_device.a in their >> dlink phase as you don't have to provide any other libraries. I have asked >> the Nvidia team if that is the case, but no reply yet. >> >> The general fix seems to be to modify lines 1759/1772 of >> FindCUDA.cmake (in gitlab master) to include CUBLAS_LIBRARIES >> >> COMMAND ${CUDA_NVCC_EXECUTABLE} ${nvcc_flags} -dlink ${object_files} >> ${CUDA_CUBLAS_LIBRARIES} -o ${output_file} >> >> This will have no impact if the cublas symbols are not used in the >> object files. >> >> If you are happy with this I can submit the change for review. >> >> Jamil >> >> >> On Thu, 2 Nov 2017 at 13:53 Robert Maynard >> wrote: >> >>> Hi, >>> >>> Have you tried using the 'CUDA_ADD_CUBLAS_TO_TARGET' command on the >>> target that has FindCUDA separable compilation enabled? >>> >>> On Wed, Nov 1, 2017 at 11:16 AM, Jamil Appa >>> wrote: >>> >>>> Hi >>>> >>>> When using FindCUDA with separable compilation combined with device >>>> code that uses cublas_device I get missing symbols when linking the >>>> intermediate file at line 1758 >>>> >>>> FindCUDA.cmake >>>> >>>> If I change line 1758 to include the cublas_device library the >>>> symbols are resolved correctly. >>>> >>>> COMMAND ${CUDA_NVCC_EXECUTABLE} ${nvcc_flags} -dlink ${object_files} >>>> -o ${output_file} -lcublas_device >>>> >>>> Is there a way to pass through a library to >>>> the CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS function that I am missing? >>>> >>>> Thanks >>>> >>>> Jamil >>>> >>>> *Jamil Appa* | Co-Founder and Director | Zenotech >>>> [image: Papercut] >>>> [image: Tel:] +44 (0)7747 606 788 <+44%207747%20606788> [image: >>>> Zenotech LTD - Simulation Unlimited] >>>> [image: Email:] jamil.appa at zenotech.com >>>> [image: Web:] www.zenotech.com >>>> [image: Papercut] >>>> [image: linkedin:] [image: >>>> Twitter:] [image: Location:] >>>> >>>> >>>> Company Registration No : 07926926 | VAT No : 128198591 >>>> >>>> Registered Office : 1 Larkfield Grove, Chepstow, Monmouthshire, NP16 >>>> 5UF, UK >>>> >>>> >>>> Address : Bristol & Bath Science Park, Dirac Cres, Emersons Green, >>>> Bristol BS16 7FR >>>> >>>> >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: >>>> http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For >>>> more information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake >>>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.appa at zenotech.com Fri Nov 3 17:49:13 2017 From: jamil.appa at zenotech.com (Jamil Appa) Date: Fri, 03 Nov 2017 21:49:13 +0000 Subject: [CMake] FindCUDA Separable Compilation and cublas_device In-Reply-To: References: Message-ID: Hi Robert Find attached a test case that reproduces the error. Jamil On Fri, 3 Nov 2017 at 21:00 Jamil Appa wrote: > Hi Robert > > I will put a minimal case together using one of the CUDA samples and > sent it through for testing with the new cmake support. > > On your second point, CUDA_CUBLAS_LIBRARIES should be empty if no > cublas libraries are present so that use case should be automatically > handled unless I am missing something. > > I will create a fork and topic branch with the change and submit it for > review. > > Thanks > > Jamil > > > On Fri, 3 Nov 2017 at 18:08 Robert Maynard > wrote: > >> HI Jamil, >> >> If you are interested in submitting a fix I can review, but I would like >> to also make sure that this issue doesn't exist inside the new cmake >> support for CUDA as a first class language. Can you produce a minimal test >> case that we can rework to use the new support and add to CMake's test >> suite. >> >> You will also need to track down what version of CUDA first added cublas_device >> so that we properly guard the inclusion. >> >> On Fri, Nov 3, 2017 at 7:39 AM, Jamil Appa >> wrote: >> >>> Hi Robert >>> >>> I am using CUDA_ADD_CUBLAS_TO_TARGET but the error happens during the >>> prelink phase when using separable compilation. (nvcc -dlink phase) >>> >>> My guess is that Nvidia have not included cublas_device.a in their >>> dlink phase as you don't have to provide any other libraries. I have asked >>> the Nvidia team if that is the case, but no reply yet. >>> >>> The general fix seems to be to modify lines 1759/1772 of >>> FindCUDA.cmake (in gitlab master) to include CUBLAS_LIBRARIES >>> >>> COMMAND ${CUDA_NVCC_EXECUTABLE} ${nvcc_flags} -dlink ${object_files} >>> ${CUDA_CUBLAS_LIBRARIES} -o ${output_file} >>> >>> This will have no impact if the cublas symbols are not used in the >>> object files. >>> >>> If you are happy with this I can submit the change for review. >>> >>> Jamil >>> >>> >>> On Thu, 2 Nov 2017 at 13:53 Robert Maynard >>> wrote: >>> >>>> Hi, >>>> >>>> Have you tried using the 'CUDA_ADD_CUBLAS_TO_TARGET' command on the >>>> target that has FindCUDA separable compilation enabled? >>>> >>>> On Wed, Nov 1, 2017 at 11:16 AM, Jamil Appa >>>> wrote: >>>> >>>>> Hi >>>>> >>>>> When using FindCUDA with separable compilation combined with device >>>>> code that uses cublas_device I get missing symbols when linking the >>>>> intermediate file at line 1758 >>>>> >>>>> FindCUDA.cmake >>>>> >>>>> If I change line 1758 to include the cublas_device library the >>>>> symbols are resolved correctly. >>>>> >>>>> COMMAND ${CUDA_NVCC_EXECUTABLE} ${nvcc_flags} -dlink >>>>> ${object_files} -o ${output_file} -lcublas_device >>>>> >>>>> Is there a way to pass through a library to >>>>> the CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS function that I am missing? >>>>> >>>>> Thanks >>>>> >>>>> Jamil >>>>> >>>>> *Jamil Appa* | Co-Founder and Director | Zenotech >>>>> [image: Papercut] >>>>> [image: Tel:] +44 (0)7747 606 788 <+44%207747%20606788> [image: >>>>> Zenotech LTD - Simulation Unlimited] >>>>> [image: Email:] jamil.appa at zenotech.com >>>>> [image: Web:] www.zenotech.com >>>>> [image: Papercut] >>>>> [image: linkedin:] [image: >>>>> Twitter:] [image: Location:] >>>>> >>>>> >>>>> Company Registration No : 07926926 | VAT No : 128198591 >>>>> >>>>> Registered Office : 1 Larkfield Grove, Chepstow, Monmouthshire, NP16 >>>>> 5UF, UK >>>>> >>>>> >>>>> Address : Bristol & Bath Science Park, Dirac Cres, Emersons Green, >>>>> Bristol BS16 7FR >>>>> >>>>> >>>>> -- >>>>> >>>>> Powered by www.kitware.com >>>>> >>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>> >>>>> Kitware offers various services to support the CMake community. For >>>>> more information on each offering, please visit: >>>>> >>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> http://public.kitware.com/mailman/listinfo/cmake >>>>> >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cuda-test.tar Type: application/x-tar Size: 10240 bytes Desc: not available URL: From Dvir.Yitzchaki at ceva-dsp.com Sun Nov 5 02:43:52 2017 From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki) Date: Sun, 5 Nov 2017 07:43:52 +0000 Subject: [CMake] CMake targeting Android with "Visual Studio 15 2017" generator issue In-Reply-To: <00ae01d354c0$8eacf530$ac06df90$@kuttatech.com> References: <00ae01d354c0$8eacf530$ac06df90$@kuttatech.com> Message-ID: <0e1e14b85c4d4abc82c1c720c8f7c76e@ceva-dsp.com> There was a CMake fork by Microsoft for generating VS 2015 Android projects (see here) but it seems it was discontinued. Regards, Dvir -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Bruce Elliott Sent: Friday, November 3, 2017 18:27 To: cmake at cmake.org Subject: [CMake] CMake targeting Android with "Visual Studio 15 2017" generator issue We are trying to port a C++/OpenGL project from MS Windows to Android. The project is using CMake to generate solution and project files for Visual Studio 2017. All attempts to create solution and project files for VS2017 when targeting Android have failed with the CMake GUI generating the following error message: >CMake Error at CMakeLists.txt:100 (project): > CMAKE_SYSTEM_NAME is 'Android' but 'NVIDIA Nsight Tegra Visual Studio > Edition' is not installed. > >Configuring incomplete, errors occurred! >See also "C:/SVN/Nexus_Android/Build_Android_vs2017/CMakeFiles/CMakeOutput.log". Line 100 of the CMakeLists.txt is: "project(${PROJECT_NAME} C CXX)" The log file contains: The target system is: Android - 23 - The host system is: Windows - 10.0.16299 - AMD64 I have tried toolchain files from OpenCV, Taka-No-Me as well as a simple toolchain file as follows: set(CMAKE_SYSTEM_NAME Android) set(CMAKE_SYSTEM_VERSION 23) # API level set(CMAKE_ANDROID_API 23) set(CMAKE_ANDROID_API_MIN 16) set(CMAKE_ANDROID_NDK C:/ProgramData/Microsoft/AndroidNDK/android-ndk-r15c) set(CMAKE_ANDROID_ARCH arm64-v8a) set(CMAKE_ANDROID_ARCH_ABI arm64-v8a) All result in the CMake GUI generating the error above. I have created a Native-Activity Application(Android) test project in VS2017 and have been able to build/deploy/debug the native C++ on both emulated targets for Android and a USB connected Android tablet target. VS2017 does not require ''NVIDIA Nsight Tegra Visual Studio Edition'. Is there a work around for CMake to get it to generate native C++ Android projects for VS2017? Tool versions being used: Visual Studio 15 2017 CMake 3.10.0-rc3 Android NDK r15c Regards, Bruce Elliott -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From linux at obiwahn.org Sun Nov 5 09:07:05 2017 From: linux at obiwahn.org (Jan Christoph Uhde) Date: Sun, 5 Nov 2017 15:07:05 +0100 Subject: [CMake] target_compile_features question Message-ID: Hi, I have a project using CMake 3.9. The project contains a header only library mylib. The library hast set the following property: target_compile_features(mylib INTERFACE cxx_std_17) Now I try to add otherlib to mylib (INTERFACE as well). otherlib has set some c++11 compile_features. When I try to compile tests for my lib I see gnu++11 as requested standard. Without otherlib gnu++17 is selected. Could this be a bug or I am using CMake in a wrong way. What is the best way to set the required standard for a header-only library? Thank You Jan https://travis-ci.org/ObiWahn/libobi/builds/297542567 https://github.com/ObiWahn/libobi/blob/cmake_problem/CMakeLists.txt#L31 - mylib https://github.com/kvasir-io/mpl/blob/development/CMakeLists.txt#L11 - otherlib From linux at obiwahn.org Sun Nov 5 10:10:54 2017 From: linux at obiwahn.org (Jan Christoph Uhde) Date: Sun, 5 Nov 2017 16:10:54 +0100 Subject: [CMake] [CMAKE] target_compile_features question In-Reply-To: References: Message-ID: <89d03bdf-f078-e207-924b-4435509f29e9@obiwahn.org> Sorry for the noise! I just noticed that I made a mistake in the shared lib version. I have obviously to use PUBLIC instead of INTERFACE, when specifying compile features. Jan On 2017-11-05 15:07, Jan Christoph Uhde wrote: > Hi, > > I have a project using CMake 3.9. > The project contains a header only library mylib. > The library hast set the following property: > > target_compile_features(mylib INTERFACE cxx_std_17) > > Now I try to add otherlib to mylib (INTERFACE as well). otherlib has set > some c++11 compile_features. > > When I try to compile tests for my lib I see gnu++11 as requested > standard. Without otherlib gnu++17 is selected. > > Could this be a bug or I am using CMake in a wrong way. What is the best > way to set the required standard for a header-only library? > > Thank You > > Jan > > > https://travis-ci.org/ObiWahn/libobi/builds/297542567 > https://github.com/ObiWahn/libobi/blob/cmake_problem/CMakeLists.txt#L31 > - mylib > https://github.com/kvasir-io/mpl/blob/development/CMakeLists.txt#L11 - > otherlib > From mailinglists at xgm.de Sun Nov 5 10:54:10 2017 From: mailinglists at xgm.de (Florian Lindner) Date: Sun, 5 Nov 2017 16:54:10 +0100 Subject: [CMake] target_compile_features question In-Reply-To: References: Message-ID: <9d025375-c8e9-8afa-dd35-500c4a9542d0@xgm.de> Am 05.11.2017 um 15:07 schrieb Jan Christoph Uhde: > Hi, > > I have a project using CMake 3.9. > The project contains a header only library mylib. > The library hast set the following property: > > target_compile_features(mylib INTERFACE cxx_std_17) > > Now I try to add otherlib to mylib (INTERFACE as well). otherlib has set > some c++11 compile_features. > > When I try to compile tests for my lib I see gnu++11 as requested > standard. Without otherlib gnu++17 is selected. Hey, just being curious, is cxx_std_17 a valid feature? I don't see it listed in https://cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html Best, Florian From lectem at gmail.com Sun Nov 5 12:34:35 2017 From: lectem at gmail.com (Lectem) Date: Sun, 5 Nov 2017 18:34:35 +0100 Subject: [CMake] target_compile_features question In-Reply-To: <9d025375-c8e9-8afa-dd35-500c4a9542d0@xgm.de> References: <9d025375-c8e9-8afa-dd35-500c4a9542d0@xgm.de> Message-ID: <59ff4bab.03a7df0a.ebb7f.2397@mx.google.com> Because you are looking at an old CMake version?? I think it was introduced in cmake 3.8.2?? De?: Florian Lindner Envoy? le?:dimanche 5 novembre 2017 17:03 ??: cmake at cmake.org Objet?:Re: [CMake] target_compile_features question Am 05.11.2017 um 15:07 schrieb Jan Christoph Uhde: > Hi, > > I have a project using CMake 3.9. > The project contains a header only library mylib. > The library hast set the following property: > > target_compile_features(mylib INTERFACE cxx_std_17) > > Now I try to add otherlib to mylib (INTERFACE as well). otherlib has set > some c++11 compile_features. > > When I try to compile tests for my lib I see gnu++11 as requested > standard. Without otherlib gnu++17 is selected. Hey, just being curious, is cxx_std_17 a valid feature? I don't see it listed in https://cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html Best, Florian -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Sun Nov 5 13:07:27 2017 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Sun, 5 Nov 2017 19:07:27 +0100 Subject: [CMake] custom_command and compile_commands.json Message-ID: Hi! I am trying to export a custom_command to the compile_commands.json database, but no luck up until now. The only similar question I found on the web is a Stackoverflow thread named ?cmake clang-tidy (or other script) as custom target?. I am trying to bring together C/C++ compilation, GnuPlot and LaTeX into a single Cmake script (done), and have the relevant Visual Studio Code extensions hook into the compile_commands.json file to recognize CMakes machinery and that they themselves are not responsible for kicking off the compilation of their respective source files. Microsofts C++ extension is compile_commands.json aware, but the LaTeX-Workshop extensino is not. I wanted to do the research before jumping to feature requests: is it possible to export @kmorel Github users UseLATEX custom_commands into the compile_commands.json database? As far as I saw, setting CMAKE_EXPORT_COMPILE_COMMANDS to ON right before add_latex_document() is not enough. Does LATEX need to be a first-class CMake language in order for this machinery to kick off? Tanks in advance, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brianlheim at gmail.com Mon Nov 6 10:34:52 2017 From: brianlheim at gmail.com (brian heim) Date: Mon, 6 Nov 2017 10:34:52 -0500 Subject: [CMake] Source modification using CMake Message-ID: Hi list, Hope you're doing well. I have a question about using CMake to patch the source code in a project I work on. This is the situation: - Project includes C++ transpiled from a different specialized language - That transpiler is not cross-platform, so we include transpiled C++ in our source tree - The generated code does not compile with MSVC 2013 because of a bug (specifically https://support.microsoft.com/en-us/help/315481/bug-too-many-unnested-loops-incorrectly-causes-a-c1061-compiler-error ) - Vendor of transpiler will not patch for this case, so we need to modify the source ourselves We don't want to _directly_ modify the source because that means we'll have to [remember to] do it on a regular basis, when new or updated source files are added. The patching is simple enough that it can be done with a regex. I am not very experienced with CMake, but I'm aware that two ways of modifying source files are: 1. configure_file(), which doesn't seem to give tools for this purpose. 2. file(READ ...) followed by file(WRITE ...). I've gotten my regex to work with it, but my attempt overwrites the source file in-place, unlike configure_file() which places the modified file in the build tree. Is there a way to do (2) correctly? By which I mean, can I do a form of configure_file() using a regex? Or is there an altogether easier solution that's staring me in the face? Thank you very much in advance for your help, Brian H -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmorel at sandia.gov Mon Nov 6 12:28:22 2017 From: kmorel at sandia.gov (Moreland, Kenneth) Date: Mon, 6 Nov 2017 17:28:22 +0000 Subject: [CMake] custom_command and compile_commands.json Message-ID: <87373553f1c147559cffc6434c6d2682@ES08AMSNLNT.srn.sandia.gov> M?t?, I don?t know anything about the CMAKE_EXPORT_COMPILE_COMMANDS feature, but I can attest that the UseLATEX commands are all created with add_custom_command (with some add_custom_target commands to set up the targets). Someone who knows the CMAKE_EXPORT_COMPILE_COMMANDS feature will have to answer whether it is possible to export custom commands. -Ken From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Nagy-Egri M?t? Ferenc via CMake Sent: Sunday, November 5, 2017 11:07 AM To: Cmake Mailing List Subject: [EXTERNAL] [CMake] custom_command and compile_commands.json Hi! I am trying to export a custom_command to the compile_commands.json database, but no luck up until now. The only similar question I found on the web is a Stackoverflow thread named ?cmake clang-tidy (or other script) as custom target?. I am trying to bring together C/C++ compilation, GnuPlot and LaTeX into a single Cmake script (done), and have the relevant Visual Studio Code extensions hook into the compile_commands.json file to recognize CMakes machinery and that they themselves are not responsible for kicking off the compilation of their respective source files. Microsofts C++ extension is compile_commands.json aware, but the LaTeX-Workshop extensino is not. I wanted to do the research before jumping to feature requests: is it possible to export @kmorel Github users UseLATEX custom_commands into the compile_commands.json database? As far as I saw, setting CMAKE_EXPORT_COMPILE_COMMANDS to ON right before add_latex_document() is not enough. Does LATEX need to be a first-class CMake language in order for this machinery to kick off? Tanks in advance, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From yue.nicholas at gmail.com Mon Nov 6 13:07:29 2017 From: yue.nicholas at gmail.com (Nicholas Yue) Date: Mon, 06 Nov 2017 18:07:29 +0000 Subject: [CMake] Source modification using CMake In-Reply-To: References: Message-ID: Hi Brian, Have you consider ExternaProject() ? It has a patching feature. https://cmake.org/cmake/help/v3.0/module/ExternalProject.html Cheers On Mon, 6 Nov 2017 at 07:35 brian heim wrote: > Hi list, > > Hope you're doing well. I have a question about using CMake to patch the > source code in a project I work on. This is the situation: > > - Project includes C++ transpiled from a different specialized language > - That transpiler is not cross-platform, so we include transpiled C++ in > our source tree > - The generated code does not compile with MSVC 2013 because of a bug > (specifically > https://support.microsoft.com/en-us/help/315481/bug-too-many-unnested-loops-incorrectly-causes-a-c1061-compiler-error > ) > - Vendor of transpiler will not patch for this case, so we need to modify > the source ourselves > > We don't want to _directly_ modify the source because that means we'll > have to [remember to] do it on a regular basis, when new or updated source > files are added. The patching is simple enough that it can be done with a > regex. I am not very experienced with CMake, but I'm aware that two ways of > modifying source files are: > > 1. configure_file(), which doesn't seem to give tools for this purpose. > 2. file(READ ...) followed by file(WRITE ...). I've gotten my regex to > work with it, but my attempt overwrites the source file in-place, unlike > configure_file() which places the modified file in the build tree. > > Is there a way to do (2) correctly? By which I mean, can I do a form of > configure_file() using a regex? Or is there an altogether easier solution > that's staring me in the face? > > Thank you very much in advance for your help, > > Brian H > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From llvm.999 at outlook.com Mon Nov 6 14:36:45 2017 From: llvm.999 at outlook.com (llvm 999) Date: Mon, 6 Nov 2017 19:36:45 +0000 Subject: [CMake] reusing CMAKELISTS.txt Message-ID: I have a CMAKELIST.txt file which can be used for more than 1 subdirectory. Is there a way to "reuse" this CMAKELISTS.txt file? I have tried placing this file at a common folder and then to place a shortcut or softlink in the sub-directories. But, this does not work. CMAKE does not seem to recognize the link. Any help would be much appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joubert.sy at gmail.com Mon Nov 6 14:44:17 2017 From: joubert.sy at gmail.com (Sylvain Joubert) Date: Mon, 6 Nov 2017 20:44:17 +0100 Subject: [CMake] reusing CMAKELISTS.txt In-Reply-To: References: Message-ID: <4ea8d15a-ad9f-5278-b619-079665675ced@gmail.com> Le 06/11/2017 ? 20:36, llvm 999 a ?crit?: > I have a CMAKELIST.txt file which can be used for more than 1 subdirectory. > > > Is there a way to "reuse" this CMAKELISTS.txt file? > As such I don't think so. > > I have tried placing this file at a common folder and then to place a > shortcut or softlink in the sub-directories. > > But, this does not work. CMAKE does not seem to recognize the link. > > > Any help would be much appreciated. > > > What you can do is create a function in a top/common CMakeLists.txt and call that function in each CMakeLists.txt of the different folders. You still need a file per folder but you don't duplicate code. From brad.king at kitware.com Mon Nov 6 14:59:38 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 6 Nov 2017 14:59:38 -0500 Subject: [CMake] CMake, Mingw-w64 32 bit exception handling. In-Reply-To: References: Message-ID: <4289c9df-3ca5-289d-9264-8e84f74dc393@kitware.com> On 08/24/2017 04:13 AM, Arne Kjetil Andersen wrote: > result in -lgcc_eh being added... The cause has been identified and reported here: https://gitlab.kitware.com/cmake/cmake/issues/17436 -Brad From annulen at yandex.ru Mon Nov 6 18:28:08 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 07 Nov 2017 02:28:08 +0300 Subject: [CMake] reusing CMAKELISTS.txt In-Reply-To: References: Message-ID: <4146961510010888@web17o.yandex.ru> > I have a CMAKELIST.txt file which can be used for more than 1 subdirectory. > > Is there a way to "reuse" this CMAKELISTS.txt file? > > I have tried placing this file at a common folder and then to place a shortcut or softlink in the sub-directories. Instead of link you can create CMakeLists.txt in each directory with include() of your common file > > But, this does not work. CMAKE does not seem to recognize the link. > > Any help would be much appreciated. -- Regards, Konstantin From craig.scott at crascit.com Mon Nov 6 21:31:41 2017 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 7 Nov 2017 10:31:41 +0800 Subject: [CMake] reusing CMAKELISTS.txt In-Reply-To: <4146961510010888@web17o.yandex.ru> References: <4146961510010888@web17o.yandex.ru> Message-ID: You can re-use the same CMakeLists.txt with add_subdirectory as long as each call specifies a different binary directory. Not saying this is a particularly good design, but it is allowable. E.g. # First time with a particular value of someVar set(someVar 1234) add_subdirectory(foo foo1) # Do it again with a different someVar set(someVar abcd) add_subdirectory(foo foo2) Instead of trying to re-use a whole CMakeLists.txt, consider defining a function or macro instead and call that in the places where you want to re-use the same code. On Tue, Nov 7, 2017 at 7:28 AM, Konstantin Tokarev wrote: > > > > I have a CMAKELIST.txt file which can be used for more than 1 > subdirectory. > > > > Is there a way to "reuse" this CMAKELISTS.txt file? > > > > I have tried placing this file at a common folder and then to place a > shortcut or softlink in the sub-directories. > > Instead of link you can create CMakeLists.txt in each directory with > include() of your common file > > > > > But, this does not work. CMAKE does not seem to recognize the link. > > > > Any help would be much appreciated. > -- > Regards, > Konstantin > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin.verschueren at gmail.com Tue Nov 7 18:29:27 2017 From: robin.verschueren at gmail.com (Robin Verschueren) Date: Tue, 07 Nov 2017 23:29:27 +0000 Subject: [CMake] How is the linker language of a library determined? Message-ID: Hi there, I'm building some C code into a library. The library needs to link to a C++ static library (IMPORTED target). I'm puzzled by the following: - with BUILD_SHARED_LIBS=OFF (default), everything works as expected and CMake sees the C library as a "C++ library" (i.e. it uses the C++ compiler/linker to link the two libraries together into a static library). - with BUILD_SHARED_LIBS=ON however, CMake tries to link the C library to the C++ library with cc (clang in my case), and I get linker errors. My questions: *What mechanism does CMake use to determine the linker language, and why is it different in these two cases?* Is it because I want to link a shared library against a static library as opposed to two static ones? Or is BUILD_SHARED_LIBS a red herring? Does CMake have a notion of what linker language to use for IMPORTED targets? I'm looking forward to your answer, Robin -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Tue Nov 7 21:47:31 2017 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 8 Nov 2017 10:47:31 +0800 Subject: [CMake] How is the linker language of a library determined? In-Reply-To: References: Message-ID: On Wed, Nov 8, 2017 at 7:29 AM, Robin Verschueren < robin.verschueren at gmail.com> wrote: > Hi there, > > I'm building some C code into a library. The library needs to link to a > C++ static library (IMPORTED target). I'm puzzled by the following: > > - with BUILD_SHARED_LIBS=OFF (default), everything works as expected > and CMake sees the C library as a "C++ library" (i.e. it uses the C++ > compiler/linker to link the two libraries together into a static library). > - with BUILD_SHARED_LIBS=ON however, CMake tries to link the C library > to the C++ library with cc (clang in my case), and I get linker errors. > > My questions: > > *What mechanism does CMake use to determine the linker language, and why > is it different in these two cases?* Is it because I want to link a > shared library against a static library as opposed to two static ones? Or > is BUILD_SHARED_LIBS a red herring? Does CMake have a notion of what linker > language to use for IMPORTED targets? > > Can you confirm which CMake generator type you are using? If it is the Xcode generator, do you get the same behaviour building at the command line as you do from within the IDE? I only ask because your symptoms sound eerily familiar to a problem I've seen before where linking used a different launcher from the command line compared to the IDE (see the Xcode section of this article ). -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin.verschueren at gmail.com Wed Nov 8 02:40:44 2017 From: robin.verschueren at gmail.com (Robin Verschueren) Date: Wed, 08 Nov 2017 07:40:44 +0000 Subject: [CMake] How is the linker language of a library determined? In-Reply-To: References: Message-ID: I use the "Unix Makefiles" generator (on macOS), with clang and clang++ as compilers (XCode version 9). On Wed, 8 Nov 2017 at 03:47 Craig Scott wrote: > > On Wed, Nov 8, 2017 at 7:29 AM, Robin Verschueren < > robin.verschueren at gmail.com> wrote: > >> Hi there, >> >> I'm building some C code into a library. The library needs to link to a >> C++ static library (IMPORTED target). I'm puzzled by the following: >> >> - with BUILD_SHARED_LIBS=OFF (default), everything works as expected >> and CMake sees the C library as a "C++ library" (i.e. it uses the C++ >> compiler/linker to link the two libraries together into a static library). >> - with BUILD_SHARED_LIBS=ON however, CMake tries to link the C >> library to the C++ library with cc (clang in my case), and I get linker >> errors. >> >> My questions: >> >> *What mechanism does CMake use to determine the linker language, and why >> is it different in these two cases?* Is it because I want to link a >> shared library against a static library as opposed to two static ones? Or >> is BUILD_SHARED_LIBS a red herring? Does CMake have a notion of what linker >> language to use for IMPORTED targets? >> >> > Can you confirm which CMake generator type you are using? If it is the > Xcode generator, do you get the same behaviour building at the command line > as you do from within the IDE? I only ask because your symptoms sound > eerily familiar to a problem I've seen before where linking used a > different launcher from the command line compared to the IDE (see the Xcode > section of this article > ). > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.zabel at egoproducts.com Wed Nov 8 09:54:42 2017 From: oliver.zabel at egoproducts.com (oliver.zabel at egoproducts.com) Date: Wed, 8 Nov 2017 15:54:42 +0100 Subject: [CMake] Toolchain with non-gcc argument format Message-ID: Hi, i have some modules which i want to cross-compile for different platforms which uses different compilers. One of them for example is the arm-gcc compiler which works over the toolchain file. Now i have a Renesas RX compiler which uses for example instead of "-I" for include paths the argument "-include=". So using this toolchain fails because cmake trys to use gcc arguments. I managed to compile my modules with the following approache: set(CMAKE_C_COMPILER_WORKS 1) project(MyModule C) cmake_minimum_required(VERSION 3.0) set(EXECUTABLE_NAME MyModule) set(SRC_FILES ${PROJECT_SOURCE_DIR}/module.c ${PROJECT_SOURCE_DIR}/main.c ) IF(RXCOMPILER) MESSAGE(STATUS "RX Mode") add_custom_target(dummy_target ALL DEPENDS EXECUTABLE_NAME) ADD_CUSTOM_COMMAND( OUTPUT EXECUTABLE_NAME COMMAND ${CMAKE_C_COMPILER} ARGS -output=obj=abs -cpu=rx200 -lang=c99 -goptimize -size ${SRC_FILES} COMMENT "RX Compiler" ) ELSE(RXCOMPILER) add_executable(EXECUTABLE_NAME ${SRC_FILES}) ENDIF(RXCOMPILER) Is there a better way of doing this? For example telling cmake to use "-include=" instaed of "-I"? Thanks for your help! Best regards, oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From algizklaudia at gmail.com Wed Nov 8 15:43:36 2017 From: algizklaudia at gmail.com (Klaudia Algiz) Date: Wed, 8 Nov 2017 21:43:36 +0100 Subject: [CMake] Problem with using CUDA Message-ID: Hello, I have a problem with using CUDA package in cmake. I've installed CUDA, version 9.0, downloaded from here: https://developer.nvidia.com/cuda-downloads?target_os=Linux&target_arch=x86_64&target_distro=Ubuntu&target_version=1604&target_type=runfilelocal and then to my CMakeList.txt file I added line: find_package (CUDA REQUIRED) but while running command cmake .. I was getting the following error: CMake Error at /usr/share/cmake-3.5/Modules/FindCUDA.cmake:617 (message): Specify CUDA_TOOLKIT_ROOT_DIR Call Stack (most recent call first): CMakeLists.txt:13 (find_package) I looked for some information and tried the following command: cmake -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda .. After that I am getting still some errors: CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message): Could NOT find CUDA (missing: CUDA_NVCC_EXECUTABLE CUDA_INCLUDE_DIRS CUDA_CUDART_LIBRARY) Call Stack (most recent call first): /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake-3.5/Modules/FindCUDA.cmake:949 (find_package_handle_standard_args) CMakeLists.txt:13 (find_package) Can anybody help me with that? -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Wed Nov 8 17:05:26 2017 From: paul at mad-scientist.net (Paul Smith) Date: Wed, 08 Nov 2017 17:05:26 -0500 Subject: [CMake] How to force use of Windows 64bit link.exe? Message-ID: <1510178726.11541.25.camel@mad-scientist.net> Hi all. I wonder if someone can help me get CMake to force Visual Studio to run the 64bit linker instead of the 32bit linker. By that I mean, the link.exe binary built for 64bit, not a linker that produces a 64bit executable. Sometimes (but not always) when I link my code I get an error from the 32bit link.exe and Visual Studio wants to automatically re-invoke the 64bit link.exe. I would prefer that it just always starts with the 64bit version, rather than fail and retry. I get errors like: LINK : the 32-bit linker (C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\link.exe) ran out of heap space; restarting link with the 64-bit linker I run CMake with a generator like this: cmake.exe -G "Visual Studio 14 2015" -A x64 D:\builds\src I want to convince cmake to tell Visual Studio to invoke the 64bit link.exe at first, rather than waiting for a failure--the 64bit link.exe is, I believe: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\link.exe Does anyone know how to force that to happen? BTW, I'm using CMake 3.5.2 at the moment. Cheers! From smeenai at fb.com Wed Nov 8 17:30:00 2017 From: smeenai at fb.com (Shoaib Meenai) Date: Wed, 8 Nov 2017 22:30:00 +0000 Subject: [CMake] How to force use of Windows 64bit link.exe? In-Reply-To: <1510178726.11541.25.camel@mad-scientist.net> References: <1510178726.11541.25.camel@mad-scientist.net> Message-ID: Running cmake from an x64 developer command prompt and passing -Thost=x64 to cmake should do the trick. On 11/8/17, 2:26 PM, "CMake on behalf of Paul Smith" wrote: Hi all. I wonder if someone can help me get CMake to force Visual Studio to run the 64bit linker instead of the 32bit linker. By that I mean, the link.exe binary built for 64bit, not a linker that produces a 64bit executable. Sometimes (but not always) when I link my code I get an error from the 32bit link.exe and Visual Studio wants to automatically re-invoke the 64bit link.exe. I would prefer that it just always starts with the 64bit version, rather than fail and retry. I get errors like: LINK : the 32-bit linker (C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\link.exe) ran out of heap space; restarting link with the 64-bit linker I run CMake with a generator like this: cmake.exe -G "Visual Studio 14 2015" -A x64 D:\builds\src I want to convince cmake to tell Visual Studio to invoke the 64bit link.exe at first, rather than waiting for a failure--the 64bit link.exe is, I believe: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\link.exe Does anyone know how to force that to happen? BTW, I'm using CMake 3.5.2 at the moment. Cheers! -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cmake.org_Wiki_CMake-5FFAQ&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=04uD08sTa71kZ1R71-0lfj2WhRqDAQ1MD4dFpTTvEMw&s=WUSP8DL8wol0uWj27DY-hr8Cxfo-wDIzw4VK8gxsYZA&e= Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_support.html&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=04uD08sTa71kZ1R71-0lfj2WhRqDAQ1MD4dFpTTvEMw&s=XPIwm3-OwRZY6iPlierCUC4nja73_1tN4MOrTmwjafU&e= CMake Consulting: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=04uD08sTa71kZ1R71-0lfj2WhRqDAQ1MD4dFpTTvEMw&s=znr1l-FqO4cl2CO0FquPjJu2rb3VFT_FB6fK5Kl7jj4&e= CMake Training Courses: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=04uD08sTa71kZ1R71-0lfj2WhRqDAQ1MD4dFpTTvEMw&s=HkOsuk57njZ5Gle8DHBws-Zxuye7VU87mKMu8Sj1Xa4&e= Visit other Kitware open-source projects at https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=04uD08sTa71kZ1R71-0lfj2WhRqDAQ1MD4dFpTTvEMw&s=PKDPXwr0OKmHvOmP0NDauxr8_gk81Twie9Bqc8IByuw&e= Follow this link to subscribe/unsubscribe: https://urldefense.proofpoint.com/v2/url?u=http-3A__public.kitware.com_mailman_listinfo_cmake&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=04uD08sTa71kZ1R71-0lfj2WhRqDAQ1MD4dFpTTvEMw&s=IMj1Uw3a24-XuV1oGDAnZFzXJiix5ZqSEg09HyKfLPU&e= From cornelis at bockemuehl.ch Wed Nov 8 18:03:09 2017 From: cornelis at bockemuehl.ch (cornelis at bockemuehl.ch) Date: Wed, 08 Nov 2017 23:03:09 +0000 Subject: [CMake] find_library not finding libraries - why? Message-ID: <20171108230309.Horde.9s7bHXVfqC4d-C2eU3kM015@webmail.bockemuehl.ch> In a CMakeLists.txt I have the following lines of code: # with this the user will be asked for a path that has then # lib64 other subdirectories that are specified below FIND_PATH(CLP_DIR LIBCLP) SET(CLP_LIB ${CLP_DIR}/LIB64) # after the user specified CLP_DIR this shows what is expected: # the full path to the libraries, but... MESSAGE(AUTHOR_WARNING ${CLP_LIB}) # with the following I think I cannot indicate more clearly where the libraries actually are: FIND_LIBRARY(CLP_LIBRARY?????? NAMES LIBCLP?????? PATHS ${CLP_LIB} NO_DEFAULT_PATH) FIND_LIBRARY(COINUTILS_LIBRARY NAMES LIBCOINUTILS PATHS ${CLP_LIB} NO_DEFAULT_PATH) FIND_LIBRARY(OSI_LIBRARY?????? NAMES LIBOSI?????? PATHS ${CLP_LIB} NO_DEFAULT_PATH) FIND_LIBRARY(OSICLP_LIBRARY??? NAMES LIBOSICLP??? PATHS ${CLP_LIB} NO_DEFAULT_PATH) # ...here everything comes as -NOTFOUND MESSAGE(AUTHOR_WARNING ${CLP_LIBRARY}) MESSAGE(AUTHOR_WARNING ${COINUTILS_LIBRARY}) MESSAGE(AUTHOR_WARNING ${OSI_LIBRARY}) MESSAGE(AUTHOR_WARNING ${OSICLP_LIBRARY}) A dir for the indicated directory shows the following files: -rwxrwxrwx 1 cornelis users???? 907? 8. Nov 18:37 libClp.la lrwxrwxrwx 1 cornelis users????? 42? 8. Nov 18:37 libClp.so -> libClp.so.1.13.11 lrwxrwxrwx 1 cornelis users????? 42? 8. Nov 18:37 libClp.so.1 -> libClp.so.1.13.11 -rwxrwxrwx 1 cornelis users 1887336? 8. Nov 18:37 libClp.so.1.13.11 -rwxrwxrwx 1 cornelis users??? 1010? 8. Nov 18:37 libClpSolver.la lrwxrwxrwx 1 cornelis users????? 54? 8. Nov 18:37 libClpSolver.so -> libClpSolver.so.1.13.11 lrwxrwxrwx 1 cornelis users????? 54? 8. Nov 18:37 libClpSolver.so.1 -> libClpSolver.so.1.13.11 -rwxrwxrwx 1 cornelis users? 415224? 8. Nov 18:37 libClpSolver.so.1.13.11 -rwxrwxrwx 1 cornelis users???? 870? 8. Nov 18:37 libCoinUtils.la lrwxrwxrwx 1 cornelis users????? 54? 8. Nov 18:37 libCoinUtils.so -> libCoinUtils.so.3.10.14 lrwxrwxrwx 1 cornelis users????? 54? 8. Nov 18:37 libCoinUtils.so.3 -> libCoinUtils.so.3.10.14 -rwxrwxrwx 1 cornelis users 1416632? 8. Nov 18:37 libCoinUtils.so.3.10.14 -rwxrwxrwx 1 cornelis users??? 1059? 8. Nov 18:37 libOsiClp.la lrwxrwxrwx 1 cornelis users????? 48? 8. Nov 18:37 libOsiClp.so -> libOsiClp.so.1.13.11 lrwxrwxrwx 1 cornelis users????? 48? 8. Nov 18:37 libOsiClp.so.1 -> libOsiClp.so.1.13.11 -rwxrwxrwx 1 cornelis users? 350080? 8. Nov 18:37 libOsiClp.so.1.13.11 -rwxrwxrwx 1 cornelis users??? 1038? 8. Nov 18:37 libOsiCommonTests.la lrwxrwxrwx 1 cornelis users????? 62? 8. Nov 18:37 libOsiCommonTests.so -> libOsiCommonTests.so.1.12.9 lrwxrwxrwx 1 cornelis users????? 62? 8. Nov 18:37 libOsiCommonTests.so.1 -> libOsiCommonTests.so.1.12.9 -rwxrwxrwx 1 cornelis users? 619392? 8. Nov 18:37 libOsiCommonTests.so.1.12.9 -rwxrwxrwx 1 cornelis users???? 905? 8. Nov 18:37 libOsi.la lrwxrwxrwx 1 cornelis users????? 40? 8. Nov 18:37 libOsi.so -> libOsi.so.1.12.9 lrwxrwxrwx 1 cornelis users????? 40? 8. Nov 18:37 libOsi.so.1 -> libOsi.so.1.12.9 -rwxrwxrwx 1 cornelis users? 400776? 8. Nov 18:37 libOsi.so.1.12.9 drwxrwxrwx 1 cornelis users??? 4096? 8. Nov 18:37 pkgconfig so the libraries are obviously there! Questions: WHAT AM I DOING WRONG? WHAT DID I POSSIBLY MISUNDERSTAND REGARDING THE FIND_LIBRARY COMMAND? Thanks for any helpful hints! Cornelis -------------- next part -------------- An HTML attachment was scrubbed... URL: From r030t1 at gmail.com Wed Nov 8 18:40:17 2017 From: r030t1 at gmail.com (R0b0t1) Date: Wed, 8 Nov 2017 17:40:17 -0600 Subject: [CMake] How to force use of Windows 64bit link.exe? In-Reply-To: References: <1510178726.11541.25.camel@mad-scientist.net> Message-ID: On Wednesday, November 8, 2017, Shoaib Meenai wrote: > Running cmake from an x64 developer command prompt and passing -Thost=x64 to cmake should do the trick. > Perhaps more advisable is selecting the Visual Studio generator and passing in the platform at the end: "Visual Studio 15 2017 Win64." Per https://cmake.org/cmake/help/v3.10/generator/Visual%20Studio%2015%202017.html . It might be wise to make 64 bit the default or at least more prominent. I had a hard time figuring this out. Cheers, R0b0t1 > On 11/8/17, 2:26 PM, "CMake on behalf of Paul Smith" < cmake-bounces at cmake.org on behalf of paul at mad-scientist.net> wrote: > > Hi all. I wonder if someone can help me get CMake to force Visual > Studio to run the 64bit linker instead of the 32bit linker. By that I > mean, the link.exe binary built for 64bit, not a linker that produces a > 64bit executable. > > Sometimes (but not always) when I link my code I get an error from the > 32bit link.exe and Visual Studio wants to automatically re-invoke the > 64bit link.exe. I would prefer that it just always starts with the > 64bit version, rather than fail and retry. > > I get errors like: > > LINK : the 32-bit linker > (C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\link.exe) > ran out of heap space; restarting link with the 64-bit linker > > I run CMake with a generator like this: > > cmake.exe -G "Visual Studio 14 2015" -A x64 D:\builds\src > > I want to convince cmake to tell Visual Studio to invoke the 64bit > link.exe at first, rather than waiting for a failure--the 64bit > link.exe is, I believe: > > C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\link.exe > > Does anyone know how to force that to happen? > > BTW, I'm using CMake 3.5.2 at the moment. > > Cheers! > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cmake.org_Wiki_CMake-5FFAQ&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=04uD08sTa71kZ1R71-0lfj2WhRqDAQ1MD4dFpTTvEMw&s=WUSP8DL8wol0uWj27DY-hr8Cxfo-wDIzw4VK8gxsYZA&e= > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_support.html&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=04uD08sTa71kZ1R71-0lfj2WhRqDAQ1MD4dFpTTvEMw&s=XPIwm3-OwRZY6iPlierCUC4nja73_1tN4MOrTmwjafU&e= > CMake Consulting: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=04uD08sTa71kZ1R71-0lfj2WhRqDAQ1MD4dFpTTvEMw&s=znr1l-FqO4cl2CO0FquPjJu2rb3VFT_FB6fK5Kl7jj4&e= > CMake Training Courses: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=04uD08sTa71kZ1R71-0lfj2WhRqDAQ1MD4dFpTTvEMw&s=HkOsuk57njZ5Gle8DHBws-Zxuye7VU87mKMu8Sj1Xa4&e= > > Visit other Kitware open-source projects at https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=04uD08sTa71kZ1R71-0lfj2WhRqDAQ1MD4dFpTTvEMw&s=PKDPXwr0OKmHvOmP0NDauxr8_gk81Twie9Bqc8IByuw&e= > > Follow this link to subscribe/unsubscribe: > https://urldefense.proofpoint.com/v2/url?u=http-3A__public.kitware.com_mailman_listinfo_cmake&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=04uD08sTa71kZ1R71-0lfj2WhRqDAQ1MD4dFpTTvEMw&s=IMj1Uw3a24-XuV1oGDAnZFzXJiix5ZqSEg09HyKfLPU&e= > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dvir.Yitzchaki at ceva-dsp.com Thu Nov 9 03:06:16 2017 From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki) Date: Thu, 9 Nov 2017 08:06:16 +0000 Subject: [CMake] [Digital Signature Failure] find_library not finding libraries - why? In-Reply-To: <20171108230309.Horde.9s7bHXVfqC4d-C2eU3kM015@webmail.bockemuehl.ch> References: <20171108230309.Horde.9s7bHXVfqC4d-C2eU3kM015@webmail.bockemuehl.ch> Message-ID: <3c40c3680943425799afa4bbbc3ddb9a@ceva-dsp.com> I think you should either use the full file name, e.g. libClp.so or just use Clp. See https://cmake.org/cmake/help/latest/command/find_library.html Regards, Dvir From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of cornelis at bockemuehl.ch Sent: Thursday, November 9, 2017 01:03 To: cmake at cmake.org Subject: [Digital Signature Failure] [CMake] find_library not finding libraries - why? In a CMakeLists.txt I have the following lines of code: # with this the user will be asked for a path that has then # lib64 other subdirectories that are specified below FIND_PATH(CLP_DIR libClp) SET(CLP_LIB ${CLP_DIR}/lib64) # after the user specified CLP_DIR this shows what is expected: # the full path to the libraries, but... message(AUTHOR_WARNING ${CLP_LIB}) # with the following I think I cannot indicate more clearly where the libraries actually are: FIND_LIBRARY(CLP_LIBRARY NAMES libClp PATHS ${CLP_LIB} NO_DEFAULT_PATH) FIND_LIBRARY(COINUTILS_LIBRARY NAMES libCoinUtils PATHS ${CLP_LIB} NO_DEFAULT_PATH) FIND_LIBRARY(OSI_LIBRARY NAMES libOsi PATHS ${CLP_LIB} NO_DEFAULT_PATH) FIND_LIBRARY(OSICLP_LIBRARY NAMES libOsiClp PATHS ${CLP_LIB} NO_DEFAULT_PATH) # ...here everything comes as -NOTFOUND message(AUTHOR_WARNING ${CLP_LIBRARY}) message(AUTHOR_WARNING ${COINUTILS_LIBRARY}) message(AUTHOR_WARNING ${OSI_LIBRARY}) message(AUTHOR_WARNING ${OSICLP_LIBRARY}) A dir for the indicated directory shows the following files: -rwxrwxrwx 1 cornelis users 907 8. Nov 18:37 libClp.la lrwxrwxrwx 1 cornelis users 42 8. Nov 18:37 libClp.so -> libClp.so.1.13.11 lrwxrwxrwx 1 cornelis users 42 8. Nov 18:37 libClp.so.1 -> libClp.so.1.13.11 -rwxrwxrwx 1 cornelis users 1887336 8. Nov 18:37 libClp.so.1.13.11 -rwxrwxrwx 1 cornelis users 1010 8. Nov 18:37 libClpSolver.la lrwxrwxrwx 1 cornelis users 54 8. Nov 18:37 libClpSolver.so -> libClpSolver.so.1.13.11 lrwxrwxrwx 1 cornelis users 54 8. Nov 18:37 libClpSolver.so.1 -> libClpSolver.so.1.13.11 -rwxrwxrwx 1 cornelis users 415224 8. Nov 18:37 libClpSolver.so.1.13.11 -rwxrwxrwx 1 cornelis users 870 8. Nov 18:37 libCoinUtils.la lrwxrwxrwx 1 cornelis users 54 8. Nov 18:37 libCoinUtils.so -> libCoinUtils.so.3.10.14 lrwxrwxrwx 1 cornelis users 54 8. Nov 18:37 libCoinUtils.so.3 -> libCoinUtils.so.3.10.14 -rwxrwxrwx 1 cornelis users 1416632 8. Nov 18:37 libCoinUtils.so.3.10.14 -rwxrwxrwx 1 cornelis users 1059 8. Nov 18:37 libOsiClp.la lrwxrwxrwx 1 cornelis users 48 8. Nov 18:37 libOsiClp.so -> libOsiClp.so.1.13.11 lrwxrwxrwx 1 cornelis users 48 8. Nov 18:37 libOsiClp.so.1 -> libOsiClp.so.1.13.11 -rwxrwxrwx 1 cornelis users 350080 8. Nov 18:37 libOsiClp.so.1.13.11 -rwxrwxrwx 1 cornelis users 1038 8. Nov 18:37 libOsiCommonTests.la lrwxrwxrwx 1 cornelis users 62 8. Nov 18:37 libOsiCommonTests.so -> libOsiCommonTests.so.1.12.9 lrwxrwxrwx 1 cornelis users 62 8. Nov 18:37 libOsiCommonTests.so.1 -> libOsiCommonTests.so.1.12.9 -rwxrwxrwx 1 cornelis users 619392 8. Nov 18:37 libOsiCommonTests.so.1.12.9 -rwxrwxrwx 1 cornelis users 905 8. Nov 18:37 libOsi.la lrwxrwxrwx 1 cornelis users 40 8. Nov 18:37 libOsi.so -> libOsi.so.1.12.9 lrwxrwxrwx 1 cornelis users 40 8. Nov 18:37 libOsi.so.1 -> libOsi.so.1.12.9 -rwxrwxrwx 1 cornelis users 400776 8. Nov 18:37 libOsi.so.1.12.9 drwxrwxrwx 1 cornelis users 4096 8. Nov 18:37 pkgconfig so the libraries are obviously there! Questions: What am I doing wrong? What did I possibly misunderstand regarding the find_library command? Thanks for any helpful hints! Cornelis -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.svitok at gmail.com Thu Nov 9 04:40:14 2017 From: jan.svitok at gmail.com (Jano Svitok) Date: Thu, 9 Nov 2017 10:40:14 +0100 Subject: [CMake] How to force use of Windows 64bit link.exe? Message-ID: -T host=x64 is your answer (-G chooses platform/generated code; -T host= chooses platform of the toolset itself). Alternatively to -T you can set ENV variable PreferredToolArchitecture=x64 See: https://stackoverflow.com/questions/19820718/how-to-make-visual-studio-use-the-native-amd64-toolchain Jano PS: I do not reply to the original message since I've just subscribed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at sap.com Thu Nov 9 04:30:23 2017 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 9 Nov 2017 09:30:23 +0000 Subject: [CMake] find_library not finding libraries - why? In-Reply-To: <20171108230309.Horde.9s7bHXVfqC4d-C2eU3kM015@webmail.bockemuehl.ch> References: <20171108230309.Horde.9s7bHXVfqC4d-C2eU3kM015@webmail.bockemuehl.ch> Message-ID: <30E26639-731A-4F6F-809E-B2CC71770BC3@sap.com> The problem is on NAMES argument. You have to specify library names without prefix. So Clp must be used rather than libClp. FIND_LIBRARY(CLP_LIBRARY NAMES Clp PATHS ${CLP_LIB} NO_DEFAULT_PATH) From: CMake on behalf of "cornelis at bockemuehl.ch" Date: Thursday 9 November 2017 at 00:09 To: "cmake at cmake.org" Subject: [CMake] find_library not finding libraries - why? In a CMakeLists.txt I have the following lines of code: # with this the user will be asked for a path that has then # lib64 other subdirectories that are specified below FIND_PATH(CLP_DIR libClp) SET(CLP_LIB ${CLP_DIR}/lib64) # after the user specified CLP_DIR this shows what is expected: # the full path to the libraries, but... message(AUTHOR_WARNING ${CLP_LIB}) # with the following I think I cannot indicate more clearly where the libraries actually are: FIND_LIBRARY(CLP_LIBRARY NAMES libClp PATHS ${CLP_LIB} NO_DEFAULT_PATH) FIND_LIBRARY(COINUTILS_LIBRARY NAMES libCoinUtils PATHS ${CLP_LIB} NO_DEFAULT_PATH) FIND_LIBRARY(OSI_LIBRARY NAMES libOsi PATHS ${CLP_LIB} NO_DEFAULT_PATH) FIND_LIBRARY(OSICLP_LIBRARY NAMES libOsiClp PATHS ${CLP_LIB} NO_DEFAULT_PATH) # ...here everything comes as -NOTFOUND message(AUTHOR_WARNING ${CLP_LIBRARY}) message(AUTHOR_WARNING ${COINUTILS_LIBRARY}) message(AUTHOR_WARNING ${OSI_LIBRARY}) message(AUTHOR_WARNING ${OSICLP_LIBRARY}) A dir for the indicated directory shows the following files: -rwxrwxrwx 1 cornelis users 907 8. Nov 18:37 libClp.la lrwxrwxrwx 1 cornelis users 42 8. Nov 18:37 libClp.so -> libClp.so.1.13.11 lrwxrwxrwx 1 cornelis users 42 8. Nov 18:37 libClp.so.1 -> libClp.so.1.13.11 -rwxrwxrwx 1 cornelis users 1887336 8. Nov 18:37 libClp.so.1.13.11 -rwxrwxrwx 1 cornelis users 1010 8. Nov 18:37 libClpSolver.la lrwxrwxrwx 1 cornelis users 54 8. Nov 18:37 libClpSolver.so -> libClpSolver.so.1.13.11 lrwxrwxrwx 1 cornelis users 54 8. Nov 18:37 libClpSolver.so.1 -> libClpSolver.so.1.13.11 -rwxrwxrwx 1 cornelis users 415224 8. Nov 18:37 libClpSolver.so.1.13.11 -rwxrwxrwx 1 cornelis users 870 8. Nov 18:37 libCoinUtils.la lrwxrwxrwx 1 cornelis users 54 8. Nov 18:37 libCoinUtils.so -> libCoinUtils.so.3.10.14 lrwxrwxrwx 1 cornelis users 54 8. Nov 18:37 libCoinUtils.so.3 -> libCoinUtils.so.3.10.14 -rwxrwxrwx 1 cornelis users 1416632 8. Nov 18:37 libCoinUtils.so.3.10.14 -rwxrwxrwx 1 cornelis users 1059 8. Nov 18:37 libOsiClp.la lrwxrwxrwx 1 cornelis users 48 8. Nov 18:37 libOsiClp.so -> libOsiClp.so.1.13.11 lrwxrwxrwx 1 cornelis users 48 8. Nov 18:37 libOsiClp.so.1 -> libOsiClp.so.1.13.11 -rwxrwxrwx 1 cornelis users 350080 8. Nov 18:37 libOsiClp.so.1.13.11 -rwxrwxrwx 1 cornelis users 1038 8. Nov 18:37 libOsiCommonTests.la lrwxrwxrwx 1 cornelis users 62 8. Nov 18:37 libOsiCommonTests.so -> libOsiCommonTests.so.1.12.9 lrwxrwxrwx 1 cornelis users 62 8. Nov 18:37 libOsiCommonTests.so.1 -> libOsiCommonTests.so.1.12.9 -rwxrwxrwx 1 cornelis users 619392 8. Nov 18:37 libOsiCommonTests.so.1.12.9 -rwxrwxrwx 1 cornelis users 905 8. Nov 18:37 libOsi.la lrwxrwxrwx 1 cornelis users 40 8. Nov 18:37 libOsi.so -> libOsi.so.1.12.9 lrwxrwxrwx 1 cornelis users 40 8. Nov 18:37 libOsi.so.1 -> libOsi.so.1.12.9 -rwxrwxrwx 1 cornelis users 400776 8. Nov 18:37 libOsi.so.1.12.9 drwxrwxrwx 1 cornelis users 4096 8. Nov 18:37 pkgconfig so the libraries are obviously there! Questions: What am I doing wrong? What did I possibly misunderstand regarding the find_library command? Thanks for any helpful hints! Cornelis -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at sap.com Thu Nov 9 04:33:02 2017 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 9 Nov 2017 09:33:02 +0000 Subject: [CMake] How to force use of Windows 64bit link.exe? In-Reply-To: <1510178726.11541.25.camel@mad-scientist.net> References: <1510178726.11541.25.camel@mad-scientist.net> Message-ID: <1A6C4B89-2633-4060-9B36-EA80445AB5F8@sap.com> For that purpose, set the environment variable PreferredToolArchitecture with value x64. On 08/11/2017 23:26, "CMake on behalf of Paul Smith" wrote: Hi all. I wonder if someone can help me get CMake to force Visual Studio to run the 64bit linker instead of the 32bit linker. By that I mean, the link.exe binary built for 64bit, not a linker that produces a 64bit executable. Sometimes (but not always) when I link my code I get an error from the 32bit link.exe and Visual Studio wants to automatically re-invoke the 64bit link.exe. I would prefer that it just always starts with the 64bit version, rather than fail and retry. I get errors like: LINK : the 32-bit linker (C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\link.exe) ran out of heap space; restarting link with the 64-bit linker I run CMake with a generator like this: cmake.exe -G "Visual Studio 14 2015" -A x64 D:\builds\src I want to convince cmake to tell Visual Studio to invoke the 64bit link.exe at first, rather than waiting for a failure--the 64bit link.exe is, I believe: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\link.exe Does anyone know how to force that to happen? BTW, I'm using CMake 3.5.2 at the moment. Cheers! -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake From cornelis at bockemuehl.ch Thu Nov 9 05:45:00 2017 From: cornelis at bockemuehl.ch (Cornelis =?ISO-8859-1?Q?Bockem=FChl?=) Date: Thu, 09 Nov 2017 11:45:00 +0100 Subject: [CMake] find_library not finding libraries - why? In-Reply-To: <30E26639-731A-4F6F-809E-B2CC71770BC3@sap.com> References: <20171108230309.Horde.9s7bHXVfqC4d-C2eU3kM015@webmail.bockemuehl.ch> <30E26639-731A-4F6F-809E-B2CC71770BC3@sap.com> Message-ID: <1510224300.17306.14.camel@bockemuehl.ch> Thanks - that was it! Now CMake is happy - just a question of seconds... Regarcs, Cornelis Am Donnerstag, den 09.11.2017, 09:30 +0000 schrieb CHEVRIER, Marc: > > > > The problem is on NAMES argument. You have to specify library names without prefix. So > Clp must be used rather than libClp. > FIND_LIBRARY(CLP_LIBRARY?????? NAMES > Clp?????? PATHS ${CLP_LIB} NO_DEFAULT_PATH) > > > > > ? > > > > > From: CMake on behalf of "cornelis at bockemue hl.ch" > > Date: Thursday 9 November 2017 at 00:09 > > > > To: "cmake at cmake.org" > > Subject: [CMake] find_library not finding libraries - why? > > > > ? > > > In a CMakeLists.txt I have the following lines of code: > > > > # with this the user will be asked for a path that has then > > # lib64 other subdirectories that are specified below > > FIND_PATH(CLP_DIR libClp) > > > > SET(CLP_LIB ${CLP_DIR}/lib64) > > > > # after the user specified CLP_DIR this shows what is expected: > > # the full path to the libraries, but... > > message(AUTHOR_WARNING ${CLP_LIB}) > > > > > # with the following I think I cannot indicate more clearly where the libraries actually are: > > > FIND_LIBRARY(CLP_LIBRARY?????? NAMES libClp?????? PATHS ${CLP_LIB} NO_DEFAULT_PATH) > > > FIND_LIBRARY(COINUTILS_LIBRARY NAMES libCoinUtils PATHS ${CLP_LIB} NO_DEFAULT_PATH) > > > FIND_LIBRARY(OSI_LIBRARY?????? NAMES libOsi?????? PATHS ${CLP_LIB} NO_DEFAULT_PATH) > > > FIND_LIBRARY(OSICLP_LIBRARY??? NAMES libOsiClp??? PATHS ${CLP_LIB} NO_DEFAULT_PATH) > > > > # ...here everything comes as -NOTFOUND > > message(AUTHOR_WARNING ${CLP_LIBRARY}) > > message(AUTHOR_WARNING ${COINUTILS_LIBRARY}) > > message(AUTHOR_WARNING ${OSI_LIBRARY}) > > message(AUTHOR_WARNING ${OSICLP_LIBRARY}) > > > > A dir for the indicated directory shows the following files: > > > > -rwxrwxrwx 1 cornelis users???? 907? 8. Nov 18:37 libClp.la > > > lrwxrwxrwx 1 cornelis users????? 42? 8. Nov 18:37 libClp.so -> libClp.so.1.13.11 > > > lrwxrwxrwx 1 cornelis users????? 42? 8. Nov 18:37 libClp.so.1 -> libClp.so.1.13.11 > > -rwxrwxrwx 1 cornelis users 1887336? 8. Nov 18:37 libClp.so.1.13.11 > > -rwxrwxrwx 1 cornelis users??? 1010? 8. Nov 18:37 libClpSolver.la > > > lrwxrwxrwx 1 cornelis users????? 54? 8. Nov 18:37 libClpSolver.so -> libClpSolver.so.1.13.11 > > > lrwxrwxrwx 1 cornelis users????? 54? 8. Nov 18:37 libClpSolver.so.1 -> libClpSolver.so.1.13.11 > > > -rwxrwxrwx 1 cornelis users? 415224? 8. Nov 18:37 libClpSolver.so.1.13.11 > > -rwxrwxrwx 1 cornelis users???? 870? 8. Nov 18:37 libCoinUtils.la > > > lrwxrwxrwx 1 cornelis users????? 54? 8. Nov 18:37 libCoinUtils.so -> libCoinUtils.so.3.10.14 > > > lrwxrwxrwx 1 cornelis users????? 54? 8. Nov 18:37 libCoinUtils.so.3 -> libCoinUtils.so.3.10.14 > > > -rwxrwxrwx 1 cornelis users 1416632? 8. Nov 18:37 libCoinUtils.so.3.10.14 > > -rwxrwxrwx 1 cornelis users??? 1059? 8. Nov 18:37 libOsiClp.la > > > lrwxrwxrwx 1 cornelis users????? 48? 8. Nov 18:37 libOsiClp.so -> libOsiClp.so.1.13.11 > > > lrwxrwxrwx 1 cornelis users????? 48? 8. Nov 18:37 libOsiClp.so.1 -> libOsiClp.so.1.13.11 > > > -rwxrwxrwx 1 cornelis users? 350080? 8. Nov 18:37 libOsiClp.so.1.13.11 > > > -rwxrwxrwx 1 cornelis users??? 1038? 8. Nov 18:37 libOsiCommonTests.la > > > lrwxrwxrwx 1 cornelis users????? 62? 8. Nov 18:37 libOsiCommonTests.so -> libOsiCommonTests.so.1.12.9 > > > lrwxrwxrwx 1 cornelis users????? 62? 8. Nov 18:37 libOsiCommonTests.so.1 -> libOsiCommonTests.so.1.12.9 > > > -rwxrwxrwx 1 cornelis users? 619392? 8. Nov 18:37 libOsiCommonTests.so.1.12.9 > > -rwxrwxrwx 1 cornelis users???? 905? 8. Nov 18:37 libOsi.la > > > lrwxrwxrwx 1 cornelis users????? 40? 8. Nov 18:37 libOsi.so -> libOsi.so.1.12.9 > > > lrwxrwxrwx 1 cornelis users????? 40? 8. Nov 18:37 libOsi.so.1 -> libOsi.so.1.12.9 > > -rwxrwxrwx 1 cornelis users? 400776? 8. Nov 18:37 libOsi.so.1.12.9 > > drwxrwxrwx 1 cornelis users??? 4096? 8. Nov 18:37 pkgconfig > > > > so the libraries are obviously there! > > > > Questions: > > What am I doing wrong? > > What did I possibly misunderstand regarding the find_library command? > > > > Thanks for any helpful hints! > > Cornelis > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Thu Nov 9 08:57:25 2017 From: paul at mad-scientist.net (Paul Smith) Date: Thu, 09 Nov 2017 08:57:25 -0500 Subject: [CMake] How to force use of Windows 64bit link.exe? In-Reply-To: References: <1510178726.11541.25.camel@mad-scientist.net> Message-ID: <1510235845.2456.263.camel@mad-scientist.net> On Wednesday, November 8, 2017, Shoaib Meenai wrote: > Running cmake from an x64 developer command prompt and passing > -Thost=x64 to cmake should do the trick. Thanks for the response! I'm not sure what you mean by "an x64 developer command": my builds are invoked in an automated way from a CI build agent (Bamboo, in my case) not from Visual Studio or from a command shell. There is no vcvarsall configuration in my environment before I invoke cmake. I tried adding the -Thost=x64 to my cmake invocation, which does indeed sound like what I want based on the cmake docs, but cmake failed. The CMakeError.log says: Project "D:\builds\CMakeFiles\3.5.2\CompilerIdC\CompilerIdC.vcxproj" on node 1 (default targets). C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Platform.targets(57 ,5): error MSB8020: The build tools for host=x64 (Platform Toolset = 'host=x64') cannot be found. To build using the host=x64 build tools, please install host=x64 build tools. Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right- click the solution, and then selecting "Retarget solution". [D:\builds\CMakeFiles\3.5.2\CompilerIdC\CompilerIdC.vcxproj] Done Building Project "D:\builds\CMakeFiles\3.5.2\CompilerIdC\CompilerIdC.vcxproj" (default targets) -- FAILED. However as far as I can see, I DO have the 64bit Visual Studo installed. My "Programs and Features" lists "Microsof Visual C++ 2015 Redistributable (x64) - 14.0.24212" (as well as "(x86)") There was nothing useful in the CMakeOutput.log (just "The system is: Windows - 6.2.9200 - AMD64") On Wed, 2017-11-08 at 17:40 -0600, R0b0t1 wrote: > Perhaps more advisable is selecting the Visual Studio generator and > passing in the platform at the end: "Visual Studio 15 2017 Win64." This isn't what I'm looking for, unfortunately. I'm already passing the -A x64 option to cmake, which is equivalent to what you're suggesting. This selects the _output_ architecture: that is, it instructs cmake to generate my programs as 64bit executables. That works fine. What I'm trying to do is get cmake to invoke the 64bit versions of the Visual Studio compiler and (in particular) linker; i.e., instead of linking my program using x86_amd64\link.exe (which is a 32bit link.exe program that can generate 64bit output) I want to link using amd64\link.exe, which is a 64bit program which can generate 64bit output. From briadam at sandia.gov Thu Nov 9 15:52:09 2017 From: briadam at sandia.gov (Adams, Brian M) Date: Thu, 9 Nov 2017 20:52:09 +0000 Subject: [CMake] [EXTERNAL] Re: Check if C++11 flag / standard was indeed found In-Reply-To: References: <31340603577c45c387e9d5faeed75355@ES06AMSNLNT.srn.sandia.gov> Message-ID: Thanks Robert, I presumed something like that was happening under the hood, but I'm trying to ask a slightly different couple questions. Suppose I set CMAKE_CXX_STANDARD=11 and CMAKE_CXX_STANDARD_REQUIRED=TRUE and configure a C++ project with at least one C++ target. Is there any variable or other means to tell if CMake was able to find and properly use a C++11 compliant compiler? I ask because if I set these variables and configure the project with a non-C++11-compliant compiler my build just trundles on until the first compile error due to lack of C++11. Or if I'm using a version of CMake that doesn't support compiler features for the toolchain in use (even if the compiler supports C++11), CMake might fail to add the necessary -std=c++11 flag, but doesn't warn or error about it. So, in that case, is there any way I can detect whether the version of CMake being run supports compiler features for the compiler in use? (As presumably that would be a reasonable indicator of language feature support.) Thanks, Brian -----Original Message----- From: Robert Maynard [mailto:robert.maynard at kitware.com] Sent: Tuesday, October 31, 2017 5:27 PM To: Adams, Brian M Cc: cmake at cmake.org Subject: [EXTERNAL] Re: [CMake] Check if C++11 flag / standard was indeed found Hi, CMake itself does this kind of inspection inside the CompileFlags.cmake file ( https://gitlab.kitware.com/cmake/cmake/blob/v3.9.3/CompileFlags.cmake#L62 ). While this exact example is for sunpro, it should be a good example of how to make a similar check for Intel. On Tue, Oct 31, 2017 at 2:17 PM, Adams, Brian M wrote: > Longer term, I plan to follow better practice and include compiler > language feature checks for specific C++11 features and let CMake > deduce the necessary language standard. > > > > In the meantime, I?m trying to implement a stopgap solution to warn > the user if CMake doesn?t know how to add a C++11 flag for the > CMAKE_CXX_COMPILER in use, so they can add it themselves. For > example, CMake C++11 support for Intel wasn?t added until 3.6, but a > user could still use CMake 3.1 to build our software if they explicitly add the ?-std=c++11? flag. > > > > I?m setting > > CMAKE_CXX_STANDARD=11 > > CMAKE_CXX_STANDARD_REQUIRED=TRUE > > > > My hope was that if the CMake version in use doesn?t know how to add > the necessary C++11 compile flag, that this would result in an error, > but it doesn?t seem to. > > > > Is there a way I can detect whether CMake was able to add the > necessary > C++11 flag, rather than letting the build run forward until a compile > failure? > > > > My fallback plan might be some conditionals that check specific > (CMAKE_CXX_COMPILER_ID, CMAKE_VERSION) pairs and warn the user for > cases where that version of CMake doesn?t have > -CXX-FeatureTests.cmake (which I?m assuming is an indicator of > being able to add the C++11 compile flags for that compiler ID?) > > > > Brian > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From craig.scott at crascit.com Fri Nov 10 00:32:27 2017 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 10 Nov 2017 13:32:27 +0800 Subject: [CMake] How is the linker language of a library determined? In-Reply-To: References: Message-ID: Can you create a small, self-contained example that reproduces the problem? A bit more than trivial since imported targets are involved, but give it a go, it will help narrow down the problem. If you're able to do that, please then report this in the issue tracker and attach that example. Also include the build output highlighting where you believe the commands used are incorrect. On Wed, Nov 8, 2017 at 3:40 PM, Robin Verschueren < robin.verschueren at gmail.com> wrote: > I use the "Unix Makefiles" generator (on macOS), with clang and clang++ as > compilers (XCode version 9). > > On Wed, 8 Nov 2017 at 03:47 Craig Scott wrote: > >> >> On Wed, Nov 8, 2017 at 7:29 AM, Robin Verschueren < >> robin.verschueren at gmail.com> wrote: >> >>> Hi there, >>> >>> I'm building some C code into a library. The library needs to link to a >>> C++ static library (IMPORTED target). I'm puzzled by the following: >>> >>> - with BUILD_SHARED_LIBS=OFF (default), everything works as expected >>> and CMake sees the C library as a "C++ library" (i.e. it uses the C++ >>> compiler/linker to link the two libraries together into a static library). >>> - with BUILD_SHARED_LIBS=ON however, CMake tries to link the C >>> library to the C++ library with cc (clang in my case), and I get linker >>> errors. >>> >>> My questions: >>> >>> *What mechanism does CMake use to determine the linker language, and why >>> is it different in these two cases?* Is it because I want to link a >>> shared library against a static library as opposed to two static ones? Or >>> is BUILD_SHARED_LIBS a red herring? Does CMake have a notion of what linker >>> language to use for IMPORTED targets? >>> >>> >> Can you confirm which CMake generator type you are using? If it is the >> Xcode generator, do you get the same behaviour building at the command line >> as you do from within the IDE? I only ask because your symptoms sound >> eerily familiar to a problem I've seen before where linking used a >> different launcher from the command line compared to the IDE (see the Xcode >> section of this article >> ). >> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> https://crascit.com >> > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.davydov at fau.de Fri Nov 10 04:54:57 2017 From: denis.davydov at fau.de (Denis Davydov) Date: Fri, 10 Nov 2017 10:54:57 +0100 Subject: [CMake] CDash does not show GIT column with commits Message-ID: <6A54F52D-91BE-447D-86B8-2897A2DB3B76@fau.de> Dear all, we are running a server with CDash v2.4.0-prebuilt (webpage shows 2.5.0 though) and can not figure out how to make CDash to show git commit for each build in the dashboard. The ctest script ends with: FILE(STRINGS ${CTEST_BINARY_DIRECTORY}/Testing/TAG _tag LIMIT_COUNT 1) SET(_path "${CTEST_BINARY_DIRECTORY}/Testing/${_tag}") FILE(WRITE ${_path}/Update.xml " ${CTEST_SITE} ${CTEST_BUILD_NAME} ${_tag}-${TRACK} GIT ${_git_rev} ${_git_branch} " ) CTEST_SUBMIT(RETURN_VALUE _res) From visual inspection I see that everything[1] is being picked up correctly in this file and it?s being created where it should. As for the CDash project settings, the ?Repository? tab has ?Repository Viewer Type? set to ?GitHub?, otherwise other fields are empty. The code is hosted at a private GitHub repository, so we can?t really point CDash to it, as far as I understand. Perhaps that?s the reason why we don?t see a ?Git? column for each build with hashes, but I kind of hoped that it?s possible to display it even if the repository itself is private and so CDash won?t be able to create meaningful hyperlinks to each commit. [1] The only minor issue is that I expected CTEST_VERSION to be defined, but it is not. So probably one would need to get it manually. Thank you in advance, Regards, Denis. From robin.verschueren at gmail.com Fri Nov 10 06:21:04 2017 From: robin.verschueren at gmail.com (Robin Verschueren) Date: Fri, 10 Nov 2017 11:21:04 +0000 Subject: [CMake] How is the linker language of a library determined? In-Reply-To: References: Message-ID: Hi Craig, Thanks for your continued support. I was able to create a small example that you can find here: https://gitlab.kitware.com/cmake/cmake/issues/17453 Best regards, Robin On Fri, 10 Nov 2017 at 06:32 Craig Scott wrote: > Can you create a small, self-contained example that reproduces the > problem? A bit more than trivial since imported targets are involved, but > give it a go, it will help narrow down the problem. If you're able to do > that, please then report this in the issue tracker and attach that example. > Also include the build output highlighting where you believe the commands > used are incorrect. > > On Wed, Nov 8, 2017 at 3:40 PM, Robin Verschueren < > robin.verschueren at gmail.com> wrote: > >> I use the "Unix Makefiles" generator (on macOS), with clang and clang++ >> as compilers (XCode version 9). >> >> On Wed, 8 Nov 2017 at 03:47 Craig Scott wrote: >> >>> >>> On Wed, Nov 8, 2017 at 7:29 AM, Robin Verschueren < >>> robin.verschueren at gmail.com> wrote: >>> >>>> Hi there, >>>> >>>> I'm building some C code into a library. The library needs to link to a >>>> C++ static library (IMPORTED target). I'm puzzled by the following: >>>> >>>> - with BUILD_SHARED_LIBS=OFF (default), everything works as >>>> expected and CMake sees the C library as a "C++ library" (i.e. it uses the >>>> C++ compiler/linker to link the two libraries together into a static >>>> library). >>>> - with BUILD_SHARED_LIBS=ON however, CMake tries to link the C >>>> library to the C++ library with cc (clang in my case), and I get linker >>>> errors. >>>> >>>> My questions: >>>> >>>> *What mechanism does CMake use to determine the linker language, and >>>> why is it different in these two cases?* Is it because I want to link >>>> a shared library against a static library as opposed to two static ones? Or >>>> is BUILD_SHARED_LIBS a red herring? Does CMake have a notion of what linker >>>> language to use for IMPORTED targets? >>>> >>>> >>> Can you confirm which CMake generator type you are using? If it is the >>> Xcode generator, do you get the same behaviour building at the command line >>> as you do from within the IDE? I only ask because your symptoms sound >>> eerily familiar to a problem I've seen before where linking used a >>> different launcher from the command line compared to the IDE (see the Xcode >>> section of this article >>> ). >>> >>> >>> >>> -- >>> Craig Scott >>> Melbourne, Australia >>> https://crascit.com >>> >> > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Fri Nov 10 09:06:42 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 10 Nov 2017 09:06:42 -0500 Subject: [CMake] [EXTERNAL] Re: Check if C++11 flag / standard was indeed found In-Reply-To: References: <31340603577c45c387e9d5faeed75355@ES06AMSNLNT.srn.sandia.gov> Message-ID: Hi, What version of CMake are you using and what miniare you exactly using? The CXX_STANDARD and REQUIRED will make sure that the compiler has the ability to enable some level of support for that language level. If CMake isn't aware of the flag to enable that language level it should error out. I expect what is happening is the compiler has partial support for C++11 so the flag is being added, but compilation fails, for these cases I recommend using target_compile_features to explicitly state what C++11 features you require from the compiler. On Thu, Nov 9, 2017 at 3:52 PM, Adams, Brian M wrote: > Thanks Robert, I presumed something like that was happening under the hood, but I'm trying to ask a slightly different couple questions. > > Suppose I set CMAKE_CXX_STANDARD=11 and CMAKE_CXX_STANDARD_REQUIRED=TRUE and configure a C++ project with at least one C++ target. Is there any variable or other means to tell if CMake was able to find and properly use a C++11 compliant compiler? > > I ask because if I set these variables and configure the project with a non-C++11-compliant compiler my build just trundles on until the first compile error due to lack of C++11. Or if I'm using a version of CMake that doesn't support compiler features for the toolchain in use (even if the compiler supports C++11), CMake might fail to add the necessary -std=c++11 flag, but doesn't warn or error about it. > > So, in that case, is there any way I can detect whether the version of CMake being run supports compiler features for the compiler in use? (As presumably that would be a reasonable indicator of language feature support.) > > Thanks, > Brian > > > -----Original Message----- > From: Robert Maynard [mailto:robert.maynard at kitware.com] > Sent: Tuesday, October 31, 2017 5:27 PM > To: Adams, Brian M > Cc: cmake at cmake.org > Subject: [EXTERNAL] Re: [CMake] Check if C++11 flag / standard was indeed found > > Hi, > > CMake itself does this kind of inspection inside the CompileFlags.cmake file ( > https://gitlab.kitware.com/cmake/cmake/blob/v3.9.3/CompileFlags.cmake#L62 > ). While this exact example is for sunpro, it should be a good example of how to make a similar check for Intel. > > On Tue, Oct 31, 2017 at 2:17 PM, Adams, Brian M wrote: >> Longer term, I plan to follow better practice and include compiler >> language feature checks for specific C++11 features and let CMake >> deduce the necessary language standard. >> >> >> >> In the meantime, I?m trying to implement a stopgap solution to warn >> the user if CMake doesn?t know how to add a C++11 flag for the >> CMAKE_CXX_COMPILER in use, so they can add it themselves. For >> example, CMake C++11 support for Intel wasn?t added until 3.6, but a >> user could still use CMake 3.1 to build our software if they explicitly add the ?-std=c++11? flag. >> >> >> >> I?m setting >> >> CMAKE_CXX_STANDARD=11 >> >> CMAKE_CXX_STANDARD_REQUIRED=TRUE >> >> >> >> My hope was that if the CMake version in use doesn?t know how to add >> the necessary C++11 compile flag, that this would result in an error, >> but it doesn?t seem to. >> >> >> >> Is there a way I can detect whether CMake was able to add the >> necessary >> C++11 flag, rather than letting the build run forward until a compile >> failure? >> >> >> >> My fallback plan might be some conditionals that check specific >> (CMAKE_CXX_COMPILER_ID, CMAKE_VERSION) pairs and warn the user for >> cases where that version of CMake doesn?t have >> -CXX-FeatureTests.cmake (which I?m assuming is an indicator of >> being able to add the C++11 compile flags for that compiler ID?) >> >> >> >> Brian >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For >> more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake From robert.maynard at kitware.com Fri Nov 10 09:57:30 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 10 Nov 2017 09:57:30 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.9.6 available for download Message-ID: We are pleased to announce that CMake 3.9.6 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.9.6 since 3.9.5: Brad King (1): CMake 3.9.6 Christian Pfeiffer (1): Restore exclusion of "gcc_eh" from implicit link libraries From Stefan.Waigand at continental-corporation.com Fri Nov 10 09:49:39 2017 From: Stefan.Waigand at continental-corporation.com (Stefan.Waigand at continental-corporation.com) Date: Fri, 10 Nov 2017 15:49:39 +0100 Subject: [CMake] spaces in generator strings troublesome Message-ID: Hello, the usual way to pass a generator string to the cmake executable on the command line is: cmake . -G"Unix Makefiles" But when i have some bash scripting around it and try to hold the command line arguments in a variable, the trouble begins... export CMDLINE=". -G\"Unix Makefiles\"" && cmake $CMDLINE -> CMake Error: Could not create named generator "Unix The reason seems to be bash separates arguments by spaces, and does not care for the quotes. I tried to escape the space character somehow, but nothing seems to help: export CMDLINE=". -G\"Unix\ Makefiles\"" && cmake $CMDLINE -> CMake Error: Could not create named generator "Unix\ export CMDLINE=". -G'Unix Makefiles'" && cmake $CMDLINE -> CMake Error: Could not create named generator 'Unix Now there might be ways how to work around this in bash. E.g. by quoting arguments on their own as done here https://stackoverflow.com/questions/42111441/how-to-pass-command-line-arguments-with-spaces-through-a-variable-in-bash or here https://unix.stackexchange.com/questions/108635/why-i-cant-escape-spaces-on-a-bash-script But this is more complicated, harder to understand and maintain - not a nice solution. Looking around, i do not seem to be alone with this kind of problem. Example https://stackoverflow.com/questions/20570042/calling-cmake-with-bash-variable-argument So here is my plea to the CMake developers and feature request: Could you please let CMake support this kind of command line? cmake . -GUnix_Makefiles i mean besides the established way CMake should accept the generator strings with '_' instead of ' '? If the command line parser could replace '_' by ' ' things would be backward compatible, right? This would solve problems as mentioned above and help people to automate their CMake environments. Thank you, Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Fri Nov 10 10:33:01 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 10 Nov 2017 18:33:01 +0300 Subject: [CMake] spaces in generator strings troublesome In-Reply-To: References: Message-ID: <2310741510327981@web36j.yandex.ru> 10.11.2017, 17:59, "stefan.waigand at continental-corporation.com" : > Hello, > > the usual way to pass a generator string to the cmake executable on the command line is: > ? ? ? ? cmake . -G"Unix Makefiles" > > But when i have some bash scripting around it and try to hold the command line arguments in a variable, the trouble begins... > > export CMDLINE=". -G\"Unix Makefiles\"" && cmake $CMDLINE > -> CMake Error: Could not create named generator "Unix > > The reason seems to be bash separates arguments by spaces, and does not care for the quotes. Just write your scripts in decent language which does not require multi-layer escaping: #!/usr/bin/env perl @cmdline = ('.', '-G', 'Unix Makefiles'); system 'cmake', @cmdline; > > I tried to escape the space character somehow, but nothing seems to help: > > export CMDLINE=". -G\"Unix\ Makefiles\"" && cmake $CMDLINE > -> CMake Error: Could not create named generator "Unix\ > > export CMDLINE=". -G'Unix Makefiles'" && cmake $CMDLINE > -> CMake Error: Could not create named generator 'Unix > > Now there might be ways how to work around this in bash. E.g. by quoting arguments on their own as done here > https://stackoverflow.com/questions/42111441/how-to-pass-command-line-arguments-with-spaces-through-a-variable-in-bash > or here > https://unix.stackexchange.com/questions/108635/why-i-cant-escape-spaces-on-a-bash-script > But this is more complicated, harder to understand and maintain - not a nice solution. > > Looking around, i do not seem to be alone with this kind of problem. Example https://stackoverflow.com/questions/20570042/calling-cmake-with-bash-variable-argument > > So here is my plea to the CMake developers and feature request: > Could you please let CMake support this kind of command line? > ? ? ? ? cmake . -GUnix_Makefiles > > i mean besides the established way CMake should accept the generator strings with '_' instead of ' '? > If the command line parser could replace '_' ?by ' ' things would be backward compatible, right? > This would solve problems as mentioned above and help people to automate their CMake environments. > > Thank you, > Stefan > > ,-- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake --? Regards, Konstantin From denis.davydov at fau.de Fri Nov 10 10:47:31 2017 From: denis.davydov at fau.de (Denis Davydov) Date: Fri, 10 Nov 2017 16:47:31 +0100 Subject: [CMake] CDash does not show GIT column with commits In-Reply-To: <6A54F52D-91BE-447D-86B8-2897A2DB3B76@fau.de> References: <6A54F52D-91BE-447D-86B8-2897A2DB3B76@fau.de> Message-ID: <5331440D-F4E3-4713-BC5C-5155706C4FE4@fau.de> Dear all, I think we figured out what is the problem. Looks like the Update.xml we were manually writing was missing time info, i.e. Nov 10 16:36 CET 1510328188 Nov 10 16:36 CET 1510328189 0 and XML parsing was failing. If we use CTEST_UPDATE() then on CDash there is another column ?Update? with ?Files? which point to revision info. The ?GIT column? I was originally referring to probably is a custom configuration of this project https://cdash.kyomu.43-1.org/index.php?project=deal.II Regards, Denis. > On 10 Nov 2017, at 10:54, Denis Davydov wrote: > > Dear all, > > we are running a server with CDash v2.4.0-prebuilt (webpage shows 2.5.0 though) and > can not figure out how to make CDash to show git commit for each build in the dashboard. > > The ctest script ends with: > > FILE(STRINGS ${CTEST_BINARY_DIRECTORY}/Testing/TAG _tag LIMIT_COUNT 1) > SET(_path "${CTEST_BINARY_DIRECTORY}/Testing/${_tag}") > > FILE(WRITE ${_path}/Update.xml > " > > ${CTEST_SITE} > ${CTEST_BUILD_NAME} > ${_tag}-${TRACK} > GIT > ${_git_rev} > ${_git_branch} > " > ) > > CTEST_SUBMIT(RETURN_VALUE _res) > > > From visual inspection I see that everything[1] is being picked up correctly in this file and it?s being created where it should. > As for the CDash project settings, the ?Repository? tab has ?Repository Viewer Type? set to ?GitHub?, otherwise other fields are empty. > The code is hosted at a private GitHub repository, so we can?t really point CDash to it, as far as I understand. > Perhaps that?s the reason why we don?t see a ?Git? column for each build with hashes, but I kind of hoped that > it?s possible to display it even if the repository itself is private and so CDash won?t be able to create meaningful > hyperlinks to each commit. > > [1] The only minor issue is that I expected CTEST_VERSION to be defined, but it is not. So probably one would need to get it > manually. > > > Thank you in advance, > Regards, > Denis. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mellery451 at gmail.com Fri Nov 10 11:30:46 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Fri, 10 Nov 2017 08:30:46 -0800 Subject: [CMake] spaces in generator strings troublesome In-Reply-To: References: Message-ID: <6602CDA2-A1DF-49A3-8047-5754DDE78215@gmail.com> > On Nov 10, 2017, at 6:49 AM, Stefan.Waigand at continental-corporation.com wrote: > > Hello, > > the usual way to pass a generator string to the cmake executable on the command line is: > cmake . -G"Unix Makefiles" > > But when i have some bash scripting around it and try to hold the command line arguments in a variable, the trouble begins... > > export CMDLINE=". -G\"Unix Makefiles\"" && cmake $CMDLINE > -> CMake Error: Could not create named generator "Unix > > The reason seems to be bash separates arguments by spaces, and does not care for the quotes. > > I tried to escape the space character somehow, but nothing seems to help: > > export CMDLINE=". -G\"Unix\ Makefiles\"" && cmake $CMDLINE > -> CMake Error: Could not create named generator "Unix\ > > export CMDLINE=". -G'Unix Makefiles'" && cmake $CMDLINE > -> CMake Error: Could not create named generator 'Unix > > Now there might be ways how to work around this in bash. E.g. by quoting arguments on their own as done here > https://stackoverflow.com/questions/42111441/how-to-pass-command-line-arguments-with-spaces-through-a-variable-in-bash > or here > https://unix.stackexchange.com/questions/108635/why-i-cant-escape-spaces-on-a-bash-script > But this is more complicated, harder to understand and maintain - not a nice solution. > > Looking around, i do not seem to be alone with this kind of problem. Example https://stackoverflow.com/questions/20570042/calling-cmake-with-bash-variable-argument > > So here is my plea to the CMake developers and feature request: > Could you please let CMake support this kind of command line? > cmake . -GUnix_Makefiles > > i mean besides the established way CMake should accept the generator strings with '_' instead of ' '? > If the command line parser could replace '_' by ' ' things would be backward compatible, right? > This would solve problems as mentioned above and help people to automate their CMake environments. > > Thank you, > Stefan perhaps handle arguments as an array variable in bash - it?s a slightly saner way to deal with args with spaces: CMDLINE=(. -G"Unix Makefiles") && cmake "${CMDLINE[@]}? -Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From fifteenknots505 at gmail.com Fri Nov 10 12:23:40 2017 From: fifteenknots505 at gmail.com (Martin Weber) Date: Fri, 10 Nov 2017 18:23:40 +0100 Subject: [CMake] [ANNOUNCE] CMake 3.9.6 available for download In-Reply-To: References: Message-ID: <3884725.4dvl4mfSQq@linux> Am Freitag, 10. November 2017, 09:57:30 CET schrieb Robert Maynard: > We are pleased to announce that CMake 3.9.6 is now available for download. > > Please use the latest release from our download page: > https://cmake.org/download/ > > Thanks for your support! > > ------------------------------------------------------------------------- > Changes in 3.9.6 since 3.9.5: > > Brad King (1): > CMake 3.9.6 > > Christian Pfeiffer (1): > Restore exclusion of "gcc_eh" from implicit link libraries Great! Does it have new keywords or language changes? (Just to keep my eclipse plugin up-to-date). Martin -- Cd wrttn wtht vwls s mch trsr. From robert.maynard at kitware.com Fri Nov 10 14:06:14 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 10 Nov 2017 14:06:14 -0500 Subject: [CMake] CMake 3.10.0-rc5 is now ready for testing Message-ID: I am proud to announce the fifth CMake 3.10 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.10 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.10/release/3.10.html Some of the more significant changes in CMake 3.10 are: * The flang Fortran compiler is now supported, with compiler id "Flang". * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * "FindMPI" received a major overhaul. It now features language specific components, better Fortran support, and support for statically linked MPI implementations. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module underwent numerous improvements. It has gained support for GLVND and EGL on Linux. It now has import targets that separate the OpenGL library and OpenGL contexts. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". CMake 3.10 Release Notes ************************ Changes made since CMake 3.9 include the following. New Features ============ Platforms --------- * The flang Fortran compiler is now supported, with compiler id "Flang". * A new minimal platform file for "Midipix" was added. * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * Support for the IAR ARM Compiler was improved. Generators ---------- * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools like ccache along with the compiler for the "CUDA" language ("C" and "CXX" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * The "CodeBlocks" extra generator learned to optionally exclude files from outside the project root directory from the generated project. See the "CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES" variable. Commands -------- * The "cmake_host_system_information()" command learned more keys to get information about the processor capabilities and the host OS version. * The "configure_file()" command learned to support indented "# cmakedefine" and "# cmakedefine01". Spaces and/or tabs between the "#" character and the "cmakedefine"/"cmakedefine01" words are now understood and preserved in the output. * The "execute_process()" command gained a "RESULTS_VARIABLE" option to collect a list of results from all children in a pipeline of processes when multiple "COMMAND" arguments are given. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * The "string()" command learned a new "PREPEND" subcommand. * The "string(TIMESTAMP)" command now supports "%A" for full weekday name and "%B" for full month name. Variables --------- * A "CMAKE_DIRECTORY_LABELS" variable was added to specify labels for all tests in a directory. Properties ---------- * A "_CPPCHECK" target property and supporting "CMAKE__CPPCHECK" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "cppcheck" with the compiler for "C" and "CXX" languages. * A "LABELS" directory property was added to specify labels for all targets and tests in a directory. * A "TEST_INCLUDE_FILES" directory property was added to list any number of files to be included when running tests with "ctest(1)". This generalizes the "TEST_INCLUDE_FILE" property. * The "VS_DOTNET_REFERENCEPROP__TAG_" target property was added to support custom XML tags for reference assemblies in C# targets. * Source file properties "VS_SHADER_OUTPUT_HEADER_FILE" and "VS_SHADER_VARIABLE_NAME" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "FindCurses" module gained a "CURSES_NEED_WIDE" option to request the wide-character variant. * The "FindEXPAT" module now provides imported targets. * The "FindFreetype" module now provides imported targets. * "FindMPI" gained a number of new features, including: * Language-specific components have been added to the module. * Many more MPI environments are now supported. * The environmental support for Fortran has been improved. * A user now has fine-grained control over the MPI selection process, including passing custom parameters to the MPI compiler. * The version of the implemented MPI standard is now being exposed. * MPI-2 C++ bindings can now be detected and also suppressed if so desired. * The available Fortran bindings are now being detected and verified. * Various MPI-3 information can be requested, including the library version and Fortran capabilities of the individual bindings. * Statically linked MPI implementations are supported. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module gained support for GLVND on Linux. * The "FindOpenMP" module gained support for language-specific components. * A "FindPatch" module was added to find the "patch" command-line executable. * The "FindProtobuf" module "protobuf_generate_cpp()" command gained a "DESCRIPTORS" option to generate descriptor files. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. Unlike the source parsing approach, dynamic discovery executes the test (in 'list available tests' mode) at build time to discover tests. This is robust against unusual ways of labeling tests, provides much better support for advanced features such as parameterized tests, and does not require re-running CMake to discover added or removed tests within a test executable. * The "InstallRequiredSystemLibraries" module gained support for installing Intel compiler runtimes. Autogen ------- * When using "AUTOMOC" or "AUTOUIC" with a multi configuration generator (e.g. "Xcode"), included "*.moc", "moc_*.cpp" and "ui_*.h" files are generated in "/include_" instead of "/include". * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * When using "AUTOMOC", CMake searches for the strings "Q_OBJECT", "Q_GADGET" or "Q_NAMESPACE" in a source file to determine if it needs to be "moc" processed. The new "CMAKE_AUTOMOC_MACRO_NAMES" variable and "AUTOMOC_MACRO_NAMES" target property may be set to register additional strings (macro names) to search for. * When using "AUTOMOC", the new "CMAKE_AUTOMOC_COMPILER_PREDEFINES" variable and "AUTOMOC_COMPILER_PREDEFINES" target property specify whether to enable or disable the generation of the compiler pre definitions file "moc_predefs.h". CTest ----- * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. CPack ----- * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "CPackDeb" module learned to set package release version in "Version" info property. See the "CPACK_DEBIAN_PACKAGE_RELEASE" variable. * The "CPackDeb" module learned more strict package version checking that complies with Debian rules. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "REPLACES" and "CHECKABLE" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_FILE_EXTENSION" variable to customize target binary format. * The "CPackIFW" module gained new "CPACK_IFW_REPOSITORIES_DIRECTORIES" variable to specify additional repositories dirs that will be used to resolve and repack dependent components. This feature is only available when using QtIFW 3.1 or later. * Modules "CPackRPM" and "CPackDeb" learned to set package epoch version. See "CPACK_RPM_PACKAGE_EPOCH" and "CPACK_DEBIAN_PACKAGE_EPOCH" variables. Other ----- * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The graphviz output now distinguishes among the different dependency types "PUBLIC", "PRIVATE" and "INTERFACE" and represents them in the output graph as solid, dashed and dotted edges. Deprecated and Removed Features =============================== * Support for building CMake itself with C++98 compilers was dropped. CMake is now implemented using C++11. * Support for building CMake on HP-UX has been dropped pending better support for C++11 and a port of libuv. See CMake Issue 17137. Use CMake 3.9 or lower instead for HP-UX support. Other Changes ============= * On FreeBSD the C++ compiler named "c++" is now the preferred default. * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". * The "get_filename_component()" "PROGRAM" mode semantics have been revised to not tolerate unquoted spaces in the path to the program while also accepting arguments. While technically incompatible with the old behavior, it is expected that behavior under typical use cases with properly-quoted command-lines has not changed. ---------------------------------------------------------------------------- Changes made since CMake 3.10.0-rc4: Andr? Apitzsch (1): FindDoxygen: Fix setting of HAVE_DOT in non-backward-compat mode Axel Huebl (1): FindHDF5: Fix H5_VERSION on Patch in C Brad King (4): FindOpenGL: Clarify logic constructing OPENGL_LIBRARIES FindOpenGL: Default to non-GLVND libraries for legacy GL Windows: Do not report manifest tool update notification as failure CMake 3.10.0-rc5 Christian Pfeiffer (2): IRSL: Add support for the 2018 release on Windows. Restore exclusion of "gcc_eh" from implicit link libraries Yoshinori Tahara (1): CSharp: Fix compiler version detection in non-English languages From m.tmatma at gmail.com Fri Nov 10 17:54:02 2017 From: m.tmatma at gmail.com (masaru tsuchiyama) Date: Sat, 11 Nov 2017 07:54:02 +0900 Subject: [CMake] Output Directory Message-ID: Hi, Before running cmake, we need to change a directotry where we want to create output files. But I think it is a bit inconvenient. Is there any plan to implement an option of the output directory? Regards. Masaru. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfsone at gmail.com Sat Nov 11 21:03:41 2017 From: kfsone at gmail.com (Oliver Smith) Date: Sat, 11 Nov 2017 18:03:41 -0800 Subject: [CMake] Feature req: Project-specified mandatory variables Message-ID: Consider the following: PROJECT(Mandatory) SET(USING_SHAPE "" CACHE STRING "[Required] Shape config: Round or Square") SET_PROPERTY(CACHE USING_SHAPE PROPERTY STRINGS Round Square) IF (NOT USING_SHAPE) MESSAGE(FATAL_ERROR "'USING_SHAPE' variable is required but was not set. Choose Round or Square") ENDIF () MESSAGE(STATUS "Shape config: ${USING_SHAPE}") ... The first time a user runs cmake here, they will receive a wall of text about compiler identification, followed by a complex error message that most developers can probably parse, but it's poorly suited for other people participating in a larger build system. etc. This leads to a common case where teams wrap their cmake invocation behind one or more script layers to hoist the setting checks out of the scripts. Consider: PROJECT(Mandatory) EXTERNAL_VALUE( # or it could be 'set' with a special case for 'FATAL_ERROR' as the default USING_SHAPE FATAL_ERROR "Shape config" STRINGS Round Square ) MESSAGE(STATUS "Shape config: ${USING_SHAPE}") The CMake GUI(s) could also pick up on these and prompt the user for them at the start of the config state. Other wordings: SET(USING_SHAPE FATAL_ERROR "Shape Config" ...) MANDATORY(USING_SHAPE "Shape Config ...) REQUIRE_SETTING REQUIRE_VARIABLE REQUIRED_VARIABLE -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dvir.Yitzchaki at ceva-dsp.com Sun Nov 12 03:52:11 2017 From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki) Date: Sun, 12 Nov 2017 08:52:11 +0000 Subject: [CMake] [Digital Signature Failure] Output Directory In-Reply-To: References: Message-ID: You have the -B switch, see https://cgold.readthedocs.io/en/latest/glossary/-B.html#b Regards, Dvir From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of masaru tsuchiyama Sent: Saturday, November 11, 2017 00:54 To: cmake at cmake.org Subject: [Digital Signature Failure] [CMake] Output Directory Hi, Before running cmake, we need to change a directotry where we want to create output files. But I think it is a bit inconvenient. Is there any plan to implement an option of the output directory? Regards. Masaru. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noflaco at gmail.com Sun Nov 12 09:04:26 2017 From: noflaco at gmail.com (Carlton Banks) Date: Sun, 12 Nov 2017 15:04:26 +0100 Subject: [CMake] cmake sometimes don't find the header Message-ID: I am not sure I understand why I am having this problem.. but cmake seem to have some problems with finding the header file located in a different project. tree view of my system: https://pastebin.com/AvydEbeW I?ve included the directory to the project which header files I am interested in, and also added the path in my target_inlcude_directories. The problems is my database.h cannot see record.h. database/CmakeLists.txt: https://pastebin.com/DpcMjtMa The weird part is that it sometimes is able to compile, and other times it get stuck with this not able to find the header? what could the problem be? From robert.maynard at kitware.com Sun Nov 12 11:02:28 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Sun, 12 Nov 2017 11:02:28 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.9.6 available for download In-Reply-To: <3884725.4dvl4mfSQq@linux> References: <3884725.4dvl4mfSQq@linux> Message-ID: No 3.9.6 just corrects a mingw regression. On Fri, Nov 10, 2017 at 12:23 PM, Martin Weber wrote: > Am Freitag, 10. November 2017, 09:57:30 CET schrieb Robert Maynard: >> We are pleased to announce that CMake 3.9.6 is now available for download. >> >> Please use the latest release from our download page: >> https://cmake.org/download/ >> >> Thanks for your support! >> >> ------------------------------------------------------------------------- >> Changes in 3.9.6 since 3.9.5: >> >> Brad King (1): >> CMake 3.9.6 >> >> Christian Pfeiffer (1): >> Restore exclusion of "gcc_eh" from implicit link libraries > > Great! > Does it have new keywords or language changes? (Just to keep my eclipse plugin > up-to-date). > > Martin > > -- > Cd wrttn wtht vwls s mch trsr. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From pfultz2 at yahoo.com Sun Nov 12 20:27:54 2017 From: pfultz2 at yahoo.com (P F) Date: Sun, 12 Nov 2017 19:27:54 -0600 Subject: [CMake] cmake sometimes don't find the header In-Reply-To: References: Message-ID: I am not sure, but you should write the cmake target-oriented(instead of using variables). So you shouldn?t use `include_directories` either. It should be written: # # Build static library add_library(database database.cpp database.h) target_compile_features(database PUBLIC cxx_defaulted_functions) target_include_directories(database PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}) target_link_libraries(database record spectogram) And record and spectogram should be written in a similar fashion. By using targets, you don?t have to worry about the targets being defined yet, so the superproject doesn?t need to order the `add_subdirectory` calls(it can even support circular dependencies). Another thing, you shouldn?t declare another project unless you planning on making it standalone. This means it should find the dependencies through `find_package` and be installable with its usage requirements, which would be written like this: project(database) find_package(record) find_package(spectogram) # # Build static library add_library(database database.cpp database.h) target_compile_features(database PUBLIC cxx_defaulted_functions) target_include_directories(database PUBLIC $) target_link_libraries(database record spectogram) install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/database.h DESTINATION include) install(TARGETS database EXPORT database-targets RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib INCLUDES DESTINATION include ) install(EXPORT database-targets FILE database-targets.cmake DESTINATION lib/cmake/database ) file(WRITE "${PROJECT_BINARY_DIR}/database-config.cmake" " include(CMakeFindDependencyMacro) find_dependency(record) find_dependency(spectogram) include(\"\${CMAKE_CURRENT_LIST_DIR}/database-targets.cmake\") ") write_basic_package_version_file("${PROJECT_BINARY_DIR}/database-config-version.cmake" VERSION 1.0 COMPATIBILITY AnyNewerVersion ) install(FILES "${PROJECT_BINARY_DIR}/database-config.cmake" "${PROJECT_BINARY_DIR}/database-config-version.cmake" DESTINATION lib/cmake/database ) The dependencies can be found either through find_package for standalone or through add_subdirectory in the superproject by overriding find_package. The effective cmake talk describes how such setup works, here: https://www.youtube.com/watch?v=bsXLMQ6WgIk Or you can use a single project for all components. > On Nov 12, 2017, at 8:04 AM, Carlton Banks wrote: > > I am not sure I understand why I am having this problem.. > but cmake seem to have some problems with finding the header file located in a different project. > > tree view of my system: https://pastebin.com/AvydEbeW > > I?ve included the directory to the project which header files I am interested in, and also added the path in my > target_inlcude_directories. The problems is my database.h cannot see record.h. > > database/CmakeLists.txt: > > https://pastebin.com/DpcMjtMa > > The weird part is that it sometimes is able to compile, and other times it get stuck with this not able to find the header? > > what could the problem 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: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.tmatma at gmail.com Mon Nov 13 17:49:20 2017 From: m.tmatma at gmail.com (masaru tsuchiyama) Date: Mon, 13 Nov 2017 22:49:20 +0000 Subject: [CMake] [Digital Signature Failure] Output Directory In-Reply-To: References: Message-ID: thanks. I'll try it. Regards Masaru 2017?11?12?(?) 17:52 Dvir Yitzchaki : > You have the -B switch, see > https://cgold.readthedocs.io/en/latest/glossary/-B.html#b > > > > Regards, > > Dvir > > > > *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *masaru > tsuchiyama > *Sent:* Saturday, November 11, 2017 00:54 > *To:* cmake at cmake.org > *Subject:* [Digital Signature Failure] [CMake] Output Directory > > > > Hi, > > > > Before running cmake, we need to change a directotry where we want to > create output files. > > But I think it is a bit inconvenient. > > > > Is there any plan to implement an option of the output directory? > > > > Regards. > > Masaru. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From psprint at zdharma.org Mon Nov 13 19:39:47 2017 From: psprint at zdharma.org (Sebastian Gniazdowski) Date: Tue, 14 Nov 2017 01:39:47 +0100 Subject: [CMake] Using CMake for general scripting tasks? Message-ID: Hello? CMake has so many powerful features that I always suspected, that it can be used for tasks normally handled by Bash or sh. I've found following package manager written in CMake:? https://docs.hunter.sh/en/latest/overview/what-is-it.html? So I think this project confirms CMake's potential for handling general scripting tasks. However, it's hard to get some inspiration from Hunter, it's just a large collection of CMake packages focused on one specialized goal.? But maybe someone used CMake for less specialized scripting tasks and would share? I'm writing Zsh plugin manager, Zplugin, and I want to integrate with CMake somehow, to get some swiss army knife features.? -- Sebastian Gniazdowski psprint /at/ zdharma.org From i.zaufi at gmail.com Mon Nov 13 20:26:28 2017 From: i.zaufi at gmail.com (Alex Turbov) Date: Tue, 14 Nov 2017 01:26:28 +0000 Subject: [CMake] Using CMake for general scripting tasks? In-Reply-To: References: Message-ID: Hi Sebastian, Particularly I've used CMake "scripts" in some "build configurations" at our CI server as a truly cross-platform scripting language for generic tasks like download archive, check sha/md5, unpack it, do some file operations... it works perfectly for Linux and Windows (it is why I chose CMake %). BTW, also I use it to talk to some REST API a little, but found lack of setting arbitrary HTTP method... :( for simple requests it is fine, but really soon it is not enough existed methods of `file` command... it is why I'm thinking about to extend it (curl library used by CMake can do all that I need)... but need to discuss first, cus I think `file` command is not a suitable candidate for such kind of extension... (casting Brad King into the thread %) On Tue, Nov 14, 2017 at 12:39 AM, Sebastian Gniazdowski wrote: > Hello > CMake has so many powerful features that I always suspected, that it can > be used for tasks normally handled by Bash or sh. I've found following > package manager written in CMake: > > https://docs.hunter.sh/en/latest/overview/what-is-it.html > > So I think this project confirms CMake's potential for handling general > scripting tasks. However, it's hard to get some inspiration from Hunter, > it's just a large collection of CMake packages focused on one specialized > goal. > > But maybe someone used CMake for less specialized scripting tasks and > would share? I'm writing Zsh plugin manager, Zplugin, and I want to > integrate with CMake somehow, to get some swiss army knife features. > > -- > Sebastian Gniazdowski > psprint /at/ zdharma.org > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwan.work at gmail.com Tue Nov 14 04:34:55 2017 From: rwan.work at gmail.com (Raymond Wan) Date: Tue, 14 Nov 2017 17:34:55 +0800 Subject: [CMake] Using CMake for general scripting tasks? In-Reply-To: References: Message-ID: Hi Sebastian, On Tue, Nov 14, 2017 at 8:39 AM, Sebastian Gniazdowski wrote: > So I think this project confirms CMake's potential for handling general scripting tasks. However, it's hard to get some inspiration from Hunter, it's just a large collection of CMake packages focused on one specialized goal. I don't know if this will get me banned from this mailing list :-) ... but for general scripting tasks, I've recently started using snakemake. Of course, the two do not overlap and I still use CMake as a build-system. Anyway, not sure if this helps, but maybe you can look into snakemake... Ray From oliver.zabel at egoproducts.com Tue Nov 14 04:36:34 2017 From: oliver.zabel at egoproducts.com (oliver.zabel at egoproducts.com) Date: Tue, 14 Nov 2017 10:36:34 +0100 Subject: [CMake] Toolchain with non-gcc argument format In-Reply-To: Message-ID: Hi, No one any idea? Thanks! From annulen at yandex.ru Tue Nov 14 04:44:09 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 14 Nov 2017 12:44:09 +0300 Subject: [CMake] Using CMake for general scripting tasks? In-Reply-To: References: Message-ID: <79171510652649@web18j.yandex.ru> 14.11.2017, 03:46, "Sebastian Gniazdowski" : > Hello > CMake has so many powerful features that I always suspected, that it can be used for tasks normally handled by Bash or sh. I've found following package manager written in CMake: > > https://docs.hunter.sh/en/latest/overview/what-is-it.html > > So I think this project confirms CMake's potential for handling general scripting tasks. However, it's hard to get some inspiration from Hunter, it's just a large collection of CMake packages focused on one specialized goal. > > But maybe someone used CMake for less specialized scripting tasks and would share? I'm writing Zsh plugin manager, Zplugin, and I want to integrate with CMake somehow, to get some swiss army knife features. For general scripting tasks use general-purpose scripting language, e.g. Perl, Python, Ruby. You will avoid many issues of sub-par languages, make your programs less verbose, and will be able to use huge collections of 3rd party modules which can do almost anything you can think about > > -- > Sebastian Gniazdowski > psprint /at/ zdharma.org > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin From annulen at yandex.ru Tue Nov 14 04:48:15 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 14 Nov 2017 12:48:15 +0300 Subject: [CMake] Toolchain with non-gcc argument format In-Reply-To: References: Message-ID: <108301510652895@web18j.yandex.ru> 14.11.2017, 12:37, "oliver.zabel at egoproducts.com" : > Hi, > > No one any idea? Look into Modules/Compiler directory of CMake installation, it implements support for many different compilers > > Thanks! > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin From johannes.zarl-zierl at jku.at Tue Nov 14 05:31:37 2017 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Tue, 14 Nov 2017 11:31:37 +0100 Subject: [CMake] Using CMake for general scripting tasks? In-Reply-To: References: Message-ID: <1966141.6cl8dWXb4D@ersa> Hello, On Dienstag, 14. November 2017 01:39:47 CET Sebastian Gniazdowski wrote: > But maybe someone used CMake for less specialized scripting tasks and would > share? I'm writing Zsh plugin manager, Zplugin, and I want to integrate > with CMake somehow, to get some swiss army knife features. Why do you want to integrate with CMake? I mean, the scripting features of CMake are a great way to create platform- independent scripts for a build system, but you already know that your users have a proper shell installed. CMake will probably never be comparable in its scripting features to a shell like Zsh. So, unless you really have a reason to use CMake, you should stick with the better tool for your task (that is already guaranteed to be installed). Cheers, Johannes From robin.verschueren at gmail.com Tue Nov 14 06:54:20 2017 From: robin.verschueren at gmail.com (Robin Verschueren) Date: Tue, 14 Nov 2017 11:54:20 +0000 Subject: [CMake] Meaning of `*' in find_library() Message-ID: Dear all, I'm having some troubles using the 'PATHS' argument to find_library. More specifically, I'm trying to find the gfortran libraries ( */usr/lib/gcc/x86_64-linux-gnu/5/libgfortran.so* on my system). If I call find_library(FORTRAN_LIBRARY NAMES gfortran PATHS "/usr/lib/gcc/x86_64-linux-gnu/*") CMake finds the gfortran libs. However, if I change the last argument to "usr/lib/gcc/*", CMake does not find the specified library and throws an error (if REQUIRED is set). *Why is the extra directory necessary? Does the `*' symbol only look one directory deeper? How can I traverse folders recursively?* I tried to look for documentation on this, but searches in both Google and the CMake docs did not return anything useful. (looked for find_library, file, glob, etc.) Best regards, Robin PS if someone knows a better way of finding Fortran libraries, please feel free to enlighten me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Tue Nov 14 07:08:12 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 14 Nov 2017 15:08:12 +0300 Subject: [CMake] Meaning of `*' in find_library() In-Reply-To: References: Message-ID: <366571510661292@web50g.yandex.ru> 14.11.2017, 14:56, "Robin Verschueren" : > Dear all, > > I'm having some troubles using the 'PATHS' argument to find_library. More specifically, I'm trying to find the gfortran libraries (/usr/lib/gcc/x86_64-linux-gnu/5/libgfortran.so on my system). > > If I call > > find_library(FORTRAN_LIBRARY > ? ? NAMES gfortran > ? ? PATHS "/usr/lib/gcc/x86_64-linux-gnu/*") > > CMake finds the gfortran libs. However, if I change the last argument to "usr/lib/gcc/*", CMake does not find the specified library and throws an error (if REQUIRED is set). FWIW shell globs (from which this syntax derives) are not recursive > > Why is the extra directory necessary? Does the `*' symbol only look one directory deeper?? How can I traverse folders recursively? > > I tried to look for documentation on this, but searches in both Google and the CMake docs did not return anything useful. (looked for find_library, file, glob, etc.) > > Best regards, > Robin > > PS if someone knows a better way of finding Fortran libraries, please feel free to enlighten me. Parse `gcc -print-search-dirs` > > ,-- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake --? Regards, Konstantin From oliver.zabel at egoproducts.com Tue Nov 14 07:32:13 2017 From: oliver.zabel at egoproducts.com (oliver.zabel at egoproducts.com) Date: Tue, 14 Nov 2017 13:32:13 +0100 Subject: [CMake] Toolchain with non-gcc argument format In-Reply-To: <108301510652895@web18j.yandex.ru> Message-ID: Hi, Thank you. There is unfortunately not the right toolchain there - according my question I do have my toolchain Running - but with a custom command and I would like to know whether there is a better way. Cheers! From annulen at yandex.ru Tue Nov 14 07:36:59 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 14 Nov 2017 15:36:59 +0300 Subject: [CMake] Toolchain with non-gcc argument format In-Reply-To: References: <108301510652895@web18j.yandex.ru> Message-ID: <108951510663019@web39o.yandex.ru> 14.11.2017, 15:32, "oliver.zabel at egoproducts.com" : > Hi, > > Thank you. There is unfortunately not the right toolchain there - according > my question I do have my toolchain Running - but with a custom command and > I would like to know whether there is a better way. I meant you can use this files as an example and make correct file for your toolchain. E.g. see how TI-C.cmake sets CMAKE_INCLUDE_FLAG_C > > Cheers! -- Regards, Konstantin From oliver.zabel at egoproducts.com Tue Nov 14 07:42:39 2017 From: oliver.zabel at egoproducts.com (oliver.zabel at egoproducts.com) Date: Tue, 14 Nov 2017 13:42:39 +0100 Subject: [CMake] Toolchain with non-gcc argument format In-Reply-To: <108951510663019@web39o.yandex.ru> Message-ID: Hi, Sorry - I don?t get the hint :) thanks, I will look into it! Cheers! Oliver From saadrustam at gmail.com Tue Nov 14 10:50:18 2017 From: saadrustam at gmail.com (Saad Khattak) Date: Tue, 14 Nov 2017 15:50:18 +0000 Subject: [CMake] Finding and including/linking external projects generated by CMake Message-ID: Hi, Let's say I have a project I cloned from github which uses CMake to build. What is the best way to link to said dependency assuming the dependency is already built and installed [1]. So let's say I have LibA that is a dependency to my ProjA. LibA has already been built. What would be the 'correct' way to find and include/link against LibA? Currently, I inspect the install/ directory of the libraries, then specify the paths for the headers/libraries/DLLs manually. However, considering the project has been built by CMake and CMake knows where the include/lib/DLL files are, I am hoping that there is a way to get another CMake project to use some auto-generated CMake files to figure out the location of the headers and libraries (and DLLs) so that ultimately, the command boils down to: find_library(LibA Path/To/Install) # CMake now gives me variables such as LibA_INCLUDE_DIRS, LibA_LIB_DIRS or similar # so that I can easily include and link to the library Thanks, Saad [1] And in case it matters, for all dependencies I override the CMAKE_INSTALL_PREFIX to be at the root of the dependency. So, if I build LibA located at D:/Deps/LibA, the install folder will be D:/Deps/LibA/install/. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin.verschueren at gmail.com Tue Nov 14 10:54:49 2017 From: robin.verschueren at gmail.com (Robin Verschueren) Date: Tue, 14 Nov 2017 15:54:49 +0000 Subject: [CMake] FindBLAS.cmake broken on macOS? Message-ID: Dear all, I'm having difficulty making CMake find any BLAS on my macOS. I have two: 1. OpenBLAS installed with homebrew: /usr/local/opt/openblas/lib/libopenblasp-r0.2.19.dylib 2. System BLAS: /System/Library/Frameworks/Accelerate.framework//Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib For (1.), I set BLA_VENDOR "OpenBLAS" as per the docs of FindBLAS.cmake. CMake fails with *"A required library with BLAS API not found. Please specify library location." *I fixed it with a kludge by - set(_libdir "/usr/local/opt/openblas/lib" CACHE INTERNAL "OpenBLAS location") in the cache before calling FindBLAS. This violates all kinds of principles, among which the fact that ${_libdir} is a local variable to the FindBLAS module. For (2.), FindBLAS actually finds something, however, the ${BLAS_LIBRARIES} variable is set to *"/System/Library/Frameworks/Accelerate.framework"* which is a folder and thus unusable in any IMPORTED targets. Any advice? I did not find anything related in the open "FindBLAS" issues on Gitlab. Best regards, Robin -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbu at burgermeister.de Tue Nov 14 11:48:33 2017 From: bbu at burgermeister.de (Bernhard Burgermeister) Date: Tue, 14 Nov 2017 17:48:33 +0100 Subject: [CMake] Populate INCLUDE_DIRECTORIES of object libraries from INTERFACE_INCLUDE_DIRECTORIES of other libraries Message-ID: Hello, I'm trying to improve parallelization of a massive parallel Ninja/icecream build by using object libraries. We are already using interface include directories extensively. While moving the compilation to separate object libraries I need to define the include directories for these object targets. Previously this simply worked by target_link_library(x PRIVATE a) so that x uses the public and interface include directories of a. With object libraries this is not possible, for example ====================================== CMAKE_MINIMUM_REQUIRED(VERSION 3.7) PROJECT(ObjectLibLink C) ADD_LIBRARY(a INTERFACE) TARGET_INCLUDE_DIRECTORIES(a INTERFACE include) ADD_LIBRARY(b OBJECT b.c) TARGET_LINK_LIBRARIES(b PRIVATE a) ====================================== gives the error message Object library target "b" may not link to anything with CMake 3.7, 3.9 and 3.10rc3. The documentation of the later version says "OBJECT libraries may not be used in the right hand side of target_link_libraries()" but does not restrict the left hand side. I would expect it to build b with include-directory "include" from a. Currently I'm using a workaround FOREACH(Lib ${ARG_LINK}) IF(TARGET ${Lib}) TARGET_INCLUDE_DIRECTORIES(MyObjectLib PRIVATE $) ENDIF() ENDFOREACH() but this only works for targets previously defined or only target libraries may be used. Otherwise the generator fails for file names or system library names because there is no generator expression to check for existing targets (see https://gitlab.kitware.com/cmake/cmake/issues/17123). I want to avoid explicitly import all these libraries. Is there an other reliable way to populate include_directories that I have not yet found? Of course compile_definitions and compile_options should be added from the other libraries too. Regards, Bernhard. From saadrustam at gmail.com Tue Nov 14 13:38:17 2017 From: saadrustam at gmail.com (Saad Khattak) Date: Tue, 14 Nov 2017 18:38:17 +0000 Subject: [CMake] Making existing, compiled projects CMake aware Message-ID: Hi, I tried searching for an example project (perhaps already on github) to follow but my Google skills have failed me. There are some projects that are already compiled and I would like to fork those projects and write a CMakeLists.txt file for them such that they can be added by other CMake projects easily. For instance, for the library: https://github.com/ygpark/Everything-SDK, how would I write a CMakeLists.txt file such that: => the project has a CMake library named "Everything" (which is normally the result of add_library) => it's headers, lib and dll files specified in the target "Everything" properly => install() command to install the above for the target "Everything" => CMake generates the relevant "-config.cmake" file so that the library can be easily found using the find_library() command If an example already exists using modern CMake techniques, a link to it would be wonderful. Thanks, Saad -------------- next part -------------- An HTML attachment was scrubbed... URL: From psprint at zdharma.org Tue Nov 14 16:04:57 2017 From: psprint at zdharma.org (Sebastian Gniazdowski) Date: Tue, 14 Nov 2017 22:04:57 +0100 Subject: [CMake] Using CMake for general scripting tasks? Message-ID: > Why do you want to integrate with CMake? > I mean, the scripting features of CMake are a great way to create platform- > independent scripts for a build system, but you already know that your users > have a proper shell installed. CMake is a swiss army knife. Coding CMake is a quality time, and I think many users would want to have CMake integrated somewhere. My Zplugin also has swiss army knife features. So adding CMake would result in a powerful setup. > CMake will probably never be comparable in its scripting features to a shell? > like Zsh. So, unless you really have a reason to use CMake, you should stick? > with the better tool for your task (that is already guaranteed to be? > installed). Will think, thanks --? Sebastian Gniazdowski psprint /at/ zdharma.org From florent.castelli at gmail.com Tue Nov 14 18:11:17 2017 From: florent.castelli at gmail.com (Florent Castelli) Date: Wed, 15 Nov 2017 00:11:17 +0100 Subject: [CMake] Populate INCLUDE_DIRECTORIES of object libraries from INTERFACE_INCLUDE_DIRECTORIES of other libraries In-Reply-To: References: Message-ID: <5199b494-fd79-6428-7612-2173508769d1@gmail.com> Which version of CMake and Ninja are you using? It seems like you are trying to reimplement what has been added in CMake 3.9. Quote from the changelog: The Ninja generator has loosened the dependencies of object compilation. Object compilation now depends only on custom targets and custom commands associated with libraries on which the object?s target depends and no longer depends on the libraries themselves. Source files in dependent targets may now compile without waiting for their targets? dependencies to link. Have you tried it? It shouldn't need any change in your project, but I'm not sure how it will behave if you already started to migrate to OBJECT libraries. Regards, Florent On 14/11/2017 17:48, Bernhard Burgermeister wrote: > Hello, > > I'm trying to improve parallelization of a massive parallel > Ninja/icecream build by using object libraries. We are already using > interface include directories extensively. > > While moving the compilation to separate object libraries I need to > define the include directories for these object targets. Previously > this simply worked by target_link_library(x PRIVATE a) so that x uses > the public and interface include directories of a. With object > libraries this is not possible, for example > > ====================================== > CMAKE_MINIMUM_REQUIRED(VERSION 3.7) > PROJECT(ObjectLibLink C) > > ADD_LIBRARY(a INTERFACE) > TARGET_INCLUDE_DIRECTORIES(a INTERFACE include) > > ADD_LIBRARY(b OBJECT b.c) > TARGET_LINK_LIBRARIES(b PRIVATE a) > ====================================== > > gives the error message > Object library target "b" may not link to anything > with CMake 3.7, 3.9 and 3.10rc3. The documentation of the later > version says "OBJECT libraries may not be used in the right hand side > of target_link_libraries()" but does not restrict the left hand side. > I would expect it to build b with include-directory "include" from a. > > Currently I'm using a workaround > FOREACH(Lib ${ARG_LINK}) > IF(TARGET ${Lib}) > TARGET_INCLUDE_DIRECTORIES(MyObjectLib PRIVATE > $) > ENDIF() > ENDFOREACH() > but this only works for targets previously defined or only target > libraries may be used. Otherwise the generator fails for file names or > system library names because there is no generator expression to check > for existing targets (see > https://gitlab.kitware.com/cmake/cmake/issues/17123). I want to avoid > explicitly import all these libraries. > > > Is there an other reliable way to populate include_directories that I > have not yet found? Of course compile_definitions and compile_options > should be added from the other libraries too. > > > Regards, > Bernhard. From oliver.zabel at egoproducts.com Wed Nov 15 03:43:04 2017 From: oliver.zabel at egoproducts.com (oliver.zabel at egoproducts.com) Date: Wed, 15 Nov 2017 09:43:04 +0100 Subject: [CMake] Antwort: Re: Toolchain with non-gcc argument format In-Reply-To: References: <108951510663019@web39o.yandex.ru> Message-ID: Hi, i tried now, to setup correctly the toolchain with your help and the existing toolchain-files but cmake is not replacing "-I" to "-include=" set(CMAKE_INCLUDE_FLAG_C "--include=" FORCE) set(CMAKE_C_COMPILE_OBJECT " -output=obj -cpu=rx200 -lang=c99 -goptimize -size ") The resulting output is: ccrx.exe -output=obj -cpu=rx200 -lang=c99 -goptimize -size -IC:\Users\.... Is there something other that has to be set? Thanks! Von: oliver.zabel at egoproducts.com An: "Konstantin Tokarev" Kopie: CMake users Datum: 14.11.2017 13:42 Betreff: Re: [CMake] Toolchain with non-gcc argument format Gesendet von: "CMake" Hi, Sorry - I don?t get the hint :) thanks, I will look into it! Cheers! Oliver -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbu at burgermeister.de Wed Nov 15 04:01:07 2017 From: bbu at burgermeister.de (Bernhard Burgermeister) Date: Wed, 15 Nov 2017 10:01:07 +0100 Subject: [CMake] Populate INCLUDE_DIRECTORIES of object libraries from INTERFACE_INCLUDE_DIRECTORIES of other libraries In-Reply-To: <5199b494-fd79-6428-7612-2173508769d1@gmail.com> References: <5199b494-fd79-6428-7612-2173508769d1@gmail.com> Message-ID: Hi Florent, thanks for the hint about changed Ninja behaviour. We started the separation into object libraries with CMake 3.7 and want to use this also together with Unix Makefiles or JOM on Windows (and perhaps also Visual Studio 2015 generator). Even together with CMake 3.10 and Ninja I have to stay with the object libraries because we have many mixed language libraries (C/C++/Fortran) so the object libraries give me more control. With separate object libraries I can assign a compile_pool for the Fortran files (which can not be distributed by icecream) and I can avoid dependency of the C/C++ files on the generated Fortran files we use for automatic interface check (and I need to keep the Fortran files in the main library to have full Fortran 90 dependency detection, so the C/C++ files have to be moved to the object library). Regards, Bernhard. 2017-11-15 0:11 GMT+01:00 Florent Castelli : > Which version of CMake and Ninja are you using? > It seems like you are trying to reimplement what has been added in CMake > 3.9. Quote from the changelog: > > The Ninja generator has loosened the dependencies of object compilation. > Object compilation now depends only on custom targets and custom commands > associated with libraries on which the object?s target depends and no longer > depends on the libraries themselves. Source files in dependent targets may > now compile without waiting for their targets? dependencies to link. > > Have you tried it? It shouldn't need any change in your project, but I'm not > sure how it will behave if you already started to migrate to OBJECT > libraries. > > Regards, > Florent > > > On 14/11/2017 17:48, Bernhard Burgermeister wrote: >> >> Hello, >> >> I'm trying to improve parallelization of a massive parallel >> Ninja/icecream build by using object libraries. We are already using >> interface include directories extensively. >> >> While moving the compilation to separate object libraries I need to >> define the include directories for these object targets. Previously >> this simply worked by target_link_library(x PRIVATE a) so that x uses >> the public and interface include directories of a. With object >> libraries this is not possible, for example >> >> ====================================== >> CMAKE_MINIMUM_REQUIRED(VERSION 3.7) >> PROJECT(ObjectLibLink C) >> >> ADD_LIBRARY(a INTERFACE) >> TARGET_INCLUDE_DIRECTORIES(a INTERFACE include) >> >> ADD_LIBRARY(b OBJECT b.c) >> TARGET_LINK_LIBRARIES(b PRIVATE a) >> ====================================== >> >> gives the error message >> Object library target "b" may not link to anything >> with CMake 3.7, 3.9 and 3.10rc3. The documentation of the later >> version says "OBJECT libraries may not be used in the right hand side >> of target_link_libraries()" but does not restrict the left hand side. >> I would expect it to build b with include-directory "include" from a. >> >> Currently I'm using a workaround >> FOREACH(Lib ${ARG_LINK}) >> IF(TARGET ${Lib}) >> TARGET_INCLUDE_DIRECTORIES(MyObjectLib PRIVATE >> $) >> ENDIF() >> ENDFOREACH() >> but this only works for targets previously defined or only target >> libraries may be used. Otherwise the generator fails for file names or >> system library names because there is no generator expression to check >> for existing targets (see >> https://gitlab.kitware.com/cmake/cmake/issues/17123). I want to avoid >> explicitly import all these libraries. >> >> >> Is there an other reliable way to populate include_directories that I >> have not yet found? Of course compile_definitions and compile_options >> should be added from the other libraries too. >> >> >> Regards, >> Bernhard. > > > From annulen at yandex.ru Wed Nov 15 06:03:58 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 15 Nov 2017 14:03:58 +0300 Subject: [CMake] Antwort: Re: Toolchain with non-gcc argument format In-Reply-To: References: <108951510663019@web39o.yandex.ru> Message-ID: <2784001510743838@web47o.yandex.ru> > Hi, > > i tried now, to setup correctly the > toolchain with your help and the existing toolchain-files but cmake is > not replacing "-I" to "-include=" > > set(CMAKE_INCLUDE_FLAG_C "--include=" > FORCE) > > set(CMAKE_C_COMPILE_OBJECT " > -output=obj -cpu=rx200 -lang=c99 -goptimize -size > ") > > The resulting output is: ccrx.exe -output=obj > -cpu=rx200 -lang=c99 -goptimize -size -IC:\Users\.... > > Is there something other that has to > be set? Are you writing this in toolchain file, or you created another module in Modules/Compiler? > > Thanks! > > Von: > oliver.zabel at egoproducts.com > > An: > "Konstantin Tokarev" > > > Kopie: > CMake users > > Datum: > 14.11.2017 13:42 > > Betreff: > Re: [CMake] > Toolchain with non-gcc argument format > > Gesendet von: > "CMake" > > > Hi, > > Sorry - I don?t get the hint :) thanks, I will look into it! > > Cheers! > > Oliver > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin From oliver.zabel at egoproducts.com Wed Nov 15 06:34:15 2017 From: oliver.zabel at egoproducts.com (oliver.zabel at egoproducts.com) Date: Wed, 15 Nov 2017 12:34:15 +0100 Subject: [CMake] Antwort: Re:Antwort: Re: Toolchain with non-gcc argument format In-Reply-To: <2784001510743838@web47o.yandex.ru> References: <108951510663019@web39o.yandex.ru> <2784001510743838@web47o.yandex.ru> Message-ID: > Are you writing this in toolchain file, or you created another module in Modules/Compiler? I wrote this in my toolchain-file. Von: Konstantin Tokarev An: oliver.zabel at egoproducts.com Kopie: CMake users , CMake Datum: 15.11.2017 12:04 Betreff: Re:Antwort: Re: [CMake] Toolchain with non-gcc argument format > Hi, > > i tried now, to setup correctly the > toolchain with your help and the existing toolchain-files but cmake is > not replacing "-I" to "-include=" > > set(CMAKE_INCLUDE_FLAG_C "--include=" > FORCE) > > set(CMAKE_C_COMPILE_OBJECT " > -output=obj -cpu=rx200 -lang=c99 -goptimize -size > ") > > The resulting output is: ccrx.exe -output=obj > -cpu=rx200 -lang=c99 -goptimize -size -IC:\Users\.... > > Is there something other that has to > be set? Are you writing this in toolchain file, or you created another module in Modules/Compiler? > > Thanks! > > Von: > oliver.zabel at egoproducts.com > > An: > "Konstantin Tokarev" > > > Kopie: > CMake users > > Datum: > 14.11.2017 13:42 > > Betreff: > Re: [CMake] > Toolchain with non-gcc argument format > > Gesendet von: > "CMake" > > > Hi, > > Sorry - I don?t get the hint :) thanks, I will look into it! > > Cheers! > > Oliver > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.zarl-zierl at jku.at Wed Nov 15 07:50:45 2017 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Wed, 15 Nov 2017 13:50:45 +0100 Subject: [CMake] Making existing, compiled projects CMake aware In-Reply-To: References: Message-ID: <5122910.56TTrJGD4r@ersa> Hello Saad, On Dienstag, 14. November 2017 18:38:17 CET Saad Khattak wrote: > There are some projects that are already compiled and I would like to fork > those projects and write a CMakeLists.txt file for them such that they can > be added by other CMake projects easily. In my experience, looking at other projects and how they switched to CMake is usually not very helpful. After all, you can only see the resulting CMakeLists.txt but no steps how it was created. What you can do instead, is to just write the CMakeLists.txt from scratch and keep it simple (i.e. don't introduce complexity that you don't understand). Before starting, it might be a good idea to update your knowledge about modern C++. A good starting point is the "Modern CMake" talk by Daniel Pfeiffer, especially the part about how to add and link to libraries: https://youtu.be/bsXLMQ6WgIk?t=818 > For instance, for the library: https://github.com/ygpark/Everything-SDK, > how would I write a CMakeLists.txt file such that: > > => the project has a CMake library named "Everything" (which is normally > the result of add_library) As you already said: use add_library. > => it's headers, lib and dll files specified in the target "Everything" > properly This is also explained in the linked video. The official documentation is here: https://cmake.org/cmake/help/latest/manual/cmake-buildsystem. 7.html#transitive-usage-requirements > => install() command to install the above for the target "Everything" > => CMake generates the relevant "-config.cmake" file This is documented here: https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html > so that the library > can be easily found using the find_library() command I guess you meant to write find_package(), not find_library() HTH, Johannes From oliver.zabel at egoproducts.com Thu Nov 16 03:44:09 2017 From: oliver.zabel at egoproducts.com (oliver.zabel at egoproducts.com) Date: Thu, 16 Nov 2017 09:44:09 +0100 Subject: [CMake] Antwort: Antwort: Re:Antwort: Re: Toolchain with non-gcc argument format In-Reply-To: References: <108951510663019@web39o.yandex.ru> <2784001510743838@web47o.yandex.ru> Message-ID: I did not find the CMAKE_INCLUDE_FLAG_C in the CMake cache - is it possible that this is somehow ignored? Von: oliver.zabel at egoproducts.com An: Konstantin Tokarev Kopie: CMake users , CMake Datum: 15.11.2017 12:34 Betreff: [CMake] Antwort: Re:Antwort: Re: Toolchain with non-gcc argument format Gesendet von: "CMake" > Are you writing this in toolchain file, or you created another module in Modules/Compiler? I wrote this in my toolchain-file. Von: Konstantin Tokarev An: oliver.zabel at egoproducts.com Kopie: CMake users , CMake Datum: 15.11.2017 12:04 Betreff: Re:Antwort: Re: [CMake] Toolchain with non-gcc argument format > Hi, > > i tried now, to setup correctly the > toolchain with your help and the existing toolchain-files but cmake is > not replacing "-I" to "-include=" > > set(CMAKE_INCLUDE_FLAG_C "--include=" > FORCE) > > set(CMAKE_C_COMPILE_OBJECT " > -output=obj -cpu=rx200 -lang=c99 -goptimize -size > ") > > The resulting output is: ccrx.exe -output=obj > -cpu=rx200 -lang=c99 -goptimize -size -IC:\Users\.... > > Is there something other that has to > be set? Are you writing this in toolchain file, or you created another module in Modules/Compiler? > > Thanks! > > Von: > oliver.zabel at egoproducts.com > > An: > "Konstantin Tokarev" > > > Kopie: > CMake users > > Datum: > 14.11.2017 13:42 > > Betreff: > Re: [CMake] > Toolchain with non-gcc argument format > > Gesendet von: > "CMake" > > > Hi, > > Sorry - I don?t get the hint :) thanks, I will look into it! > > Cheers! > > Oliver > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.tmatma at gmail.com Thu Nov 16 07:31:32 2017 From: m.tmatma at gmail.com (masaru tsuchiyama) Date: Thu, 16 Nov 2017 21:31:32 +0900 Subject: [CMake] [Digital Signature Failure] Output Directory In-Reply-To: References: Message-ID: Hi It worked. Regards. Masaru 2017-11-14 7:49 GMT+09:00 masaru tsuchiyama : > thanks. > I'll try it. > > Regards > Masaru > > 2017?11?12?(?) 17:52 Dvir Yitzchaki : > >> You have the -B switch, see https://cgold.readthedocs.io/ >> en/latest/glossary/-B.html#b >> >> >> >> Regards, >> >> Dvir >> >> >> >> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *masaru >> tsuchiyama >> *Sent:* Saturday, November 11, 2017 00:54 >> *To:* cmake at cmake.org >> *Subject:* [Digital Signature Failure] [CMake] Output Directory >> >> >> >> Hi, >> >> >> >> Before running cmake, we need to change a directotry where we want to >> create output files. >> >> But I think it is a bit inconvenient. >> >> >> >> Is there any plan to implement an option of the output directory? >> >> >> >> Regards. >> >> Masaru. >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pawel.veselov at gmail.com Fri Nov 17 18:09:11 2017 From: pawel.veselov at gmail.com (Pawel Veselov) Date: Sat, 18 Nov 2017 00:09:11 +0100 Subject: [CMake] Add a build event that depends on a target Message-ID: Hi. Is it possible in some way to add a build event that depends on a target (different target than what the build event is for)? add_custom_command() doesn't seem to support that. What I'm trying to do is: 1) Have target "test", which builds tests 2) Have target "program". Have a post-build build event that executes test, so that the program is only fully built when the tests are successful Simple: ------ cut ------ add_executable(test test.c) add_executable(program program.c) enable_testing() add_test(NAME test COMMAND test) add_custom_command( TARGET program POST_BUILD COMMAND ${CMAKE_CTEST_COMMAND} -R test ) ------ cut ------ doesn't work, at least in parallel build, there is nothing that prevents the unit test to run before test is built (which is what happens). Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwan.work at gmail.com Sat Nov 18 10:42:20 2017 From: rwan.work at gmail.com (Raymond Wan) Date: Sat, 18 Nov 2017 23:42:20 +0800 Subject: [CMake] Making existing, compiled projects CMake aware In-Reply-To: <5122910.56TTrJGD4r@ersa> References: <5122910.56TTrJGD4r@ersa> Message-ID: Hi Johannes, On Wed, Nov 15, 2017 at 8:50 PM, Johannes Zarl-Zierl wrote: > Before starting, it might be a good idea to update your knowledge about modern > C++. A good starting point is the "Modern CMake" talk by Daniel Pfeiffer, > especially the part about how to add and link to libraries: > https://youtu.be/bsXLMQ6WgIk?t=818 I'm sorry to jump into this discussion but I was looking through this video and it was very helpful! Thank you for posting it; I was not aware of it! Unfortunately, I know CMake but I haven't actively used it for many years and this video showed me that I'm very out of date. I think Daniel used the phrase about doing things that are "so version 2.8"... That more or less describes me. ;-( Do you or anyone else on this list have suggestions on moving someone like me to the latest CMake? For example, a tutorial, for example. I noticed this: https://cmake.org/cmake-tutorial/ and I wonder if this tutorial uses recent CMake practices... The "cmake_minimum_required (VERSION 2.6)" at the top makes me wonder whether or not it is up-to-date. If not, can anyone suggest one? I guess CMake 2.8 practices could still work but since it's been a while for me, maybe I should start with recent practices and put what I used to do behind me. Any suggestions would be appreciated...thank you! Ray From psprint at zdharma.org Sat Nov 18 12:28:48 2017 From: psprint at zdharma.org (Sebastian Gniazdowski) Date: Sat, 18 Nov 2017 18:28:48 +0100 Subject: [CMake] Using CMake for general scripting tasks? In-Reply-To: <79171510652649@web18j.yandex.ru> References: <79171510652649@web18j.yandex.ru> Message-ID: On 14 Nov 2017 at 10:44:09, Konstantin Tokarev (annulen at yandex.ru) wrote: > 14.11.2017, 03:46, "Sebastian Gniazdowski" : > I'm writing Zsh plugin manager, Zplugin, and I want to integrate with CMake somehow, > to get some swiss army knife features. > > For general scripting tasks use general-purpose scripting language, e.g. Perl, Python, > Ruby. You will avoid many issues of sub-par languages, make your programs less verbose, > and will be able to use huge collections of 3rd party modules which can do almost anything > you can think about I'm a specific person, although I'm certain that many share my traits ? getting fun from using something in surprising and difficult way, especially if it's low level. I have a good example ? I've written HTML-like ncurses library for Zsh. So, buttons, list boxes, text fields, etc. created from simple input text (the "HTML"). I have to defend myself against criticism of not using high level languages, because low-level way is really good on it's own right and good things should be defended. A proof is this curses application written in pure Zshell script with use of the library (called "ZUI"):?https://asciinema.org/a/147225. Curses library correctly describes itself by its name, and with that library there's no need for more "curses" when creating terminal app. Maybe I should ask what advanced, surprising functionality did you or someone else obtain by CMake macro or function? This could lead me to what CMake can give to Zplugin. I have an example of such functionality, although I think it's not that much advanced, but for my beginners level it's good and informing ? I spotted this function: function( QUERY_QMAKE VAR RESULT ) ? get_target_property( QMAKE_EXEC Qt5::qmake LOCATION ) ? exec_program( "${QMAKE_EXEC}" ARGS "-query ${VAR}" RETURN_VALUE retval OUTPUT_VARIABLE out ) ? if( retval EQUAL 0 ) ? file( TO_CMAKE_PATH "${out}" out ) ? set( ${RESULT} ${out} PARENT_SCOPE ) ? endif() endfunction() It allows to query Qt's "qmake" and get library paths etc. Didn't need it, because Qt5 has proper CMake packages. --? Sebastian Gniazdowski psprint at zdharma.org From roberto.diremigio at gmail.com Sun Nov 19 13:16:10 2017 From: roberto.diremigio at gmail.com (Roberto Di Remigio) Date: Sun, 19 Nov 2017 19:16:10 +0100 Subject: [CMake] Handling of generator expressions Message-ID: Hello, I am trying to compile the following code snippet: int main(int argc, char ** argv) { int stack_array[100]; stack_array[1] = 0; return stack_array[argc + 100]; // BOOM } The followin CMakeLists.txt works fine, but you can notice that target_compile_options takes a list, while target_link_libraries takes a string. Always using the string will result in a compilation error, because the compiler flags are passed quoted to the compiler. Always using the list doesn't work either, because the generator expression is evaluated as $<1:-fsanitize=address -fno-omit-frame-pointer> and then passed as-is to the linker, which doesn't know what to do with it. Is this supposed to be like this? If yes, what's the rationale? Thanks in advance! Roberto cmake_minimum_required(VERSION 3.3 FATAL_ERROR) project(recipe-09 CXX) set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_EXTENSIONS OFF) set(CMAKE_CXX_STANDARD_REQUIRED ON) list(APPEND CXX_BASIC_FLAGS "-g3" "-O1") include(CheckCXXCompilerFlag) set(ASAN_FLAGS "-fsanitize=address -fno-omit-frame-pointer") set(CMAKE_REQUIRED_FLAGS ${ASAN_FLAGS}) check_cxx_compiler_flag(${ASAN_FLAGS} asan_works) unset(CMAKE_REQUIRED_FLAGS) add_executable(asan-example asan-example.cpp) string(REPLACE " " ";" _asan_flags ${ASAN_FLAGS}) target_compile_options(asan-example PUBLIC ${CXX_BASIC_FLAGS} $<$:${_asan_flags}> ) target_link_libraries(asan-example PUBLIC $<$:${ASAN_FLAGS}> ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dvir.Yitzchaki at ceva-dsp.com Mon Nov 20 01:31:48 2017 From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki) Date: Mon, 20 Nov 2017 06:31:48 +0000 Subject: [CMake] [Digital Signature Failure] Add a build event that depends on a target In-Reply-To: References: Message-ID: <827c8eff88214f1da206b02869e91e04@ceva-dsp.com> Try add_dependencies(program test) See https://cmake.org/cmake/help/latest/command/add_dependencies.html. Regards, Dvir From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Pawel Veselov Sent: Saturday, November 18, 2017 01:09 To: cmake at cmake.org Subject: [Digital Signature Failure] [CMake] Add a build event that depends on a target Hi. Is it possible in some way to add a build event that depends on a target (different target than what the build event is for)? add_custom_command() doesn't seem to support that. What I'm trying to do is: 1) Have target "test", which builds tests 2) Have target "program". Have a post-build build event that executes test, so that the program is only fully built when the tests are successful Simple: ------ cut ------ add_executable(test test.c) add_executable(program program.c) enable_testing() add_test(NAME test COMMAND test) add_custom_command( TARGET program POST_BUILD COMMAND ${CMAKE_CTEST_COMMAND} -R test ) ------ cut ------ doesn't work, at least in parallel build, there is nothing that prevents the unit test to run before test is built (which is what happens). Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From pawel.veselov at gmail.com Mon Nov 20 06:35:23 2017 From: pawel.veselov at gmail.com (Pawel Veselov) Date: Mon, 20 Nov 2017 12:35:23 +0100 Subject: [CMake] [Digital Signature Failure] Add a build event that depends on a target In-Reply-To: <827c8eff88214f1da206b02869e91e04@ceva-dsp.com> References: <827c8eff88214f1da206b02869e91e04@ceva-dsp.com> Message-ID: Hi Dvir, On Mon, Nov 20, 2017 at 7:31 AM, Dvir Yitzchaki wrote: > Try > > > > add_dependencies(program test) > Thank you! That helped. > > > See https://cmake.org/cmake/help/latest/command/add_dependencies.html. > > > > Regards, > > Dvir > > > > *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Pawel > Veselov > *Sent:* Saturday, November 18, 2017 01:09 > *To:* cmake at cmake.org > *Subject:* [Digital Signature Failure] [CMake] Add a build event that > depends on a target > > > > Hi. > > > > Is it possible in some way to add a build event that depends on a target > > (different target than what the build event is for)? add_custom_command() > > doesn't seem to support that. > > > > What I'm trying to do is: > > 1) Have target "test", which builds tests > > 2) Have target "program". Have a post-build build event > > that executes test, so that the program is only > > fully built when the tests are successful > > > > Simple: > > ------ cut ------ > > add_executable(test test.c) > > add_executable(program program.c) > > enable_testing() > > add_test(NAME test COMMAND test) > > add_custom_command( > > TARGET program > > POST_BUILD > > COMMAND ${CMAKE_CTEST_COMMAND} -R test > > ) > > ------ cut ------ > > > > doesn't work, at least in parallel build, there is nothing that prevents > > the unit test to run before test is built (which is what happens). > > > > Thank you! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Nov 20 16:23:25 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 20 Nov 2017 16:23:25 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.10.0 available for download Message-ID: I am proud to announce that CMake 3.10.0 is now available for download at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.10 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.10/release/3.10.html Some of the more significant changes in CMake 3.10 are: * The flang Fortran compiler is now supported, with compiler id "Flang". * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * "FindMPI" received a major overhaul. It now features language specific components, better Fortran support, and support for statically linked MPI implementations. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module underwent numerous improvements. It has gained support for GLVND and EGL on Linux. It now has import targets that separate the OpenGL library and OpenGL contexts. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". CMake 3.10 Release Notes ************************ Changes made since CMake 3.9 include the following. New Features ============ Platforms --------- * The flang Fortran compiler is now supported, with compiler id "Flang". * A new minimal platform file for "Midipix" was added. * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * Support for the IAR ARM Compiler was improved. Generators ---------- * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools like ccache along with the compiler for the "CUDA" language ("C" and "CXX" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * The "CodeBlocks" extra generator learned to optionally exclude files from outside the project root directory from the generated project. See the "CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES" variable. Commands -------- * The "cmake_host_system_information()" command learned more keys to get information about the processor capabilities and the host OS version. * The "configure_file()" command learned to support indented "# cmakedefine" and "# cmakedefine01". Spaces and/or tabs between the "#" character and the "cmakedefine"/"cmakedefine01" words are now understood and preserved in the output. * The "execute_process()" command gained a "RESULTS_VARIABLE" option to collect a list of results from all children in a pipeline of processes when multiple "COMMAND" arguments are given. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * The "string()" command learned a new "PREPEND" subcommand. * The "string(TIMESTAMP)" command now supports "%A" for full weekday name and "%B" for full month name. Variables --------- * A "CMAKE_DIRECTORY_LABELS" variable was added to specify labels for all tests in a directory. Properties ---------- * A "_CPPCHECK" target property and supporting "CMAKE__CPPCHECK" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "cppcheck" with the compiler for "C" and "CXX" languages. * A "LABELS" directory property was added to specify labels for all targets and tests in a directory. * A "TEST_INCLUDE_FILES" directory property was added to list any number of files to be included when running tests with "ctest(1)". This generalizes the "TEST_INCLUDE_FILE" property. * The "VS_DOTNET_REFERENCEPROP__TAG_" target property was added to support custom XML tags for reference assemblies in C# targets. * Source file properties "VS_SHADER_OUTPUT_HEADER_FILE" and "VS_SHADER_VARIABLE_NAME" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "FindCurses" module gained a "CURSES_NEED_WIDE" option to request the wide-character variant. * The "FindEXPAT" module now provides imported targets. * The "FindFreetype" module now provides imported targets. * "FindMPI" gained a number of new features, including: * Language-specific components have been added to the module. * Many more MPI environments are now supported. * The environmental support for Fortran has been improved. * A user now has fine-grained control over the MPI selection process, including passing custom parameters to the MPI compiler. * The version of the implemented MPI standard is now being exposed. * MPI-2 C++ bindings can now be detected and also suppressed if so desired. * The available Fortran bindings are now being detected and verified. * Various MPI-3 information can be requested, including the library version and Fortran capabilities of the individual bindings. * Statically linked MPI implementations are supported. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module gained support for GLVND on Linux. * The "FindOpenMP" module gained support for language-specific components. * A "FindPatch" module was added to find the "patch" command-line executable. * The "FindProtobuf" module "protobuf_generate_cpp()" command gained a "DESCRIPTORS" option to generate descriptor files. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. Unlike the source parsing approach, dynamic discovery executes the test (in 'list available tests' mode) at build time to discover tests. This is robust against unusual ways of labeling tests, provides much better support for advanced features such as parameterized tests, and does not require re-running CMake to discover added or removed tests within a test executable. * The "InstallRequiredSystemLibraries" module gained support for installing Intel compiler runtimes. Autogen ------- * When using "AUTOMOC" or "AUTOUIC" with a multi configuration generator (e.g. "Xcode"), included "*.moc", "moc_*.cpp" and "ui_*.h" files are generated in "/include_" instead of "/include". * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * When using "AUTOMOC", CMake searches for the strings "Q_OBJECT", "Q_GADGET" or "Q_NAMESPACE" in a source file to determine if it needs to be "moc" processed. The new "CMAKE_AUTOMOC_MACRO_NAMES" variable and "AUTOMOC_MACRO_NAMES" target property may be set to register additional strings (macro names) to search for. * When using "AUTOMOC", the new "CMAKE_AUTOMOC_COMPILER_PREDEFINES" variable and "AUTOMOC_COMPILER_PREDEFINES" target property specify whether to enable or disable the generation of the compiler pre definitions file "moc_predefs.h". CTest ----- * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. CPack ----- * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "CPackDeb" module learned to set package release version in "Version" info property. See the "CPACK_DEBIAN_PACKAGE_RELEASE" variable. * The "CPackDeb" module learned more strict package version checking that complies with Debian rules. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "REPLACES" and "CHECKABLE" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_FILE_EXTENSION" variable to customize target binary format. * The "CPackIFW" module gained new "CPACK_IFW_REPOSITORIES_DIRECTORIES" variable to specify additional repositories dirs that will be used to resolve and repack dependent components. This feature is only available when using QtIFW 3.1 or later. * Modules "CPackRPM" and "CPackDeb" learned to set package epoch version. See "CPACK_RPM_PACKAGE_EPOCH" and "CPACK_DEBIAN_PACKAGE_EPOCH" variables. Other ----- * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The graphviz output now distinguishes among the different dependency types "PUBLIC", "PRIVATE" and "INTERFACE" and represents them in the output graph as solid, dashed and dotted edges. Deprecated and Removed Features =============================== * Support for building CMake itself with C++98 compilers was dropped. CMake is now implemented using C++11. * Support for building CMake on HP-UX has been dropped pending better support for C++11 and a port of libuv. See CMake Issue 17137. Use CMake 3.9 or lower instead for HP-UX support. Other Changes ============= * On FreeBSD the C++ compiler named "c++" is now the preferred default. * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". * The "get_filename_component()" "PROGRAM" mode semantics have been revised to not tolerate unquoted spaces in the path to the program while also accepting arguments. While technically incompatible with the old behavior, it is expected that behavior under typical use cases with properly-quoted command-lines has not changed. ---------------------------------------------------------------------------- Changes made since CMake 3.10.0-rc5: Brad King (5): cmake-gui: Add build option to use Qt5 windows plugin statically Tests: Add options to disable tests requiring Qt FindOpenGL: Re-order component library searches FindOpenGL: Add option to prefer GLVND for legacy GL CMake 3.10.0 vector-of-bool (1): server: Fix regression in partial message handling From carsten.fuchs at cafu.de Tue Nov 21 03:00:55 2017 From: carsten.fuchs at cafu.de (Carsten Fuchs) Date: Tue, 21 Nov 2017 09:00:55 +0100 Subject: [CMake] Using find_package() portably? Message-ID: <015f1e5c-ffae-d96d-1dd3-8ca0b8939698@cafu.de> Dear group, I'm new to CMake and read all related tutorials that I could find and the Mastering CMake book (I didn't get very far) and watched Daniel Pfeifer's talk. Unfortunately, I'm afraid that I still cannot figure out a couple of apparently simple things, especially in today's "best practices" style. Please consider: find_package(JPEG REQUIRED) At first, this didn't work for me under Ubuntu Linux, because I didn't have the libjpeg-dev package installed. The error message was: CMake Error at /usr/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find JPEG (missing: JPEG_LIBRARY JPEG_INCLUDE_DIR) Call Stack (most recent call first): /usr/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake-3.9/Modules/FindJPEG.cmake:30 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) Libs/CMakeLists.txt:5 (find_package) Well, I provoked this intentionally for learning and testing, but if I hadn't been prepared, from the error message alone I would not have known how to proceed. `sudo apt install libjepg-dev` fixed the problem. Now I'm under Windows, Visual Studio Community 2017. Same error message, and obviously no solution as easy as `sudo apt ...`. It's quite clear that I have to add the libjpeg source code as a subfolder to my project and compile it as part of the main project. But, starting with the above `find_package(JPEG REQUIRED)`, how is this properly done? Generalizing my question: I started with `find_package(JPEG REQUIRED)` as shown above in order to the find the JPEG library that comes preinstalled with the system. How do I deal with the following scenarios? - libjpeg is theoretically available, but just not installed in the system (that is, `sudo apt install libjpeg-dev` would help)? - libjpeg is available in the system, but the version is too new or too old? - libjpeg is not available in the system at all (e.g. Windows)? - As a fallback, in the case that any of the above checks is negative, it seems that there is no alternative but to ship and compile a copy of libjpeg along with my project: How is this properly expressed in my project's CMakeLists.txt? Daniel mentioned something about the behavior of `find_package()` in his talk, but I'm afraid that I still cannot come up with a proper solution. Best regards, Carsten From annulen at yandex.ru Tue Nov 21 03:45:43 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 21 Nov 2017 11:45:43 +0300 Subject: [CMake] Using find_package() portably? In-Reply-To: <015f1e5c-ffae-d96d-1dd3-8ca0b8939698@cafu.de> References: <015f1e5c-ffae-d96d-1dd3-8ca0b8939698@cafu.de> Message-ID: <1439271511253943@web52j.yandex.ru> > Dear group, > > I'm new to CMake and read all related tutorials that I could find and > the Mastering CMake book (I didn't get very far) and watched Daniel > Pfeifer's talk. Unfortunately, I'm afraid that I still cannot figure out > a couple of apparently simple things, especially in today's "best > practices" style. > > Please consider: > > find_package(JPEG REQUIRED) > > At first, this didn't work for me under Ubuntu Linux, because I didn't > have the libjpeg-dev package installed. The error message was: > > CMake Error at > /usr/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 > (message): > Could NOT find JPEG (missing: JPEG_LIBRARY JPEG_INCLUDE_DIR) > Call Stack (most recent call first): > /usr/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:377 > (_FPHSA_FAILURE_MESSAGE) > /usr/share/cmake-3.9/Modules/FindJPEG.cmake:30 > (FIND_PACKAGE_HANDLE_STANDARD_ARGS) > Libs/CMakeLists.txt:5 (find_package) > > Well, I provoked this intentionally for learning and testing, but if I > hadn't been prepared, from the error message alone I would not have > known how to proceed. `sudo apt install libjepg-dev` fixed the problem. > > Now I'm under Windows, Visual Studio Community 2017. Same error message, > and obviously no solution as easy as `sudo apt ...`. > It's quite clear that I have to add the libjpeg source code as a > subfolder to my project and compile it as part of the main project. But, > starting with the above `find_package(JPEG REQUIRED)`, how is this > properly done? > > Generalizing my question: > > I started with `find_package(JPEG REQUIRED)` as shown above in order to > the find the JPEG library that comes preinstalled with the system. > How do I deal with the following scenarios? > > - libjpeg is theoretically available, but just not installed in the > system (that is, `sudo apt install libjpeg-dev` would help)? > > - libjpeg is available in the system, but the version is too new or > too old? > > - libjpeg is not available in the system at all (e.g. Windows)? > > - As a fallback, in the case that any of the above checks is > negative, it seems that there is no alternative but to ship and compile > a copy of libjpeg along with my project: How is this properly expressed > in my project's CMakeLists.txt? Daniel mentioned something about the > behavior of `find_package()` in his talk, but I'm afraid that I still > cannot come up with a proper solution. find_package() allows you to use external libraries (or other kinds of files for that matter) which are not shipped with your source code. It knows nothing about how to install the missing dependencies, or if this is possible at all (usually possible, because you can compile dependencies from sources and maybe even share resulting binaries with other developers). Instead, you can 1) add instruction how to install dependencies 2) use hand-made script or more complex solution to automate dependency installation, or 3) avoid using find_package() st all > > Best regards, > Carsten > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin From johannes.zarl-zierl at jku.at Tue Nov 21 05:44:35 2017 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Tue, 21 Nov 2017 11:44:35 +0100 Subject: [CMake] Using find_package() portably? In-Reply-To: <1439271511253943@web52j.yandex.ru> References: <015f1e5c-ffae-d96d-1dd3-8ca0b8939698@cafu.de> <1439271511253943@web52j.yandex.ru> Message-ID: <1639003.WzOYk1S0Ou@ersa> Hi, I thought you might want some context for the suggestions: On Dienstag, 21. November 2017 11:45:43 CET Konstantin Tokarev wrote: > 1) add instruction how to install dependencies This is what many/most projects do, and it works reasonably well. Advantages: - You don't clutter your project with dependencies - People on each platform already know how to install dependencies - You don't complicate things for package maintainers Disadvantages: - No automatic dependency resolution > 2) use hand-made script or more complex solution to automate dependency > installation, or Hand-made scripts are often a maintenance nightmare and hard to get right for all platforms. The One True Way(TM) would be a so-called "super-build", i.e. a CMake project that uses external_project() to build your project along with its dependencies. > 3) avoid using find_package() st all That's the first time I've heard that suggestion. I'm not sure if this will ease your pain ;-) 4) Shipping the dependency with your project (not using external_project) This can sometimes be useful, but you should carefully consider the implications beforehand to see if it's worth it for your project. As a rule of thumb: don't do this if the dependency is readily available and/or big. Cheers, Johannes From annulen at yandex.ru Tue Nov 21 06:36:57 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 21 Nov 2017 14:36:57 +0300 Subject: [CMake] Using find_package() portably? In-Reply-To: <1639003.WzOYk1S0Ou@ersa> References: <015f1e5c-ffae-d96d-1dd3-8ca0b8939698@cafu.de> <1439271511253943@web52j.yandex.ru> <1639003.WzOYk1S0Ou@ersa> Message-ID: <118291511264217@web4g.yandex.ru> 21.11.2017, 13:45, "Johannes Zarl-Zierl" : > Hi, > > I thought you might want some context for the suggestions: > > On Dienstag, 21. November 2017 11:45:43 CET Konstantin Tokarev wrote: >> ?1) add instruction how to install dependencies > > This is what many/most projects do, and it works reasonably well. > Advantages: > ?- You don't clutter your project with dependencies > ?- People on each platform already know how to install dependencies > ?- You don't complicate things for package maintainers > Disadvantages: > ?- No automatic dependency resolution > >> ?2) use hand-made script or more complex solution to automate dependency >> ?installation, or > > Hand-made scripts are often a maintenance nightmare and hard to get right for > all platforms. The One True Way(TM) would be a so-called "super-build", i.e. a > CMake project that uses external_project() to build your project along with > its dependencies. FWIW I've seen many projects that provide scripts or one-liners how to install all dependencies on popular systems, and if things are readily available or otherwise pre-built and downloadable from central place, it's not hard to maintain, at least when number of dependencies is small Examples: 1. (Not related to cmake, just to show idea): https://wiki.qt.io/Building_Qt_5_from_Git#Linux.2FX11 - lists packages which you need to install on different distros on wiki page 2. https://trac.webkit.org/browser/webkit/trunk/Tools/gtk/install-dependencies - similar thing but automated 3. https://trac.webkit.org/browser/webkit/trunk/Tools/Scripts/update-webkit-wincairo-libs.py - downloads and unpacks zip file with all dependencies into fixed location > >> ?3) avoid using find_package() st all > > That's the first time I've heard that suggestion. I'm not sure if this will > ease your pain ;-) I've meant by using things like ExternalProject, or from your point 4, or when using other metabuilders. When all dependencies are in known locations, you don't really need to use find_package anymore. Though It may be handy though if you allow building with both external and internal dependencies, e.g. if you develop open source project distributors will be reluctant to include it if it can use bundled dependencies only. > > 4) Shipping the dependency with your project (not using external_project) > This can sometimes be useful, but you should carefully consider the > implications beforehand to see if it's worth it for your project. As a rule of > thumb: don't do this if the dependency is readily available and/or big. > > Cheers, > ??Johannes > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin From mwpowellhtx at gmail.com Tue Nov 21 10:37:39 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Tue, 21 Nov 2017 10:37:39 -0500 Subject: [CMake] Finding package for 7-zip comprehension Message-ID: Hello, Does anyone happen to know, is there 7-zip comprehension in CMake today? i.e., that something like this could be done: include (FindSevenZip.cmake) or: find_package (SevenZip) I've seen mention of it in places, but could not find it formally as part of CMake itself, it seems. I am running the latest stable v3.9, that I know of. Thanks! Cheers, Michael Powell From annulen at yandex.ru Tue Nov 21 10:43:04 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 21 Nov 2017 18:43:04 +0300 Subject: [CMake] Finding package for 7-zip comprehension In-Reply-To: References: Message-ID: <24011511278984@web8j.yandex.ru> 21.11.2017, 18:38, "Michael Powell" : > Hello, > > Does anyone happen to know, is there 7-zip comprehension in CMake > today? i.e., that something like this could be done: > > include (FindSevenZip.cmake) > > or: > > find_package (SevenZip) > > I've seen mention of it in places, but could not find it formally as > part of CMake itself, it seems. > > I am running the latest stable v3.9, that I know of. Not exactly 7-zip, but you can unpack tar.xz files via built-in cmake -E tar command > > Thanks! > > Cheers, > > Michael Powell > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin From marc.chevrier at sap.com Tue Nov 21 10:47:37 2017 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Tue, 21 Nov 2017 15:47:37 +0000 Subject: [CMake] Finding package for 7-zip comprehension In-Reply-To: <24011511278984@web8j.yandex.ru> References: <24011511278984@web8j.yandex.ru> Message-ID: <6FF804D4-2201-4772-A9E3-0C516CB8357D@sap.com> ?cmake ?E tar? supports 7-zip format. Use option ?format=7zip (see https://cmake.org/cmake/help/v3.9/manual/cmake.1.html). On 21/11/2017 16:43, "CMake on behalf of Konstantin Tokarev" wrote: 21.11.2017, 18:38, "Michael Powell" : > Hello, > > Does anyone happen to know, is there 7-zip comprehension in CMake > today? i.e., that something like this could be done: > > include (FindSevenZip.cmake) > > or: > > find_package (SevenZip) > > I've seen mention of it in places, but could not find it formally as > part of CMake itself, it seems. > > I am running the latest stable v3.9, that I know of. Not exactly 7-zip, but you can unpack tar.xz files via built-in cmake -E tar command > > Thanks! > > Cheers, > > Michael Powell > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake From mwpowellhtx at gmail.com Tue Nov 21 10:48:10 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Tue, 21 Nov 2017 10:48:10 -0500 Subject: [CMake] Finding package for 7-zip comprehension In-Reply-To: <24011511278984@web8j.yandex.ru> References: <24011511278984@web8j.yandex.ru> Message-ID: On Tue, Nov 21, 2017 at 10:43 AM, Konstantin Tokarev wrote: > > > 21.11.2017, 18:38, "Michael Powell" : >> Hello, >> >> Does anyone happen to know, is there 7-zip comprehension in CMake >> today? i.e., that something like this could be done: >> >> include (FindSevenZip.cmake) >> >> or: >> >> find_package (SevenZip) >> >> I've seen mention of it in places, but could not find it formally as >> part of CMake itself, it seems. >> >> I am running the latest stable v3.9, that I know of. > > Not exactly 7-zip, but you can unpack tar.xz files via built-in cmake -E tar command It's good to know, but I've already got tar identified. Perhaps not "kosher", at least from what I'm reading about how to FindXyz, and the Xyx_FOUND and Xyz_EXECUTABLE perspective. However, no, what I am interested in is 7-zip, specifically. I have my reasons. Thank you! >> Thanks! >> >> Cheers, >> >> Michael Powell >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > > -- > Regards, > Konstantin From mwpowellhtx at gmail.com Tue Nov 21 10:49:03 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Tue, 21 Nov 2017 10:49:03 -0500 Subject: [CMake] Finding package for 7-zip comprehension In-Reply-To: <6FF804D4-2201-4772-A9E3-0C516CB8357D@sap.com> References: <24011511278984@web8j.yandex.ru> <6FF804D4-2201-4772-A9E3-0C516CB8357D@sap.com> Message-ID: On Tue, Nov 21, 2017 at 10:47 AM, CHEVRIER, Marc wrote: > ?cmake ?E tar? supports 7-zip format. Use option ?format=7zip (see https://cmake.org/cmake/help/v3.9/manual/cmake.1.html). Ah! This I did not know. Thanks for pointing that out! > On 21/11/2017 16:43, "CMake on behalf of Konstantin Tokarev" wrote: > > > > 21.11.2017, 18:38, "Michael Powell" : > > Hello, > > > > Does anyone happen to know, is there 7-zip comprehension in CMake > > today? i.e., that something like this could be done: > > > > include (FindSevenZip.cmake) > > > > or: > > > > find_package (SevenZip) > > > > I've seen mention of it in places, but could not find it formally as > > part of CMake itself, it seems. > > > > I am running the latest stable v3.9, that I know of. > > Not exactly 7-zip, but you can unpack tar.xz files via built-in cmake -E tar command > > > > > Thanks! > > > > Cheers, > > > > Michael Powell > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > > -- > Regards, > Konstantin > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > From mwpowellhtx at gmail.com Tue Nov 21 10:54:23 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Tue, 21 Nov 2017 10:54:23 -0500 Subject: [CMake] Finding package for 7-zip comprehension In-Reply-To: References: <24011511278984@web8j.yandex.ru> <6FF804D4-2201-4772-A9E3-0C516CB8357D@sap.com> Message-ID: On Tue, Nov 21, 2017 at 10:49 AM, Michael Powell wrote: > On Tue, Nov 21, 2017 at 10:47 AM, CHEVRIER, Marc wrote: >> ?cmake ?E tar? supports 7-zip format. Use option ?format=7zip (see https://cmake.org/cmake/help/v3.9/manual/cmake.1.html). > > Ah! This I did not know. Thanks for pointing that out! Well, the version of Tar I am working with does not seem to have this feature implemented? I could be wrong, unless it is undocumented. Based on the version (1.29?) adopted in the Git for Windows distribution. C:\Dev\Git\usr\bin\tar.exe --help | C:\Dev\Git\usr\bin\grep.exe zip -j, --bzip2 filter the archive through bzip2 --lzip filter the archive through lzip -z, --gzip, --gunzip, --ungzip filter the archive through gzip G:\Source\Boost.Build\Prototype\repos\boost-1.65.1>C:\Dev\Git\usr\bin\tar.exe -- help | C:\Dev\Git\usr\bin\grep.exe zip -j, --bzip2 filter the archive through bzip2 --lzip filter the archive through lzip -z, --gzip, --gunzip, --ungzip filter the archive through gzip C:\Dev\Git\usr\bin\tar.exe --help | C:\Dev\Git\usr\bin\grep.exe format -g, --listed-incremental=FILE handle new GNU-format incremental backup -G, --incremental handle old GNU-format incremental backup set version of the sparse format to use (implies extract information about file permissions Archive format selection: -H, --format=FORMAT create archive of the given format gnu GNU tar 1.13.x format oldgnu GNU format as per tar <= 1.12 pax POSIX 1003.1-2001 (pax) format ustar POSIX 1003.1-1988 (ustar) format v7 old V7 tar format same as --format=v7 --posix same as --format=posix File name transformations: Informative output: show file or archive names after transformation --format=gnu -f- -b20 --quoting-style=escape >> On 21/11/2017 16:43, "CMake on behalf of Konstantin Tokarev" wrote: >> >> >> >> 21.11.2017, 18:38, "Michael Powell" : >> > Hello, >> > >> > Does anyone happen to know, is there 7-zip comprehension in CMake >> > today? i.e., that something like this could be done: >> > >> > include (FindSevenZip.cmake) >> > >> > or: >> > >> > find_package (SevenZip) >> > >> > I've seen mention of it in places, but could not find it formally as >> > part of CMake itself, it seems. >> > >> > I am running the latest stable v3.9, that I know of. >> >> Not exactly 7-zip, but you can unpack tar.xz files via built-in cmake -E tar command >> >> > >> > Thanks! >> > >> > Cheers, >> > >> > Michael Powell >> > -- >> > >> > Powered by www.kitware.com >> > >> > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> > >> > Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> > >> > CMake Support: http://cmake.org/cmake/help/support.html >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> > CMake Training Courses: http://cmake.org/cmake/help/training.html >> > >> > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/cmake >> >> -- >> Regards, >> Konstantin >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> >> From annulen at yandex.ru Tue Nov 21 10:56:36 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 21 Nov 2017 18:56:36 +0300 Subject: [CMake] Finding package for 7-zip comprehension In-Reply-To: References: <24011511278984@web8j.yandex.ru> <6FF804D4-2201-4772-A9E3-0C516CB8357D@sap.com> Message-ID: <224821511279796@web9g.yandex.ru> 21.11.2017, 18:54, "Michael Powell" : > On Tue, Nov 21, 2017 at 10:49 AM, Michael Powell wrote: >> ?On Tue, Nov 21, 2017 at 10:47 AM, CHEVRIER, Marc wrote: >>> ??cmake ?E tar? supports 7-zip format. Use option ?format=7zip (see https://cmake.org/cmake/help/v3.9/manual/cmake.1.html). >> >> ?Ah! This I did not know. Thanks for pointing that out! > > Well, the version of Tar I am working with does not seem to have this > feature implemented? I could be wrong, unless it is undocumented. You are using GNU tar, while CMake uses libarchive (which is a core of more powerful BSD tar) > > Based on the version (1.29?) adopted in the Git for Windows distribution. > > C:\Dev\Git\usr\bin\tar.exe --help | C:\Dev\Git\usr\bin\grep.exe zip > ??-j, --bzip2 filter the archive through bzip2 > ??????--lzip filter the archive through lzip > ??-z, --gzip, --gunzip, --ungzip filter the archive through gzip > > G:\Source\Boost.Build\Prototype\repos\boost-1.65.1>C:\Dev\Git\usr\bin\tar.exe -- > help | C:\Dev\Git\usr\bin\grep.exe zip > ??-j, --bzip2 filter the archive through bzip2 > ??????--lzip filter the archive through lzip > ??-z, --gzip, --gunzip, --ungzip filter the archive through gzip > > C:\Dev\Git\usr\bin\tar.exe --help | C:\Dev\Git\usr\bin\grep.exe format > ??-g, --listed-incremental=FILE handle new GNU-format incremental backup > ??-G, --incremental handle old GNU-format incremental backup > ?????????????????????????????set version of the sparse format to use (implies > ?????????????????????????????extract information about file permissions > ?Archive format selection: > ??-H, --format=FORMAT create archive of the given format > ????gnu GNU tar 1.13.x format > ????oldgnu GNU format as per tar <= 1.12 > ????pax POSIX 1003.1-2001 (pax) format > ????ustar POSIX 1003.1-1988 (ustar) format > ????v7 old V7 tar format > ?????????????????????????????same as --format=v7 > ??????--posix same as --format=posix > ?File name transformations: > ?Informative output: > ?????????????????????????????show file or archive names after transformation > --format=gnu -f- -b20 --quoting-style=escape > >>> ?On 21/11/2017 16:43, "CMake on behalf of Konstantin Tokarev" wrote: >>> >>> ?????21.11.2017, 18:38, "Michael Powell" : >>> ?????> Hello, >>> ?????> >>> ?????> Does anyone happen to know, is there 7-zip comprehension in CMake >>> ?????> today? i.e., that something like this could be done: >>> ?????> >>> ?????> include (FindSevenZip.cmake) >>> ?????> >>> ?????> or: >>> ?????> >>> ?????> find_package (SevenZip) >>> ?????> >>> ?????> I've seen mention of it in places, but could not find it formally as >>> ?????> part of CMake itself, it seems. >>> ?????> >>> ?????> I am running the latest stable v3.9, that I know of. >>> >>> ?????Not exactly 7-zip, but you can unpack tar.xz files via built-in cmake -E tar command >>> >>> ?????> >>> ?????> Thanks! >>> ?????> >>> ?????> Cheers, >>> ?????> >>> ?????> Michael Powell >>> ?????> -- >>> ?????> >>> ?????> Powered by www.kitware.com >>> ?????> >>> ?????> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> ?????> >>> ?????> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> ?????> >>> ?????> CMake Support: http://cmake.org/cmake/help/support.html >>> ?????> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> ?????> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> ?????> >>> ?????> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> ?????> >>> ?????> Follow this link to subscribe/unsubscribe: >>> ?????> http://public.kitware.com/mailman/listinfo/cmake >>> >>> ?????-- >>> ?????Regards, >>> ?????Konstantin >>> ?????-- >>> >>> ?????Powered by www.kitware.com >>> >>> ?????Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> ?????Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> ?????CMake Support: http://cmake.org/cmake/help/support.html >>> ?????CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> ?????CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> ?????Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> ?????Follow this link to subscribe/unsubscribe: >>> ?????http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin From mwpowellhtx at gmail.com Tue Nov 21 10:58:16 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Tue, 21 Nov 2017 10:58:16 -0500 Subject: [CMake] Finding package for 7-zip comprehension In-Reply-To: References: <24011511278984@web8j.yandex.ru> <6FF804D4-2201-4772-A9E3-0C516CB8357D@sap.com> Message-ID: On Tue, Nov 21, 2017 at 10:54 AM, Michael Powell wrote: > On Tue, Nov 21, 2017 at 10:49 AM, Michael Powell wrote: >> On Tue, Nov 21, 2017 at 10:47 AM, CHEVRIER, Marc wrote: >>> ?cmake ?E tar? supports 7-zip format. Use option ?format=7zip (see https://cmake.org/cmake/help/v3.9/manual/cmake.1.html). >> >> Ah! This I did not know. Thanks for pointing that out! Oh, duh. I get it. CMake has this built in. > Well, the version of Tar I am working with does not seem to have this > feature implemented? I could be wrong, unless it is undocumented. > > Based on the version (1.29?) adopted in the Git for Windows distribution. > > C:\Dev\Git\usr\bin\tar.exe --help | C:\Dev\Git\usr\bin\grep.exe zip > -j, --bzip2 filter the archive through bzip2 > --lzip filter the archive through lzip > -z, --gzip, --gunzip, --ungzip filter the archive through gzip > > G:\Source\Boost.Build\Prototype\repos\boost-1.65.1>C:\Dev\Git\usr\bin\tar.exe -- > help | C:\Dev\Git\usr\bin\grep.exe zip > -j, --bzip2 filter the archive through bzip2 > --lzip filter the archive through lzip > -z, --gzip, --gunzip, --ungzip filter the archive through gzip > > C:\Dev\Git\usr\bin\tar.exe --help | C:\Dev\Git\usr\bin\grep.exe format > -g, --listed-incremental=FILE handle new GNU-format incremental backup > -G, --incremental handle old GNU-format incremental backup > set version of the sparse format to use (implies > extract information about file permissions > Archive format selection: > -H, --format=FORMAT create archive of the given format > gnu GNU tar 1.13.x format > oldgnu GNU format as per tar <= 1.12 > pax POSIX 1003.1-2001 (pax) format > ustar POSIX 1003.1-1988 (ustar) format > v7 old V7 tar format > same as --format=v7 > --posix same as --format=posix > File name transformations: > Informative output: > show file or archive names after transformation > --format=gnu -f- -b20 --quoting-style=escape > >>> On 21/11/2017 16:43, "CMake on behalf of Konstantin Tokarev" wrote: >>> >>> >>> >>> 21.11.2017, 18:38, "Michael Powell" : >>> > Hello, >>> > >>> > Does anyone happen to know, is there 7-zip comprehension in CMake >>> > today? i.e., that something like this could be done: >>> > >>> > include (FindSevenZip.cmake) >>> > >>> > or: >>> > >>> > find_package (SevenZip) >>> > >>> > I've seen mention of it in places, but could not find it formally as >>> > part of CMake itself, it seems. >>> > >>> > I am running the latest stable v3.9, that I know of. >>> >>> Not exactly 7-zip, but you can unpack tar.xz files via built-in cmake -E tar command >>> >>> > >>> > Thanks! >>> > >>> > Cheers, >>> > >>> > Michael Powell >>> > -- >>> > >>> > Powered by www.kitware.com >>> > >>> > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> > >>> > Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> > >>> > CMake Support: http://cmake.org/cmake/help/support.html >>> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> > CMake Training Courses: http://cmake.org/cmake/help/training.html >>> > >>> > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> > >>> > Follow this link to subscribe/unsubscribe: >>> > http://public.kitware.com/mailman/listinfo/cmake >>> >>> -- >>> Regards, >>> Konstantin >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake >>> >>> From robert.maynard at kitware.com Tue Nov 21 12:11:18 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 21 Nov 2017 12:11:18 -0500 Subject: [CMake] CMake Monthly Meeting Summary Message-ID: Hi, The next CMake monthly meeting will occur on Dec 5th at 10am in the KHQ21 Conference Room ( meet.google.com/nak-crpy-ykz ). If you want to be added to the calendar invite don't hesitate to send me an email. The next monthly meeting currently doesn't have a agenda yet, so please suggest things to talk about. Currently on my list of items to talk about is: - Setup a group of people to investigate the amount of work needed to support C++20 modules - Should we schedule an internal CMake course - Keep working on blog articles I wrote up some CMake 3.10 highlights slides which can be found at: https://docs.google.com/a/kitware.com/presentation/d/1gFe2XQBS_z97SGBRDrWyp3dvtax7K2uM77Omb6rKpo0/edit?usp=sharing My goal with these slides is to have material to help people disseminate new CMake features other Kitware teams and a keeping collaborators informed. I plan on making these slides for every significant CMake release. As far as the blog to book goes the following action items have been organized: - Bill is working on a blog post for December that will cover clang tidy / use_what_you_include support in CMake - Chuck/Robert/Bill are working on a CMake style guideline blog post which is aiming for February From mwpowellhtx at gmail.com Tue Nov 21 12:28:13 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Tue, 21 Nov 2017 12:28:13 -0500 Subject: [CMake] Finding package for 7-zip comprehension In-Reply-To: References: <24011511278984@web8j.yandex.ru> <6FF804D4-2201-4772-A9E3-0C516CB8357D@sap.com> Message-ID: Okay, this seems great for Zip and for 7z. My guess is it is an open issue for Gzip? https://cmake.org/Bug/view.php?id=10973 (0010973: Add a cmake -E command to access gzip/gunzip) On Tue, Nov 21, 2017 at 10:58 AM, Michael Powell wrote: > On Tue, Nov 21, 2017 at 10:54 AM, Michael Powell wrote: >> On Tue, Nov 21, 2017 at 10:49 AM, Michael Powell wrote: >>> On Tue, Nov 21, 2017 at 10:47 AM, CHEVRIER, Marc wrote: >>>> ?cmake ?E tar? supports 7-zip format. Use option ?format=7zip (see https://cmake.org/cmake/help/v3.9/manual/cmake.1.html). >>> >>> Ah! This I did not know. Thanks for pointing that out! > > Oh, duh. I get it. CMake has this built in. > >> Well, the version of Tar I am working with does not seem to have this >> feature implemented? I could be wrong, unless it is undocumented. >> >> Based on the version (1.29?) adopted in the Git for Windows distribution. >> >> C:\Dev\Git\usr\bin\tar.exe --help | C:\Dev\Git\usr\bin\grep.exe zip >> -j, --bzip2 filter the archive through bzip2 >> --lzip filter the archive through lzip >> -z, --gzip, --gunzip, --ungzip filter the archive through gzip >> >> G:\Source\Boost.Build\Prototype\repos\boost-1.65.1>C:\Dev\Git\usr\bin\tar.exe -- >> help | C:\Dev\Git\usr\bin\grep.exe zip >> -j, --bzip2 filter the archive through bzip2 >> --lzip filter the archive through lzip >> -z, --gzip, --gunzip, --ungzip filter the archive through gzip >> >> C:\Dev\Git\usr\bin\tar.exe --help | C:\Dev\Git\usr\bin\grep.exe format >> -g, --listed-incremental=FILE handle new GNU-format incremental backup >> -G, --incremental handle old GNU-format incremental backup >> set version of the sparse format to use (implies >> extract information about file permissions >> Archive format selection: >> -H, --format=FORMAT create archive of the given format >> gnu GNU tar 1.13.x format >> oldgnu GNU format as per tar <= 1.12 >> pax POSIX 1003.1-2001 (pax) format >> ustar POSIX 1003.1-1988 (ustar) format >> v7 old V7 tar format >> same as --format=v7 >> --posix same as --format=posix >> File name transformations: >> Informative output: >> show file or archive names after transformation >> --format=gnu -f- -b20 --quoting-style=escape >> >>>> On 21/11/2017 16:43, "CMake on behalf of Konstantin Tokarev" wrote: >>>> >>>> >>>> >>>> 21.11.2017, 18:38, "Michael Powell" : >>>> > Hello, >>>> > >>>> > Does anyone happen to know, is there 7-zip comprehension in CMake >>>> > today? i.e., that something like this could be done: >>>> > >>>> > include (FindSevenZip.cmake) >>>> > >>>> > or: >>>> > >>>> > find_package (SevenZip) >>>> > >>>> > I've seen mention of it in places, but could not find it formally as >>>> > part of CMake itself, it seems. >>>> > >>>> > I am running the latest stable v3.9, that I know of. >>>> >>>> Not exactly 7-zip, but you can unpack tar.xz files via built-in cmake -E tar command >>>> >>>> > >>>> > Thanks! >>>> > >>>> > Cheers, >>>> > >>>> > Michael Powell >>>> > -- >>>> > >>>> > Powered by www.kitware.com >>>> > >>>> > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>> > >>>> > Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>> > >>>> > CMake Support: http://cmake.org/cmake/help/support.html >>>> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> > CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> > >>>> > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>> > >>>> > Follow this link to subscribe/unsubscribe: >>>> > http://public.kitware.com/mailman/listinfo/cmake >>>> >>>> -- >>>> Regards, >>>> Konstantin >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake >>>> >>>> From robert.maynard at kitware.com Tue Nov 21 12:40:58 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 21 Nov 2017 12:40:58 -0500 Subject: [CMake] CMake Monthly Meeting Summary In-Reply-To: References: Message-ID: Sorry about this this was meant for an internal mailing list. On Tue, Nov 21, 2017 at 12:11 PM, Robert Maynard wrote: > Hi, > > The next CMake monthly meeting will occur on Dec 5th at 10am in the > KHQ21 Conference Room ( meet.google.com/nak-crpy-ykz ). If you want to > be added to the calendar invite don't hesitate to send me an email. > > The next monthly meeting currently doesn't have a agenda yet, so > please suggest things to talk about. Currently on my list of items to > talk about is: > - Setup a group of people to investigate the amount of work needed > to support C++20 modules > - Should we schedule an internal CMake course > - Keep working on blog articles > > I wrote up some CMake 3.10 highlights slides which can be found at: > https://docs.google.com/a/kitware.com/presentation/d/1gFe2XQBS_z97SGBRDrWyp3dvtax7K2uM77Omb6rKpo0/edit?usp=sharing > > My goal with these slides is to have material to help people > disseminate new CMake features other Kitware teams and a keeping > collaborators informed. I plan on making these slides for every > significant CMake release. > > As far as the blog to book goes the following action items have been organized: > - Bill is working on a blog post for December that will cover clang > tidy / use_what_you_include support in CMake > - Chuck/Robert/Bill are working on a CMake style guideline blog post > which is aiming for February From robert.maynard at kitware.com Tue Nov 21 13:17:08 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 21 Nov 2017 13:17:08 -0500 Subject: [CMake] Handling of generator expressions In-Reply-To: References: Message-ID: Hi Roberto, Can you please report this as an issue ( https://gitlab.kitware.com/cmake/cmake ) as this looks like a bug in the way we are parsing generator expressions in target_link_libraries. The target_link_libraries fully supports taking a list of linker flags when it isn't part of a generator expression. On Sun, Nov 19, 2017 at 1:16 PM, Roberto Di Remigio wrote: > Hello, > I am trying to compile the following code snippet: > > int main(int argc, char ** argv) { > int stack_array[100]; > stack_array[1] = 0; > return stack_array[argc + 100]; // BOOM > } > > The followin CMakeLists.txt works fine, but you can notice that > target_compile_options takes a list, while target_link_libraries takes a > string. Always using the string will result in a compilation error, because > the compiler flags are passed quoted to the compiler. Always using the list > doesn't work either, because the generator expression is evaluated as > $<1:-fsanitize=address -fno-omit-frame-pointer> and then passed as-is to the > linker, which doesn't know what to do with it. > Is this supposed to be like this? If yes, what's the rationale? > Thanks in advance! > Roberto > > cmake_minimum_required(VERSION 3.3 FATAL_ERROR) > > project(recipe-09 CXX) > > set(CMAKE_CXX_STANDARD 11) > set(CMAKE_CXX_EXTENSIONS OFF) > set(CMAKE_CXX_STANDARD_REQUIRED ON) > > list(APPEND CXX_BASIC_FLAGS "-g3" "-O1") > > include(CheckCXXCompilerFlag) > > set(ASAN_FLAGS "-fsanitize=address -fno-omit-frame-pointer") > set(CMAKE_REQUIRED_FLAGS ${ASAN_FLAGS}) > check_cxx_compiler_flag(${ASAN_FLAGS} asan_works) > unset(CMAKE_REQUIRED_FLAGS) > > add_executable(asan-example asan-example.cpp) > string(REPLACE " " ";" _asan_flags ${ASAN_FLAGS}) > target_compile_options(asan-example > PUBLIC > ${CXX_BASIC_FLAGS} > $<$:${_asan_flags}> > ) > target_link_libraries(asan-example > PUBLIC > $<$:${ASAN_FLAGS}> > ) > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From cristian.adam at gmail.com Tue Nov 21 14:20:02 2017 From: cristian.adam at gmail.com (Cristian Adam) Date: Tue, 21 Nov 2017 20:20:02 +0100 Subject: [CMake] CMake Monthly Meeting Summary In-Reply-To: References: Message-ID: On Tue, Nov 21, 2017 at 6:40 PM, Robert Maynard wrote: > Sorry about this this was meant for an internal mailing list. > > Please do give us an update on the part regarding C++20 modules! I think I'm not the only on interested in this. Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From r030t1 at gmail.com Tue Nov 21 14:46:15 2017 From: r030t1 at gmail.com (R0b0t1) Date: Tue, 21 Nov 2017 13:46:15 -0600 Subject: [CMake] Using find_package() portably? In-Reply-To: <118291511264217@web4g.yandex.ru> References: <015f1e5c-ffae-d96d-1dd3-8ca0b8939698@cafu.de> <1439271511253943@web52j.yandex.ru> <1639003.WzOYk1S0Ou@ersa> <118291511264217@web4g.yandex.ru> Message-ID: Hello friends! The points brought up are good. However, I have some experience with CMake's edge cases (due to using Gentoo) so I feel like I should give my opinion on some of the solutions. The solutions are good, I just think it is important to indicate that building truly cross platform code with CMake still seems to be an open problem. Specifically, if anyone has anything to add on how to use CMake to find Windows dependencies, I am looking for help in that area. On Tue, Nov 21, 2017 at 5:36 AM, Konstantin Tokarev wrote: > > > 21.11.2017, 13:45, "Johannes Zarl-Zierl" : >> Hi, >> >> I thought you might want some context for the suggestions: >> >> On Dienstag, 21. November 2017 11:45:43 CET Konstantin Tokarev wrote: >>> 1) add instruction how to install dependencies >> >> This is what many/most projects do, and it works reasonably well. >> Advantages: >> - You don't clutter your project with dependencies >> - People on each platform already know how to install dependencies >> - You don't complicate things for package maintainers >> Disadvantages: >> - No automatic dependency resolution >> This is really the best solution on Unix-based operating systems and will work in the vast majority of cases. The one sticking point is that most FOSS libraries are not distributed by installer for Windows anymore, and it is extremely likely you will need to bundle your dependencies with your project when targeting Windows. Also, sometimes fringe distributions will not have their library install locations in the paths checked by CMake. Usually they will have pkg-config configured properly, and you can find the libraries and headers that way. >>> 2) use hand-made script or more complex solution to automate dependency >>> installation, or >> >> Hand-made scripts are often a maintenance nightmare and hard to get right for >> all platforms. The One True Way(TM) would be a so-called "super-build", i.e. a >> CMake project that uses external_project() to build your project along with >> its dependencies. > > FWIW I've seen many projects that provide scripts or one-liners how to install all > dependencies on popular systems, and if things are readily available or otherwise pre-built > and downloadable from central place, it's not hard to maintain, at least when number of > dependencies is small > >> >>> 3) avoid using find_package() st all >> >> That's the first time I've heard that suggestion. I'm not sure if this will >> ease your pain ;-) > > I've meant by using things like ExternalProject, or from your point 4, or when > using other metabuilders. When all dependencies are in known locations, > you don't really need to use find_package anymore. > > Though It may be handy though if you allow building with both external and > internal dependencies, e.g. if you develop open source project distributors > will be reluctant to include it if it can use bundled dependencies only. > Using ExternalProject and a dependency fetching script suffer from the same problem. It is very easy to implement these things insecurely, and it makes your software hard to package for Linux distributions. When I see a trendy new project that prominently features a "curl | sh" line on its webpage I shudder and, try as I might, I usually write it off in my mind. Besides those lines sometimes not having "https://" in them, installing software outside of your package manager will eventually lead to a slew of problems (developers that focus on one or two projects may never experience those problems, but that is almost entirely luck). I think there are two major examples I can give: 1) Haskell's Cabal would fetch code (some immediately executed but also the packages) over HTTP with no authentication, and that code would often run as root. This has only recently been fixed, but I still feel like I need to double check myself. 2) Sage Math bundles, I think, 80 pieces of software with it, and has its own package management system. It builds GCC to build itself! For some of the problems that this causes, see https://bugs.gentoo.org/201321. I do recognize that sometimes distributions simply won't have the libraries you need. In that case, I recommend leaving it to the user to find a way to get those libraries. Personally I install them to ~/.local and add them to the search paths, but this is hard to do with CMake. Sometimes users will find newer libraries in a backports repository. >> >> 4) Shipping the dependency with your project (not using external_project) >> This can sometimes be useful, but you should carefully consider the >> implications beforehand to see if it's worth it for your project. As a rule of >> thumb: don't do this if the dependency is readily available and/or big. >> I dislike doing this on principle but it's pretty common for Windows. Sticking a deps/ directory in your repository with precompiled libraries and the header files is an easy way to reduce the burden for potential contributors. I have also seen instructions for building packages and specifying their location manually. Should you do this, GPG-signing your commits would be an especially good idea. Cheers, R0b0t1 From annulen at yandex.ru Tue Nov 21 16:56:55 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 22 Nov 2017 00:56:55 +0300 Subject: [CMake] Using find_package() portably? In-Reply-To: References: <015f1e5c-ffae-d96d-1dd3-8ca0b8939698@cafu.de> <1439271511253943@web52j.yandex.ru> <1639003.WzOYk1S0Ou@ersa> <118291511264217@web4g.yandex.ru> Message-ID: <429221511301415@web20o.yandex.ru> > Using ExternalProject and a dependency fetching script suffer from the > same problem. It is very easy to implement these things insecurely, > and it makes your software hard to package for Linux distributions. > When I see a trendy new project that prominently features a "curl | > sh" line on its webpage I shudder and, try as I might, I usually write > it off in my mind. Besides those lines sometimes not having "https://" > in them, You should check sha256 of all downloaded files. It really guarantees that files were not tampered, unlike that "s" letter in the URL after "http" which only checks that peer's TLS certificate looks okay. > installing software outside of your package manager will > eventually lead to a slew of problems (developers that focus on one or > two projects may never experience those problems, but that is almost > entirely luck). This is not the case if done carefully, and is not relevant at all if dependencies are not installed into system location -- Regards, Konstantin From yue.nicholas at gmail.com Tue Nov 21 19:07:24 2017 From: yue.nicholas at gmail.com (Nicholas Yue) Date: Wed, 22 Nov 2017 00:07:24 +0000 Subject: [CMake] Which version of NSIS to use with CMake's CPack ? Message-ID: Hi, Is there a recommended version of NSIS which works best with CMake's CPack ? Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From kelly.j.couch at intel.com Tue Nov 21 19:42:26 2017 From: kelly.j.couch at intel.com (Couch, Kelly J) Date: Wed, 22 Nov 2017 00:42:26 +0000 Subject: [CMake] cmake 2.8.12 - How to prevent target executable having dependency to prefixed path of target shared libraries Message-ID: <934D8D6A4B048048942509C4D57C8A40DE2D0E20@ORSMSX103.amr.corp.intel.com> I am using cmake to build a binary with multiple shared libraries (some built and some on the system). I want the resulting executable to have dependencies on the required shared libraries (WITHOUT prefixed path to the library). Specific build environment: OpenSuse 11.3 cmake 2.8.12 and gcc: i686-linux5.0-gcc (GCC) 4.6.3 g++: g++ (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585] When specifying target_link_libraries(tgtA libA), the result is a tgtA with library linked using a relative path to the libA. For example, when using 'ldd tgtA', result is something like: ... libpthread.so.0 => /lib/libpthread.so.0 (0xf6290000) /lib/ld-linux.so.2 (0xf7758000) librt.so.1 => /lib/librt.so.1 (0xf6286000) ---> directoryA/directoryB/libA.so => not found Additional details: 1. The same cmake files work as expected on other linux distributions. It is only the specified config above that I encounter this issue. 2. I've various combinations of setting/NOT-setting all of these, trying to overcome this issue: CMAKE_BINARY_DIR, CMAKE_ARCHIVE_OUTPUT_DIRECTORY, CMAKE_RUNTIME_OUTPUT_DIRECTORY, CMAKE_LIBRARY_OUTPUT_DIRECTORY, CMAKE_SKIP_RPATH, CMAKE_SKIP_INSTALL_RPATH 3. The behavior of prefixed library occurs on libraries that are built targets and library found using find_library 4. when I examine resulting link.txt file, the link command line includes the path to the shared library (so). Why doesn't cmake use -L to express the path to look and then only pass the library name as -l? Looks like "g++ -o tgtA /directoryA/directoryB/libA.so" I have tried all manner of changes related to RPATH options and cmake install, but the prefixed path to the library is always remains present. I am stumped and appreciate the help! Thanks, -Kelly From irwin at beluga.phys.uvic.ca Tue Nov 21 21:18:07 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 21 Nov 2017 18:18:07 -0800 (PST) Subject: [CMake] cmake 2.8.12 - How to prevent target executable having dependency to prefixed path of target shared libraries In-Reply-To: <934D8D6A4B048048942509C4D57C8A40DE2D0E20@ORSMSX103.amr.corp.intel.com> References: <934D8D6A4B048048942509C4D57C8A40DE2D0E20@ORSMSX103.amr.corp.intel.com> Message-ID: On 2017-11-22 00:42-0000 Couch, Kelly J wrote: > I am using cmake to build a binary with multiple shared libraries (some built and some on the system). I want the resulting executable to have dependencies on the required shared libraries (WITHOUT prefixed path to the library). > > Specific build environment: > OpenSuse 11.3 > cmake 2.8.12 and > gcc: i686-linux5.0-gcc (GCC) 4.6.3 > g++: g++ (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585] > > When specifying target_link_libraries(tgtA libA), the result is a tgtA with library linked using a relative path to the libA. For example, when using 'ldd tgtA', result is something like: > > ... > libpthread.so.0 => /lib/libpthread.so.0 (0xf6290000) > /lib/ld-linux.so.2 (0xf7758000) > librt.so.1 => /lib/librt.so.1 (0xf6286000) > ---> directoryA/directoryB/libA.so => not found > > Additional details: > 1. The same cmake files work as expected on other linux distributions. It is only the specified config above that I encounter this issue. > 2. I've various combinations of setting/NOT-setting all of these, trying to overcome this issue: CMAKE_BINARY_DIR, CMAKE_ARCHIVE_OUTPUT_DIRECTORY, CMAKE_RUNTIME_OUTPUT_DIRECTORY, CMAKE_LIBRARY_OUTPUT_DIRECTORY, CMAKE_SKIP_RPATH, CMAKE_SKIP_INSTALL_RPATH > 3. The behavior of prefixed library occurs on libraries that are built targets and library found using find_library > 4. when I examine resulting link.txt file, the link command line includes the path to the shared library (so). Why doesn't cmake use -L to express the path to look and then only pass the library name as -l? Looks like "g++ -o tgtA /directoryA/directoryB/libA.so" > > I have tried all manner of changes related to RPATH options and cmake install, but the prefixed path to the library is always remains present. I am stumped and appreciate the help! Hi Kelly: PLplot also depends on both internally built and external libraries, but I have absolutely no trouble with the issues you have mentioned, and it sounds like you also don't have the problem on any Linux distro other than this old Suse one. So I suspect the fundamental issue is your ancient version = 2.8.12 (!) of CMake that you are attempting to use. So I suggest instead of fooling around with CMake-2.8.12 you try building your project with modern CMake. I would set a minimum version (which sets policies) of something like CMake-3.6.2 (the minimum I have adopted for PLplot) since most modern versions of software distributions provide that version of CMake. When you build your own project with modern CMake that process will likely find bugs and issues with your own package's build system, but getting rid of those is a good thing! Modern cmake is obviously not packaged for your old Suse distro, but one option is for you is to build modern CMake (with version equal to whatever you adopt for your minimum version and/or newer) using the bootstrap approach. I have done that quite a lot for versions of CMake between our minimum version and the latest (3.10.0) version, and those builds have all been quite straightforward (and the corresponding PLplot builds have been good as well). Of course, another option is to upgrade your Suse distro to the latest version. But that is a much more intrusive change than simply building the CMake version(s) you need for testing your software project on that old Suse distro. 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 cpo at slac.stanford.edu Wed Nov 22 00:11:47 2017 From: cpo at slac.stanford.edu (O'Grady, Paul Christopher) Date: Wed, 22 Nov 2017 05:11:47 +0000 Subject: [CMake] /usr/include filtered out of include paths? Message-ID: <6B305733-9740-49C8-9108-19990C245FAF@slac.stanford.edu> Hi, We?re using cmake/anaconda, including the anaconda-delivered gcc7 compilers. As delivered by anaconda, I believe those compilers don?t search include paths like /usr/include and library paths like /lib64 /usr/lib64. When I try to add those paths (e.g. /usr/include to cmake's target_include_directories) it appears to me that cmake filters them out (i.e. doesn?t put them in the list). I can get other paths to show up without a problem. I?m guessing cmake is assuming that the compiler will add those paths automatically. If my understanding is correct, is there a way I can disable this filtering? I have a workaround where I can modify environment variables like CFLAGS/CXXFLAGS/LDFLAGS before running cmake, but that felt somewhat ugly. Thanks for any thoughts you might have, chris From eric.noulard at gmail.com Wed Nov 22 03:49:38 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 22 Nov 2017 09:49:38 +0100 Subject: [CMake] Antwort: Antwort: Re:Antwort: Re: Toolchain with non-gcc argument format In-Reply-To: References: <108951510663019@web39o.yandex.ru> <2784001510743838@web47o.yandex.ru> Message-ID: Hi Olivier, Putting the list back. You may try developer list as well. 2017-11-22 9:02 GMT+01:00 : > Hi, > > Is there really no way to override this var with a toolchain file? that > seems somehow strange to me, since CMAKE is so configurable that i can't > change "-I" to "-include=" .... what do i have to do? I'm sorry I'm a little short in time to investigate that with you at the moment and I hope some other people may step in. The var "CMAKE_INCLUDE_FLAG_C" is NOT a toolchain file variable and it won't end-up in the cache file. AFAIK It is **only** used in compiler detection, e.g. at early stage of project configuration when processing project(...) or enable_language(..) Adding new toolchain is not as flexible as adding a new **kind** of compiler. The knobs accessing for writing a toolchain are described here: https://cmake.org/cmake/help/v3.10/manual/cmake-toolchains.7.html There you can see that: "Languages are enabled by the project() command. Language-specific built-in variables, such as CMAKE_CXX_COMPILER, CMAKE_CXX_COMPILER_ID etc are set by invoking the project() command." Unless I'm wrong the toolchain mechanism does not include the capability to change "-I" to "-include". Now adding a new "kind" of compiler, a.k.a. compiler ID, enables you to specify that include directive flag is " -include" (and many other things as well) Adding a new compiler ID requires to add files in /Modules/Compiler (see https://github.com/Kitware/CMake/tree/master/Modules/Compiler) as you can see it requires at least a couple of file to find a compiler and one file per supported language (C, CXX, etc...) in the C or CXX specific file you may use CMAKE_INCLUDE_FLAG_C and other variables: see e.g.: https://github.com/Kitware/CMake/blob/master/Modules/Compiler/TI-C.cmake I did never add a new kind of compiler so I hope people with more knowlegde than me in this area will explain that part better than me. Eric > > > > 2017-11-16 9:44 GMT+01:00 <*oliver.zabel at egoproducts.com* > >: > I did not find the CMAKE_INCLUDE_FLAG_C in the CMake cache - is it > possible that this is somehow ignored? > > This variable is used by CMake **builtin compiler** discovery and > configuration. > The file are are put in "Modules/Compiler" there is one per-langage and > per-compiler ID: > *https://cmake.org/cmake/help/v3.7/variable/CMAKE_LANG_COMPILER_ID.html* > > > I don't know the exact processing order of this set of files. > > Toolchain files: > *https://cmake.org/cmake/help/v3.7/manual/cmake-toolchains.7.html* > > does not use or contain such variables. > > -- > Eric > > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornelis at bockemuehl.ch Wed Nov 22 03:56:38 2017 From: cornelis at bockemuehl.ch (Cornelis =?ISO-8859-1?Q?Bockem=FChl?=) Date: Wed, 22 Nov 2017 09:56:38 +0100 Subject: [CMake] Strange error with brand new CMake 4.10.0 Message-ID: <1511340998.7600.16.camel@bockemuehl.ch> Yesterday I had a problem with the CMake release candidate 4 for the version 4.10.0 on Windows with MSVC 2015, and I realized by reading the CMakeOutput.log that testing the Manifest Tool (MT) was failing. And with a little Google I got the impression that this is now fixed with the final release: https://gitlab.kitware.com/cmake/cmake/commit/2201ecec44adcc490c7481a52 a88d6543bc5dd7b Now today seeing on the cmake.org website that the version 4.10.0 is out I immediately downloaded and installed it. However the result is a bit disappointing: Indeed the error message has gone from the CMakeOutput.log file - but the Configure run still fails with the same message: CMake Error at CMakeLists.txt:32 (message): ? MSVS not properly configured yet! Now I am lost because I really do not know where to look further! For the very moment, and in order to have a quick solution, I will now probably simply downgrade to the previous version 3.9, but still I wanted to report this problem to the experts! Regards, Cornelis -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornelis at bockemuehl.ch Wed Nov 22 04:22:56 2017 From: cornelis at bockemuehl.ch (Cornelis =?ISO-8859-1?Q?Bockem=FChl?=) Date: Wed, 22 Nov 2017 10:22:56 +0100 Subject: [CMake] Strange error with brand new CMake 4.10.0 - SOLVED In-Reply-To: <1511340998.7600.16.camel@bockemuehl.ch> References: <1511340998.7600.16.camel@bockemuehl.ch> Message-ID: <1511342576.7600.22.camel@bockemuehl.ch> What a shame! Actually that error message comes from my own CMakeLists.txt file - where I had so far only configured some settings for Linux and not yet for MSVC... This is indeed not any more the MT problem, but simply my own - so please forget about my previous posting! Regards, Cornelis Am Mittwoch, den 22.11.2017, 09:56 +0100 schrieb Cornelis Bockem?hl: > > > > > Yesterday I had a problem with the CMake release candidate 4 for the version 4.10.0 on Windows with MSVC 2015, and I realized by reading the CMakeOutput.log that testing the Manifest Tool (MT) was failing. And with a little Google I got the impression that this is now fixed with the final release: > > > https://gitlab.kitware.com/cmake/cmake/commit/2201ecec44adcc490c7481a 52a88d6543bc5dd7b > > > > > > Now today seeing on the cmake.org website that the version 4.10.0 is out I immediately downloaded and installed it. However the result is a bit disappointing: Indeed the error message has gone from the CMakeOutput.log file - but the Configure run still fails with the same message: > > CMake Error at CMakeLists.txt:32 (message): > ? MSVS not properly configured yet! > > Now I am lost because I really do not know where to look further! > > > > For the very moment, and in order to have a quick solution, I will now probably simply downgrade to the previous version 3.9, but still I wanted to report this problem to the experts! > > Regards, Cornelis -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.zabel at egoproducts.com Wed Nov 22 04:33:09 2017 From: oliver.zabel at egoproducts.com (oliver.zabel at egoproducts.com) Date: Wed, 22 Nov 2017 10:33:09 +0100 Subject: [CMake] Antwort: Re: Re: Antwort: Antwort: Re:Antwort: Re: Toolchain with non-gcc argument format In-Reply-To: References: <108951510663019@web39o.yandex.ru> <2784001510743838@web47o.yandex.ru> Message-ID: Hi Eric, thanks a lot for your help! i'm going to try it on the dev mailing list. Cheers, Oliver Von: Eric Noulard An: oliver.zabel at egoproducts.com Kopie: CMake Mailinglist Datum: 22.11.2017 09:49 Betreff: Re: Re: [CMake] Antwort: Antwort: Re:Antwort: Re: Toolchain with non-gcc argument format Hi Olivier, Putting the list back. You may try developer list as well. 2017-11-22 9:02 GMT+01:00 : Hi, Is there really no way to override this var with a toolchain file? that seems somehow strange to me, since CMAKE is so configurable that i can't change "-I" to "-include=" .... what do i have to do? I'm sorry I'm a little short in time to investigate that with you at the moment and I hope some other people may step in. The var "CMAKE_INCLUDE_FLAG_C" is NOT a toolchain file variable and it won't end-up in the cache file. AFAIK It is **only** used in compiler detection, e.g. at early stage of project configuration when processing project(...) or enable_language(..) Adding new toolchain is not as flexible as adding a new **kind** of compiler. The knobs accessing for writing a toolchain are described here: https://cmake.org/cmake/help/v3.10/manual/cmake-toolchains.7.html There you can see that: "Languages are enabled by the project() command. Language-specific built-in variables, such as CMAKE_CXX_COMPILER, CMAKE_CXX_COMPILER_ID etc are set by invoking the project() command." Unless I'm wrong the toolchain mechanism does not include the capability to change "-I" to "-include". Now adding a new "kind" of compiler, a.k.a. compiler ID, enables you to specify that include directive flag is " -include" (and many other things as well) Adding a new compiler ID requires to add files in /Modules/Compiler (see https://github.com/Kitware/CMake/tree/master/Modules/Compiler) as you can see it requires at least a couple of file to find a compiler and one file per supported language (C, CXX, etc...) in the C or CXX specific file you may use CMAKE_INCLUDE_FLAG_C and other variables: see e.g.: https://github.com/Kitware/CMake/blob/master/Modules/Compiler/TI-C.cmake I did never add a new kind of compiler so I hope people with more knowlegde than me in this area will explain that part better than me. Eric 2017-11-16 9:44 GMT+01:00 : I did not find the CMAKE_INCLUDE_FLAG_C in the CMake cache - is it possible that this is somehow ignored? This variable is used by CMake **builtin compiler** discovery and configuration. The file are are put in "Modules/Compiler" there is one per-langage and per-compiler ID: https://cmake.org/cmake/help/v3.7/variable/CMAKE_LANG_COMPILER_ID.html I don't know the exact processing order of this set of files. Toolchain files: https://cmake.org/cmake/help/v3.7/manual/cmake-toolchains.7.html does not use or contain such variables. -- Eric -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From carsten.fuchs at cafu.de Wed Nov 22 05:32:22 2017 From: carsten.fuchs at cafu.de (Carsten Fuchs) Date: Wed, 22 Nov 2017 11:32:22 +0100 Subject: [CMake] Using find_package() portably? In-Reply-To: <429221511301415@web20o.yandex.ru> References: <015f1e5c-ffae-d96d-1dd3-8ca0b8939698@cafu.de> <1439271511253943@web52j.yandex.ru> <1639003.WzOYk1S0Ou@ersa> <118291511264217@web4g.yandex.ru> <429221511301415@web20o.yandex.ru> Message-ID: Hi all, thanks to you all for your replies! Concluding from your replies, it seems that the following approach for each external dependency implements a good(?) solution: find_package(JPEG) # without "REQUIRED" if (NOT JPEG_FOUND) # Optionally, under Linux only: # Stop with custom error message that explains how to install libjpeg. # Or ask if alternatively the shipped library should be used. # This complements the installation instructions in the user docs. ... # TODO! # Proceed with the shipped copy of libjpeg: # Always under Windows and possibly under Linux as outlined above. # Always in source code form, compiling here; not pre-made binaries. # (This approach is my personal preference over the other options # that have been suggested.) add_subdirectory(../ExtLibs/libjpeg ../ExtLibs/libjpeg) ... # see below endif() # How does this work in case `NOT JPEG_FOUND` above? target_link_libraries(main_program ${JPEG_LIBRARIES}) That is, follow-up question: near the "..." above, we have got a target "libjpeg", but how do I get the variables JPEG_INCLUDES, JPEG_LIBRARIES etc. that `find_package(JPEG)` normally provides so that the last line with the `target_link_libraries()` works? I guess that defining them in `../ExtLibs/libjpeg/CMakeLists.txt` is wrong. It seems to me that the 2017 talks by Mathieu Roperts and Daniel Pfeifer (starting at slide 53, see especially slide 64 at https://www.slideshare.net/DanielPfeifer1/effective-cmake) suggest that this is how the modern, modular CMake is supposed to work? Best regards, Carsten From oleksii.vilchanskyi at gmail.com Wed Nov 22 05:40:05 2017 From: oleksii.vilchanskyi at gmail.com (Oleksii Vilchanskyi) Date: Wed, 22 Nov 2017 11:40:05 +0100 Subject: [CMake] Handling of generator expressions In-Reply-To: References: Message-ID: <39f9bc3b-a6e3-988f-82d8-d6f006eaa9e6@gmail.com> UPD. forgot to CC the mailing list Hi, I am also confused by this and decided to test it. I found a long thread from 2012 that discusses list expansion issues. It doesn't tell though whether the patch was mainlined. tldr; if you quote the whole genexpr, the list will expand properly. Below is the working code. ---------------------------------------------------------------------- cmake_minimum_required(VERSION 3.3 FATAL_ERROR) project(recipe-09 CXX) set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_EXTENSIONS OFF) set(CMAKE_CXX_STANDARD_REQUIRED ON) list(APPEND CXX_BASIC_FLAGS "-g3" "-O1") include(CheckCXXCompilerFlag) set(ASAN_FLAGS "-fsanitize=address -fno-omit-frame-pointer") set(CMAKE_REQUIRED_FLAGS ${ASAN_FLAGS}) check_cxx_compiler_flag(${ASAN_FLAGS} asan_works) unset(CMAKE_REQUIRED_FLAGS) add_executable(asan-example asan-example.cpp) string(REPLACE " " ";" _asan_flags ${ASAN_FLAGS}) target_compile_options(asan-example PUBLIC ${CXX_BASIC_FLAGS} $<$:${_asan_flags}> ) target_link_libraries(asan-example PUBLIC "$<$:${_asan_flags}>" # <-- NOTE THIS ) ---------------------------------------------------------------------- On 19.11.2017 19:16, Roberto Di Remigio wrote: > Hello, > I am trying to compile the following code snippet: > > int main(int argc, char ** argv) { > ? int stack_array[100]; > ? stack_array[1] = 0; > ? return stack_array[argc + 100]; // BOOM > } > > The followin CMakeLists.txt works fine, but you can notice that > target_compile_options takes a list, while target_link_libraries takes a > string. Always using the string will result in a compilation error, > because the compiler flags are passed quoted to the compiler. Always > using the list doesn't work either, because the generator expression is > evaluated as $<1:-fsanitize=address -fno-omit-frame-pointer> and then > passed as-is to the linker, which doesn't know what to do with it. > Is this supposed to be like this? If yes, what's the rationale? > Thanks in advance! > ? Roberto > > cmake_minimum_required(VERSION 3.3 FATAL_ERROR) > > project(recipe-09 CXX) > > set(CMAKE_CXX_STANDARD 11) > set(CMAKE_CXX_EXTENSIONS OFF) > set(CMAKE_CXX_STANDARD_REQUIRED ON) > > list(APPEND CXX_BASIC_FLAGS "-g3" "-O1") > > include(CheckCXXCompilerFlag) > > set(ASAN_FLAGS "-fsanitize=address -fno-omit-frame-pointer") > set(CMAKE_REQUIRED_FLAGS ${ASAN_FLAGS}) > check_cxx_compiler_flag(${ASAN_FLAGS} asan_works) > unset(CMAKE_REQUIRED_FLAGS) > > add_executable(asan-example asan-example.cpp) > string(REPLACE " " ";" _asan_flags ${ASAN_FLAGS}) > target_compile_options(asan-example > ? PUBLIC > ? ? ${CXX_BASIC_FLAGS} > ? ? $<$:${_asan_flags}> > ? ) > target_link_libraries(asan-example > ? PUBLIC > ? ? $<$:${ASAN_FLAGS}> > ? ) > > -- Regards, Oleksii Vilchanskyi PGP:0x8D3A0E046BDE941F2A53867CE3FD952D48C0B338 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From annulen at yandex.ru Wed Nov 22 05:44:04 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 22 Nov 2017 13:44:04 +0300 Subject: [CMake] Using find_package() portably? In-Reply-To: References: <015f1e5c-ffae-d96d-1dd3-8ca0b8939698@cafu.de> <1439271511253943@web52j.yandex.ru> <1639003.WzOYk1S0Ou@ersa> <118291511264217@web4g.yandex.ru> <429221511301415@web20o.yandex.ru> Message-ID: <502751511347444@web13o.yandex.ru> 22.11.2017, 13:37, "Carsten Fuchs" : > Hi all, > > thanks to you all for your replies! > > Concluding from your replies, it seems that the following approach for > each external dependency implements a good(?) solution: > > find_package(JPEG) # without "REQUIRED" > > if (NOT JPEG_FOUND) > ?????# Optionally, under Linux only: > ?????# Stop with custom error message that explains how to install libjpeg. > ?????# Or ask if alternatively the shipped library should be used. > ?????# This complements the installation instructions in the user docs. > ?????... # TODO! > > ?????# Proceed with the shipped copy of libjpeg: > ?????# Always under Windows Note that there are package systems on Windows too, e.g. VCPKG or MSYS2. Also there are a few packages which can be found by CMake by using registry keys provided by their installers (not the case for libjpeg) > and possibly under Linux as outlined above. > ?????# Always in source code form, compiling here; not pre-made binaries. > ?????# (This approach is my personal preference over the other options > ?????# that have been suggested.) > ?????add_subdirectory(../ExtLibs/libjpeg ../ExtLibs/libjpeg) > > ?????... # see below > endif() > > # How does this work in case `NOT JPEG_FOUND` above? > target_link_libraries(main_program ${JPEG_LIBRARIES}) > > That is, follow-up question: near the "..." above, we have got a target > "libjpeg", but how do I get the variables JPEG_INCLUDES, JPEG_LIBRARIES > etc. that `find_package(JPEG)` normally provides so that the last line > with the `target_link_libraries()` works? > I guess that defining them in `../ExtLibs/libjpeg/CMakeLists.txt` is wrong. > > It seems to me that the 2017 talks by Mathieu Roperts and Daniel Pfeifer > (starting at slide 53, see especially slide 64 at > https://www.slideshare.net/DanielPfeifer1/effective-cmake) suggest that > this is how the modern, modular CMake is supposed to work? > > Best regards, > Carsten > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin From johannes.zarl-zierl at jku.at Wed Nov 22 06:03:45 2017 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Wed, 22 Nov 2017 12:03:45 +0100 Subject: [CMake] Using find_package() portably? In-Reply-To: References: <015f1e5c-ffae-d96d-1dd3-8ca0b8939698@cafu.de> <429221511301415@web20o.yandex.ru> Message-ID: <5662152.4nPEXIznPt@ersa> On Mittwoch, 22. November 2017 11:32:22 CET Carsten Fuchs wrote: > That is, follow-up question: near the "..." above, we have got a target > "libjpeg", but how do I get the variables JPEG_INCLUDES, JPEG_LIBRARIES > etc. that `find_package(JPEG)` normally provides so that the last line > with the `target_link_libraries()` works? > I guess that defining them in `../ExtLibs/libjpeg/CMakeLists.txt` is wrong. You've found an ugly corner in CMake ;-) The problem in this specific case is that CMake ships with a FindJPEG module that does not define modern import libs, but uses the old way of defining _LIBRARIES and _INCLUDE_DIRS. IMO this highlights one of the main problems with find modules: nobody really maintains them. If JPEG had proper imported targets, your code could look like this: find_package(JPEG) # without "REQUIRED" if (NOT JPEG_FOUND) ... # Proceed with the shipped copy of libjpeg: add_subdirectory(../ExtLibs/libjpeg ../ExtLibs/libjpeg) endif() target_link_libraries(main_program JPEG::JPEG) You just have to make sure that your shipped libjpeg creates the proper namespaced target: add_library(JPEG ...) add_library(JPEG::JPEG ALIAS JPEG) HTH, Johannes From roberto.diremigio at gmail.com Wed Nov 22 10:13:11 2017 From: roberto.diremigio at gmail.com (Roberto Di Remigio) Date: Wed, 22 Nov 2017 16:13:11 +0100 Subject: [CMake] Handling of generator expressions In-Reply-To: <39f9bc3b-a6e3-988f-82d8-d6f006eaa9e6@gmail.com> References: <39f9bc3b-a6e3-988f-82d8-d6f006eaa9e6@gmail.com> Message-ID: Dear Oleksii, indeed it works! Thank you! I have opened an issue on the CMake repository: https://gitlab.kitware.com/cmake/cmake/issues/17501 I think it could still be a bug, since target_compile_definitions and target_link_libraries seem to evaluate the expression differently. All the best, Roberto On Wed, Nov 22, 2017 at 11:40 AM, Oleksii Vilchanskyi < oleksii.vilchanskyi at gmail.com> wrote: > UPD. forgot to CC the mailing list > > Hi, > > I am also confused by this and decided to test it. I found a long thread > from 2012 > thread.html#16509> > that discusses list expansion issues. It doesn't tell though whether the > patch was mainlined. > > tldr; if you quote the whole genexpr, the list will expand properly. > Below is the working code. > > ---------------------------------------------------------------------- > cmake_minimum_required(VERSION 3.3 FATAL_ERROR) > > project(recipe-09 CXX) > > set(CMAKE_CXX_STANDARD 11) > set(CMAKE_CXX_EXTENSIONS OFF) > set(CMAKE_CXX_STANDARD_REQUIRED ON) > > list(APPEND CXX_BASIC_FLAGS "-g3" "-O1") > > include(CheckCXXCompilerFlag) > > set(ASAN_FLAGS "-fsanitize=address -fno-omit-frame-pointer") > set(CMAKE_REQUIRED_FLAGS ${ASAN_FLAGS}) > check_cxx_compiler_flag(${ASAN_FLAGS} asan_works) > unset(CMAKE_REQUIRED_FLAGS) > > add_executable(asan-example asan-example.cpp) > string(REPLACE " " ";" _asan_flags ${ASAN_FLAGS}) > target_compile_options(asan-example > PUBLIC > ${CXX_BASIC_FLAGS} > $<$:${_asan_flags}> > ) > target_link_libraries(asan-example > PUBLIC > "$<$:${_asan_flags}>" # <-- NOTE THIS > ) > ---------------------------------------------------------------------- > > On 19.11.2017 19:16, Roberto Di Remigio wrote: > > Hello, > > I am trying to compile the following code snippet: > > > > int main(int argc, char ** argv) { > > int stack_array[100]; > > stack_array[1] = 0; > > return stack_array[argc + 100]; // BOOM > > } > > > > The followin CMakeLists.txt works fine, but you can notice that > > target_compile_options takes a list, while target_link_libraries takes a > > string. Always using the string will result in a compilation error, > > because the compiler flags are passed quoted to the compiler. Always > > using the list doesn't work either, because the generator expression is > > evaluated as $<1:-fsanitize=address -fno-omit-frame-pointer> and then > > passed as-is to the linker, which doesn't know what to do with it. > > Is this supposed to be like this? If yes, what's the rationale? > > Thanks in advance! > > Roberto > > > > cmake_minimum_required(VERSION 3.3 FATAL_ERROR) > > > > project(recipe-09 CXX) > > > > set(CMAKE_CXX_STANDARD 11) > > set(CMAKE_CXX_EXTENSIONS OFF) > > set(CMAKE_CXX_STANDARD_REQUIRED ON) > > > > list(APPEND CXX_BASIC_FLAGS "-g3" "-O1") > > > > include(CheckCXXCompilerFlag) > > > > set(ASAN_FLAGS "-fsanitize=address -fno-omit-frame-pointer") > > set(CMAKE_REQUIRED_FLAGS ${ASAN_FLAGS}) > > check_cxx_compiler_flag(${ASAN_FLAGS} asan_works) > > unset(CMAKE_REQUIRED_FLAGS) > > > > add_executable(asan-example asan-example.cpp) > > string(REPLACE " " ";" _asan_flags ${ASAN_FLAGS}) > > target_compile_options(asan-example > > PUBLIC > > ${CXX_BASIC_FLAGS} > > $<$:${_asan_flags}> > > ) > > target_link_libraries(asan-example > > PUBLIC > > $<$:${ASAN_FLAGS}> > > ) > > > > > > -- > Regards, > Oleksii Vilchanskyi > PGP:0x8D3A0E046BDE941F2A53867CE3FD952D48C0B338 > > -- Roberto Di Remigio -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Wed Nov 22 11:47:58 2017 From: csiga.biga at aol.com (=?utf-8?Q?M=C3=A1t=C3=A9_Ferenc_Nagy-Egri?=) Date: Wed, 22 Nov 2017 17:47:58 +0100 Subject: [CMake] Toolchain files and vcpkg Message-ID: Hi! I?m trying to use packages (HPX specifically) installed with vcpkg, and according to its wiki, it is easiest to do so via the toolchain file provided by vcpkg. Here?s is what I?m doing: cd build cmake -G ?Ninja? -D CMAKE_BUILD_TYPE=Release -D CMAKE_TOOLCHAIN_FILE=C:/Users/nagy-/Source/Repos/vcpkg/scripts/buildsystems/vcpkg.cmake ..\ But it seems that CMake completely disregards the toolchain file, as if it weren?t even there. Same happens for Visual Studio generators, not just Ninja. Am I doing something wrong? Does anyone have a minimal working script with HPX installed through vcpkg? Cheers, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stefan.Waigand at continental-corporation.com Wed Nov 22 12:07:06 2017 From: Stefan.Waigand at continental-corporation.com (Stefan.Waigand at continental-corporation.com) Date: Wed, 22 Nov 2017 18:07:06 +0100 Subject: [CMake] spaces in generator strings troublesome (Konstantin Tokarev) In-Reply-To: References: Message-ID: Hello Konstantin Tokarev, thank you for your answer. > Just write your scripts in decent language Well, i know, there are more sophisticated languages than bash. But in our environment here unfortunately there are reasons why we cannot use another language. Please do not let us discuss why. My problem is also not that i don't have a solution in bash. I got it working finally. The point is. this solution is not nice, it is hardly comprehensible, hardly maintainable. Also other people out there have to deal with this. It is just more complicated as it needs to be. So i kindly ask the CMake project to support command lines like "cmake . -GUnix_Makefiles". Thank you. Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stefan.Waigand at continental-corporation.com Wed Nov 22 12:38:23 2017 From: Stefan.Waigand at continental-corporation.com (Stefan.Waigand at continental-corporation.com) Date: Wed, 22 Nov 2017 18:38:23 +0100 Subject: [CMake] spaces in generator strings troublesome (Michael Ellery) In-Reply-To: References: Message-ID: Hi Michael Ellery thank you for your reply. > perhaps handle arguments as an array variable in bash - it?s a > slightly saner way to deal with args with spaces: > > CMDLINE=(. -G"Unix Makefiles") && cmake "${CMDLINE[@]}? Well i already got it working in bash when i wrote that. I have the parameters in a variable and i use eval to execute: eval $CMAKE_EXECUTABLE $CMAKE_PARAMS_ALL My point is not i cannot solve the problem. My point is, i like to simplify this in the future. The current solution is not nice - it is a workaround. It is more difficult to understand and maintain as it needs to be. And i am not the only one who has to deal with this problem. CMake uses spaces inside arguments where spaces are usually for separation of arguments. Do you agree? Countless hours i spent debugging similar problems with paths like c:\Program Files. I know, one shouldn't use windows as development environment, but this is something we cannot change unfortunately. Since we force our developers to not install their perl, compilers etc. in such paths, things are much better. I appreciate having the same in CMake. Isn't it as simple as replacing all '_' by ' ' to support this and be backward compatible? Are there other reasons i do not see? So i again like to kindly ask you to support (besides the established way) a command line like cmake . -GUnix_Makefiles Thank you, Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwpowellhtx at gmail.com Wed Nov 22 13:45:50 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Wed, 22 Nov 2017 13:45:50 -0500 Subject: [CMake] Cannot seem to add include directory Message-ID: Hello, I have a couple of libraries added, one SHARED and the other STATIC, for which I want to add include directories, but they are not adding. I am trying the following: target_include_directories (${MY_PROJECT_NAME_SHARED} PUBLIC "G:/Source/Boost.Installed/boost-1.65.1/include" ) Where MY_PROJECT_NAME_SHARED if my project name. I've also tried with the $, to no avail. I review my VS2015 project settings and I do not see any directories changing after the solution reloads. Cheers, Michael Powell From mwpowellhtx at gmail.com Wed Nov 22 14:03:48 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Wed, 22 Nov 2017 14:03:48 -0500 Subject: [CMake] Cannot seem to add include directory In-Reply-To: References: Message-ID: On Wed, Nov 22, 2017 at 1:45 PM, Michael Powell wrote: > Hello, > > I have a couple of libraries added, one SHARED and the other STATIC, > for which I want to add include directories, but they are not adding. Oh, okay... So they are being added under "additional include directories". Or they seem to be... > I am trying the following: > > target_include_directories (${MY_PROJECT_NAME_SHARED} PUBLIC > "G:/Source/Boost.Installed/boost-1.65.1/include" > ) > > Where MY_PROJECT_NAME_SHARED if my project name. > > I've also tried with the $, to no avail. > > I review my VS2015 project settings and I do not see any directories > changing after the solution reloads. > > Cheers, > > Michael Powell From lectem at gmail.com Wed Nov 22 14:12:39 2017 From: lectem at gmail.com (=?UTF-8?Q?Cl=C3=A9ment_Gregoire?=) Date: Wed, 22 Nov 2017 19:12:39 +0000 Subject: [CMake] Cannot seem to add include directory In-Reply-To: References: Message-ID: Well, that's the standard way to add include for msbuild projects, other variables are meant to be used for the tool chain includes only Le mer. 22 nov. 2017 ? 20:04, Michael Powell a ?crit : > On Wed, Nov 22, 2017 at 1:45 PM, Michael Powell > wrote: > > Hello, > > > > I have a couple of libraries added, one SHARED and the other STATIC, > > for which I want to add include directories, but they are not adding. > > Oh, okay... So they are being added under "additional include > directories". Or they seem to be... > > > I am trying the following: > > > > target_include_directories (${MY_PROJECT_NAME_SHARED} PUBLIC > > "G:/Source/Boost.Installed/boost-1.65.1/include" > > ) > > > > Where MY_PROJECT_NAME_SHARED if my project name. > > > > I've also tried with the $, to no avail. > > > > I review my VS2015 project settings and I do not see any directories > > changing after the solution reloads. > > > > Cheers, > > > > Michael Powell > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andlind at gmail.com Wed Nov 22 16:16:31 2017 From: andlind at gmail.com (Anders Lindgren) Date: Wed, 22 Nov 2017 22:16:31 +0100 Subject: [CMake] Antwort: Re: Re: Antwort: Antwort: Re:Antwort: Re: Toolchain with non-gcc argument format In-Reply-To: References: <108951510663019@web39o.yandex.ru> <2784001510743838@web47o.yandex.ru> Message-ID: Hi! One solution is to write a wrapper script in your favourite scripting language (Ruby, Python etc) that pretend that it's a compiler. It could recognise the -I option and start the RX compiler with the --include option. It would not hurt to make it recognise other standard flags like "-o" and "-c" in case the RX compiler doesn't support them either. -- Anders On Wed, Nov 22, 2017 at 10:33 AM, wrote: > Hi Eric, > > thanks a lot for your help! i'm going to try it on the dev mailing list. > > Cheers, > Oliver > > > > Von: Eric Noulard > An: oliver.zabel at egoproducts.com > Kopie: CMake Mailinglist > Datum: 22.11.2017 09:49 > Betreff: Re: Re: [CMake] Antwort: Antwort: Re:Antwort: Re: > Toolchain with non-gcc argument format > ------------------------------ > > > > Hi Olivier, > > Putting the list back. > You may try developer list as well. > > > 2017-11-22 9:02 GMT+01:00 <*oliver.zabel at egoproducts.com* > >: > Hi, > > Is there really no way to override this var with a toolchain file? that > seems somehow strange to me, since CMAKE is so configurable that i can't > change "-I" to "-include=" .... what do i have to do? > > > I'm sorry I'm a little short in time to investigate that with you at the > moment and I hope some other people may step in. > The var "CMAKE_INCLUDE_FLAG_C" is NOT a toolchain file variable and it > won't end-up in the cache file. > AFAIK It is **only** used in compiler detection, e.g. at early stage of > project configuration when processing project(...) > or enable_language(..) > > Adding new toolchain is not as flexible as adding a new **kind** of > compiler. > The knobs accessing for writing a toolchain are described here: > *https://cmake.org/cmake/help/v3.10/manual/cmake-toolchains.7.html* > > > There you can see that: > "Languages are enabled by the project() command. Language-specific > built-in variables, such as CMAKE_CXX_COMPILER, CMAKE_CXX_COMPILER_ID etc > are set by invoking the project() command." > > Unless I'm wrong the toolchain mechanism does not include the capability > to change "-I" to "-include". > > Now adding a new "kind" of compiler, a.k.a. compiler ID, enables you to > specify that include directive flag is " -include" (and many other things > as well) > Adding a new compiler ID requires to add files in > /Modules/Compiler (see > *https://github.com/Kitware/CMake/tree/master/Modules/Compiler* > ) > > as you can see it requires at least a couple of file to find a compiler > and one file per supported language (C, CXX, etc...) > in the C or CXX specific file you may use CMAKE_INCLUDE_FLAG_C and other > variables: > > see e.g.: > *https://github.com/Kitware/CMake/blob/master/Modules/Compiler/TI-C.cmake* > > > > I did never add a new kind of compiler so I hope people with more > knowlegde than me in this area will explain that part better than me. > > Eric > > > > > > 2017-11-16 9:44 GMT+01:00 <*oliver.zabel at egoproducts.com* > >: > I did not find the CMAKE_INCLUDE_FLAG_C in the CMake cache - is it > possible that this is somehow ignored? > > This variable is used by CMake **builtin compiler** discovery and > configuration. > The file are are put in "Modules/Compiler" there is one per-langage and > per-compiler ID: > *https://cmake.org/cmake/help/v3.7/variable/CMAKE_LANG_COMPILER_ID.html* > > > I don't know the exact processing order of this set of files. > > Toolchain files: > *https://cmake.org/cmake/help/v3.7/manual/cmake-toolchains.7.html* > > does not use or contain such variables. > > -- > Eric > > > > > -- > 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: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From terminatorul at gmail.com Thu Nov 23 07:05:27 2017 From: terminatorul at gmail.com (Timothy Madden) Date: Thu, 23 Nov 2017 14:05:27 +0200 Subject: [CMake] Win cmake belives I am building a .dll, but the only target is an .exe file Message-ID: Hello, In my CMakeLists.txt I have a simple executable target like: cmake_minimum_required(VERSION 3.2) # I actually have 3.10 installed project(cl-tool CXX) set(OPENCL_INCLUDE_SEARCH_PATHS ...) set(OPENCL_LIBRARY_64_SEARCH_PATHS ...) if (CYGWIN) set(CMAKE_FIND_LIBRARY_SUFFIXES .lib) set(OCL_LIB_SUFFIX .lib) endif() set(OPENCL_LIBRARY_SEARCH_PATHS ${OPENCL_LIBRARY_64_SEARCH_PATHS}) set(FIND_LIBRARY_USE_LIB64_PATHS ON) find_path(OPENCL_INCLUDE_DIRS CL/cl.h PATHS ENV OpencCL_INCPATH ${OPENCL_INCLUDE_SEARCH_PATHS}) find_path(OPENCL2_HPP_INCLUDE_DIRS CL/cl2.hpp PATHS ENV OpencCL_INCPATH ${OPENCL_INCLUDE_SEARCH_PATHS}) find_library(OPENCL_LIBRARIES NAMES OpenCL DOC "OpenCL library" PATHS ENV OpenCL_LIBPATH ${OPENCL_LIBRARY_SEARCH_PATHS}) find_package(Threads) set(CL_INFO_SOURCES cl-matrix-mult.hh cl-matrix-mult.cc cl-platform-info.hh cl-platform-info.cc cl-tool.cc) *add_executable(cl-tool ${CL_INFO_SOURCES})* target_compile_features(cl-tool PRIVATE cxx_std_14) target_compile_definitions(cl-tool PRIVATE CL_HPP_TARGET_OPENCL_VERSION=120 CL_HPP_MINIMUM_OPENCL_VERSION=110 CL_HPP_CL_1_2_DEFAULT_BUILD CL_HPP_ENABLE_EXCEPTIONS) target_compile_definitions(cl-tool PRIVATE __CL_ENABLE_EXCEPTIONS CL_VERSION_1_2) target_include_directories(cl-tool PRIVATE ${OPENCL_INCLUDE_DIRS} ${OPENCL2_HPP_INCLUDE_DIRS}) target_compile_options(cl-tool PRIVATE -Wno-ignored-attributes -fvisibility=hidden) target_link_libraries(cl-tool ${OPENCL_LIBRARIES} Threads::Threads) But then at build time with: cd build && cmake .. -G "MinGW ..." -DCMAKE_CXX_COMPILER=g++ gmake VERBOSE=1 I get bellow unexpected behaviour: CMake is building a static archive with `ar` containing all 3 objects in my target executable cl-tool.exe. The static archive is then linked in the executable with -Wl,--whole-archive. CMake also wants to output an import library, Although the target is clearly an executable named cl-tool.exe, on the same g++ command line used for linking. My objects use some templates that are instantiated in 2 of the 3 objects, and using --Wl,--whole-archive with these object files, results in multiple definitions for the instantiations. Normally the linker would see the multiple symbols as weak references and discard duplicates, but now CMake insists on using --whole-archive on the linker command line, so duplicates now result in an error. I have Win10 up-to-date, CMake 3.10, and g++ 7.1, from the MinGW installation that comes packaged with Strawberry Perl. Also Intel OpenCL SDKincluded and linked with. This unexpected behaviour is breaking my build, and I am also worried about the duplicate / unused code in the resulting executable. Is there a proper solution to this problem please ? Why does CMake go to the trouble of: - creating a separate static archive with the 3 object files (which is not requested from the CMakeLists.txt file) ? - using --whole-archive on the resulting .a file instead of linking normally ? - attempt to output the import library for an .exe module ? Apparently CMake believes my target is a .dll (shared library), but nowhere in the CMakeLists is a .dll ever created. I set ENABLE_EXPORTS and CMAKE_WIN32_EXPORT_ENABLE to "OFF", with no effect. -- Thank you, Timothy Madden -------------- next part -------------- An HTML attachment was scrubbed... URL: From terminatorul at gmail.com Fri Nov 24 19:01:49 2017 From: terminatorul at gmail.com (Timothy Madden) Date: Sat, 25 Nov 2017 02:01:49 +0200 Subject: [CMake] Win cmake belives I am building a .dll, but the only target is an .exe file In-Reply-To: References: Message-ID: It turns out this is not a CMake issue. Sorry for the wrong question. I switched from a makefile to CMake at the same time I switched from one cpp to 3 cpp in my little project. The problem occurs when "CL/cl2.hpp" is used in multiple .cpp files, with or without using CMake to build. I still don't know why the linker sees multiple definitions, it turns out it's from a function like this in the header: namespace detail { static inline cl_int errHandler (cl_int err, const char * errStr = NULL) { if (err != CL_SUCCESS) throw Error(err, errStr); return err; } } (which I understand should be safe to use in a .hpp) On Thu, Nov 23, 2017 at 2:05 PM, Timothy Madden wrote: > Hello, > > In my CMakeLists.txt I have a simple executable target like: > > cmake_minimum_required(VERSION 3.2) # I actually have 3.10 installed > project(cl-tool CXX) > > set(OPENCL_INCLUDE_SEARCH_PATHS ...) > set(OPENCL_LIBRARY_64_SEARCH_PATHS ...) > > if (CYGWIN) > set(CMAKE_FIND_LIBRARY_SUFFIXES .lib) > set(OCL_LIB_SUFFIX .lib) > endif() > > set(OPENCL_LIBRARY_SEARCH_PATHS ${OPENCL_LIBRARY_64_SEARCH_PATHS}) > set(FIND_LIBRARY_USE_LIB64_PATHS ON) > > find_path(OPENCL_INCLUDE_DIRS CL/cl.h PATHS ENV OpencCL_INCPATH > ${OPENCL_INCLUDE_SEARCH_PATHS}) > find_path(OPENCL2_HPP_INCLUDE_DIRS CL/cl2.hpp PATHS ENV OpencCL_INCPATH > ${OPENCL_INCLUDE_SEARCH_PATHS}) > > find_library(OPENCL_LIBRARIES NAMES OpenCL DOC "OpenCL library" PATHS ENV > OpenCL_LIBPATH ${OPENCL_LIBRARY_SEARCH_PATHS}) > find_package(Threads) > > set(CL_INFO_SOURCES cl-matrix-mult.hh cl-matrix-mult.cc > cl-platform-info.hh cl-platform-info.cc cl-tool.cc) > *add_executable(cl-tool ${CL_INFO_SOURCES})* > target_compile_features(cl-tool PRIVATE cxx_std_14) > target_compile_definitions(cl-tool PRIVATE CL_HPP_TARGET_OPENCL_VERSION=120 > CL_HPP_MINIMUM_OPENCL_VERSION=110 CL_HPP_CL_1_2_DEFAULT_BUILD > CL_HPP_ENABLE_EXCEPTIONS) > target_compile_definitions(cl-tool PRIVATE __CL_ENABLE_EXCEPTIONS > CL_VERSION_1_2) > target_include_directories(cl-tool PRIVATE ${OPENCL_INCLUDE_DIRS} > ${OPENCL2_HPP_INCLUDE_DIRS}) > target_compile_options(cl-tool PRIVATE -Wno-ignored-attributes > -fvisibility=hidden) > target_link_libraries(cl-tool ${OPENCL_LIBRARIES} Threads::Threads) > > But then at build time with: > > cd build && cmake .. -G "MinGW ..." -DCMAKE_CXX_COMPILER=g++ > gmake VERBOSE=1 > > I get bellow unexpected behaviour: > > CMake is building a static archive with `ar` containing all 3 objects in > my target executable cl-tool.exe. > The static archive is then linked in the executable with > -Wl,--whole-archive. CMake also wants to output an import library, > Although the target is clearly an executable named cl-tool.exe, on the > same g++ command line used for linking. > > My objects use some templates that are instantiated in 2 of the 3 objects, > and using --Wl,--whole-archive with these object files, > results in multiple definitions for the instantiations. > > Normally the linker would see the multiple symbols as weak references and > discard duplicates, but now CMake insists on using > --whole-archive on the linker command line, so duplicates now result in an > error. > > I have Win10 up-to-date, CMake 3.10, and g++ 7.1, from the MinGW > installation that comes packaged with Strawberry Perl. > Also Intel OpenCL SDKincluded and linked with. > > This unexpected behaviour is breaking my build, and I am also worried > about the duplicate / unused code in the resulting executable. > Is there a proper solution to this problem please ? > > Why does CMake go to the trouble of: > - creating a separate static archive with the 3 object files (which is > not requested from the CMakeLists.txt file) ? > - using --whole-archive on the resulting .a file instead of linking > normally ? > - attempt to output the import library for an .exe module ? > > Apparently CMake believes my target is a .dll (shared library), but > nowhere in the CMakeLists is a .dll ever created. > > I set ENABLE_EXPORTS and CMAKE_WIN32_EXPORT_ENABLE to "OFF", with no > effect. > > -- > Thank you, > Timothy Madden > -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Fri Nov 24 19:32:44 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 25 Nov 2017 03:32:44 +0300 Subject: [CMake] Automoc for a part of target sources In-Reply-To: <804211460489529@web26g.yandex.ru> References: <804211460489529@web26g.yandex.ru> Message-ID: <696251511569964@web35o.yandex.ru> 12.04.2016, 22:32, "Konstantin Tokarev" : > Hi all, > > Is it somehow possible to apply automoc-like processing to the list of files, not whole target? > > My use case: in QtWebKit most of sources composing core targets are not related to Qt at all, but there are specific sources specific to Qt port. Currently I'm using automoc, but I suspect that it should be possible to improve incremental build times by reducing number of automoc'ed files. Answering myself: yes, this is possible by setting SKIP_AUTOMOC property on files. This property appears in documentation since CMake 3.8, but in fact it is available since automoc was added to CMake. -- Regards, Konstantin From carsten.fuchs at cafu.de Sat Nov 25 05:46:44 2017 From: carsten.fuchs at cafu.de (Carsten Fuchs) Date: Sat, 25 Nov 2017 11:46:44 +0100 Subject: [CMake] Using find_package() portably? In-Reply-To: <5662152.4nPEXIznPt@ersa> References: <015f1e5c-ffae-d96d-1dd3-8ca0b8939698@cafu.de> <429221511301415@web20o.yandex.ru> <5662152.4nPEXIznPt@ersa> Message-ID: Hello Johannes, Am 2017-11-22 um 12:03 schrieb Johannes Zarl-Zierl: > The problem in this specific case is that CMake ships with a FindJPEG module > that does not define modern import libs, but uses the old way of defining > _LIBRARIES and _INCLUDE_DIRS. > IMO this highlights one of the main problems with find modules: nobody really > maintains them. > > If JPEG had proper imported targets, your code could look like this: > [...] > You just have to make sure that your shipped libjpeg creates the proper > namespaced target: > add_library(JPEG ...) > add_library(JPEG::JPEG ALIAS JPEG) Thanks for your reply, but how can I proceed from here? In order to be able to write in the parent script something that works in either case, that is, target_link_libraries(main_program ) it seems that I either - have to make a copy of FindJPEG.cmake, customize it to define target JPEG::JEPG and ship it along with my project, - or write my `../ExtLibs/libjpeg/CMakeLists.txt` so that it globally defines JPEG_LIBRARIES and JPEG_INCLUDE_DIRS Is that right? Best regards, Carsten From neil.n.carlson at gmail.com Sun Nov 26 10:49:07 2017 From: neil.n.carlson at gmail.com (Neil Carlson) Date: Sun, 26 Nov 2017 08:49:07 -0700 Subject: [CMake] Defining dependent compile and run tests using CMake/CTest Message-ID: I have a test code (think compiler regression test) that want to compile as a test, and if it compiles and links successfully, to go on to run as a subsequent test. I found a thread from Sept that pointed to a method used in boost-cmake for the first compile test. It moves execution of the compile/link from the make step to the ctest step, and works great. I'm now using the FIXTURES_REQUIRED and FIXTURES_SETUP test properties to make the run test depend on the successful completion of the compile test, but this doesn't seem to be working properly. It does order the tests so that the compile test is done first, However if it fails, ctest spews a long message for the run test detailing all the places it looked for the executable (not created because the compile/link test failed) but could not find. It's as if ctest tries to set up the test before checking to see whether it should be run at all. Am I doing something incorrect here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sun Nov 26 14:42:26 2017 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 27 Nov 2017 06:42:26 +1100 Subject: [CMake] Defining dependent compile and run tests using CMake/CTest In-Reply-To: References: Message-ID: Please post your CMakeLists.txt so we can see how you've got the fixtures and tests defined. On Mon, Nov 27, 2017 at 2:49 AM, Neil Carlson wrote: > I have a test code (think compiler regression test) that want to compile > as a test, and if it compiles and links successfully, to go on to run as a > subsequent test. I found a thread from Sept that pointed to a method used > in boost-cmake for the first compile test. It moves execution of the > compile/link from the make step to the ctest step, and works great. I'm > now using the FIXTURES_REQUIRED and FIXTURES_SETUP test properties to make > the run test depend on the successful completion of the compile test, but > this doesn't seem to be working properly. It does order the tests so that > the compile test is done first, However if it fails, ctest spews a long > message for the run test detailing all the places it looked for the > executable (not created because the compile/link test failed) but could not > find. It's as if ctest tries to set up the test before checking to see > whether it should be run at all. Am I doing something incorrect here? > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil.n.carlson at gmail.com Sun Nov 26 18:06:51 2017 From: neil.n.carlson at gmail.com (Neil Carlson) Date: Sun, 26 Nov 2017 16:06:51 -0700 Subject: [CMake] Defining dependent compile and run tests using CMake/CTest In-Reply-To: References: Message-ID: On Sun, Nov 26, 2017 at 12:42 PM, Craig Scott wrote: > Please post your CMakeLists.txt so we can see how you've got the fixtures > and tests defined. > Here's what I've got (I put the run test first to verify that the reordering takes place): add_test(NAME intel-20171126-run COMMAND intel-20171126) set_tests_properties(intel-20171126-run PROPERTIES PASS_REGULAR_EXPRESSION "pass") set_tests_properties(intel-20171126-run PROPERTIES FIXTURES_REQUIRED foo) add_executable(intel-20171126 EXCLUDE_FROM_ALL intel-20171126.f90) add_test(NAME intel-20171126 COMMAND ${CMAKE_COMMAND} --build . --target intel-20171126 --config $ WORKING_DIRECTORY ${CMAKE_BINARY_DIR}) set_tests_properties(intel-20171126 PROPERTIES FIXTURES_SETUP foo) After posting my question, I manually created the "executable" ('touch intel-20171126`) and re-ran ctest. Sure enough, that time I didn't get the long message spew about being able to find the executable, but instead a 1-line message, which is what I had expected to see originally Start 2: intel-20171126 1/13 Test #2: intel-20171126 ...................***Failed 0.15 sec Start 1: intel-20171126-run Failed test dependencies: intel-20171126 2/13 Test #1: intel-20171126-run ...............***Not Run 0.00 sec -------------- next part -------------- An HTML attachment was scrubbed... URL: From cary at txcorp.com Sun Nov 26 18:29:05 2017 From: cary at txcorp.com (JR Cary) Date: Sun, 26 Nov 2017 16:29:05 -0700 Subject: [CMake] FortranCInterface not working with 3.9.0 with Intel 2015 Message-ID: Works with 3.8.2. Compilers specified by -DCMAKE_C_COMPILER:FILEPATH='C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/icl.exe' -DCMAKE_CXX_COMPILER:FILEPATH='C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/icl.exe' -DCMAKE_Fortran_COMPILER:FILEPATH='C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/ifort.exe' The cmake code is include(FortranCInterface) FortranCInterface_HEADER( ? ${CMAKE_BINARY_DIR}/FCMangle.h ? MACRO_NAMESPACE "FC_" ? SYMBOL_NAMESPACE "FC_" ? SYMBOLS mysub mymod:my_sub ) The relevant output is -- Detecting Fortran/C Interface -- Detecting Fortran/C Interface - Failed to compile CMake Warning (dev) at C:/winsame/cary/usim/contrib-icl15/cmake-3.9.0-ser/share/ cmake-3.9/Modules/FortranCInterface.cmake:309 (message): ? No FortranCInterface mangling known for mysub Call Stack (most recent call first): ? scimake/SciFortranChecks.cmake:269 (FortranCInterface_HEADER) ? scimake/SciInit.cmake:232 (include) ? CMakeLists.txt:28 (include) This warning is for project developers.? Use -Wno-dev to suppress it. CMake Warning (dev) at C:/winsame/cary/usim/contrib-icl15/cmake-3.9.0-ser/share/ cmake-3.9/Modules/FortranCInterface.cmake:295 (message): ? No FortranCInterface mangling known for mymod:my_sub Call Stack (most recent call first): ? scimake/SciFortranChecks.cmake:269 (FortranCInterface_HEADER) ? scimake/SciInit.cmake:232 (include) ? CMakeLists.txt:28 (include) This warning is for project developers.? Use -Wno-dev to suppress it. The resulting file is $ cat FCMangle.h #ifndef FC_HEADER_INCLUDED #define FC_HEADER_INCLUDED /*--------------------------------------------------------------------------*/ /* Mangle some symbols automatically.?????????????????????????????????????? */ #endif Any help appreciated..........John Cary From craig.scott at crascit.com Mon Nov 27 05:19:14 2017 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 27 Nov 2017 21:19:14 +1100 Subject: [CMake] Defining dependent compile and run tests using CMake/CTest In-Reply-To: References: Message-ID: On Mon, Nov 27, 2017 at 10:06 AM, Neil Carlson wrote: > > On Sun, Nov 26, 2017 at 12:42 PM, Craig Scott > wrote: > >> Please post your CMakeLists.txt so we can see how you've got the fixtures >> and tests defined. >> > > Here's what I've got (I put the run test first to verify that the > reordering takes place): > > add_test(NAME intel-20171126-run COMMAND intel-20171126) > set_tests_properties(intel-20171126-run PROPERTIES > PASS_REGULAR_EXPRESSION "pass") > set_tests_properties(intel-20171126-run PROPERTIES FIXTURES_REQUIRED foo) > > add_executable(intel-20171126 EXCLUDE_FROM_ALL intel-20171126.f90) > add_test(NAME intel-20171126 > COMMAND ${CMAKE_COMMAND} --build . --target intel-20171126 --config > $ > WORKING_DIRECTORY ${CMAKE_BINARY_DIR}) > set_tests_properties(intel-20171126 PROPERTIES FIXTURES_SETUP foo) > > After posting my question, I manually created the "executable" > ('touch intel-20171126`) > and re-ran ctest. Sure enough, that time I didn't get the long message > spew about > being able to find the executable, but instead a 1-line message, which is > what I had > expected to see originally > > Start 2: intel-20171126 > 1/13 Test #2: intel-20171126 ...................***Failed 0.15 sec > Start 1: intel-20171126-run > Failed test dependencies: intel-20171126 > 2/13 Test #1: intel-20171126-run ...............***Not Run 0.00 sec > > Thanks, that makes the situation clear. I've traced through the CTest source and I think the logic can be improved. I've created an issue for this in the bug tracker here: https://gitlab.kitware.com/cmake/cmake/issues/17514 I'll look into a fix, but for now that bug report includes a workaround you can use in the meantime. On a side note, triggering parts of the build when running tests may seem like a convenient solution, but be aware it has some less obvious gotchas. If you are doing this with more than one test, multiple tests might try and build simultaneously. If the things being built share any common dependencies, the two builds may interfere with each other and overwrite each other's files, etc. In the case of parallel builds, multiple build invocations may result in excessive load due to too many tasks running at once. This can cause out of memory issues if compiling or linking particularly big files. If you want to be sure these things can't happen, you may want to force such tests to run serially to guarantee that they are the only build job: set_tests_properties(intel-20171126 PROPERTIES RUN_SERIAL YES) If you are confident that you can guarantee that you know all the test cases that must not run simultaneously, you can use the RESOURCE_LOCK test property instead to only make those specific tests run not at the same time as each other. This will allow other harmless tests to run concurrently with a build test case, leading to more efficient test execution when parallel testing is enabled. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmake at web.de Mon Nov 27 06:22:29 2017 From: cmake at web.de (cmake at web.de) Date: Mon, 27 Nov 2017 12:22:29 +0100 Subject: [CMake] No token in ExternalProject Message-ID: An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Mon Nov 27 07:12:21 2017 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 27 Nov 2017 23:12:21 +1100 Subject: [CMake] No token in ExternalProject In-Reply-To: References: Message-ID: On Mon, Nov 27, 2017 at 10:22 PM, wrote: > Hello all, > > I'm surprised that there is no token available in > ExternalProject. > > As written in the documentation [1] there are tokens , SUBDIR>, , , and . But > seems to be missing. > The relevant part of the module code is here . It does seem to be an unexpected omission, but I don't know if there's a reason for it or not. > > However if I have an external project with a custom DOWNLOAD_COMMAND it > would be handy to be able to use in the following steps. > > Is there another way to know the download directory without setting it > explicitely? > You can retrieve it with ExternalProject_Get_Property(myExtProj DOWNLOAD_DIR), which will store the result in a variable also named DOWNLOAD_DIR. That's a bit tricky though, since you can only call that after you've defined the download command in your ExternalProject_Add() call. You could define a custom step in a subsequent call and perhaps set up dependencies between steps to get the behaviour you want, but it does seem unnecessarily fiddly. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Mon Nov 27 07:16:39 2017 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 27 Nov 2017 23:16:39 +1100 Subject: [CMake] Defining dependent compile and run tests using CMake/CTest In-Reply-To: References: Message-ID: Merge request 1526 should fix this behavior. Would be great if you could try it out to confirm that it addresses your particular situation. On Mon, Nov 27, 2017 at 9:19 PM, Craig Scott wrote: > > > On Mon, Nov 27, 2017 at 10:06 AM, Neil Carlson > wrote: > >> >> On Sun, Nov 26, 2017 at 12:42 PM, Craig Scott >> wrote: >> >>> Please post your CMakeLists.txt so we can see how you've got the >>> fixtures and tests defined. >>> >> >> Here's what I've got (I put the run test first to verify that the >> reordering takes place): >> >> add_test(NAME intel-20171126-run COMMAND intel-20171126) >> set_tests_properties(intel-20171126-run PROPERTIES >> PASS_REGULAR_EXPRESSION "pass") >> set_tests_properties(intel-20171126-run PROPERTIES FIXTURES_REQUIRED foo) >> >> add_executable(intel-20171126 EXCLUDE_FROM_ALL intel-20171126.f90) >> add_test(NAME intel-20171126 >> COMMAND ${CMAKE_COMMAND} --build . --target intel-20171126 --config >> $ >> WORKING_DIRECTORY ${CMAKE_BINARY_DIR}) >> set_tests_properties(intel-20171126 PROPERTIES FIXTURES_SETUP foo) >> >> After posting my question, I manually created the "executable" >> ('touch intel-20171126`) >> and re-ran ctest. Sure enough, that time I didn't get the long message >> spew about >> being able to find the executable, but instead a 1-line message, which is >> what I had >> expected to see originally >> >> Start 2: intel-20171126 >> 1/13 Test #2: intel-20171126 ...................***Failed 0.15 sec >> Start 1: intel-20171126-run >> Failed test dependencies: intel-20171126 >> 2/13 Test #1: intel-20171126-run ...............***Not Run 0.00 sec >> >> > Thanks, that makes the situation clear. I've traced through the CTest > source and I think the logic can be improved. I've created an issue for > this in the bug tracker here: > > https://gitlab.kitware.com/cmake/cmake/issues/17514 > > I'll look into a fix, but for now that bug report includes a workaround > you can use in the meantime. > > On a side note, triggering parts of the build when running tests may seem > like a convenient solution, but be aware it has some less obvious gotchas. > If you are doing this with more than one test, multiple tests might try and > build simultaneously. If the things being built share any common > dependencies, the two builds may interfere with each other and overwrite > each other's files, etc. In the case of parallel builds, multiple build > invocations may result in excessive load due to too many tasks running at > once. This can cause out of memory issues if compiling or linking > particularly big files. If you want to be sure these things can't happen, > you may want to force such tests to run serially to guarantee that they are > the only build job: > > set_tests_properties(intel-20171126 PROPERTIES RUN_SERIAL YES) > > If you are confident that you can guarantee that you know all the test > cases that must not run simultaneously, you can use the RESOURCE_LOCK test > property instead to only make those specific tests run not at the same time > as each other. This will allow other harmless tests to run concurrently > with a build test case, leading to more efficient test execution when > parallel testing is enabled. > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmake at web.de Tue Nov 28 04:16:26 2017 From: cmake at web.de (cmake at web.de) Date: Tue, 28 Nov 2017 10:16:26 +0100 Subject: [CMake] No token in ExternalProject In-Reply-To: References: Message-ID: Thanks for the link and the suggestion. The latter is similar to one of the things I've tried - splitting the external project into two external projects with one just managing the download. It seemed like a workaround for something which I expected to be an usual use case. Hence I thought I might be missing something. This doesn?t seem to be the case, so I?ll submit a feature request to add a token . Thanks again, Bjorn > On 27. Nov 2017, at 13:12, Craig Scott wrote: > > > > On Mon, Nov 27, 2017 at 10:22 PM, wrote: > Hello all, > > I'm surprised that there is no token available in ExternalProject. > > As written in the documentation [1] there are tokens , , , , and . But seems to be missing. > > The relevant part of the module code is here. It does seem to be an unexpected omission, but I don't know if there's a reason for it or not. > > > > > However if I have an external project with a custom DOWNLOAD_COMMAND it would be handy to be able to use in the following steps. > > Is there another way to know the download directory without setting it explicitely? > > You can retrieve it with ExternalProject_Get_Property(myExtProj DOWNLOAD_DIR), which will store the result in a variable also named DOWNLOAD_DIR. That's a bit tricky though, since you can only call that after you've defined the download command in your ExternalProject_Add() call. You could define a custom step in a subsequent call and perhaps set up dependencies between steps to get the behaviour you want, but it does seem unnecessarily fiddly. > > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com From yue.nicholas at gmail.com Tue Nov 28 19:50:28 2017 From: yue.nicholas at gmail.com (Nicholas Yue) Date: Wed, 29 Nov 2017 00:50:28 +0000 Subject: [CMake] CPack OS X bundle : generator expression for CPACK_BUNDLE_STARTUP_COMMAND Message-ID: I am using CMake 3.10 I can't seems to find a way to tell the OS X bundle where to find the compiled binary. I get the following errors: Run CPack packaging tool... CPack: Create package using Bundle CPack: Install projects CPack: - Run preinstall target for: OSXBundle CPack: - Install project: OSXBundle CPack: Create package CPack Error: Error copying $ to /Users/nicholas/projects/OSX_BundleRPath/build/_CPack_Packages/Darwin/Bundle/OSXBundle-0.1.1-Darwin/MyApp.app/Contents/MacOS/MyApp CPack Error: Error copying startup command. Check the value of CPACK_BUNDLE_STARTUP_COMMAND. CPack Error: Problem compressing the directory CPack Error: Error when generating package: OSXBundle make: *** [package] Error 1 I have the following CMakeLists.txt: CMAKE_MINIMUM_REQUIRED(VERSION 3.8) PROJECT (OSXBundle) FIND_PACKAGE (Boost REQUIRED) ADD_EXECUTABLE (myapp src/main.cpp ) INSTALL ( TARGETS myapp DESTINATION ./bin ) IF (APPLE) # GET_TARGET_PROPERTY ( APP_LOCATION myapp LOCATION ) SET ( APP_LOCATION "$" ) SET ( CPACK_BUNDLE_NAME "MyApp" ) SET ( CPACK_GENERATOR "Bundle" ) SET ( CPACK_BUNDLE_PLIST ${CMAKE_CURRENT_SOURCE_DIR}/resources/Info.plist ) SET ( CPACK_BUNDLE_ICON ${CMAKE_CURRENT_SOURCE_DIR}/resources/MyApp.icns ) SET ( CPACK_PACKAGE_ICON ${CMAKE_CURRENT_SOURCE_DIR}/resources/MyApp.icns ) SET ( CPACK_BUNDLE_STARTUP_COMMAND ${APP_LOCATION} ) ENDIF () INCLUDE ( CPack ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleksii.vilchanskyi at gmail.com Tue Nov 28 22:18:07 2017 From: oleksii.vilchanskyi at gmail.com (Oleksii Vilchanskyi) Date: Wed, 29 Nov 2017 04:18:07 +0100 Subject: [CMake] CPack OS X bundle : generator expression for CPACK_BUNDLE_STARTUP_COMMAND In-Reply-To: References: Message-ID: <56ac10e4-245a-5645-c146-2036d5752e4e@gmail.com> Hi, `set()` is evaluated at configuration time and as of CMake 3.10 does not accept genexps. You can refer to this diagram for better understanding of the general CMake pipeline: Therefore, > SET ( APP_LOCATION "$" ) > SET ( CPACK_BUNDLE_STARTUP_COMMAND ${APP_LOCATION} ) is interpreted exactly how it's written: > CPack Error: Error copying $ to... Due to this limitation your [probably] sole option to introduce genxps in CPack config would be to use `file(GENERATE)`. Otherwise, use single-configuration generators and you won't have configuration-dependent paths. On 29.11.2017 01:50, Nicholas Yue wrote: > I am using CMake 3.10 > > I can't seems to find a way to tell the OS X bundle where to find the > compiled binary. > > I get the following errors: > > Run CPack packaging tool... > CPack: Create package using Bundle > CPack: Install projects > CPack: - Run preinstall target for: OSXBundle > CPack: - Install project: OSXBundle > CPack: Create package > CPack Error: Error copying $ to > /Users/nicholas/projects/OSX_BundleRPath/build/_CPack_Packages/Darwin/Bundle/OSXBundle-0.1.1-Darwin/MyApp.app/Contents/MacOS/MyApp > CPack Error: Error copying startup command.? Check the value of > CPACK_BUNDLE_STARTUP_COMMAND. > CPack Error: Problem compressing the directory > CPack Error: Error when generating package: OSXBundle > make: *** [package] Error 1 > > > I have the following CMakeLists.txt: > > CMAKE_MINIMUM_REQUIRED(VERSION 3.8) > > PROJECT (OSXBundle) > > FIND_PACKAGE (Boost REQUIRED) > > ADD_EXECUTABLE (myapp > ? src/main.cpp > ? ) > > INSTALL ( TARGETS > ? myapp > ? DESTINATION > ? ./bin > ? ) > > IF (APPLE) > ? # GET_TARGET_PROPERTY ( APP_LOCATION myapp LOCATION ) > ? SET ( APP_LOCATION "$" ) > ?? > ? SET ( CPACK_BUNDLE_NAME "MyApp" ) > ?? > ? SET ( CPACK_GENERATOR "Bundle" ) > ? SET ( CPACK_BUNDLE_PLIST > ${CMAKE_CURRENT_SOURCE_DIR}/resources/Info.plist ) > ? SET ( CPACK_BUNDLE_ICON ${CMAKE_CURRENT_SOURCE_DIR}/resources/MyApp.icns ) > ? SET ( CPACK_PACKAGE_ICON > ${CMAKE_CURRENT_SOURCE_DIR}/resources/MyApp.icns ) > ? SET ( CPACK_BUNDLE_STARTUP_COMMAND ${APP_LOCATION} ) > ENDIF () > > INCLUDE ( CPack ) > > > -- Regards, Oleksii Vilchanskyi PGP:0x8D3A0E046BDE941F2A53867CE3FD952D48C0B338 *** All the world's a pipeline, And all the men and women merely instructions. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From ramya.gopalkrishna at accoliteindia.com Wed Nov 29 01:32:03 2017 From: ramya.gopalkrishna at accoliteindia.com (ramya.gopalkrishna at accoliteindia.com) Date: Wed, 29 Nov 2017 12:02:03 +0530 Subject: [CMake] CMAKE custom compiler for Android Message-ID: <02cc01d368db$c6fa5f20$54ef1d60$@accoliteindia.com> HI All, We are working towards creating a toolchain file for an ANDROID compiler We understand that the flow in CMAKE, when CMAKE_SYSTEM_NAME is specified in Android is different when compared to specifying CMAKE_SYSTEM_NAME as IOS or LINUX Please validate our current understanding when a toolchain file or command-line option sets CMAKE_SYSTEM_NAME to "Android" * CMakeDetermineSystem.cmake loads this file: Android-Determine.cmake * Next is the platform-specific initialization step: CMakeSystemSpecificInitialize.cmake which loads Android-Initialize.cmake to select the sysroot. * A "determine" step also runs for each language when it is first enabled in a new build tree: Android-Determine-C.cmake Android-Determine-CXX.cmake * The language files go here: Determine-Compiler.cmake Determine-Compiler-NDK.cmake * The latter file is where we parse a bunch of information from the NDK. The results persist in CMakeFiles/$v/CMake${lang}Compiler.cmake for future runs. Next is the language-specific initialization step. For Example - in case {lang} is C : CMakeCInformation.cmake That loads one of these: Android-GNU-C.cmake Android-Clang-C.cmake which loads one of these: Android-GNU.cmake Android-Clang.cmake Determine-Compiler-NDK.cmake is where cmake looks for versions of clang or gcc or llvm toolchains and sets the appropriate compiler. Our Requirement and Problem statement When we tried manually setting a c and cxx compiler from a toolchain file, cmake would not allow us to point to our own compilers. Ideally, we want our toolchain file to tell cmake the libraries to include/link and the compilers to use. But once, System has been determined as android, cmake goes through the above sequence of events and expects toolchains to be specified for either clang, gcc or llvm compilers. We would probably need to make changes in the following files to accommodate cmake to use our own compilers. Determine-Compiler-NDK.cmake - We would need to add support for an "NewCompiler Toolchain" which would contain android libraries and compilers. New Android-{NewCompiler}-C.cmake, Android-{ NewCompiler }-CXX.cmake, Android-{ NewCompiler }.cmake and another appropriate toolchain file to set target architecture and compiler flags. Can you please provide your suggestions and validate the understanding as well Thanks & Regards, Ramya -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.zarl-zierl at jku.at Wed Nov 29 06:02:01 2017 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Wed, 29 Nov 2017 12:02:01 +0100 Subject: [CMake] Using find_package() portably? In-Reply-To: References: <015f1e5c-ffae-d96d-1dd3-8ca0b8939698@cafu.de> <5662152.4nPEXIznPt@ersa> Message-ID: <3171356.xi6d4M9i8k@ersa> Hello Carsten, On Samstag, 25. November 2017 11:46:44 CET Carsten Fuchs wrote: > Thanks for your reply, but how can I proceed from here? > > In order to be able to write in the parent script something that works > in either case, that is, > > target_link_libraries(main_program ) Well, that's one way, but that doesn't really provide any benefit above the original solution (i.e. just define the JPEG_INCLUDES and JPEG_LIBRARIES variables accordingly). > it seems that I either > > - have to make a copy of FindJPEG.cmake, customize it to define > target JPEG::JEPG and ship it along with my project, Either that or you define it yourself: find_package(JPEG) if (JPEG_FOUND) add_library(JPEG::JPEG UNKNOWN IMPORTED) set_property( TARGET JPEG::JPEG PROPERTY IMPORTED_LOCATION ${JPEG_LIBRARIES} ) set_property( TARGET JPEG::JPEG PROPERTY INTERFACE_INCLUDE_DIRECTORIES ${JPEG_INCLUDES} ) endif() I admit it's not a huge benefit over just using the variables. The advantages: - you get slightly better error handling - your target_link_libraries commands are slightly more readable. > - or write my `../ExtLibs/libjpeg/CMakeLists.txt` so that it globally > defines JPEG_LIBRARIES and JPEG_INCLUDE_DIRS That will work, too. Cheers, Johannes From davidklind at gmail.com Wed Nov 29 11:07:58 2017 From: davidklind at gmail.com (DKLind) Date: Wed, 29 Nov 2017 09:07:58 -0700 (MST) Subject: [CMake] CPack: Create debian packge for each sub-project In-Reply-To: <1500681322140-7595889.post@n2.nabble.com> References: <1500681322140-7595889.post@n2.nabble.com> Message-ID: <1511971678430-0.post@n2.nabble.com> I have finally found time to work on a patch so CPACK_DEBAIN__PACKAGE_VERSION is recognized. I am amazed how simple the fix actually is. I plan on submitting a formal patch soon for Debian and RPM. I don't know anything about other CMake packaging features that might benefit from this patch. -- Sent from: http://cmake.3232098.n2.nabble.com/ From kgt at lanl.gov Wed Nov 29 11:45:31 2017 From: kgt at lanl.gov (Thompson, KT) Date: Wed, 29 Nov 2017 16:45:31 +0000 Subject: [CMake] CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE Message-ID: <7c801a5a8de94bd6b2c0640223bbb54d@EXG13-P-MBX09.win.lanl.gov> Hi, I'm trying to limit the amount of data that is uploaded to my CDash server by setting set( CTEST_CUSTOM_MAXIMUM_NUMBER_OF_WARNINGS "30" ) set( CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE "1024" ) # bytes (1 kB) set( CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE "1024" ) # bytes (1 kB) in my projects's CTestCustom.cmake (this file exists in my project source directory and is copied to the top level build tree). But this seems to have no effect. The documentation for these variables is very sparse so I would appreciate any links to discussions or examples about how to use these variables. Thank you! -kt -------------- next part -------------- An HTML attachment was scrubbed... URL: From florent.castelli at gmail.com Wed Nov 29 15:17:10 2017 From: florent.castelli at gmail.com (Florent Castelli) Date: Wed, 29 Nov 2017 21:17:10 +0100 Subject: [CMake] Using find_package() portably? In-Reply-To: <3171356.xi6d4M9i8k@ersa> References: <015f1e5c-ffae-d96d-1dd3-8ca0b8939698@cafu.de> <5662152.4nPEXIznPt@ersa> <3171356.xi6d4M9i8k@ersa> Message-ID: On 29/11/2017 12:02, Johannes Zarl-Zierl wrote: > Hello Carsten, > > On Samstag, 25. November 2017 11:46:44 CET Carsten Fuchs wrote: >> Thanks for your reply, but how can I proceed from here? >> >> In order to be able to write in the parent script something that works >> in either case, that is, >> >> target_link_libraries(main_program ) > Well, that's one way, but that doesn't really provide any benefit above the > original solution (i.e. just define the JPEG_INCLUDES and JPEG_LIBRARIES > variables accordingly). > >> it seems that I either >> >> - have to make a copy of FindJPEG.cmake, customize it to define >> target JPEG::JEPG and ship it along with my project, > Either that or you define it yourself: > find_package(JPEG) > if (JPEG_FOUND) I'd say "if(JPEG_FOUND AND NOT TARGET JPEG::JPEG)" If someone improves FindJPEG.cmake, you won't break your build. > add_library(JPEG::JPEG UNKNOWN IMPORTED) > set_property( > TARGET JPEG::JPEG > PROPERTY IMPORTED_LOCATION ${JPEG_LIBRARIES} > ) > set_property( > TARGET JPEG::JPEG PROPERTY > INTERFACE_INCLUDE_DIRECTORIES ${JPEG_INCLUDES} > ) > endif() > > I admit it's not a huge benefit over just using the variables. The advantages: > - you get slightly better error handling > - your target_link_libraries commands are slightly more readable. > >> - or write my `../ExtLibs/libjpeg/CMakeLists.txt` so that it globally >> defines JPEG_LIBRARIES and JPEG_INCLUDE_DIRS > That will work, too. > > > Cheers, > Johannes > From bill.hoffman at kitware.com Thu Nov 30 13:07:06 2017 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 30 Nov 2017 13:07:06 -0500 Subject: [CMake] FortranCInterface not working with 3.9.0 with Intel 2015 In-Reply-To: References: Message-ID: On 11/26/2017 6:29 PM, JR Cary wrote: > Works with 3.8.2. > Does it work with 3.10? Also, look in the CMakeFiles/CMakeError.log file to find out why this happened: - Detecting Fortran/C Interface - Failed to compile. -Bill From domen.vrankar at gmail.com Thu Nov 30 19:15:31 2017 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Fri, 1 Dec 2017 01:15:31 +0100 Subject: [CMake] CPack: Create debian packge for each sub-project In-Reply-To: <1511971678430-0.post@n2.nabble.com> References: <1500681322140-7595889.post@n2.nabble.com> <1511971678430-0.post@n2.nabble.com> Message-ID: 2017-11-29 17:07 GMT+01:00 DKLind : > I have finally found time to work on a patch so > CPACK_DEBAIN__PACKAGE_VERSION is recognized. I am amazed how > simple the fix actually is. > > I plan on submitting a formal patch soon for Debian and RPM. I don't know > anything about other CMake packaging features that might benefit from this > patch. > Hi, I've also been working on a bit larger feature extension that would possibly be of interest to you: https://gitlab.kitware.com/cmake/cmake/merge_requests/1545 I haven't decided on implementing per component versioning since it makes no sense to version different components of the same release differently unless they are a separate project which requires more variable overrides and manual setting of components - ExternalProject seems a better alternative in such cases. Maybe your solution can convince me otherwise. Thanks, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Thu Nov 30 23:41:03 2017 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 1 Dec 2017 15:41:03 +1100 Subject: [CMake] CPack: Create debian packge for each sub-project In-Reply-To: References: <1500681322140-7595889.post@n2.nabble.com> <1511971678430-0.post@n2.nabble.com> Message-ID: On Fri, Dec 1, 2017 at 11:15 AM, Domen Vrankar wrote: > 2017-11-29 17:07 GMT+01:00 DKLind : > >> I have finally found time to work on a patch so >> CPACK_DEBAIN__PACKAGE_VERSION is recognized. I am amazed how >> simple the fix actually is. >> >> I plan on submitting a formal patch soon for Debian and RPM. I don't know >> anything about other CMake packaging features that might benefit from this >> patch. >> > > Hi, > > I've also been working on a bit larger feature extension that would > possibly be of interest to you: https://gitlab.kitware.com/ > cmake/cmake/merge_requests/1545 > > I haven't decided on implementing per component versioning since it makes > no sense to version different components of the same release differently > unless they are a separate project which requires more variable overrides > and manual setting of components - ExternalProject seems a better > alternative in such cases. Maybe your solution can convince me otherwise. > An example where per-component versions would be really useful is if you have one large build that produces multiple products (i.e. one git repo and one CMake build). You may want to be able to create a release package for each product, but if each product has its own distinct version number, then you currently can't quite do it with CMake for some package types. I have exactly this situation at work at the moment. In one project, I get away with it because the release packages are tar balls so I just provide a custom name that embeds the version number for each product using CPACK_ARCHIVE__FILE_NAME. But I have other projects which produce RPMs and for those I don't currently have a solution. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: