From zcsd2012 at gmail.com Fri Jul 1 02:58:25 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Thu, 30 Jun 2016 23:58:25 -0700 (MST) Subject: [CMake] How to assign specific c, c++, fortran compiler and does CMake support Intel C/C++/Fortran Compiler? Message-ID: <1467356305853-7593880.post@n2.nabble.com> Hi, all, First, thanks for review my email. There are two questions i faced now: 1. I faced problem to assign specific compiler in CMake, and i searched for a while then i found [ CC="Foo\gcc.exe" CXX="Foo\g++.exe" cmake . ] seem work. Now i use CMake in QtCreator, is there other way i can assign specific compiler? 2. The compiler i want to assign is Intel C/C++/Fortran Compiler, does CMake support it? I have found in CMake\share\cmake-3.2\Modules\Compiler there are [ Intel-C.cmake ] and [ Intel-CXX.cmake ], could you please tell me the function of them? Best regards, chao -- View this message in context: http://cmake.3232098.n2.nabble.com/How-to-assign-specific-c-c-fortran-compiler-and-does-CMake-support-Intel-C-C-Fortran-Compiler-tp7593880.html Sent from the CMake mailing list archive at Nabble.com. From zcsd2012 at gmail.com Fri Jul 1 03:04:03 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Fri, 1 Jul 2016 00:04:03 -0700 (MST) Subject: [CMake] [ANNOUNCE] CMake 3.6.0-rc4 now ready for testing! In-Reply-To: References: Message-ID: <1467356643293-7593881.post@n2.nabble.com> Thanks a lot for your hard working, thus we can benefit from cmake! :-)Best regard,chao Robert Maynard wrote > I am proud to announce the fourth CMake 3.6 release candidate.Sources and > binaries are available at: https://cmake.org/download/Documentation is > available at: https://cmake.org/cmake/help/v3.6Release notes appear below > and are also published at > https://cmake.org/cmake/help/v3.6/release/3.6.htmlSome of the more > significant features of CMake 3.6 are:* The "Visual Studio 14 2015" > generator learned to support the Clang/C2 toolsets, e.g. with the "-T > v140_clang_3_7" option. This feature is experimental.* The "list()" > command gained a "FILTER" sub-command to filter list elements by regular > expression.* A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to > optionally tell the "try_compile()" command to build a static library > instead of an executable. This is useful for cross-compiling toolchains > that cannot link binaries without custom flags or scripts.* A " > _CLANG_TIDY" target property and supporting "CMAKE_ > _CLANG_TIDY" variable were introduced to tell the Makefile Generators and > the "Ninja" generator to run "clang-tidy" along with the compiler for "C" > and "CXX" languages.* The "ExternalProject" module leared the "GIT_SHALLOW > 1" option to perform a shallow clone of a Git repository.* The > "ExternalProject" module learned to initialize Git submodules recursively > and also to initialize new submodules on updates. Use the > "GIT_SUBMODULES" option to restrict which submodules are initalized and > updated.* The "InstallRequiredSystemLibraries" module learned a new > "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of > the Windows Universal CRT libraries with Visual Studio 2015.* The "Compile > Features" functionality is now aware of features supported by Intel C++ > compilers versions 12.1 through 16.0 on UNIX platforms.Deprecated and > Removed Features===============================* The "CMakeForceCompiler" > module and its macros are now deprecated. See module documentation for an > explanation.* The "Visual Studio 7 .NET 2003" generator is now deprecated > and will be removed in a future version of CMake.* The "Visual Studio 7" > generator (for VS .NET 2002) has been removed. It had been deprecated > since CMake 3.3.* The "Visual Studio 6" generator has been removed. It had > been deprecated since CMake 3.3.CMake 3.6 Release > Notes***********************Changes made since CMake 3.5 include the > following.New Features============Generators----------* The "Ninja" > generator learned to produce phony targets of the form "sub/dir/all" to > drive the build of a subdirectory. This is equivalent to "cd sub/dir; > make all" with Makefile Generators.* The "Ninja" generator now includes > system header files in build dependencies to ensure correct re-builds > when system packages are updated.* The "Visual Studio 14 2015" generator > learned to support the Clang/C2 toolsets, e.g. with the "-T > v140_clang_3_7" option. This feature is experimental.Commands--------* > The "add_custom_command()" and "add_custom_target()" commands learned how > to use the "CROSSCOMPILING_EMULATOR" executable target property.* The > "install()" command learned a new "EXCLUDE_FROM_ALL" option to leave > installation rules out of the default installation.* The "list()" command > gained a "FILTER" sub-command to filter list elements by regular > expression.* The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained > support for the "%s" placeholder. This is the number of seconds since > the UNIX Epoch.Variables---------* A "CMAKE_DEPENDS_IN_PROJECT_ONLY" > variable was introduced to tell Makefile Generators to limit dependency > scanning only to files in the project source and build trees.* A new > "CMAKE_HOST_SOLARIS" variable was introduced to indicate when CMake is > running on an Oracle Solaris host.* A "CMAKE_ > _STANDARD_INCLUDE_DIRECTORIES" variable was added for use by toolchain > files to specify system include directories to be appended to all > compiler command lines.* The "CMAKE_ > _STANDARD_LIBRARIES" variable is now documented. It is intended for use > by toolchain files to specify system libraries to be added to all linker > command lines.* A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced > to tell the "Ninja" generator to configure the generated "build.ninja" > file for use as a "subninja".* A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" > variable was added for use by toolchain files to specify > platform-specific variables that must be propagated by the > "try_compile()" command into test projects.* A > "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the > "try_compile()" command to build a static library instead of an > executable. This is useful for cross-compiling toolchains that cannot > link binaries without custom flags or scripts.Properties----------* A > "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to tell the > "Visual Studio 9 2008" and "Visual Studio 8 2005" generators to generate > the "remote directory" for WinCE project deployment and debugger > settings.* A " > _CLANG_TIDY" target property and supporting "CMAKE_ > _CLANG_TIDY" variable were introduced to tell the Makefile Generators and > the "Ninja" generator to run "clang-tidy" along with the compiler for "C" > and "CXX" languages.* A "TIMEOUT_AFTER_MATCH" test property was introduced > to optionally tell CTest to enforce a secondary timeout after matching > certain output from a test.* A "VS_CONFIGURATION_TYPE" target property > was introduced to specify a custom project file type for Visual Studio > Generators supporting VS 2010 and above.* A "VS_STARTUP_PROJECT" > directory property was introduced to specify for Visual Studio Generators > the default startup project for generated solutions (".sln" > files).Modules-------* The "CMakePushCheckState" module now > pushes/pops/resets the variable "CMAKE_EXTRA_INCLUDE_FILE" used in > "CheckTypeSize".* The "ExternalProject" module leared the "GIT_SHALLOW 1" > option to perform a shallow clone of a Git repository.* The > "ExternalProject" module learned to initialize Git submodules recursively > and also to initialize new submodules on updates. Use the > "GIT_SUBMODULES" option to restrict which submodules are initalized and > updated.* The "ExternalProject" module leared the "DOWNLOAD_NO_EXTRACT 1" > argument to skip extracting the file that is downloaded (e.g., for > self-extracting shell installers or ".msi" files).* The "ExternalProject" > module now uses "TLS_VERIFY" when fetching from git repositories.* The > "FindBLAS" and "FindLAPACK" modules learned to support OpenBLAS.* The > "FindCUDA" module learned to find the "cublas_device" library.* The > "FindGTest" module "gtest_add_tests" function now causes CMake to > automatically re-run when test sources change so that they can be > re-scanned.* The "FindLTTngUST" module was introduced to find the > LTTng-UST library.* The "FindPkgConfig" module learned to optionally > create imported targets for the libraries it has found.* The > "FindProtobuf" module learned to provide a "Protobuf_VERSION" variable > and check the version number requested in a "find_package()" call.* The > "InstallRequiredSystemLibraries" module learned a new > "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of > the Windows Universal CRT libraries with Visual Studio > 2015.Platforms---------* The Clang compiler is now supported on CYGWIN.* > Support was added for the Bruce C Compiler with compiler id > "Bruce".CTest-----* The "ctest_update()" command now looks at the > "CTEST_GIT_INIT_SUBMODULES" variable to determine whether submodules > should be updated or not before updating.* The "ctest_update()" command > will now synchronize submodules on an update. Updates which add > submodules or change a submodule's URL will now be pulled > properly.CPack-----* The "CPackDeb" module learned how to handle "$ORIGIN" > in "CMAKE_INSTALL_RPATH" when "CPACK_DEBIAN_PACKAGE_SHLIBDEPS" is used > for dependency auto detection.* The "CPackDeb" module learned how to > generate "DEBIAN/shlibs" contorl file when package contains shared > libraries.* The "CPackDeb" module learned how to generate > "DEBIAN/postinst" and "DEBIAN/postrm" files if the package installs > libraries in ldconfig- controlled locations (e.g. "/lib/", "/usr/lib/").* > The "CPackDeb" module learned how to generate dependencies between Debian > packages if multi-component setup is used and "CPACK_COMPONENT_ > _DEPENDS" variables are set. For backward compatibility this feature is > disabled by default. See "CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS".* The > "CPackDeb" module learned how to set custom package file names including > how to generate properly-named Debian packages: > _ > - > _ > .deb For backward compatibility this feature is disabled by default. See > "CPACK_DEBIAN_FILE_NAME" and "CPACK_DEBIAN_ > _FILE_NAME".* The "CPackDeb" module learned how to set the package release > number ("DebianRevisionNumber" in package file name when used in > combination with "DEB-DEFAULT" value set by "CPACK_DEBIAN_FILE_NAME"). > See "CPACK_DEBIAN_PACKAGE_RELEASE".* The "CPackDeb" module learned how to > set the package architecture per-component. See "CPACK_DEBIAN_ > _PACKAGE_ARCHITECTURE".* The "CPackDMG" module learned a new option to > tell the CPack "DragNDrop" generaor to skip the "/Applications" symlink. > See the "CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK" variable.* The > "CPackIFW" module gained a new "cpack_ifw_update_repository()" command to > update a QtIFW-specific repository from a remote repository.* The > "CPackRPM" module learned how to set RPM "dist" tag as part of RPM > "Release:" tag when enabled (mandatory on some Linux distributions for > e.g. on Fedora). See "CPACK_RPM_PACKAGE_RELEASE_DIST".* The "CPackRPM" > module learned how to set default values for owning user/group and > file/directory permissions of package content. See > "CPACK_RPM_DEFAULT_USER", "CPACK_RPM_DEFAULT_GROUP", > "CPACK_RPM_DEFAULT_FILE_PERMISSIONS", "CPACK_RPM_DEFAULT_DIR_PERMISSIONS" > and their per component counterparts.* The "CPackRPM" module learned how > to set user defined package file names, how to specify that rpmbuild > should decide on file name format as well as handling of multiple rpm > packages generated by a single user defined spec file. See > "CPACK_RPM_PACKAGE_NAME" and "CPACK_RPM_ > _PACKAGE_NAME".* The "CPackRPM" module learned how to correctly handle > symlinks that are pointing outside generated packages.Other-----* The > "Compile Features" functionality is now aware of features supported by > Intel C++ compilers versions 12.1 through 16.0 on UNIX > platforms.Deprecated and Removed Features===============================* > The "CMakeForceCompiler" module and its macros are now deprecated. See > module documentation for an explanation.* The "find_library()", > "find_path()", and "find_file()" commands no longer search in > installation prefixes derived from the "PATH" environment variable on > non-Windows platforms. This behavior was added in CMake 3.3 to support > Windows hosts but has proven problematic on UNIX hosts. Users that keep > some " > /bin" directories in the "PATH" just for their tools do not necessarily > want any supporting " > /lib" directories searched. One may set the "CMAKE_PREFIX_PATH" > environment variable with a ;-list of prefixes that are to be searched.* > The "Visual Studio 7 .NET 2003" generator is now deprecated and will be > removed in a future version of CMake.* The "Visual Studio 7" generator > (for VS .NET 2002) has been removed. It had been deprecated since CMake > 3.3.* The "Visual Studio 6" generator has been removed. It had been > deprecated since CMake 3.3.Other Changes=============* The precompiled OS > X binary provided on "cmake.org" now requires OS X 10.7 or newer.* On > Linux and FreeBSD platforms, when building CMake itself from source and > not using a system-provided libcurl, OpenSSL is now used by default if it > is found on the system. This enables SSL/TLS support for commands > supporting network communication via "https", such as "file(DOWNLOAD)", > "file(UPLOAD)", and "ctest_submit()".* The "cmake(1)" "--build" > command-line tool now rejects multiple "-- target" options with an error > instead of silently ignoring all but the last one.* "AUTOMOC" now > diagnoses name collisions when multiple source files in different > directories use "#include > " with the same name (because the generated "moc_foo.cpp" files would > collide).* The "FindBISON" module "BISON_TARGET" macro now supports > special characters by passing the "VERBATIM" option to internal > "add_custom_command()" calls. This may break clients that added escaping > manually to work around the bug.* The "FindFLEX" module "FLEX_TARGET" > macro now supports special characters by passing the "VERBATIM" option to > internal "add_custom_command()" calls. This may break clients that added > escaping manually to work around the bug.* The "FindProtobuf" module input > and output variables were all renamed from "PROTOBUF_" to "Protobuf_" for > consistency with other find modules. Input variables of the old case will > be honored if provided, and output variables of the old case are always > provided.* The "CPackRPM" module now supports upper cased component names > in per component CPackRPM specific variables. E.g. component named "foo" > now expects component specific variable to be > "CPACK_RPM_FOO_PACKAGE_NAME" while before it expected > "CPACK_RPM_foo_PACKAGE_NAME". Upper cased component name part in > variables is compatible with convention used for other CPack variables. > For back compatibility old format of variables is still valid and > preferred if both versions of variable are set, but the preferred future > use is upper cased component names in variables. New variables that will > be added to CPackRPM in later versions will only support upper cased > component variable > format.----------------------------------------------------------------------------Changes > made since CMake 3.6.0-rc3:Bartosz Kosiorek (1): Help: Describe > VERSION and SOVERSION meanings for Mach-O binariesBen Boeckel (1): > ninja, rc: ignore CMAKE_NINJA_FORCE_RESPONSE_FILE for RC filesBrad King > (2): Revert "try_compile: Honor CMAKE_ > _FLAGS_ > changes" CMake 3.6.0-rc4Gregor Jasny (1): Help: Cross reference > CXX_STANDARD and CXX_EXTENSIONS (#16162)Robert Maynard (5): FindHDF5: > correctly add lang to each component target name. FindHDF5: Handle > HDF5 builds with non-suffixed components FindHDF5: When component > targets not found fallback to compiler wrappers FindHDF5: cache the > correct path to the high level libraries FindHDF5: create all the > *_LIBRARIES when using hdf5-config.cmakeRolf Eike Beer (1): > GetPrerequisites: fix typo in comment-- Powered by www.kitware.comPlease > keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQKitware offers various services to > support the CMake community. For more information on each offering, please > visit:CMake Support: http://cmake.org/cmake/help/support.htmlCMake > Consulting: http://cmake.org/cmake/help/consulting.htmlCMake Training > Courses: http://cmake.org/cmake/help/training.htmlVisit other Kitware > open-source projects at > http://www.kitware.com/opensource/opensource.htmlFollow this link to > subscribe/unsubscribe:http://public.kitware.com/mailman/listinfo/cmake -- View this message in context: http://cmake.3232098.n2.nabble.com/ANNOUNCE-CMake-3-6-0-rc4-now-ready-for-testing-tp7593862p7593881.html Sent from the CMake mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Fri Jul 1 04:06:11 2016 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Fri, 01 Jul 2016 08:06:11 +0000 Subject: [CMake] CMake 3.6.0-rc4 now ready for testing! In-Reply-To: <57751C8F.6030602@kitware.com> References: <1548229B-0D2D-4F7D-8AE9-BFE9E993D54A@hendrik-sattler.de> <57751C8F.6030602@kitware.com> Message-ID: <20160701080611.Horde.78eAeXB-Yge_tL7lZ5aW8Ub@mail.hendrik-sattler.de> Zitat von Brad King : > On 06/29/2016 05:05 PM, Hendrik Sattler wrote: >>> * The "InstallRequiredSystemLibraries" module learned a new >>> "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment >>> of the Windows Universal CRT libraries with Visual Studio 2015. >> >> Maybe the help should note that this is only needed when targeting >> WindowsXP. > > It is also useful for deploying to Windows 7 machines that have > not had updates installed to provide the UCRT libraries. I've > updated the documentation to show Windows XP as an example: > > InstallRequiredSystemLibraries: Document UCRT option use case > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dab3ccf2 Thanks. >>> * A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for >>> use by toolchain files to specify platform-specific variables that >>> must be propagated by the "try_compile()" command into test >>> projects. >> >> Can someone please add an example to the help. > > Done: > > Help: Document CMAKE_TRY_COMPILE_PLATFORM_VARIABLES example > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c05d240e > >> E.g. I tried to make the initial try_compile() to respect my >> CMAKE_CXX_FLAGS_INIT variable that gets defined in my toolchain file... > > CMAKE_CXX_FLAGS_INIT is not documented for use in a toolchain file. > It is used internally by platform modules. > >> I really have to use CXXFLAGS environment variable which feels clumsy. >> It's that really the only reliable way to define compiler arguments >> like -mcpu= for all compiler invocations? > > It is one way. Another way is to set the cache entry directly: > > set(CMAKE_CXX_FLAGS "-mcpu=..." CACHE STRING "C++ flags") > > Note that CMAKE_CXX_FLAGS is propagated by try_compile automatically. > The above two approaches are actually just trying to get a toolchain > file to have a say in the initial CMAKE_CXX_FLAGS cache entry value > of the main project. The the following code in CMakeCXXInformation.cmake does nothing --------------------snip-------------------- # add the flags to the cache based # on the initial values computed in the platform/*.cmake files # use _INIT variables so that this only happens the first time # and you can set these flags in the cmake cache set(CMAKE_CXX_FLAGS_INIT "$ENV{CXXFLAGS} ${CMAKE_CXX_FLAGS_INIT}") # avoid just having a space as the initial value for the cache if(CMAKE_CXX_FLAGS_INIT STREQUAL " ") set(CMAKE_CXX_FLAGS_INIT) endif() set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS_INIT}" CACHE STRING "Flags used by the compiler during all build types.") --------------------snip-------------------- So each and every toolchain file shall also take care of the environment variable? How about CMAKE_CXX_FLAGS_INIT set by other module files? Ok, only 3 real users in CMake's module folder. And VERY IMPORTANT: the toolchain file MUST make those variables CACHE variables, else it will not work (at least CMAKE_CXX_FLAGS is only propagated, then). Thanks... Hendrik From mario.werner at iaik.tugraz.at Fri Jul 1 08:30:19 2016 From: mario.werner at iaik.tugraz.at (Mario Werner) Date: Fri, 1 Jul 2016 14:30:19 +0200 Subject: [CMake] ctest: how to include pre- and post- processing commands In-Reply-To: <00ea01d1d2cc$1d68bde0$583a39a0$@gmail.com> References: <00ea01d1d2cc$1d68bde0$583a39a0$@gmail.com> Message-ID: Hi Ted, On 2016-06-30 14:37, TS wrote: > [snip] > Is it possible to have a ctest which involves preprocessing as well as > postprocessing. The code to test is myCode.exe, which writes an output file. > PASS or FAIL is the result of comparison of output against reference data. AFAIK, there is currently no direct language support for this in cmake/ctest. However, you can achieve the desired result by using a custom script which does the preprocessing, the target execution, and the postprocessing. I attached you an example for such a "wrapper" cmake script, which I once used for direct file comparison. I presume that your comparison is slightly different but it should get you started. The `add_test` looks then something like that: ``` add_test(NAME test COMMAND ${CMAKE_COMMAND} -D "PROGRAM:STRING=$;infile;outfile" -D "PRE_DELETE_OUTPUT_FILES:BOOL=true" -D "REFERENCE_FILES:STRING=reffile" -D "OUTPUT_FILES:STRING=outfile" -P "${CMAKE_SOURCE_DIR}/path-to-script/run_and_compare.cmake" ) ``` > [snip] > but because rm is not build by cmake, it complains that cannot find it. > > Kind of unrelated to your original question but you can use either `file(REMOVE ...)` within a cmake script, or call `cmake -E remove ...` to delete files in a platform independent way. Regards, Mario -------------- next part -------------- A non-text attachment was scrubbed... Name: run_and_compare.cmake Type: text/x-cmake Size: 2487 bytes Desc: not available URL: From ruslan_baratov at yahoo.com Fri Jul 1 08:54:08 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 1 Jul 2016 15:54:08 +0300 Subject: [CMake] How do you handle recursive dependencies in CMake In-Reply-To: <57751814.2080501@rug.nl> References: <5774DF8A.3070107@rug.nl> <57751814.2080501@rug.nl> Message-ID: Hi, On 30-Jun-16 16:01, Sven Baars wrote: > I don't think this is a solution to the problem, since then it seems > like the build will still fail for all our users unless they also build > all their packages from inside hunter. What do you mean by "from inside hunter"? Users have to add 'hunter_add_package(YourProject)' + 'find_package(YourProject CONFIG REQUIRED)' this is true. You want to avoid that? > If I wanted it to work just for > myself I could just use hardcoded paths. The problem is that I want a > portable way such that users can build my projects without losing > dependency information. Hunter will download all dependencies automatically. YourProjectConfig.cmake should contain all dependencies too so 'find_package(YourProject CONFIG REQUIRED)' is enough. > In the current situation they are forced to > copy-paste all of my CMakeLists.txt files and add their own stuff to > that. At least if I follow the guides on the wiki/the advice that I got > so far. That is, unless I misunderstand something, which I hope I do, > but no one pointed that out yet. > > Sven Ruslo > > On 06/30/2016 02:41 PM, Nicholas Braden wrote: >> If find_project is not enough, and ExternalProject's only problem is >> build duplication, then I think it makes sense to consider a >> CMake-based dependency manager such as hunter: >> https://github.com/ruslo/hunter >> >> >> On Thu, Jun 30, 2016 at 3:59 AM, Sven Baars wrote: >>> This is a reply to the options that Ray gave. Here I will use the >>> package dependencies C -> B -> A{1,2}: >>> >>> 1) The "ad-hoc" method I first mentioned by setting >>> CMAKE_LIBRARY_OUTPUT_DIRECTORY. >>> >>> As far as I understand, this would mean that every user of all of the >>> different projects would have to be forced to use this, and would not be >>> allowed to "install" anything anywhere else, which doesn't seem nice. >>> >>> 2) ExternalProject which will grab a repository and build it. >>> >>> This will not work. One of the projects I use is Trilinos, which has >>> build of around 1GB. I don't want to pull and build that for every >>> project I have. Also the build flags that are used sometimes differ per >>> machine, not per project, so it would be nice if I could build it only >>> once per machine. >>> >>> Also, in a more generalized sense, this would also mean that every >>> project I pull with ExtenalProject should also pull its own dependencies >>> with ExternalProject. So then if every project on my system used CMake, >>> this would mean that I would recursively rebuild my entire system for >>> every project I have. This doesn't seem right. >>> >>> 3) Some Find_Package () mechanism that will do a search for it. >>> >>> The point I had is that we actually try to use this. However, the >>> find_package does not find all dependencies. And we don't know in >>> package C whether it depends on A1 or A2, because of build flags/CMake >>> checks that were used for project B. So we can't just do a find_package >>> for either A1 or A2, because we don't know which one was used unless we >>> perform all the CMake checks that were done in project B (in some cases >>> 10k+ lines of CMake code). >>> >>> 4) Your option of including *.cmake files that provide the paths >>> [sorry, I might have misunderstood it]. >>> >>> This, so far, is the only option, because then B can tell us that it >>> used A2, not A1. This can just be done by providing absolute paths to >>> the libraries that were used in the compilation of B. But we are looking >>> for a standardized way to do this. I'd prefer to not have a lot of >>> custom code in all of my libraries. >>> >>> Now some more information: >>> >>> On supercomputers it is very common that every library on the system is >>> installed in a different directory. This is so every user can load their >>> own version of the library without breaking the system for others. >>> Therefore, you will never find libraries that are installed in the >>> standard system directories where CMake looks for the libraries. By >>> using PATH you can make it able to find the place where to look for the >>> FoobarConfig.cmake files, which is great when you want to build project >>> B, and this is also done automatically on all supercomputers I work on, >>> but those config files do not contain information on where the actual >>> libraries of project A are when you build project C. I guess Cfyz and me >>> think they should in some standardized way. >>> >>> Sven >>> -- >>> >>> 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 Jul 1 09:09:20 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 1 Jul 2016 09:09:20 -0400 Subject: [CMake] CMAKE_C_COMPILE_OBJECT vs In-Reply-To: References: <14455837-B56D-48FE-AB20-82EEB82C4C69@eleveneng.com> Message-ID: Sorry I had misread that you where still having this problem with CMake 3.4, not that it had resolved your issue. On Thu, Jun 30, 2016 at 4:36 PM, Sam Cristall wrote: > Hi Robert, > > Yes, we are adding the Keil C8051 compiler, which is very old and uses a very unique command line syntax compared to the others supported by CMake. Also, it's Windows only but Wine works -- so we optionally add Wine on non-Windows platforms. An example would be: > > wine C51.exe INCDIR(/path/to/dir/1/, /path/to/dir/2/) DEBUG DEFINE(FOO_FLAG) OBJECT(/path/to/output.obj) /path/to/source.c > > To achieve this, we use a wrapper cmake script with the following: > > set(CMAKE_C_COMPILE_OBJECT > "cmake\ > -DWINE=${WINE}\ > -DCOMPILER=\ > -DSOURCE=\ > -DINCLUDES=\"\"\ > -DFLAGS=\" \"\ > -DOBJECT=\ > -P \"${CMAKE_CURRENT_LIST_DIR}/C8051Compile.cmake\"" > ) > > It was important that be separate, as its form is significantly different than most compilers. Prior to cmake 3.4, it would be very difficult to handle this, since would append the includes as a list of directories, and there is no CMAKE_INCLUDE_FLAG suffix variable (need a closing bracket for INCDIR). > > >> On Jun 30, 2016, at 2:23 PM, Robert Maynard wrote: >> >> Hi, >> >> Can you explain what the goal of your compilation wrappers are? Are >> you trying to add a new compiler? >> >> >> >> On Wed, Jun 29, 2016 at 1:41 PM, Sam Cristall wrote: >>> Looks like this was just a change in CMake 3.4. Updated to latest, and everything is working. >>>> On Jun 28, 2016, at 5:19 PM, Sam Cristall wrote: >>>> >>>> I'm trying to implement a cross compilation wrapper and hit a snag with CMAKE_C_COMPILE_OBJECT. I've found that on OSX / Linux (Makefile Generator), and work as expected, however on Windows (MinGW Makefile Generator), has both the flags and includes, whereas is undefined. Is this expected? >>>> >>> -- >>> >>> 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 wambach at rohmann.de Fri Jul 1 12:02:38 2016 From: wambach at rohmann.de (Wambach, Florian [Rohmann GmbH]) Date: Fri, 1 Jul 2016 16:02:38 +0000 Subject: [CMake] QT5 i18n with cmake / QT5_CREATE_TRANSLATION Message-ID: <0455CF7EE9D52949802DAA6B09AE0EF968D17252@ROHEX02.rohmann.de> // ---- tldr; QT5_CREATE_TRANSLATION calls lupdate with unwanted parameter @lst_file // ---- despite being quite new to cmake, I succeeded to create a new project including Qt5LinguistTools and a .ts file containing my translations. For convenient string-update and qm-compilation, I added a section into my cmake file to call lupdate and lrelease on my file(s) using the defined macro QT5_CREATE_TRANSLATION. It actually calls lupdate, with my ts-file and my other given options, but always also including the additional parameter @/_lst_file (to tell lupdate additional source directories). I assumed my source directory as content, but surprisingly it contains all Include paths used in the project: E.g., as I also use boost library, my boost_dir is also included. This seems very strange to me. I analyzed the macro, where the lst_file is being created, so for me it seems as a bug in the cmake macro. Can I disable this lst_file anyhow -- without touching the macro from qt? Kind regards, F. Wambach, DE From andrey.fedorov at gmail.com Fri Jul 1 15:30:54 2016 From: andrey.fedorov at gmail.com (Andrey Fedorov) Date: Fri, 1 Jul 2016 15:30:54 -0400 Subject: [CMake] Error: cannot find DartConfiguration.tcl on windows Message-ID: Hi, I am doing continuous integration testing on appveyor, and I am getting this error: https://ci.appveyor.com/project/fedorov/dcmqi/build/0.0.145 [image: Inline image 1] For the same repository, testing is working just fine on travisci and appveyor. The versions of cmake are not identical, but the one on windows is 3.5, quite recent. The source code repository is here: http://github.com/qiicr/dcmqi Can someone help me with this error? Thank you AF -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 117793 bytes Desc: not available URL: From crestchristopher at gmail.com Sat Jul 2 00:39:36 2016 From: crestchristopher at gmail.com (Crest Christopher) Date: Sat, 02 Jul 2016 00:39:36 -0400 Subject: [CMake] Compiling binaries with cmake -- help In-Reply-To: References: <576B2D9F.7090400@gmail.com> <576B6632.7010706@gmail.com> <611F4C8C6DD445C6957D50BA73C22025@quad> <576B6BF4.6040806@gmail.com> <576B6F50.9030802@gmail.com> <576B71BA.1060804@gmail.com> Message-ID: <57774588.2030505@gmail.com> I have the dependencies installed but I'm still getting an error; that there is an error in the configuration files and that the project may be invalid ? > Nicholas Braden > Thursday, June 23, 2016 8:37 AM > Yep, if you have all the dependencies it should just work as I > described in a previous message. > > On Thu, Jun 23, 2016 at 12:20 AM, Crest Christopher > Crest Christopher > Thursday, June 23, 2016 1:20 AM > I'll get the Python sipconfig module installed, then I hope we can > continue with getting it compiled ? > > > Nicholas Braden > Thursday, June 23, 2016 1:15 AM > Yes, many projects do not include their dependencies and require you > to obtain them yourself. In this case it looks like you need the > Python sipconfig module installed. > > On Thu, Jun 23, 2016 at 12:10 AM, Crest Christopher > Crest Christopher > Thursday, June 23, 2016 1:10 AM > It can work, but it's missing dependencies ? > > > Nicholas Braden > Thursday, June 23, 2016 1:08 AM > It looks like the instructions are there in the README. I tried > building on my system but I'm missing some dependencies (e.g. at some > point it finds my Python 3 installation and tries to run some code but > fails due to a missing sipconfig module, which I am not familiar > with). > > Generally, to build a project that uses CMake, create an empty > directory for the build and open a terminal in it, then run CMake with > the path to the directory containing CMakeLists.txt and optionally > specify the generator to use if the default is not the one you want. > Then, if it completes without errors, you can use "cmake --build ." to > build it and "cmake --build . --target install" to install it, even if > you used an IDE generator. > > As for the project dependencies, you are own your own to get those. > > On Wed, Jun 22, 2016 at 11:56 PM, Crest Christopher -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikita.glukhov at gmail.com Sat Jul 2 05:07:04 2016 From: nikita.glukhov at gmail.com (Nikita Glukhov) Date: Sat, 2 Jul 2016 12:07:04 +0300 Subject: [CMake] Compiling binaries with cmake -- help In-Reply-To: <57774588.2030505@gmail.com> References: <576B2D9F.7090400@gmail.com> <576B6632.7010706@gmail.com> <611F4C8C6DD445C6957D50BA73C22025@quad> <576B6BF4.6040806@gmail.com> <576B6F50.9030802@gmail.com> <576B71BA.1060804@gmail.com> <57774588.2030505@gmail.com> Message-ID: Hi, Crest Christopher! I've never built SeExpr by himself, so I can not help here. But if your goal is simply to play around with SeExpr then you can download Natron: http://natron.fr/ which have built-in SeExpr node. Cheers, Nikita. 2016-07-02 7:39 GMT+03:00 Crest Christopher : > I have the dependencies installed but I'm still getting an error; that > there is an error in the configuration files and that the project may be > invalid ? > > Nicholas Braden > Thursday, June 23, 2016 8:37 AM > Yep, if you have all the dependencies it should just work as I > described in a previous message. > > On Thu, Jun 23, 2016 at 12:20 AM, Crest Christopher > Crest Christopher > Thursday, June 23, 2016 1:20 AM > I'll get the Python sipconfig module installed, then I hope we can > continue with getting it compiled ? > > > Nicholas Braden > Thursday, June 23, 2016 1:15 AM > Yes, many projects do not include their dependencies and require you > to obtain them yourself. In this case it looks like you need the > Python sipconfig module installed. > > On Thu, Jun 23, 2016 at 12:10 AM, Crest Christopher > Crest Christopher > Thursday, June 23, 2016 1:10 AM > It can work, but it's missing dependencies ? > > > Nicholas Braden > Thursday, June 23, 2016 1:08 AM > It looks like the instructions are there in the README. I tried > building on my system but I'm missing some dependencies (e.g. at some > point it finds my Python 3 installation and tries to run some code but > fails due to a missing sipconfig module, which I am not familiar > with). > > Generally, to build a project that uses CMake, create an empty > directory for the build and open a terminal in it, then run CMake with > the path to the directory containing CMakeLists.txt and optionally > specify the generator to use if the default is not the one you want. > Then, if it completes without errors, you can use "cmake --build ." to > build it and "cmake --build . --target install" to install it, even if > you used an IDE generator. > > As for the project dependencies, you are own your own to get those. > > On Wed, Jun 22, 2016 at 11:56 PM, Crest Christopher > > > > -- > > 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 crestchristopher at gmail.com Sat Jul 2 07:38:12 2016 From: crestchristopher at gmail.com (Crest Christopher) Date: Sat, 02 Jul 2016 07:38:12 -0400 Subject: [CMake] Compiling binaries with cmake -- help In-Reply-To: References: <576B2D9F.7090400@gmail.com> <576B6632.7010706@gmail.com> <611F4C8C6DD445C6957D50BA73C22025@quad> <576B6BF4.6040806@gmail.com> <576B6F50.9030802@gmail.com> <576B71BA.1060804@gmail.com> <57774588.2030505@gmail.com> Message-ID: <5777A7A4.1060802@gmail.com> Hi, thanks but I really want to compile it myself ;-) I hope someone can help ! Nikita Glukhov wrote: > > Hi, Crest Christopher! > > I've never built SeExpr by himself, so I can not help here. > But if your goal is simply to play around with SeExpr then you can > download Natron: > http://natron.fr/ > which have built-in SeExpr node. > > Cheers, > Nikita. > > 2016-07-02 7:39 GMT+03:00 Crest Christopher > >: > > I have the dependencies installed but I'm still getting an error; > that there is an error in the configuration files and that the > project may be invalid ? > >> >> Nicholas Braden >> Thursday, June 23, 2016 8:37 AM >> Yep, if you have all the dependencies it should just work as I >> described in a previous message. >> >> On Thu, Jun 23, 2016 at 12:20 AM, Crest Christopher >> Crest Christopher >> Thursday, June 23, 2016 1:20 AM >> I'll get the Python sipconfig module installed, then I hope we >> can continue with getting it compiled ? >> >> >> Nicholas Braden >> Thursday, June 23, 2016 1:15 AM >> Yes, many projects do not include their dependencies and require you >> to obtain them yourself. In this case it looks like you need the >> Python sipconfig module installed. >> >> On Thu, Jun 23, 2016 at 12:10 AM, Crest Christopher >> Crest Christopher >> Thursday, June 23, 2016 1:10 AM >> It can work, but it's missing dependencies ? >> >> >> Nicholas Braden >> Thursday, June 23, 2016 1:08 AM >> It looks like the instructions are there in the README. I tried >> building on my system but I'm missing some dependencies (e.g. at some >> point it finds my Python 3 installation and tries to run some >> code but >> fails due to a missing sipconfig module, which I am not familiar >> with). >> >> Generally, to build a project that uses CMake, create an empty >> directory for the build and open a terminal in it, then run CMake >> with >> the path to the directory containing CMakeLists.txt and optionally >> specify the generator to use if the default is not the one you want. >> Then, if it completes without errors, you can use "cmake --build >> ." to >> build it and "cmake --build . --target install" to install it, >> even if >> you used an IDE generator. >> >> As for the project dependencies, you are own your own to get those. >> >> On Wed, Jun 22, 2016 at 11:56 PM, Crest Christopher > > > > -- > > 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 Sun Jul 3 03:46:32 2016 From: rwan.work at gmail.com (Raymond Wan) Date: Sun, 3 Jul 2016 15:46:32 +0800 Subject: [CMake] Compiling binaries with cmake -- help In-Reply-To: <5777A7A4.1060802@gmail.com> References: <576B2D9F.7090400@gmail.com> <576B6632.7010706@gmail.com> <611F4C8C6DD445C6957D50BA73C22025@quad> <576B6BF4.6040806@gmail.com> <576B6F50.9030802@gmail.com> <576B71BA.1060804@gmail.com> <57774588.2030505@gmail.com> <5777A7A4.1060802@gmail.com> Message-ID: On Sat, Jul 2, 2016 at 7:38 PM, Crest Christopher wrote: > Hi, thanks but I really want to compile it myself ;-) I hope someone can > help ! To be honest, you really should contact the original developers for help with dependencies and compiling. Not only are they the experts with their own programs, but they also have an interest in having users being able to compile their programs. Likewise, if there is a bug in their program or even their instructions, I'm sure they would like to know (and hopefully update accordingly). This even includes "bugs" in their CMakeList.txt ... (If developers don't have such an interest, then I don't know why bother sharing code on GitHub. So, my *guess* is that they should be helpful if you contact them...but I could be wrong!) Ray From sambeet161616 at gmail.com Sun Jul 3 19:26:08 2016 From: sambeet161616 at gmail.com (Sambeet Panigrahi) Date: Mon, 4 Jul 2016 04:56:08 +0530 Subject: [CMake] Logical block opening error Message-ID: Hi, I am using Cmake to compile Orocos RTT. While building mqueue I encountered this error: CMake Error in rtt/transports/mqueue/CMakeLists.txt: A logical block opening on the line /home/sambeet/NewRockPort/x86/Build/rock/rtt/rtt/transports/mqueue/CMakeLists.txt:2 (IF) is not close I closed the brackets but still the error stays. The following is the code for this purpose: # this option was set in global_rules.cmake IF(ENABLE_MQ) MESSAGE( "Building MQueue Transport library (Requires Boost >= 1.37.0).") if (NOT Boost_SERIALIZATION_FOUND) MESSAGE(SEND_ERROR "Can't build MQueue transport without Boost Serialization. Please install serialiation or disable MQUEUE.") endif() FILE( GLOB CPPS Dispatcher.cpp MQSendRecv.cpp ) FILE( GLOB HPPS [^.]*.hpp [^.]*.h [^.]*.inl) #MESSAGE("CPPS: $ENV{GLOBAL_GENERATED_SRCS}") #MESSAGE("HPPS: ${HPPS}") GLOBAL_ADD_INCLUDE( rtt/transports/mqueue ${HPPS}) # Due to generation of some .h files in build directories, we also need to include some build dirs in our include paths. INCLUDE_DIRECTORIES(BEFORE ${PROJ_SOURCE_DIR} ${PROJ_SOURCE_DIR}/rtt ${PROJ_SOURCE_DIR}/rtt/os ${PROJ_SOURCE_DIR}/rtt/os/${OROCOS_TARGET} ) INCLUDE_DIRECTORIES(BEFORE ${PROJ_BINARY_DIR}/rtt ${PROJ_BINARY_DIR}/rtt/os ${PROJ_BINARY_DIR}/rtt/os/${OROCOS_TARGET} ) INCLUDE_DIRECTORIES(BEFORE ${PROJ_BINARY_DIR}/rtt/transports/mqueue ${MQ_INCLUDE_DIRS}) INCLUDE_DIRECTORIES(BEFORE ${PROJ_BINARY_DIR}/rtt/typekit ) # For rtt-typekit-config.h if(NOT MQ_LDFLAGS) set(MQ_LDFLAGS "") endif() IF ( BUILD_STATIC ) ADD_LIBRARY(orocos-rtt-mqueue-${OROCOS_TARGET}_static STATIC ${CPPS}) SET_TARGET_PROPERTIES( orocos-rtt-mqueue-${OROCOS_TARGET}_static PROPERTIES DEFINE_SYMBOL "RTT_MQ_DLL_EXPORT" OUTPUT_NAME orocos-rtt-mqueue-${OROCOS_TARGET} CLEAN_DIRECT_OUTPUT 1 VERSION "${RTT_VERSION}" LINK_FLAGS "${MQ_LDFLAGS} ${CMAKE_LD_FLAGS}" COMPILE_DEFINITIONS "${OROCOS-RTT_DEFINITIONS}") ENDIF( BUILD_STATIC ) IF(NOT NOT_BUILD_SHARED ) ADD_LIBRARY(orocos-rtt-mqueue-${OROCOS_TARGET}_dynamic SHARED ${CPPS}) TARGET_LINK_LIBRARIES(orocos-rtt-mqueue-${OROCOS_TARGET}_dynamic orocos-rtt-${OROCOS_TARGET}_dynamic ${MQ_LIBRARIES} ${Boost_SERIALIZATION_LIBRARY} ) SET_TARGET_PROPERTIES( orocos-rtt-mqueue-${OROCOS_TARGET}_dynamic PROPERTIES DEFINE_SYMBOL "RTT_MQ_DLL_EXPORT" OUTPUT_NAME orocos-rtt-mqueue-${OROCOS_TARGET} CLEAN_DIRECT_OUTPUT 1 LINK_FLAGS "${MQ_LDFLAGS} ${CMAKE_LD_FLAGS}" COMPILE_DEFINITIONS "${OROCOS-RTT_DEFINITIONS}" SOVERSION "${RTT_VERSION_MAJOR}.${RTT_VERSION_MINOR}" VERSION "${RTT_VERSION}" ENDIF(NOT NOT_BUILD_SHARED ) INSTALL_NAME_DIR "${CMAKE_INSTALL_PREFIX}/lib") create_pc_flags( "${MQ_DEFINITIONS}" "${MQ_INCLUDE_DIRS}" "${MQ_LIBRARIES}" RTT_MQ_DEFINES RTT_MQ_CFLAGS RTT_MQ_LINKFLAGS) CONFIGURE_FILE( ${CMAKE_CURRENT_SOURCE_DIR}/orocos-rtt-mqueue.pc.in ${CMAKE_CURRENT_BINARY_DIR}/orocos-rtt-mqueue-${OROCOS_TARGET}.pc @ONLY) CONFIGURE_FILE( ${CMAKE_CURRENT_SOURCE_DIR}/rtt-mqueue-config.h.in ${CMAKE_CURRENT_BINARY_DIR}/rtt-mqueue-config.h @ONLY) IF ( BUILD_STATIC ) INSTALL(TARGETS orocos-rtt-mqueue-${OROCOS_TARGET}_static EXPORT ${LIBRARY_EXPORT_FILE} ARCHIVE DESTINATION lib ) target_link_libraries( rtt-transport-mqueue-${OROCOS_TARGET}_plugin orocos-rtt-mqueue-${OROCOS_TARGET}_static) ENDIF( BUILD_STATIC ) IF(NOT NOT_BUILD_SHARED) INSTALL(TARGETS orocos-rtt-mqueue-${OROCOS_TARGET}_dynamic EXPORT ${LIBRARY_EXPORT_FILE} LIBRARY DESTINATION lib RUNTIME DESTINATION bin ) INSTALL(FILES ${CMAKE_CURRENT_BINARY_DIR}/orocos-rtt-mqueue-${OROCOS_TARGET}.pc DESTINATION lib/pkgconfig ) ENDIF(NOT NOT_BUILD_SHARED) SET(RTT_DEFINITIONS "${OROCOS-RTT_DEFINITIONS}") ADD_RTT_TYPEKIT( rtt-transport-mqueue ${RTT_VERSION} MQLib.cpp) target_link_libraries( rtt-transport-mqueue-${OROCOS_TARGET}_plugin orocos-rtt-mqueue-${OROCOS_TARGET}_dynamic) set_target_properties( rtt-transport-mqueue-${OROCOS_TARGET}_plugin PROPERTIES LINK_FLAGS "${MQ_LDFLAGS} ${CMAKE_LD_FLAGS}") INSTALL(FILES ${CMAKE_CURRENT_BINARY_DIR}/rtt-mqueue-config.h TransportPlugin.hpp DESTINATION include/rtt/transports/mqueue ) ENDIF(ENABLE_MQ) Can someone help me to resolve this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From yue.nicholas at gmail.com Sun Jul 3 20:25:50 2016 From: yue.nicholas at gmail.com (Nicholas Yue) Date: Sun, 3 Jul 2016 17:25:50 -0700 Subject: [CMake] Windows Debug/Release/Multi-threaded[Static/Dynamic] combinations build all ? Message-ID: <1f695e40-34e0-cfe7-1fb4-14f7c59accea@gmail.com> Hi, I have been using CMake for some time now but usually for Linux and OS X Recently, I was looking into Windows build. I am wondering if CMake is able to do a combination of building a target (for windows) which has the various combination of /MT/MTd/MDD/MDDd runtime I would like to then construct a CPack of all the combinations of libraries (say, I use the naming convention of Boost on Windows) Cheers -- Nicholas Yue Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5 Custom Dev - C++ porting, OSX, Linux, Windows https://ca.linkedin.com/in/nicholasyue https://vimeo.com/channels/naiadtools From domen.vrankar at gmail.com Mon Jul 4 02:44:31 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Mon, 4 Jul 2016 08:44:31 +0200 Subject: [CMake] CPack source package install location In-Reply-To: <9c149daf-35b8-f984-5a9a-e4e5790f6b7c@gmail.com> References: <9c149daf-35b8-f984-5a9a-e4e5790f6b7c@gmail.com> Message-ID: Hi, > I have a very standard CPack configuration for deb package. I have two > questions: > > 1. I generate the deb with: cpack --config CPackConfig.cmake -G "DEB" > > This is supposedly a binary package but when I install it on the machine I > see header files being installed in /usr/include. > > Is this normal? I'm guessing that CPackConfig.cmake is generated by cmake and not hand written. CMake generates CPackConfig.cmake that can be used to create a package with content listed with 'install()' commands (see: https://cmake.org/cmake/help/v3.5/command/install.html). If those commands contain header files then those files will be part of the package. You could also split packages between bin and dev packages by using COMPONENT attribute in install commands and then generating component packages - one per component. > 2. Header files are installed into /usr/include but there is one problem: > other projects using the library are including header files with #include > as a standard practice. > > So I actually want them installed in /usr/include/libname instead. After > scouring the CPack variables in documentation I didn't really find anything > suitable to do this. Is it possible to achieve? This would have to be changed in CMakeLists.txt (install commands) or is possibly already written with prefix variable in mind in which case you have to look into CMakeLists.txt install commands and set the variable that is used there for this purpose. Regards, Domen From gjasny at googlemail.com Mon Jul 4 02:45:15 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Mon, 4 Jul 2016 08:45:15 +0200 Subject: [CMake] Logical block opening error In-Reply-To: References: Message-ID: <5acdfffc-8c18-e513-e878-a92e77f6f17f@googlemail.com> Hello, an editor with syntax highlighting and indention support would have helped here. On 04/07/16 01:26, Sambeet Panigrahi wrote: > IF(NOT NOT_BUILD_SHARED ) > ADD_LIBRARY(orocos-rtt-mqueue-${OROCOS_TARGET}_dynamic SHARED ${CPPS}) > TARGET_LINK_LIBRARIES(orocos-rtt-mqueue-${OROCOS_TARGET}_dynamic > orocos-rtt-${OROCOS_TARGET}_dynamic > ${MQ_LIBRARIES} ${Boost_SERIALIZATION_LIBRARY} > ) > SET_TARGET_PROPERTIES( orocos-rtt-mqueue-${OROCOS_TARGET}_dynamic > PROPERTIES > DEFINE_SYMBOL "RTT_MQ_DLL_EXPORT" > OUTPUT_NAME orocos-rtt-mqueue-${OROCOS_TARGET} > CLEAN_DIRECT_OUTPUT 1 > LINK_FLAGS "${MQ_LDFLAGS} ${CMAKE_LD_FLAGS}" > COMPILE_DEFINITIONS "${OROCOS-RTT_DEFINITIONS}" > SOVERSION "${RTT_VERSION_MAJOR}.${RTT_VERSION_MINOR}" > VERSION "${RTT_VERSION}" The SET_TARGET_PROPERTIES lacks a closing ) > ENDIF(NOT NOT_BUILD_SHARED ) Thanks, Gregor From olamatthews at gmail.com Mon Jul 4 14:55:42 2016 From: olamatthews at gmail.com (Matthew Adewole) Date: Mon, 4 Jul 2016 19:55:42 +0100 Subject: [CMake] (no subject) Message-ID: Sir/Ma, I tried generating NEKTAR++ using CMAKE 3.5.2 but I keep receiving an error involving "CheckSymbolExists.c" and "CheckSymbolExists.obj". I could find "CheckSymbolExists.c" in one of the sub-directories of CMAKE directory but I couldn't find "CheckSymbolExists.obj". Please how can I download "CheckSymbolExists.obj"? From imbacen at gmail.com Mon Jul 4 17:13:58 2016 From: imbacen at gmail.com (cen) Date: Mon, 4 Jul 2016 23:13:58 +0200 Subject: [CMake] CPack source package install location In-Reply-To: References: <9c149daf-35b8-f984-5a9a-e4e5790f6b7c@gmail.com> Message-ID: <80b7519e-7e04-4655-d5d6-f9183bc9a122@gmail.com> Exactly on point, thank you. Domen Vrankar je 04. 07. 2016 ob 08:44 napisal: > Hi, > >> I have a very standard CPack configuration for deb package. I have two >> questions: >> >> 1. I generate the deb with: cpack --config CPackConfig.cmake -G "DEB" >> >> This is supposedly a binary package but when I install it on the machine I >> see header files being installed in /usr/include. >> >> Is this normal? > I'm guessing that CPackConfig.cmake is generated by cmake and not hand written. > > CMake generates CPackConfig.cmake that can be used to create a package > with content listed with 'install()' commands (see: > https://cmake.org/cmake/help/v3.5/command/install.html). If those > commands contain header files then those files will be part of the > package. You could also split packages between bin and dev packages by > using COMPONENT attribute in install commands and then generating > component packages - one per component. > >> 2. Header files are installed into /usr/include but there is one problem: >> other projects using the library are including header files with #include >> as a standard practice. >> >> So I actually want them installed in /usr/include/libname instead. After >> scouring the CPack variables in documentation I didn't really find anything >> suitable to do this. Is it possible to achieve? > This would have to be changed in CMakeLists.txt (install commands) or > is possibly already written with prefix variable in mind in which case > you have to look into CMakeLists.txt install commands and set the > variable that is used there for this purpose. > > Regards, > Domen From rwkrwk122 at gmail.com Tue Jul 5 14:05:39 2016 From: rwkrwk122 at gmail.com (Richard Kralik) Date: Tue, 5 Jul 2016 14:05:39 -0400 Subject: [CMake] ImageMagick Not Found with CMake Message-ID: I am trying to install Theia-SfM (http://www.theia-sfm.org/index.html) using cmake 3.6 on Ubuntu 16.04. When trying to configure the project the output ends with -- Check for ImageMagick CMake Error at /usr/local/share/cmake-3.6/Modules/FindPackageHandleStandardArgs.cmake:148 (message): Could NOT find ImageMagick (missing: ImageMagick_convert_EXECUTABLE ImageMagick_mogrify_EXECUTABLE ImageMagick_convert_EXECUTABLE ImageMagick_mogrify_EXECUTABLE) Call Stack (most recent call first): /usr/local/share/cmake-3.6/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE) /usr/local/share/cmake-3.6/Modules/FindImageMagick.cmake:268 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) libraries/cimg/CMakeLists.txt:44 (find_package) -- Configuring incomplete, errors occurred! I am sure that ImageMagick and the commands convert and mogrify are installed and working. They can both be found in the terminal; name at name-all-series-invalid-entry-length-16-fixed-up-to-11:~$ type -a convert convert is /usr/local/bin/convert name at name-all-series-invalid-entry-length-16-fixed-up-to-11:~$ type -a mogrify mogrify is /usr/local/bin/mogrify Why can FindImageMagick not find convert and mogrify? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarra13 at gmail.com Tue Jul 5 15:59:50 2016 From: ggarra13 at gmail.com (Gonzalo) Date: Tue, 5 Jul 2016 16:59:50 -0300 Subject: [CMake] ImageMagick Not Found with CMake In-Reply-To: References: Message-ID: <577C11B6.3050007@gmail.com> El 05/07/16 a las 15:05, Richard Kralik escribi?: > I am trying to install Theia-SfM > (http://www.theia-sfm.org/index.html) using cmake 3.6 on Ubuntu 16.04. > When trying to configure the project the output ends with > > Why can FindImageMagick not find convert and mogrify? My guess. Because they are in /usr/local/bin and cmake does not check that. Call cmake with your standard options plus: -DImageMagick_EXECUTABLE_DIR=/usr/local/bin -- Gonzalo Garramu?o ggarra13 at gmail.com From middleton.ted at gmail.com Tue Jul 5 18:17:45 2016 From: middleton.ted at gmail.com (Ted Middleton) Date: Tue, 5 Jul 2016 15:17:45 -0700 Subject: [CMake] Confusion over INTERFACE vs STATIC|SHARED IMPORTED vs INTERFACE IMPORTED Message-ID: I'm looking at the documentation for add_library(), and I'm really confused about the distinction between add_library(foo INTERFACE) vs add_library(foo INTERFACE IMPORTED) vs add_library(foo IMPORTED). Correct me if I'm wrong (and I probably am), but add_library(foo INTERFACE) is for propagating properties like INTERFACE_INCLUDE_DIRECTORIES to other targets using target_link_libraries(), so that header-only libraries can be consumed by other targets conveniently. My understanding of this is that setting INTERFACE_LINK_LIBRARIES on a target like this would be an error? And add_library(foo SHARED IMPORTED) would be to create a target object for a pre-existing library (like a platform lib or something) for which cmake is not supposed to try to create an actual "call the compiler and linkeditor or archiver" build rule. This still boils down to mostly propagating properties, no? Except now some of those properties can be things like INTERFACE_LINK_LIBRARIES? So can anyone tell me what add_library(foo INTERFACE IMPORTED) is? The documentation says, "An INTERFACE Imported Target may also be created with this signature. An IMPORTED library target references a library defined outside the project. The target name has scope in the directory in which it is created and below, but the GLOBAL option extends visibility. It may be referenced like any target built within the project. IMPORTED libraries are useful for convenient reference from commands like target_link_libraries()." That description is what I thought add_library(foo IMPORTED) was for? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas11braden at gmail.com Tue Jul 5 19:09:38 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Tue, 5 Jul 2016 18:09:38 -0500 Subject: [CMake] Confusion over INTERFACE vs STATIC|SHARED IMPORTED vs INTERFACE IMPORTED In-Reply-To: References: Message-ID: >From what I understand, interface libraries just don't have sources or build results. INTERFACE IMPORTED would then mean there is no compiled binary to be linked against, just as INTERFACE alone means there are no sources to create said binary from. At least, that is my understanding. > My understanding of this is that setting INTERFACE_LINK_LIBRARIES on a target like this would be an error? Why can't a header-only library link to non-header-only libraries? On Tue, Jul 5, 2016 at 5:17 PM, Ted Middleton wrote: > I'm looking at the documentation for add_library(), and I'm really confused > about the distinction between add_library(foo INTERFACE) vs add_library(foo > INTERFACE IMPORTED) vs add_library(foo IMPORTED). > > Correct me if I'm wrong (and I probably am), but add_library(foo INTERFACE) > is for propagating properties like INTERFACE_INCLUDE_DIRECTORIES to other > targets using target_link_libraries(), so that header-only libraries can be > consumed by other targets conveniently. My understanding of this is that > setting INTERFACE_LINK_LIBRARIES on a target like this would be an error? > > And add_library(foo SHARED IMPORTED) would be to create a target object for > a pre-existing library (like a platform lib or something) for which cmake is > not supposed to try to create an actual "call the compiler and linkeditor or > archiver" build rule. This still boils down to mostly propagating > properties, no? Except now some of those properties can be things like > INTERFACE_LINK_LIBRARIES? > > So can anyone tell me what add_library(foo INTERFACE IMPORTED) is? The > documentation says, > > "An INTERFACE Imported Target may also be created with this signature. An > IMPORTED library target references a library defined outside the project. > The target name has scope in the directory in which it is created and below, > but the GLOBAL option extends visibility. It may be referenced like any > target built within the project. IMPORTED libraries are useful for > convenient reference from commands like target_link_libraries()." > > That description is what I thought add_library(foo IMPORTED) > was for? > > > > -- > > 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 middleton.ted at gmail.com Tue Jul 5 20:35:46 2016 From: middleton.ted at gmail.com (Ted Middleton) Date: Tue, 5 Jul 2016 17:35:46 -0700 Subject: [CMake] Confusion over INTERFACE vs STATIC|SHARED IMPORTED vs INTERFACE IMPORTED In-Reply-To: References: Message-ID: Ack - sorry. s/INTERFACE_LINK_LIBRARIES/IMPORTED_LOCATION/cg. INTERFACE_LINK_LIBRARIES I guess would be a completely valid property to set on an add_library(foo INTERFACE) target. But IMPORTED_LOCATION wouldn't, right? "INTERFACE IMPORTED would then mean there is no compiled binary to be linked against, just as INTERFACE alone means there are no sources to create said binary from" Is there a difference between them, then? If neither produce an actual build rule, and neither can point to a .lib/.so/.dll/.a/.dylib, are they not exactly the same thing? The documentation says that add_library(foo INTERFACE IMPORTED) creates an /imported target/, but the explanation of what exactly this is is ... confusing? Based on the description of what an /imported target/ is, I would think that it is the same thing that add_library(foo IMPORTED) produces? On Tue, Jul 5, 2016 at 4:09 PM, Nicholas Braden wrote: > From what I understand, interface libraries just don't have sources or > build results. INTERFACE IMPORTED would then mean there is no compiled > binary to be linked against, just as INTERFACE alone means there are > no sources to create said binary from. At least, that is my > understanding. > > > My understanding of this is that setting INTERFACE_LINK_LIBRARIES on a > target like this would be an error? > > Why can't a header-only library link to non-header-only libraries? > > On Tue, Jul 5, 2016 at 5:17 PM, Ted Middleton > wrote: > > I'm looking at the documentation for add_library(), and I'm really > confused > > about the distinction between add_library(foo INTERFACE) vs > add_library(foo > > INTERFACE IMPORTED) vs add_library(foo IMPORTED). > > > > Correct me if I'm wrong (and I probably am), but add_library(foo > INTERFACE) > > is for propagating properties like INTERFACE_INCLUDE_DIRECTORIES to other > > targets using target_link_libraries(), so that header-only libraries can > be > > consumed by other targets conveniently. My understanding of this is that > > setting INTERFACE_LINK_LIBRARIES on a target like this would be an error? > > > > And add_library(foo SHARED IMPORTED) would be to create a target object > for > > a pre-existing library (like a platform lib or something) for which > cmake is > > not supposed to try to create an actual "call the compiler and > linkeditor or > > archiver" build rule. This still boils down to mostly propagating > > properties, no? Except now some of those properties can be things like > > INTERFACE_LINK_LIBRARIES? > > > > So can anyone tell me what add_library(foo INTERFACE IMPORTED) is? The > > documentation says, > > > > "An INTERFACE Imported Target may also be created with this signature. An > > IMPORTED library target references a library defined outside the project. > > The target name has scope in the directory in which it is created and > below, > > but the GLOBAL option extends visibility. It may be referenced like any > > target built within the project. IMPORTED libraries are useful for > > convenient reference from commands like target_link_libraries()." > > > > That description is what I thought add_library(foo > IMPORTED) > > was for? > > > > > > > > -- > > > > 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 Martin.Wagner at neuberger.net Wed Jul 6 01:18:00 2016 From: Martin.Wagner at neuberger.net (Wagner Martin) Date: Wed, 6 Jul 2016 05:18:00 +0000 Subject: [CMake] C header file cross dependency In-Reply-To: <20160606113628.6a729d17@posteo.de> References: <56E920142ED81D4FBE3260E4B9D1DB3E97208951@ROTSRV13.Neuberger.local> <20160525113902.0eb6f70d@posteo.de> <56E920142ED81D4FBE3260E4B9D1DB3E97208FAB@ROTSRV13.Neuberger.local> <20160606113628.6a729d17@posteo.de> Message-ID: <56E920142ED81D4FBE3260E4B9D1DB3E97285A19@ROTSRV13.Neuberger.local> Hi @all, I've finally found a solution to the problem. My solution is here: https://github.com/martinwag/test_cmake/tree/master What I did: - remove "OBJECT" library targets as they do not work in combination with interface libraries - added one install target per library, so I get one "lib*.a" archive per library (which is not what I need) - added an post install target as described here: stackoverflow.com/questions/9998679 . This step creates a "thin" archive, that is packed with the other archives at cpack-time. This archive can be used as single file when linking in the consuming stage. Regards, Martin From konstantin at podsvirov.pro Wed Jul 6 02:06:02 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 06 Jul 2016 09:06:02 +0300 Subject: [CMake] Disable removing generated file Message-ID: <247471467785162@web10h.yandex.ru> An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Wed Jul 6 02:46:16 2016 From: d3ck0r at gmail.com (J Decker) Date: Tue, 5 Jul 2016 23:46:16 -0700 Subject: [CMake] cmp0065 Message-ID: https://cmake.org/cmake/help/v3.4/policy/CMP0065.html while I like the idea it suggests, I don't use the flags for -rdynamic so this is meaningless to me https://cmake.org/cmake/help/v3.4/prop_tgt/ENABLE_EXPORTS.html#prop_tgt:ENABLE_EXPORTS SET_PROPERTY(TARGET ${project} APPEND PROPERTY COMPILE_DEFINITIONS TARGET_LABEL=${TARGET_LABEL};TARETNAME=\"${TARGETNAME}\" ) or SET_PROPERTY( TARGET ${project} APPEND PROPERTY COMPILE_DEFINITIONS "CONSOLE_SHELL" ) to indicate it's non-WIN32.... I noted at the bottom of that the the default behavior will eventually be phased out... but then can we have some other flag to phase it back in? I really prefer to use COMPILE_DEFINITIONS because it allows quoted definitions to be defined -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.boettcher at posteo.de Wed Jul 6 04:19:05 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Wed, 6 Jul 2016 10:19:05 +0200 Subject: [CMake] CTest - how to structure tests for different test jobs with a shared build-dir Message-ID: <20160706101905.01feaaa0@posteo.de> Hi, in my project I have several hundreds of non-regression and unit tests. Generated by cmake/make (or ninja) and run with ctest. Build jobs and test-run-jobs are separated and have their dedicated workspace available. (within jenkins) Tests are prefixed with an adjective to indicate when they should be run. This somehow a kind of category. For example we have 'short' and 'long' and their prefix is 'short::' and 'long::' . In the future we will have other categories. This allows the test jobs to run a sub-selection of tests. For example for each commit done we trigger a build and run all short::-tests. cmake [..] ninja triggers short-tests-job ctest -Rshort:: -T test Once a night we run all the long-tests: ctest -Rlong:: -T test All of it is done within the workspace from the build-job. My problem is, that ctest is writing all xUnit-results into the build-dir. This makes it difficult (I haven't found a way) to process the (xUnit)-results only concerned by the job (the short-job only wants to digest the results from the short::-run). I have several options at hand: - I could install the tests into the test-job-workspace (not sure if this will really work with ctest) - I could copy the build-dir (what about the absolute paths used) - I could simple rebuild my binaries for each job (very long and redundant) Ideally I could tell ctest: here is the cmake-binary-dir, here you can find the test-binaries, but please put the results into the job's workspace this dir. Is this possible? Is there something I oversaw (I strongly hope so!)? Thanks, -- Patrick. From johannes.zarl-zierl at jku.at Wed Jul 6 05:52:42 2016 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Wed, 06 Jul 2016 11:52:42 +0200 Subject: [CMake] cmp0065 In-Reply-To: References: Message-ID: <3608561.ZGd3KOTENa@ersa> Hi, On Tuesday 05 July 2016 23:46:16 J Decker wrote: > https://cmake.org/cmake/help/v3.4/policy/CMP0065.html > while I like the idea it suggests, I don't use the flags for -rdynamic so > this is meaningless to me I'm not sure I understood you correctly, but if the policy is meaningless to you, it shouldn't affect you... > https://cmake.org/cmake/help/v3.4/prop_tgt/ENABLE_EXPORTS.html#prop_tgt:ENAB > LE_EXPORTS > SET_PROPERTY(TARGET ${project} APPEND PROPERTY COMPILE_DEFINITIONS > TARGET_LABEL=${TARGET_LABEL};TARETNAME=\"${TARGETNAME}\" ) > > or > > SET_PROPERTY( TARGET ${project} APPEND PROPERTY COMPILE_DEFINITIONS > "CONSOLE_SHELL" ) > > to indicate it's non-WIN32.... First of all, there are the usual standard definitions provided by the compiler, so you can just use #if defined(WIN32) #endif to check whether the compilation happens for windows or another platform. If you have the need for additional definitions, it seems to me that the usual command: target_compile_definitions( yourTarget PRIVATE COMPILE_SHELL) https://cmake.org/cmake/help/v3.4/command/target_compile_definitions.html Is that what you are searching for? > I noted at the bottom of that the the default behavior will eventually be > phased out... but then can we have some other flag to phase it back in? You can always set policies to ?OLD? to revert to the old behavior (until it is finally phased out). In the case of cmp0065 the documentation explains what you can do to have the same behavior with the policiy enabled: Just set the ENABLE_EXPORTS property on the targets that need to export their symbols. HTH, Johannes From nicholas11braden at gmail.com Wed Jul 6 08:41:32 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Wed, 6 Jul 2016 07:41:32 -0500 Subject: [CMake] Confusion over INTERFACE vs STATIC|SHARED IMPORTED vs INTERFACE IMPORTED In-Reply-To: References: Message-ID: There is one difference that I thought of immediately, and I tested it - an INTERFACE target can be installed/exported, but an INTERFACE IMPORTED target cannot be installed/exported because CMake considers it to not be in the build/source directory. I'm sure there are other internal differences due to the fact that imported targets aren't considered to be inside the build or source directories. I think the main takeaway is that "INTERFACE IMPORTED" is not actually a different kind of target, it is just a target which is both INTERFACE and IMPORTED. Why not allow all four combinations of INTERFACE and IMPORTED? On Tue, Jul 5, 2016 at 7:35 PM, Ted Middleton wrote: > Ack - sorry. s/INTERFACE_LINK_LIBRARIES/IMPORTED_LOCATION/cg. > INTERFACE_LINK_LIBRARIES I guess would be a completely valid property to set > on an add_library(foo INTERFACE) target. But IMPORTED_LOCATION wouldn't, > right? > > "INTERFACE IMPORTED would then mean there is no compiled > binary to be linked against, just as INTERFACE alone means there are > no sources to create said binary from" > > Is there a difference between them, then? If neither produce an actual build > rule, and neither can point to a .lib/.so/.dll/.a/.dylib, are they not > exactly the same thing? The documentation says that add_library(foo > INTERFACE IMPORTED) creates an /imported target/, but the explanation of > what exactly this is is ... confusing? Based on the description of what an > /imported target/ is, I would think that it is the same thing that > add_library(foo IMPORTED) produces? > > > > On Tue, Jul 5, 2016 at 4:09 PM, Nicholas Braden > wrote: >> >> From what I understand, interface libraries just don't have sources or >> build results. INTERFACE IMPORTED would then mean there is no compiled >> binary to be linked against, just as INTERFACE alone means there are >> no sources to create said binary from. At least, that is my >> understanding. >> >> > My understanding of this is that setting INTERFACE_LINK_LIBRARIES on a >> > target like this would be an error? >> >> Why can't a header-only library link to non-header-only libraries? >> >> On Tue, Jul 5, 2016 at 5:17 PM, Ted Middleton >> wrote: >> > I'm looking at the documentation for add_library(), and I'm really >> > confused >> > about the distinction between add_library(foo INTERFACE) vs >> > add_library(foo >> > INTERFACE IMPORTED) vs add_library(foo IMPORTED). >> > >> > Correct me if I'm wrong (and I probably am), but add_library(foo >> > INTERFACE) >> > is for propagating properties like INTERFACE_INCLUDE_DIRECTORIES to >> > other >> > targets using target_link_libraries(), so that header-only libraries can >> > be >> > consumed by other targets conveniently. My understanding of this is that >> > setting INTERFACE_LINK_LIBRARIES on a target like this would be an >> > error? >> > >> > And add_library(foo SHARED IMPORTED) would be to create a target object >> > for >> > a pre-existing library (like a platform lib or something) for which >> > cmake is >> > not supposed to try to create an actual "call the compiler and >> > linkeditor or >> > archiver" build rule. This still boils down to mostly propagating >> > properties, no? Except now some of those properties can be things like >> > INTERFACE_LINK_LIBRARIES? >> > >> > So can anyone tell me what add_library(foo INTERFACE IMPORTED) is? The >> > documentation says, >> > >> > "An INTERFACE Imported Target may also be created with this signature. >> > An >> > IMPORTED library target references a library defined outside the >> > project. >> > The target name has scope in the directory in which it is created and >> > below, >> > but the GLOBAL option extends visibility. It may be referenced like any >> > target built within the project. IMPORTED libraries are useful for >> > convenient reference from commands like target_link_libraries()." >> > >> > That description is what I thought add_library(foo >> > IMPORTED) >> > was for? >> > >> > >> > >> > -- >> > >> > 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 arankin at robarts.ca Wed Jul 6 10:42:43 2016 From: arankin at robarts.ca (Adam Rankin) Date: Wed, 6 Jul 2016 14:42:43 +0000 Subject: [CMake] [Visual Studio] Universal Windows Platform projects Message-ID: Hello all, I've been trying to identify the correct variables to set to create a UWP project using VS2015, and the projects generated are missing a few critical tags. I'm using CMAKE_SYSTEM_NAME=WindowsStore and CMAKE_SYSTEM_VERSION=10.0. This correctly identifies and sets the target platform tag, but does not set the following 'Globals' Properties in the PropertyGroup of the .vcxproj file true Windows Store 10.0.10240.0 10.0 Has anyone successfully created a UWP project using CMake? Regards, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Jul 6 11:07:58 2016 From: brad.king at kitware.com (Brad King) Date: Wed, 6 Jul 2016 11:07:58 -0400 Subject: [CMake] ImageMagick Not Found with CMake In-Reply-To: <577C11B6.3050007@gmail.com> References: <577C11B6.3050007@gmail.com> Message-ID: <577D1ECE.9030308@kitware.com> On 07/05/2016 03:59 PM, Gonzalo wrote: > El 05/07/16 a las 15:05, Richard Kralik escribi?: >> Why can FindImageMagick not find convert and mogrify? > My guess. Because they are in /usr/local/bin and cmake does not check that. > > Call cmake with your standard options plus: > > -DImageMagick_EXECUTABLE_DIR=/usr/local/bin That should be searched by find_program but FindImageMagick is incorrectly using find_path for it instead. I've re-opened the associated issue: https://gitlab.kitware.com/cmake/cmake/issues/16179 -Brad From d3ck0r at gmail.com Wed Jul 6 11:45:41 2016 From: d3ck0r at gmail.com (J Decker) Date: Wed, 6 Jul 2016 08:45:41 -0700 Subject: [CMake] Fwd: cmp0065 In-Reply-To: References: <3608561.ZGd3KOTENa@ersa> Message-ID: (probably breaks thread coherance; misreplied) ---------- Forwarded message ---------- From: J Decker Date: Wed, Jul 6, 2016 at 8:43 AM Subject: Re: [CMake] cmp0065 To: Johannes Zarl-Zierl On Wed, Jul 6, 2016 at 2:52 AM, Johannes Zarl-Zierl < johannes.zarl-zierl at jku.at> wrote: > Hi, > > On Tuesday 05 July 2016 23:46:16 J Decker wrote: > > https://cmake.org/cmake/help/v3.4/policy/CMP0065.html > > while I like the idea it suggests, I don't use the flags for -rdynamic so > > this is meaningless to me > > I'm not sure I understood you correctly, but if the policy is meaningless > to > you, it shouldn't affect you... > > > > https://cmake.org/cmake/help/v3.4/prop_tgt/ENABLE_EXPORTS.html#prop_tgt:ENAB > > LE_EXPORTS > > SET_PROPERTY(TARGET ${project} APPEND PROPERTY COMPILE_DEFINITIONS > > TARGET_LABEL=${TARGET_LABEL};TARETNAME=\"${TARGETNAME}\" ) > > > > or > > > > SET_PROPERTY( TARGET ${project} APPEND PROPERTY COMPILE_DEFINITIONS > > "CONSOLE_SHELL" ) > > > > to indicate it's non-WIN32.... > > First of all, there are the usual standard definitions provided by the > compiler, so you can just use > > #if defined(WIN32) > #endif > not WIN32 that way... as in add_executable( something WIN32 ... ) (or not WIN32) > > target_compile_definitions( yourTarget PRIVATE COMPILE_SHELL) > https://cmake.org/cmake/help/v3.4/command/target_compile_definitions.html > > Is that what you are searching for? > it says "tems will populate theCOMPILE_DEFINITIONS property of" sounds like that will trigger the same CMP0065 warnings. > > > I noted at the bottom of that the the default behavior will eventually be > > phased out... but then can we have some other flag to phase it back in? > > You can always set policies to ?OLD? to revert to the old behavior (until > it > is finally phased out). In the case of cmp0065 the documentation explains > what > you can do to have the same behavior with the policiy enabled: > Just set the ENABLE_EXPORTS property on the targets that need to export > their > symbols. > again though; the flags specified have nothing to do with exporting symbols; so enabling that is false; I want to provide COMPILE_DEFINITIONS for many targets that don't export symbols and are DLLs. > > HTH, > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan at nacnud.ca Wed Jul 6 17:00:29 2016 From: duncan at nacnud.ca (Duncan Chisholm) Date: Wed, 6 Jul 2016 18:00:29 -0300 Subject: [CMake] How to disable the CPack preinstall build? Message-ID: Hello All, I'm looking for some CPack (3.5.2) wrangling assistance... I have CMake automatically generating a unique ID on every build. This ID is compiled into several components of my project and I want the same value to appear in my package file name. I do this by inserting it into a CPack project config file at build time. This works great in Visual Studio and XCode. When I build the package target, a new ID is generated, all the dependents are rebuilt and the package is created with the correct file name. However, it doesn't work for makefiles. When I execute 'make package', CMake subsequently executes 'make preinstall'. This causes two build IDs to be generated; the first ending up in the package filename and the second ending up in my modules (which are compiled twice). As a workaround, I've found that if I edit the CPackConfig.cmake file to replace CPACK_CMAKE_GENERATOR "Unix Makefiles" with "Xcode", it works. CPack apparently knows that it doesn't need to worry about building anything in this case. So... Is there a better way to get this message across to CPack? Just package; don't build. Duncan -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.zarl-zierl at jku.at Wed Jul 6 17:49:48 2016 From: johannes.zarl-zierl at jku.at (Johannes Zarl) Date: Wed, 06 Jul 2016 23:49:48 +0200 Subject: [CMake] cmp0065 In-Reply-To: References: <3608561.ZGd3KOTENa@ersa> Message-ID: <2037693.7G2EFGqigq@mani> Hi, On Wednesday 06 July 2016 08:43:44 you wrote: > > #if defined(WIN32) > > #endif > > not WIN32 that way... as in add_executable( something WIN32 ... ) (or not > WIN32) I'm not sure I can follow. I thought you want to have compile time definitions like "-DSOMETHING" for GCC or "/DSOMETHING" for MSVC. If that's what you want, then use the already defined macros for your target platform/OS. For Windows, the correct macro is "_WIN32" (sorry I forgot the underscore before). A comprehensive list of these macros can be found here: https://sourceforge.net/p/predef/wiki/OperatingSystems/ If that's not what you want, it would help if you could elaborate a little, or maybe even provide a minimum working example. > > target_compile_definitions( yourTarget PRIVATE COMPILE_SHELL) > > https://cmake.org/cmake/help/v3.4/command/target_compile_definitions.html > > > > Is that what you are searching for? > > it says "tems will populate theCOMPILE_DEFINITIONS > t:COMPILE_DEFINITIONS> property > of" > sounds like that will trigger the same CMP0065 warnings. Did you verify that? I cannot fathom how using target_compile_definitions could trigger a CMP0065 warning. But maybe I'm just reading the docs completely wrong... Btw. the documentation states that CMP0065 does not warn by default, but silently reverts to the old behavior if it's not set. Cheers, Johannes P.S.: Checking this using a minimum example does not trigger any warning for me on cmake 3.5.2: --CMakeLists.txt: cmake_minimum_required(VERSION 3.5) project(cmake-test) add_executable(myExe main.cpp) target_compile_definitions(myExe PRIVATE MY_DEFINITION) target_compile_definitions(myExe PRIVATE VERSION_STRING="0.8.15") --main.cpp: #include #ifdef _WIN32 #warning "Target platform is windows 32 or 64 bit!" #endif int main(int argc, char** argv) { #ifdef MY_DEFINITION std::cout << argv[0] << "compiled with MY_DEFINITION!" << std::endl; #endif std::cout << argv[0] << VERSION_STRING << std::endl; return 0; } For quoted definitions, I usually use configure_file to create a platform header. From craig.scott at crascit.com Wed Jul 6 17:50:03 2016 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 7 Jul 2016 07:50:03 +1000 Subject: [CMake] How to disable the CPack preinstall build? In-Reply-To: References: Message-ID: Good chance CMAKE_BUILD_WITH_INSTALL_RPATH may be what you are looking for. There's also always the option of just running cpack directly rather than "make package" (not sure if that will avoid the part of the process that is causing you problems though). On Thu, Jul 7, 2016 at 7:00 AM, Duncan Chisholm wrote: > Hello All, > > I'm looking for some CPack (3.5.2) wrangling assistance... > > I have CMake automatically generating a unique ID on every build. This ID > is compiled into several components of my project and I want the same value > to appear in my package file name. I do this by inserting it into a CPack > project config file at build time. > > This works great in Visual Studio and XCode. When I build the package > target, a new ID is generated, all the dependents are rebuilt and the > package is created with the correct file name. > > However, it doesn't work for makefiles. When I execute 'make package', > CMake subsequently executes 'make preinstall'. This causes two build IDs to > be generated; the first ending up in the package filename and the second > ending up in my modules (which are compiled twice). > > As a workaround, I've found that if I edit the CPackConfig.cmake file to > replace CPACK_CMAKE_GENERATOR "Unix Makefiles" with "Xcode", it works. > CPack apparently knows that it doesn't need to worry about building > anything in this case. > > So... Is there a better way to get this message across to CPack? Just > package; don't build. > > Duncan > > > -- > > 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 http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Wed Jul 6 20:41:38 2016 From: d3ck0r at gmail.com (J Decker) Date: Wed, 6 Jul 2016 17:41:38 -0700 Subject: [CMake] cmp0065 In-Reply-To: <2037693.7G2EFGqigq@mani> References: <3608561.ZGd3KOTENa@ersa> <2037693.7G2EFGqigq@mani> Message-ID: M:/tmp/cmake_cmp0065/CMakeLists.txt(1): cmake_minimum_required(VERSION 3.0 ) M:/tmp/cmake_cmp0065/CMakeLists.txt(2): project(cmake-test ) M:/tmp/cmake_cmp0065/CMakeLists.txt(3): add_executable(myExe main.c ) M:/tmp/cmake_cmp0065/CMakeLists.txt(4): target_compile_definitions(myExe PRIVATE MY_DEFINITION ) M:/tmp/cmake_cmp0065/CMakeLists.txt(5): target_compile_definitions(myExe PRIVATE VERSION_STRING="0.8.15" ) M:/tmp/cmake_cmp0065/CMakeLists.txt(6): set(project myExe ) -- Configuring done CMake Warning (dev) in CMakeLists.txt: Policy CMP0065 is not set: Do not add flags to export symbols from executables without the ENABLE_EXPORTS target property. Run "cmake --help-policy CMP0065" for policy details. Use the cmake_policy command to set the policy and suppress this warning. For compatibility with older versions of CMake, additional flags may be added to export symbols on all executables regardless of thier ENABLE_EXPORTS property. This warning is for project developers. Use -Wno-dev to suppress it. -- Generating done -- Build files have been written to: M:/tmp/cmake_cmp0065/build --------------- you have cmake_minimum_required(VERSION 3.5 ) in your example... setting 3.0 instead and adding --trace shows the warning... ----- then command you said to use is doing exactly the same thing I'm doing to the same target property... of course it should generate the same result.... and it does. -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Jul 6 22:17:21 2016 From: DLRdave at aol.com (David Cole) Date: Wed, 6 Jul 2016 22:17:21 -0400 Subject: [CMake] cmp0065 In-Reply-To: References: <3608561.ZGd3KOTENa@ersa> <2037693.7G2EFGqigq@mani> Message-ID: Seems like you ought to be able to avoid this warning just by setting ENABLE_EXPORTS to 0 or 1 ... If you're going to require 3.0, then use 3.0. If you're going to use 3.5, then add the property to squelch the warning and get the behavior you want. D On Wednesday, July 6, 2016, J Decker wrote: > > M:/tmp/cmake_cmp0065/CMakeLists.txt(1): cmake_minimum_required(VERSION > 3.0 ) > M:/tmp/cmake_cmp0065/CMakeLists.txt(2): project(cmake-test ) > M:/tmp/cmake_cmp0065/CMakeLists.txt(3): add_executable(myExe main.c ) > M:/tmp/cmake_cmp0065/CMakeLists.txt(4): target_compile_definitions(myExe > PRIVATE MY_DEFINITION ) > M:/tmp/cmake_cmp0065/CMakeLists.txt(5): target_compile_definitions(myExe > PRIVATE VERSION_STRING="0.8.15" ) > M:/tmp/cmake_cmp0065/CMakeLists.txt(6): set(project myExe ) > > -- Configuring done > CMake Warning (dev) in CMakeLists.txt: > Policy CMP0065 is not set: Do not add flags to export symbols from > executables without the ENABLE_EXPORTS target property. Run "cmake > --help-policy CMP0065" for policy details. Use the cmake_policy command > to > set the policy and suppress this warning. > > For compatibility with older versions of CMake, additional flags may be > added to export symbols on all executables regardless of thier > ENABLE_EXPORTS property. > This warning is for project developers. Use -Wno-dev to suppress it. > > -- Generating done > -- Build files have been written to: M:/tmp/cmake_cmp0065/build > > --------------- > you have cmake_minimum_required(VERSION 3.5 ) in your example... setting > 3.0 instead and adding --trace shows the warning... > > ----- > then command you said to use is doing exactly the same thing I'm doing to > the same target property... of course it should generate the same > result.... and it does. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Jul 6 22:18:15 2016 From: DLRdave at aol.com (David Cole) Date: Wed, 6 Jul 2016 22:18:15 -0400 Subject: [CMake] cmp0065 In-Reply-To: References: <3608561.ZGd3KOTENa@ersa> <2037693.7G2EFGqigq@mani> Message-ID: Seems like you ought to be able to avoid this warning just by setting ENABLE_EXPORTS to 0 or 1 ... If you're going to require 3.0, then use 3.0. If you're going to use 3.5, then add the property to squelch the warning and get the behavior you want. D On Wednesday, July 6, 2016, J Decker wrote: > > M:/tmp/cmake_cmp0065/CMakeLists.txt(1): cmake_minimum_required(VERSION > 3.0 ) > M:/tmp/cmake_cmp0065/CMakeLists.txt(2): project(cmake-test ) > M:/tmp/cmake_cmp0065/CMakeLists.txt(3): add_executable(myExe main.c ) > M:/tmp/cmake_cmp0065/CMakeLists.txt(4): target_compile_definitions(myExe > PRIVATE MY_DEFINITION ) > M:/tmp/cmake_cmp0065/CMakeLists.txt(5): target_compile_definitions(myExe > PRIVATE VERSION_STRING="0.8.15" ) > M:/tmp/cmake_cmp0065/CMakeLists.txt(6): set(project myExe ) > > -- Configuring done > CMake Warning (dev) in CMakeLists.txt: > Policy CMP0065 is not set: Do not add flags to export symbols from > executables without the ENABLE_EXPORTS target property. Run "cmake > --help-policy CMP0065" for policy details. Use the cmake_policy command > to > set the policy and suppress this warning. > > For compatibility with older versions of CMake, additional flags may be > added to export symbols on all executables regardless of thier > ENABLE_EXPORTS property. > This warning is for project developers. Use -Wno-dev to suppress it. > > -- Generating done > -- Build files have been written to: M:/tmp/cmake_cmp0065/build > > --------------- > you have cmake_minimum_required(VERSION 3.5 ) in your example... setting > 3.0 instead and adding --trace shows the warning... > > ----- > then command you said to use is doing exactly the same thing I'm doing to > the same target property... of course it should generate the same > result.... and it does. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.boettcher at posteo.de Thu Jul 7 01:47:31 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Thu, 7 Jul 2016 07:47:31 +0200 Subject: [CMake] CTest - how to structure tests for different test jobs with a shared build-dir In-Reply-To: <20160706101905.01feaaa0@posteo.de> References: <20160706101905.01feaaa0@posteo.de> Message-ID: <20160707074731.500db407@posteo.de> Hi list, On Wed, 6 Jul 2016 10:19:05 +0200 Patrick Boettcher wrote: > I have several options at hand: > > - I could install the tests into the test-job-workspace (not sure if > this will really work with ctest) > - I could copy the build-dir (what about the absolute paths used) > - I could simple rebuild my binaries for each job (very long and > redundant) > > Ideally I could tell ctest: here is the cmake-binary-dir, here you can > find the test-binaries, but please put the results into the job's > workspace this dir. I find a solution which satisfies my needs: I just copy all the CTestTestFiles.cmake recursively while keeping the path-hierarchy. Then running ctest at the top-level executes the tests from the original build-dir (absolute paths) . Copying is done like this rsync -avm --include='*CTestTestfile.cmake' -f 'hide,! */' This, for the moment works. Would be nice if there was a way to tell cmake to generate ctest-files into a separate dir. regards, -- Patrick. From brad.king at kitware.com Thu Jul 7 09:07:02 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 7 Jul 2016 09:07:02 -0400 Subject: [CMake] initializing flags from toolchain files (was: CMake 3.6.0-rc4 now ready for testing!) In-Reply-To: <20160701080611.Horde.78eAeXB-Yge_tL7lZ5aW8Ub@mail.hendrik-sattler.de> References: <1548229B-0D2D-4F7D-8AE9-BFE9E993D54A@hendrik-sattler.de> <57751C8F.6030602@kitware.com> <20160701080611.Horde.78eAeXB-Yge_tL7lZ5aW8Ub@mail.hendrik-sattler.de> Message-ID: <577E53F6.7070208@kitware.com> On 07/01/2016 04:06 AM, Hendrik Sattler wrote: > So each and every toolchain file shall also take care of the > environment variable? > How about CMAKE_CXX_FLAGS_INIT set by other module files? Currently the only way to get CMake's default flags for the platform and also add one's own flags from a toolchain file is to set the environment variable. I've now made changes (for CMake 3.7) to enable use of CMAKE_CXX_FLAGS_INIT for this: Honor CMAKE__FLAGS[_]_INIT set in toolchain files https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a66004be Also, CMake 3.7 will add a new policy to allow the per-config flags to be used in try_compile too: try_compile: Add policy CMP0066 to honor CMAKE__FLAGS_ https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d582c23a -Brad From robert.maynard at kitware.com Thu Jul 7 13:11:58 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 7 Jul 2016 13:11:58 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.6.0 available for download Message-ID: I am proud to announce that CMake 3.6.0 is now available for download at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.6 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.6/release/3.6.html Some of the more significant features of CMake 3.6 are: * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. CMake 3.6 Release Notes *********************** Changes made since CMake 3.5 include the following. New Features ============ Generators ---------- * The "Ninja" generator learned to produce phony targets of the form "sub/dir/all" to drive the build of a subdirectory. This is equivalent to "cd sub/dir; make all" with Makefile Generators. * The "Ninja" generator now includes system header files in build dependencies to ensure correct re-builds when system packages are updated. * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned how to use the "CROSSCOMPILING_EMULATOR" executable target property. * The "install()" command learned a new "EXCLUDE_FROM_ALL" option to leave installation rules out of the default installation. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained support for the "%s" placeholder. This is the number of seconds since the UNIX Epoch. Variables --------- * A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell Makefile Generators to limit dependency scanning only to files in the project source and build trees. * A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate when CMake is running on an Oracle Solaris host. * A "CMAKE__STANDARD_INCLUDE_DIRECTORIES" variable was added for use by toolchain files to specify system include directories to be appended to all compiler command lines. * The "CMAKE__STANDARD_LIBRARIES" variable is now documented. It is intended for use by toolchain files to specify system libraries to be added to all linker command lines. * A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell the "Ninja" generator to configure the generated "build.ninja" file for use as a "subninja". * A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for use by toolchain files to specify platform-specific variables that must be propagated by the "try_compile()" command into test projects. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. Properties ---------- * A "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to tell the "Visual Studio 9 2008" and "Visual Studio 8 2005" generators to generate the "remote directory" for WinCE project deployment and debugger settings. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * A "TIMEOUT_AFTER_MATCH" test property was introduced to optionally tell CTest to enforce a secondary timeout after matching certain output from a test. * A "VS_CONFIGURATION_TYPE" target property was introduced to specify a custom project file type for Visual Studio Generators supporting VS 2010 and above. * A "VS_STARTUP_PROJECT" directory property was introduced to specify for Visual Studio Generators the default startup project for generated solutions (".sln" files). Modules ------- * The "CMakePushCheckState" module now pushes/pops/resets the variable "CMAKE_EXTRA_INCLUDE_FILE" used in "CheckTypeSize". * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "ExternalProject" module leared the "DOWNLOAD_NO_EXTRACT 1" argument to skip extracting the file that is downloaded (e.g., for self-extracting shell installers or ".msi" files). * The "ExternalProject" module now uses "TLS_VERIFY" when fetching from git repositories. * The "FindBLAS" and "FindLAPACK" modules learned to support OpenBLAS. * The "FindCUDA" module learned to find the "cublas_device" library. * The "FindGTest" module "gtest_add_tests" function now causes CMake to automatically re-run when test sources change so that they can be re-scanned. * The "FindLTTngUST" module was introduced to find the LTTng-UST library. * The "FindPkgConfig" module learned to optionally create imported targets for the libraries it has found. * The "FindProtobuf" module learned to provide a "Protobuf_VERSION" variable and check the version number requested in a "find_package()" call. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. Platforms --------- * The Clang compiler is now supported on CYGWIN. * Support was added for the Bruce C Compiler with compiler id "Bruce". CTest ----- * The "ctest_update()" command now looks at the "CTEST_GIT_INIT_SUBMODULES" variable to determine whether submodules should be updated or not before updating. * The "ctest_update()" command will now synchronize submodules on an update. Updates which add submodules or change a submodule's URL will now be pulled properly. CPack ----- * The "CPackDeb" module learned how to handle "$ORIGIN" in "CMAKE_INSTALL_RPATH" when "CPACK_DEBIAN_PACKAGE_SHLIBDEPS" is used for dependency auto detection. * The "CPackDeb" module learned how to generate "DEBIAN/shlibs" contorl file when package contains shared libraries. * The "CPackDeb" module learned how to generate "DEBIAN/postinst" and "DEBIAN/postrm" files if the package installs libraries in ldconfig- controlled locations (e.g. "/lib/", "/usr/lib/"). * The "CPackDeb" module learned how to generate dependencies between Debian packages if multi-component setup is used and "CPACK_COMPONENT__DEPENDS" variables are set. For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS". * The "CPackDeb" module learned how to set custom package file names including how to generate properly-named Debian packages: _-_.deb For backward compatibility this feature is disabled by default. See "CPACK_DEBIAN_FILE_NAME" and "CPACK_DEBIAN__FILE_NAME". * The "CPackDeb" module learned how to set the package release number ("DebianRevisionNumber" in package file name when used in combination with "DEB-DEFAULT" value set by "CPACK_DEBIAN_FILE_NAME"). See "CPACK_DEBIAN_PACKAGE_RELEASE". * The "CPackDeb" module learned how to set the package architecture per-component. See "CPACK_DEBIAN__PACKAGE_ARCHITECTURE". * The "CPackDMG" module learned a new option to tell the CPack "DragNDrop" generaor to skip the "/Applications" symlink. See the "CPACK_DMG_DISABLE_APPLICATIONS_SYMLINK" variable. * The "CPackIFW" module gained a new "cpack_ifw_update_repository()" command to update a QtIFW-specific repository from a remote repository. * The "CPackRPM" module learned how to set RPM "dist" tag as part of RPM "Release:" tag when enabled (mandatory on some Linux distributions for e.g. on Fedora). See "CPACK_RPM_PACKAGE_RELEASE_DIST". * The "CPackRPM" module learned how to set default values for owning user/group and file/directory permissions of package content. See "CPACK_RPM_DEFAULT_USER", "CPACK_RPM_DEFAULT_GROUP", "CPACK_RPM_DEFAULT_FILE_PERMISSIONS", "CPACK_RPM_DEFAULT_DIR_PERMISSIONS" and their per component counterparts. * The "CPackRPM" module learned how to set user defined package file names, how to specify that rpmbuild should decide on file name format as well as handling of multiple rpm packages generated by a single user defined spec file. See "CPACK_RPM_PACKAGE_NAME" and "CPACK_RPM__PACKAGE_NAME". * The "CPackRPM" module learned how to correctly handle symlinks that are pointing outside generated packages. Other ----- * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features =============================== * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "find_library()", "find_path()", and "find_file()" commands no longer search in installation prefixes derived from the "PATH" environment variable on non-Windows platforms. This behavior was added in CMake 3.3 to support Windows hosts but has proven problematic on UNIX hosts. Users that keep some "/bin" directories in the "PATH" just for their tools do not necessarily want any supporting "/lib" directories searched. One may set the "CMAKE_PREFIX_PATH" environment variable with a ;-list of prefixes that are to be searched. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. Other Changes ============= * The precompiled OS X binary provided on "cmake.org" now requires OS X 10.7 or newer. * On Linux and FreeBSD platforms, when building CMake itself from source and not using a system-provided libcurl, OpenSSL is now used by default if it is found on the system. This enables SSL/TLS support for commands supporting network communication via "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and "ctest_submit()". * The "cmake(1)" "--build" command-line tool now rejects multiple "-- target" options with an error instead of silently ignoring all but the last one. * "AUTOMOC" now diagnoses name collisions when multiple source files in different directories use "#include " with the same name (because the generated "moc_foo.cpp" files would collide). * The "FindBISON" module "BISON_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindFLEX" module "FLEX_TARGET" macro now supports special characters by passing the "VERBATIM" option to internal "add_custom_command()" calls. This may break clients that added escaping manually to work around the bug. * The "FindProtobuf" module input and output variables were all renamed from "PROTOBUF_" to "Protobuf_" for consistency with other find modules. Input variables of the old case will be honored if provided, and output variables of the old case are always provided. * The "CPackRPM" module now supports upper cased component names in per component CPackRPM specific variables. E.g. component named "foo" now expects component specific variable to be "CPACK_RPM_FOO_PACKAGE_NAME" while before it expected "CPACK_RPM_foo_PACKAGE_NAME". Upper cased component name part in variables is compatible with convention used for other CPack variables. For back compatibility old format of variables is still valid and preferred if both versions of variable are set, but the preferred future use is upper cased component names in variables. New variables that will be added to CPackRPM in later versions will only support upper cased component variable format. ---------------------------------------------------------------------------- Changes made since CMake 3.6.0-rc4: Brad King (4): InstallRequiredSystemLibraries: Document UCRT option use case Help: Document CMAKE_TRY_COMPILE_PLATFORM_VARIABLES example clang-format.bash: Fix filter-branch example documentation CMake 3.6.0 Konstantin Podsvirov (1): CPackIFW: Fix attributes for Promoting Updates repository replacement O Libre (1): FindJNI: Fix support for Ubuntu 15.10 From rcdailey.lists at gmail.com Thu Jul 7 16:59:13 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 7 Jul 2016 15:59:13 -0500 Subject: [CMake] Ninja + parallel linking Message-ID: I notice on ninja builds generated via CMake 3.6, the link step blocks compilation threads. What I expect is that if I have 32 threads available for compiling, those are also shared via the link step. In other words, if I reach a link step, I want it to consume 1 thread and the other 31 threads start compiling translation units for the next library. Is there a reason it isn't behaving as I describe? Is there a setting or CMake option I can set to enable this? From brad.king at kitware.com Fri Jul 8 11:40:38 2016 From: brad.king at kitware.com (Brad King) Date: Fri, 8 Jul 2016 11:40:38 -0400 Subject: [CMake] Ninja + parallel linking In-Reply-To: References: Message-ID: <577FC976.1070606@kitware.com> On 07/07/2016 04:59 PM, Robert Dailey wrote: > I notice on ninja builds generated via CMake 3.6, the link step blocks > compilation threads. What I expect is that if I have 32 threads > available for compiling, those are also shared via the link step. In > other words, if I reach a link step, I want it to consume 1 thread and > the other 31 threads start compiling translation units for the next > library. > > Is there a reason it isn't behaving as I describe? Is there a setting > or CMake option I can set to enable this? This happens because CMake generates order-only dependencies on the compilation rules of each exe/lib's objects to make sure the do not compile until linking of dependencies is done. This makes the build semantics match that of other generators where each logical target is treated as its own isolated build that is evaluated only when its logical target dependencies have been finished. This is unfortunately necessary to get correct builds for CMake projects in general because we support cases where add_custom_command is used in library "foo" to generate a header file that is included during compilation in library "bar" that links to "foo", but we have no good way to express this dependency besides the ordering dependency of bar on foo. It is likely possible to detect causes automatically when this is not necessary, such as when the transitive closure of a target's dependencies contains no custom commands. A dedicated effort will be needed to investigate this further and implement such optimizations on the build graph generation. -Brad From ben.boeckel at kitware.com Fri Jul 8 11:55:45 2016 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 8 Jul 2016 11:55:45 -0400 Subject: [CMake] Ninja + parallel linking In-Reply-To: <577FC976.1070606@kitware.com> References: <577FC976.1070606@kitware.com> Message-ID: <20160708155545.GA22123@megas.kitware.com> On Fri, Jul 08, 2016 at 11:40:38 -0400, Brad King wrote: > This happens because CMake generates order-only dependencies on the > compilation rules of each exe/lib's objects to make sure the do not > compile until linking of dependencies is done. This makes the build > semantics match that of other generators where each logical target is > treated as its own isolated build that is evaluated only when its > logical target dependencies have been finished. > > This is unfortunately necessary to get correct builds for CMake projects > in general because we support cases where add_custom_command is used > in library "foo" to generate a header file that is included during > compilation in library "bar" that links to "foo", but we have no good > way to express this dependency besides the ordering dependency of bar > on foo. > > It is likely possible to detect causes automatically when this is > not necessary, such as when the transitive closure of a target's > dependencies contains no custom commands. A dedicated effort will be > needed to investigate this further and implement such optimizations > on the build graph generation. There's an issue for this already: https://gitlab.kitware.com/cmake/cmake/issues/15555 I've brainstormed how to detect when the dependencies can be dropped (it's on some paper around here somewhere...), but haven't implemented it yet. --Ben From santipagola1 at icloud.com Sat Jul 9 06:18:29 2016 From: santipagola1 at icloud.com (Santiago Pagola) Date: Sat, 09 Jul 2016 10:18:29 +0000 (GMT) Subject: [CMake] Issues when cmake prints compiler messages Message-ID: Hello everyone! I am new on this list, and I would like to ask if someone here has experienced the same error me: When I try to compile any project (or even simple programs), the compiler starts printing information. It seems normal except for the fact that when it comes to variable names, these are not shown (that is, instead of showing something like: Warning: unused parameter 'm_dummy_variable' It shows the following: Warning: unused parameter ' ? ? ? ? ? ? ? ' The thing is that, when I try to copy-paste the output from the console to a text file, the variables are indeed there, which leads me to believe that the variable names in the terminal may be of the same color that the background of the terminal itself. Has anyone had this little issue before? Is is something directly related with cmake or is it the compiler? Any suggestions? Thanks in advance! Best regards, /Santiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsvanbethlehem at gmail.com Sat Jul 9 08:17:36 2016 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Sat, 9 Jul 2016 14:17:36 +0200 Subject: [CMake] Issues when cmake prints compiler messages In-Reply-To: References: Message-ID: Hej Santiago, Before being able to help you further, I guess it makes sense to fill in some details here: which OS, which compiler (version), which version of CMake. Personally I have never seen anything like this on a broad range of OS/compiler combinations. Also, since you suspect the background color of the terminal is the problem here, you could tell us about the background color you set for your terminal. Even simpler would be for you to change the background color of the terminal, and run the compiler again to verify whether your suspicion is correct or not. Sincerely, Jakob > On 09 Jul 2016, at 12:18, Santiago Pagola wrote: > > Hello everyone! > > I am new on this list, and I would like to ask if someone here has experienced the same error me: > > When I try to compile any project (or even simple programs), the compiler starts printing information. It seems normal except for the fact that when it comes to variable names, these are not shown (that is, instead of showing something like: > > Warning: unused parameter 'm_dummy_variable' > > It shows the following: > > Warning: unused parameter ' ' > > The thing is that, when I try to copy-paste the output from the console to a text file, the variables are indeed there, which leads me to believe that the variable names in the terminal may be of the same color that the background of the terminal itself. > > Has anyone had this little issue before? Is is something directly related with cmake or is it the compiler? Any suggestions? > > Thanks in advance! > > Best regards, > /Santiago > -- > > 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 rcdailey.lists at gmail.com Sat Jul 9 19:03:54 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sat, 9 Jul 2016 18:03:54 -0500 Subject: [CMake] Unable to find source files in different directory using target_sources(INTERFACE) Message-ID: I have the following: cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR) project(foo) add_library(foo INTERFACE) target_sources(foo INTERFACE foo.h) add_subdirectory(subdir) And inside subdir, I specify add_executable() and then target_link_libraries(myexe foo). I get an error: Cannot find source file: foo.h I'm using CMake 3.6. What am I doing wrong here? My goal is to generate a header-only project in Visual Studio. According to the documentation, what I'm trying to do won't give me that. Instead, foo.h would exist in every project that links to it as a dependency (that's what it seems like anyhow). Advice is appreciated. From craig.scott at crascit.com Sat Jul 9 20:04:06 2016 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 10 Jul 2016 10:04:06 +1000 Subject: [CMake] Unable to find source files in different directory using target_sources(INTERFACE) In-Reply-To: References: Message-ID: When using target_sources(), if you specify the source file(s) with a relative path, CMake does not convert that to an absolute path when storing it in the target's SOURCES property (that's my interpretation anyway). The end result is that the source you specify is going to be interpreted as being relative to the source directory the dependent target is defined in, not the directory where you called target_sources(). You can prevent the problem you described by ensuring the path for the source file(s) is always an absolute one. For example: target_sources(foo INTERFACE "${CMAKE_CURRENT_LIST_DIR}/foo.h") You may find the following blog article useful (it discusses the above problem and also other related material): https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/ On Sun, Jul 10, 2016 at 9:03 AM, Robert Dailey wrote: > I have the following: > > cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR) > project(foo) > add_library(foo INTERFACE) > target_sources(foo INTERFACE foo.h) > add_subdirectory(subdir) > > And inside subdir, I specify add_executable() and then > target_link_libraries(myexe foo). > > I get an error: > > Cannot find source file: foo.h > > I'm using CMake 3.6. What am I doing wrong here? > > My goal is to generate a header-only project in Visual Studio. > According to the documentation, what I'm trying to do won't give me > that. Instead, foo.h would exist in every project that links to it as > a dependency (that's what it seems like anyhow). > > Advice is appreciated. > -- > > 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 http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sat Jul 9 20:23:46 2016 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 10 Jul 2016 10:23:46 +1000 Subject: [CMake] Unable to find source files in different directory using target_sources(INTERFACE) In-Reply-To: References: Message-ID: Sorry, hit the send button prematurely. To achieve your desired goal of creating a header only library as a target in Visual Studio, it somewhat depends on what you want to do with that library. If you just want it to be there so you can see the header in the IDE, then simply defining a dummy custom target is one approach I've seen people use. E.g. add_custom_target(foo SOURCES foo.h) If you want to actually link to the target so it can provide header search path dependencies, then the approach you tried is probably the closest (with the use of absolute paths as described in my previous email). As you discovered though, it adds the header to the sources list of each project linking against it, which it sounds like you want to avoid. An interface library doesn't create build output on its own, so it doesn't make sense for it to have its own list of sources. The only way sources make sense for it is for those sources to be added to anything linking against it, which is the behaviour you are seeing. On Sun, Jul 10, 2016 at 10:04 AM, Craig Scott wrote: > When using target_sources(), if you specify the source file(s) with a > relative path, CMake does not convert that to an absolute path when storing > it in the target's SOURCES property (that's my interpretation anyway). The > end result is that the source you specify is going to be interpreted as > being relative to the source directory the dependent target is defined in, > not the directory where you called target_sources(). You can prevent the > problem you described by ensuring the path for the source file(s) is always > an absolute one. For example: > > target_sources(foo INTERFACE "${CMAKE_CURRENT_LIST_DIR}/foo.h") > > You may find the following blog article useful (it discusses the above > problem and also other related material): > > > https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/ > > > > > On Sun, Jul 10, 2016 at 9:03 AM, Robert Dailey > wrote: > >> I have the following: >> >> cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR) >> project(foo) >> add_library(foo INTERFACE) >> target_sources(foo INTERFACE foo.h) >> add_subdirectory(subdir) >> >> And inside subdir, I specify add_executable() and then >> target_link_libraries(myexe foo). >> >> I get an error: >> >> Cannot find source file: foo.h >> >> I'm using CMake 3.6. What am I doing wrong here? >> >> My goal is to generate a header-only project in Visual Studio. >> According to the documentation, what I'm trying to do won't give me >> that. Instead, foo.h would exist in every project that links to it as >> a dependency (that's what it seems like anyhow). >> >> Advice is appreciated. >> -- >> >> 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 > http://crascit.com > -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Sat Jul 9 21:37:10 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sat, 9 Jul 2016 20:37:10 -0500 Subject: [CMake] Unable to find source files in different directory using target_sources(INTERFACE) In-Reply-To: References: Message-ID: Thanks, I just verified that doing absolute path works. I find it frustrating though that relative paths aren't calculated to absolute at the time the function is called, though. I feel like CMake should be doing this for me. On Sat, Jul 9, 2016 at 7:23 PM, Craig Scott wrote: > Sorry, hit the send button prematurely. To achieve your desired goal of > creating a header only library as a target in Visual Studio, it somewhat > depends on what you want to do with that library. If you just want it to be > there so you can see the header in the IDE, then simply defining a dummy > custom target is one approach I've seen people use. E.g. > > add_custom_target(foo SOURCES foo.h) > > If you want to actually link to the target so it can provide header search > path dependencies, then the approach you tried is probably the closest (with > the use of absolute paths as described in my previous email). As you > discovered though, it adds the header to the sources list of each project > linking against it, which it sounds like you want to avoid. An interface > library doesn't create build output on its own, so it doesn't make sense for > it to have its own list of sources. The only way sources make sense for it > is for those sources to be added to anything linking against it, which is > the behaviour you are seeing. > > > > > > On Sun, Jul 10, 2016 at 10:04 AM, Craig Scott > wrote: >> >> When using target_sources(), if you specify the source file(s) with a >> relative path, CMake does not convert that to an absolute path when storing >> it in the target's SOURCES property (that's my interpretation anyway). The >> end result is that the source you specify is going to be interpreted as >> being relative to the source directory the dependent target is defined in, >> not the directory where you called target_sources(). You can prevent the >> problem you described by ensuring the path for the source file(s) is always >> an absolute one. For example: >> >> target_sources(foo INTERFACE "${CMAKE_CURRENT_LIST_DIR}/foo.h") >> >> You may find the following blog article useful (it discusses the above >> problem and also other related material): >> >> >> https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/ >> >> >> >> >> On Sun, Jul 10, 2016 at 9:03 AM, Robert Dailey >> wrote: >>> >>> I have the following: >>> >>> cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR) >>> project(foo) >>> add_library(foo INTERFACE) >>> target_sources(foo INTERFACE foo.h) >>> add_subdirectory(subdir) >>> >>> And inside subdir, I specify add_executable() and then >>> target_link_libraries(myexe foo). >>> >>> I get an error: >>> >>> Cannot find source file: foo.h >>> >>> I'm using CMake 3.6. What am I doing wrong here? >>> >>> My goal is to generate a header-only project in Visual Studio. >>> According to the documentation, what I'm trying to do won't give me >>> that. Instead, foo.h would exist in every project that links to it as >>> a dependency (that's what it seems like anyhow). >>> >>> Advice is appreciated. >>> -- >>> >>> 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 >> http://crascit.com > > > > > -- > Craig Scott > Melbourne, Australia > http://crascit.com From Dvir.Yitzchaki at ceva-dsp.com Sun Jul 10 01:04:35 2016 From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki) Date: Sun, 10 Jul 2016 05:04:35 +0000 Subject: [CMake] CMAKE_C++_CREATE_SHARED_LIBRARY missing Message-ID: <71350F7ED6EBB54AA2D182B26086A1B60114AC591B@ILMAIL1.corp.local> Hi. I use cmake 3.3.1 on Red-Hat 5 and 6. When I generate a project I get the following error: CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_C++_CREATE_SHARED_LIBRARY However, after the error the generation succeeds and I can build the project successfully. The same project is generated without errors on Windows 7 with Visual Studio generators and other projects are also generated without errors on the same Linux machine. Does anyone knows the source of that error? Thanks, Dvir -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleigh at codelibre.net Sun Jul 10 07:35:23 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Sun, 10 Jul 2016 11:35:23 +0000 Subject: [CMake] CMake with VS2015 C++ Build Tools and missing ucrtbased.dll Message-ID: <578232FB.8040804@codelibre.net> I'm doing some initial testing of CMake 3.6.0 with the newly-released Visual Studio 2015 Update 3 C++ Build Tools (http://landinghub.visualstudio.com/visual-cpp-build-tools). I.e. the standalone compiler without the IDE. I'm configuring with: cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug|Release [in an x64 native tools command prompt] cmake -G "Visual Studio 14 2015 Win64" And then building and running the unit tests with ctest. With a release build using either generator, all the tests run and pass. With a debug build using either generator, every test fails with the message: - System Error The program can't start because ucrtbased.dll is missing from your computer. Try reinstalling the program to fix this problem. The DLL *is* installed on the system: /cygdrive/c/Program Files (x86)/Microsoft SDKs/Windows Kits/10/ExtensionSDKs/Microsoft.UniversalCRT.Debug/10.0.10240.0/Redist/Debug/arm/ucrtbased.dll /cygdrive/c/Program Files (x86)/Microsoft SDKs/Windows Kits/10/ExtensionSDKs/Microsoft.UniversalCRT.Debug/10.0.10240.0/Redist/Debug/arm64/ucrtbased.dll /cygdrive/c/Program Files (x86)/Microsoft SDKs/Windows Kits/10/ExtensionSDKs/Microsoft.UniversalCRT.Debug/10.0.10240.0/Redist/Debug/x64/ucrtbased.dll /cygdrive/c/Program Files (x86)/Microsoft SDKs/Windows Kits/10/ExtensionSDKs/Microsoft.UniversalCRT.Debug/10.0.10240.0/Redist/Debug/x86/ucrtbased.dll /cygdrive/c/Program Files (x86)/Windows Kits/10/bin/arm/ucrt/ucrtbased.dll /cygdrive/c/Program Files (x86)/Windows Kits/10/bin/arm64/ucrt/ucrtbased.dll /cygdrive/c/Program Files (x86)/Windows Kits/10/bin/x64/ucrt/ucrtbased.dll /cygdrive/c/Program Files (x86)/Windows Kits/10/bin/x86/ucrt/ucrtbased.dll And the environment: INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE;C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt;C:\Program Files (x86)\Windows Kits\8.1\include\shared;C:\Program Files (x86)\Windows Kits\8.1\include\um;C:\Program Files (x86)\Windows Kits\8.1\include\winrt; LIB=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64;C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x64;C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x64; LIBPATH=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Windows\Microsoft.NET\Framework64\;References\CommonConfiguration\Neutral;\Microsoft.VCLibs\14.0\References\CommonConfiguration\neutral; Path=c:\opt\bin;C:\Program Files (x86)\MSBuild\14.0\bin\amd64;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Windows\Microsoft.NET\Framework64\;C:\Program Files (x86)\Windows Kits\8.1\bin\x64;C:\Program Files (x86)\Windows Kits\8.1\bin\x86;C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\PuTTY\;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\Program Files\CMake\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Users\rleigh\AppData\Local\Programs\Git\cmd But for some reason it's not on the PATH while the release version of the ucrtbase.dll is. I'm not sure if this is a bug in the VS command prompt environment--"Windows Kits/8.1/bin/x64" is on the path, but not "Windows Kits/10/bin/x64", while both are in the include path... Could this be a bug in the VS command prompt environment? Or is this more likely to be a cmake issue? The code in question is https://github.com/rleigh-dundee/xercesc-cmake (I'm working on a conversion of the autotools and VS project files to a cmake build), but I suspect this would happen with any project which wants to run a debug executable. Thanks, Roger From andi at lisas.de Sun Jul 10 12:11:35 2016 From: andi at lisas.de (Andreas Mohr) Date: Sun, 10 Jul 2016 18:11:35 +0200 Subject: [CMake] CMAKE_C++_CREATE_SHARED_LIBRARY missing In-Reply-To: <71350F7ED6EBB54AA2D182B26086A1B60114AC591B@ILMAIL1.corp.local> Message-ID: <20160710161135.GA30778@rhlx01.hs-esslingen.de> Hi, On Sun, Jul 10, 2016 at 12:00:02PM -0400, cmake-request at cmake.org wrote: > Message: 1 > Date: Sun, 10 Jul 2016 05:04:35 +0000 > From: Dvir Yitzchaki > To: "'cmake at cmake.org'" > Subject: [CMake] CMAKE_C++_CREATE_SHARED_LIBRARY missing > Message-ID: > <71350F7ED6EBB54AA2D182B26086A1B60114AC591B at ILMAIL1.corp.local> > Content-Type: text/plain; charset="us-ascii" > > Hi. > > I use cmake 3.3.1 on Red-Hat 5 and 6. > When I generate a project I get the following error: > > CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. > Missing variable is: > CMAKE_C++_CREATE_SHARED_LIBRARY > > However, after the error the generation succeeds and I can build the project successfully. > The same project is generated without errors on Windows 7 with Visual Studio generators and other projects are also generated without errors on the same Linux machine. > > Does anyone knows the source of that error? Rimshot idea: Quite possibly someone did a project(foo C C++) rather than using the (IIRC - no docs here ATM) correct CXX. HTH, Andreas Mohr From rcdailey.lists at gmail.com Sun Jul 10 14:23:46 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sun, 10 Jul 2016 13:23:46 -0500 Subject: [CMake] Convenience version of CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE for INTERFACE_SOURCES Message-ID: I am exporting/installing a header-only INTERFACE library and I run into difficulty with target_sources() because I can't use relative paths to the files. So I do this: set(project_name fubar) set(source_files myfile.h ) # Include dir for installed targets set(INCLUDE_DIR include/${project_name}-${upstream_version}) foreach(source_file ${source_files}) get_filename_component(abs_source_file ${source_file} ABSOLUTE) list(APPEND absolute_source_files $ $ ) endforeach() add_library(${project_name} INTERFACE) target_sources(${project_name} INTERFACE ${absolute_source_files}) Without the separate generator expressions for BUILD_INTERFACE and INSTALL_INTERFACE, CMake complains that absolute paths are not inside INSTALL_PREFIX in my install() command later: CMake Error in CMakeLists.txt: Target "better-enums" INTERFACE_SOURCES property contains path: "C:/code/fubar/myfile.h" which is prefixed in the source directory. Corresponding install() command is: install(TARGETS ${project_name} EXPORT ${project_name}-targets INCLUDES DESTINATION ${INCLUDE_DIR} ) export(EXPORT ${project_name}-targets FILE ${CMAKE_CURRENT_BINARY_DIR}/${project_name}-targets.cmake ) install(EXPORT ${project_name}-targets FILE ${project_name}-targets.cmake DESTINATION ${package_config_dir} ) For INTERFACE_INCLUDE_DIRECTORIES, this same problem exists except CMake provides a convenience toggle called INTERFACE_SYSTEM_INCLUDE_DIRECTORIES. Is there a similar convenience for interface sources? Or maybe I'm going about this all the wrong way? Honestly the only reason interface sources are specified is because I have a header-only library and I want that header to show up in only MY targets during development so I can edit those header files through my IDE. I do not expect the header files to appear in targets that simply import my target as a dependency. So it's possible I'm going about this the wrong way. Advice is greatly appreciated. From rcdailey.lists at gmail.com Sun Jul 10 15:16:21 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sun, 10 Jul 2016 14:16:21 -0500 Subject: [CMake] Automatic inclusion of import targets found by find_package()? Message-ID: Let's say I have my own upstream library and I export a target for it. This subsequent cmake file (containing my IMPORT target definition) is included with my tarball. When a consuming project wants to find and use my import targets, they currently have to do (consider this pseudocode since i just typed it up for example purposes): find_package(mylibrary REQUIRED CONFIG) include(${mylibrary_DIR}/lib/cmake/mylibrary-0.1.2/mylibrary.cmake) add_executable(fubar mylibrary) It would be nice if the include part happened automatically. Mostly because since the version number is intertwined with the path, it makes explicitly specifying it cumbersome and high maintenance. Is there more automation here that I'm not seeing? Thanks in advance. From steveire at gmail.com Sun Jul 10 18:11:25 2016 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 11 Jul 2016 00:11:25 +0200 Subject: [CMake] Automatic inclusion of import targets found by find_package()? References: Message-ID: Robert Dailey wrote: > Is there more automation here that I'm not seeing? Thanks in advance. Yes, the documentation tells you to include what you need in the config file: https://cmake.org/cmake/help/v3.6/manual/cmake-packages.7.html#creating-a-package-configuration-file Thanks, Steve. From rcdailey.lists at gmail.com Sun Jul 10 18:26:02 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sun, 10 Jul 2016 17:26:02 -0500 Subject: [CMake] Why is target installation done in 2 separate steps? Message-ID: Documentation states, that to export a file that imports your targets, you must do roughly: install(TARGETS fubar EXPORT fubar-targets) install(EXPORT fubar-targets DESTINATION lib/cmake/fubar) Why is this done in two steps? Based on reading the install() documentation, I don't see how the install(TARGETS) command is useful without the corresponding install(EXPORT). Can someone explain why these are separate commands instead of 1 complete command? Thanks in advance. From rcdailey.lists at gmail.com Sun Jul 10 18:27:10 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sun, 10 Jul 2016 17:27:10 -0500 Subject: [CMake] Automatic inclusion of import targets found by find_package()? In-Reply-To: References: Message-ID: On Sun, Jul 10, 2016 at 5:11 PM, Stephen Kelly wrote: > Robert Dailey wrote: > >> Is there more automation here that I'm not seeing? Thanks in advance. > > Yes, the documentation tells you to include what you need in the config > file: > > https://cmake.org/cmake/help/v3.6/manual/cmake-packages.7.html#creating-a-package-configuration-file Thanks, I realized this a bit too late. The title of the section was a little misleading, I thought that section would go over the normal find module scenario, not the config package one. In other words, the section above it already gave instructions on creating the config package file. From rcdailey.lists at gmail.com Sun Jul 10 18:29:33 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sun, 10 Jul 2016 17:29:33 -0500 Subject: [CMake] Convenience version of CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE for INTERFACE_SOURCES In-Reply-To: References: Message-ID: On Sun, Jul 10, 2016 at 1:23 PM, Robert Dailey wrote: > I am exporting/installing a header-only INTERFACE library and I run > into difficulty with target_sources() because I can't use relative > paths to the files. So I do this: > > > > set(project_name fubar) > > set(source_files > myfile.h > ) > > # Include dir for installed targets > set(INCLUDE_DIR include/${project_name}-${upstream_version}) > > foreach(source_file ${source_files}) > get_filename_component(abs_source_file ${source_file} ABSOLUTE) > list(APPEND absolute_source_files > $ > $ > ) > endforeach() > > add_library(${project_name} INTERFACE) > target_sources(${project_name} INTERFACE ${absolute_source_files}) > > > > Without the separate generator expressions for BUILD_INTERFACE and > INSTALL_INTERFACE, CMake complains that absolute paths are not inside > INSTALL_PREFIX in my install() command later: > > > > CMake Error in CMakeLists.txt: > Target "better-enums" INTERFACE_SOURCES property contains path: > > "C:/code/fubar/myfile.h" > > which is prefixed in the source directory. > > > > Corresponding install() command is: > > > install(TARGETS ${project_name} EXPORT ${project_name}-targets > INCLUDES DESTINATION ${INCLUDE_DIR} > ) > > export(EXPORT ${project_name}-targets > FILE ${CMAKE_CURRENT_BINARY_DIR}/${project_name}-targets.cmake > ) > > install(EXPORT ${project_name}-targets > FILE ${project_name}-targets.cmake > DESTINATION ${package_config_dir} > ) > > For INTERFACE_INCLUDE_DIRECTORIES, this same problem exists except > CMake provides a convenience toggle called > INTERFACE_SYSTEM_INCLUDE_DIRECTORIES. Is there a similar convenience > for interface sources? Or maybe I'm going about this all the wrong > way? > > Honestly the only reason interface sources are specified is because I > have a header-only library and I want that header to show up in only > MY targets during development so I can edit those header files through > my IDE. I do not expect the header files to appear in targets that > simply import my target as a dependency. > > So it's possible I'm going about this the wrong way. Advice is greatly > appreciated. So after I posted this, I made a minor change so that my INTERFACE_SOURCES property (modified via the target_sources() command) simply doesn't specify a listing for INSTALL_INTERFACE. Basically only the BUILD_INTERFACE is populated. I think this gives me the desired output, since I do not want downstream targets to inherit my library's public headers in their own project's file listing. They only get the public include directories instead. I still feel like I'm doing things wrong or sub-optimally, so feedback is still very much appreciated. From smithbreannan at gmail.com Sun Jul 10 18:34:15 2016 From: smithbreannan at gmail.com (Breannan Smith) Date: Sun, 10 Jul 2016 15:34:15 -0700 Subject: [CMake] CMake Reports Incorrect HDF5 Libraries on OS X after 3.6.0 Upgrade Message-ID: After upgrading to CMake 3.6.0 from 3.5.2, CMake fails to find HDF5 on OS X. With 3.5.2, find_package(HDF5 REQUIRED COMPONENTS C) reports the following for HDF5_LIBRARIES. Note the presences of libhdf5.dylib, in this list: /usr/local/Cellar/hdf5/1.8.16_1/lib/libhdf5.dylib;/usr/local/opt/szip/lib/libsz.dylib;/usr/lib/libz.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib With 3.6.0, the same find_package command gives the following HDF5_LIBRARIES. Notice that libhdf5.dylib is not even present: /usr/local/lib/libsz.dylib;/usr/lib/libz.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib The contents of the HDF5_LIBRARIES and HDF5_C_LIBRARIES are the same under 3.6.0. Interestingly, the FindHDF5.cmake module does not report a failure under 3.6.0 even though it fails to locate the HDF5 library. I did not see any changes to FindHDF5.cmake listed under the 3.6 release notes [1], but diffing the module files there were extensive edits made. Has anyone else run into this issue or found a fix? Thank you! [1] https://cmake.org/cmake/help/v3.6/release/3.6.html From Dvir.Yitzchaki at ceva-dsp.com Mon Jul 11 03:17:47 2016 From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki) Date: Mon, 11 Jul 2016 07:17:47 +0000 Subject: [CMake] CMAKE_C++_CREATE_SHARED_LIBRARY missing In-Reply-To: <20160710161135.GA30778@rhlx01.hs-esslingen.de> References: <71350F7ED6EBB54AA2D182B26086A1B60114AC591B@ILMAIL1.corp.local> <20160710161135.GA30778@rhlx01.hs-esslingen.de> Message-ID: <71350F7ED6EBB54AA2D182B26086A1B60114AC9C41@ILMAIL1.corp.local> You were close. I searched for 'C++' in all our CMakeLists.txt and found the line set_target_properties(foo PROPERTIES LINKER_LANGUAGE C++) changed that to CXX and now the error is gone. Thanks, Dvir -----Original Message----- From: Andreas Mohr [mailto:andi at lisas.de] Sent: Sunday, July 10, 2016 7:12 PM To: cmake at cmake.org Cc: Dvir Yitzchaki Subject: Re: [CMake] CMAKE_C++_CREATE_SHARED_LIBRARY missing Hi, On Sun, Jul 10, 2016 at 12:00:02PM -0400, cmake-request at cmake.org wrote: > Message: 1 > Date: Sun, 10 Jul 2016 05:04:35 +0000 > From: Dvir Yitzchaki > To: "'cmake at cmake.org'" > Subject: [CMake] CMAKE_C++_CREATE_SHARED_LIBRARY missing > Message-ID: > <71350F7ED6EBB54AA2D182B26086A1B60114AC591B at ILMAIL1.corp.local> > Content-Type: text/plain; charset="us-ascii" > > Hi. > > I use cmake 3.3.1 on Red-Hat 5 and 6. > When I generate a project I get the following error: > > CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. > Missing variable is: > CMAKE_C++_CREATE_SHARED_LIBRARY > > However, after the error the generation succeeds and I can build the project successfully. > The same project is generated without errors on Windows 7 with Visual Studio generators and other projects are also generated without errors on the same Linux machine. > > Does anyone knows the source of that error? Rimshot idea: Quite possibly someone did a project(foo C C++) rather than using the (IIRC - no docs here ATM) correct CXX. HTH, Andreas Mohr From michele.portolan at imag.fr Mon Jul 11 06:38:26 2016 From: michele.portolan at imag.fr (portolan) Date: Mon, 11 Jul 2016 12:38:26 +0200 Subject: [CMake] Package shared libraries when linking Message-ID: Hello, I am building a C++14 projet in CMAKE for both Intel and ARM target, so I set up the cross-compilation and everything works fine build-wise. Unfortunately my ARM target Linux kernel does not have a libstdc++.so.6 so I cannot run the executable.....is it possible to have CMAKE statically include the libraries inside the compiled file, like ld does with the -static-libstdg++ command (http://stackoverflow.com/questions/27385995/shipping-libstdc-so-6-with-application) ? Thanks, Michele From robert.maynard at kitware.com Mon Jul 11 08:52:30 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 11 Jul 2016 08:52:30 -0400 Subject: [CMake] CMake Reports Incorrect HDF5 Libraries on OS X after 3.6.0 Upgrade In-Reply-To: References: Message-ID: Hi Breannan, I am able to reproduce this and will start digging into why this is occurring. On Sun, Jul 10, 2016 at 6:34 PM, Breannan Smith wrote: > After upgrading to CMake 3.6.0 from 3.5.2, CMake fails to find HDF5 on OS X. > > With 3.5.2, find_package(HDF5 REQUIRED COMPONENTS C) reports the > following for HDF5_LIBRARIES. Note the presences of libhdf5.dylib, in > this list: > > /usr/local/Cellar/hdf5/1.8.16_1/lib/libhdf5.dylib;/usr/local/opt/szip/lib/libsz.dylib;/usr/lib/libz.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib > > With 3.6.0, the same find_package command gives the following > HDF5_LIBRARIES. Notice that libhdf5.dylib is not even present: > > /usr/local/lib/libsz.dylib;/usr/lib/libz.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib > > The contents of the HDF5_LIBRARIES and HDF5_C_LIBRARIES are the same > under 3.6.0. Interestingly, the FindHDF5.cmake module does not report > a failure under 3.6.0 even though it fails to locate the HDF5 library. > > I did not see any changes to FindHDF5.cmake listed under the 3.6 > release notes [1], but diffing the module files there were extensive > edits made. > > Has anyone else run into this issue or found a fix? Thank you! > > [1] https://cmake.org/cmake/help/v3.6/release/3.6.html > -- > > 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 michele.portolan at imag.fr Tue Jul 12 03:00:43 2016 From: michele.portolan at imag.fr (portolan) Date: Tue, 12 Jul 2016 09:00:43 +0200 Subject: [CMake] Splitting in multiple directories Message-ID: Hello, I am new to Cmake and I have a pretty strange behaviour: I set my c+++ project to work with a single CMakefile.txt, and now I am trying to have a more proper version with a .txt for each subdirectory Pretty normal stuff, my source tree is: --Lib (my sources) --Logger (as the name says, a logger) --Lib_UT (Unitary tests for CxxTest) --Lib_UT_Runner (the Cxx-generated test runner) I have a Lib_UT/CMakefile.txt and Lib_UT_Runner/CMakefile.txt, I call them using include_directory(Lib_UT) and include_directory(Lib_UT_Runner) and everything is fine (apart from the runner executable being in a different directory) BUT is I do the same for the logger, Lib_UT_Runner has a linking error where it cannot link to LibLogger.so. But the shared library is correctly generated and it is on the command line : /usr/bin/c++ -lpthread CMakeFiles/Lib_UT_Runner.dir/Runner.cpp.o -o Lib_UT_Runner ../Lib_UT/libLib_UT.so ../libLib.so ../libLogger.so -lpthread -Wl,-rpath,/home/michele/mast-devel/cmake_debug/Lib_UT:/home/michele/mast-devel/cmake_debug:/home/michele/mast-devel/cmake_debug/Logger I tried using find_library, but I always get not-found What am I missing? Regards, Michele From robert.maynard at kitware.com Tue Jul 12 08:12:36 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 12 Jul 2016 08:12:36 -0400 Subject: [CMake] CMake Reports Incorrect HDF5 Libraries on OS X after 3.6.0 Upgrade In-Reply-To: References: Message-ID: Hi Breannan, You can track the status of the fix at https://gitlab.kitware.com/cmake/cmake/merge_requests/34 On Mon, Jul 11, 2016 at 8:52 AM, Robert Maynard wrote: > Hi Breannan, > > I am able to reproduce this and will start digging into why this is occurring. > > On Sun, Jul 10, 2016 at 6:34 PM, Breannan Smith wrote: >> After upgrading to CMake 3.6.0 from 3.5.2, CMake fails to find HDF5 on OS X. >> >> With 3.5.2, find_package(HDF5 REQUIRED COMPONENTS C) reports the >> following for HDF5_LIBRARIES. Note the presences of libhdf5.dylib, in >> this list: >> >> /usr/local/Cellar/hdf5/1.8.16_1/lib/libhdf5.dylib;/usr/local/opt/szip/lib/libsz.dylib;/usr/lib/libz.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib >> >> With 3.6.0, the same find_package command gives the following >> HDF5_LIBRARIES. Notice that libhdf5.dylib is not even present: >> >> /usr/local/lib/libsz.dylib;/usr/lib/libz.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib >> >> The contents of the HDF5_LIBRARIES and HDF5_C_LIBRARIES are the same >> under 3.6.0. Interestingly, the FindHDF5.cmake module does not report >> a failure under 3.6.0 even though it fails to locate the HDF5 library. >> >> I did not see any changes to FindHDF5.cmake listed under the 3.6 >> release notes [1], but diffing the module files there were extensive >> edits made. >> >> Has anyone else run into this issue or found a fix? Thank you! >> >> [1] https://cmake.org/cmake/help/v3.6/release/3.6.html >> -- >> >> 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 Harry at codexdigital.com Tue Jul 12 12:49:55 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Tue, 12 Jul 2016 16:49:55 +0000 Subject: [CMake] OSX Code Signing best practice Message-ID: Hello all, What is the current best practice for code signing OSX .apps and binaries? I am using: 1. MAC_OSX_BUNDLE for my .app targets. 2. unix style executables 3. dylibs 4. A prefpane (which I haven't got working yet) using something like the below: add_library(prefpane MODULE ${sourceFiles} ) set_target_properties(codexprefpane PROPERTIES BUNDLE YES BUNDLE_EXTENSION prefPane XCODE_ATTRIBUTE_WRAPPER_EXTENSION prefPane MACOSX_BUNDLE_INFO_PLIST ${prefpane_plist_file} ) I am not using the CPackBundle generator so I cannot use the signing in that. I have tried: 1. Using set_target_properties( .... "XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY" "${SIGN_ID}") 2. Using an add_custom_command step. This code signs before all the Resources are copied in so the signatures are invalid Any ideas? Harry Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 From andrey.fedorov at gmail.com Tue Jul 12 13:33:37 2016 From: andrey.fedorov at gmail.com (Andrey Fedorov) Date: Tue, 12 Jul 2016 13:33:37 -0400 Subject: [CMake] Error: cannot find DartConfiguration.tcl on windows In-Reply-To: References: Message-ID: I resolved this issue by passing "-C Release" to ctest On Fri, Jul 1, 2016 at 3:30 PM, Andrey Fedorov wrote: > Hi, > > I am doing continuous integration testing on appveyor, and I am getting > this error: > > https://ci.appveyor.com/project/fedorov/dcmqi/build/0.0.145 > > [image: Inline image 1] > > For the same repository, testing is working just fine on travisci and > appveyor. The versions of cmake are not identical, but the one on windows > is 3.5, quite recent. > > The source code repository is here: http://github.com/qiicr/dcmqi > > Can someone help me with this error? > > Thank you > > AF > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 117793 bytes Desc: not available URL: From dan.a.ibanez at gmail.com Tue Jul 12 14:11:10 2016 From: dan.a.ibanez at gmail.com (Dan Ibanez) Date: Tue, 12 Jul 2016 14:11:10 -0400 Subject: [CMake] best way to handle subdirectory libraries ? Message-ID: Hello, I've used CMake for a while but only recently discovered several features for better installing a package, and am trying to update the way I use CMake. My question as to do with projects which contain several modules/components/libraries, each of which is in a subdirectory. Each library may depend on other libraries in other subdirectories. I've set up two GitHub repos with my current understanding of how this should be done in CMake: https://github.com/ibaned/two_libs https://github.com/ibaned/use_two_libs This works, but a few things are naggingly sub-optimal, such as the way include directories are passed from one sub-dir to another: https://github.com/ibaned/two_libs/blob/master/add_nums/CMakeLists.txt#L8 Is there a better way to carry include dirs across scopes ? Our real project right now generates Config.cmake files for each subdirectory and then other subdirectories use find_package just to get this info across: https://github.com/SCOREC/core/blob/master/pcu/CMakeLists.txt#L44 Other projects have a whole system atop CMake that manages this. I'm trying to get a sense of what the "best" setup looks like using pure CMake. Any advice about this is much appreciated, Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Tue Jul 12 14:54:40 2016 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 12 Jul 2016 14:54:40 -0400 Subject: [CMake] best way to handle subdirectory libraries ? In-Reply-To: References: Message-ID: <065276e8-fa63-17e9-79dc-173b6f2b0d6d@kitware.com> On 7/12/2016 2:11 PM, Dan Ibanez wrote: > Other projects have a whole system atop CMake that manages this. > I'm trying to get a sense of what the "best" setup looks like using pure > CMake. > See Usage Requirements: https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#id10 https://cmake.org/cmake/help/v3.0/prop_tgt/INTERFACE_INCLUDE_DIRECTORIES.html -Bill From zcsd2012 at gmail.com Tue Jul 12 22:54:27 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Tue, 12 Jul 2016 19:54:27 -0700 (MST) Subject: [CMake] Does Makefile generated by CMake support make -jN? Message-ID: <1468378467509-7593949.post@n2.nabble.com> Hi, all, I was trying to compile my project using CMake, after CMake generated Makefile. I used `/usr/bin/time -v make` to make the Makefile, got the result: 'Percent of CPU this job got: 96%'. Then i used `/usr/bin/time -v make -j8` to make the Makefile, the result of CPU used is 'Percent of CPU this job got: 648%'. So i wonder if Makefile generated by CMake support make -jN, BTW my CPU is I7-4790, and after i use 'cat /proc/cpuinfo', there are 8 processors. Thanks a lot, Chao -- View this message in context: http://cmake.3232098.n2.nabble.com/Does-Makefile-generated-by-CMake-support-make-jN-tp7593949.html Sent from the CMake mailing list archive at Nabble.com. From rwan.work at gmail.com Tue Jul 12 23:01:11 2016 From: rwan.work at gmail.com (Raymond Wan) Date: Wed, 13 Jul 2016 11:01:11 +0800 Subject: [CMake] Does Makefile generated by CMake support make -jN? In-Reply-To: <1468378467509-7593949.post@n2.nabble.com> References: <1468378467509-7593949.post@n2.nabble.com> Message-ID: Hi Chao, On Wed, Jul 13, 2016 at 10:54 AM, Chaos Zhang wrote: > I was trying to compile my project using CMake, after CMake generated > Makefile. > I used `/usr/bin/time -v make` to make the Makefile, got the result: > 'Percent of CPU this job got: 96%'. > Then i used `/usr/bin/time -v make -j8` to make the Makefile, the result of > CPU used is 'Percent of CPU this job got: 648%'. > So i wonder if Makefile generated by CMake support make -jN, BTW my CPU is > I7-4790, and after i use 'cat /proc/cpuinfo', there are 8 processors. I'm not sure what you are asking... You ran make with -j 8 and you got a percentage greater than 96% ... this implies that the Makefile does support -jN, doesn't it? If you got 96% both times, then I would say there's a problem. Is what you're wondering why it is 648% and not 800%? I think that depends on the dependencies in your Makefile. It's possible that some of them depend on each other in such a way that 8 parallel threads is not possible. Also, I can't remember the value returned by /usr/bin/time -v, but I guess 648% is the average and not maximum. So, perhaps there are parts within the Makefile that only one thread could be used and then it gets averaged out? Ray From zcsd2012 at gmail.com Tue Jul 12 23:48:37 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Tue, 12 Jul 2016 20:48:37 -0700 (MST) Subject: [CMake] Does Makefile generated by CMake support make -jN? In-Reply-To: References: <1468378467509-7593949.post@n2.nabble.com> Message-ID: <1468381717313-7593951.post@n2.nabble.com> Thanks for your reply Raymond, by 'If you got 96% both times, then I would say there's a problem.', did you mean if make performed like this, it means this project can't use make -jN? BTW, does CMake support some options to turn on hardware acceleration? Raymond Wan-2 wrote > Hi Chao, > > > On Wed, Jul 13, 2016 at 10:54 AM, Chaos Zhang < > zcsd2012@ > > wrote: >> I was trying to compile my project using CMake, after CMake generated >> Makefile. >> I used `/usr/bin/time -v make` to make the Makefile, got the result: >> 'Percent of CPU this job got: 96%'. >> Then i used `/usr/bin/time -v make -j8` to make the Makefile, the result >> of >> CPU used is 'Percent of CPU this job got: 648%'. >> So i wonder if Makefile generated by CMake support make -jN, BTW my CPU >> is >> I7-4790, and after i use 'cat /proc/cpuinfo', there are 8 processors. > > > I'm not sure what you are asking... > > You ran make with -j 8 and you got a percentage greater than 96% ... > this implies that the Makefile does support -jN, doesn't it? If you > got 96% both times, then I would say there's a problem. > > Is what you're wondering why it is 648% and not 800%? I think that > depends on the dependencies in your Makefile. It's possible that some > of them depend on each other in such a way that 8 parallel threads is > not possible. > > Also, I can't remember the value returned by /usr/bin/time -v, but I > guess 648% is the average and not maximum. So, perhaps there are > parts within the Makefile that only one thread could be used and then > it gets averaged out? > > Ray > -- > > 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 -- View this message in context: http://cmake.3232098.n2.nabble.com/Does-Makefile-generated-by-CMake-support-make-jN-tp7593949p7593951.html Sent from the CMake mailing list archive at Nabble.com. From d3ck0r at gmail.com Wed Jul 13 00:19:30 2016 From: d3ck0r at gmail.com (J Decker) Date: Tue, 12 Jul 2016 21:19:30 -0700 Subject: [CMake] Does Makefile generated by CMake support make -jN? In-Reply-To: <1468378467509-7593949.post@n2.nabble.com> References: <1468378467509-7593949.post@n2.nabble.com> Message-ID: On Tue, Jul 12, 2016 at 7:54 PM, Chaos Zhang wrote: > Hi, all, > > I was trying to compile my project using CMake, after CMake generated > Makefile. > I used `/usr/bin/time -v make` to make the Makefile, got the result: > 'Percent of CPU this job got: 96%'. > Then i used `/usr/bin/time -v make -j8` to make the Makefile, the result of > CPU used is 'Percent of CPU this job got: 648%'. > So i wonder if Makefile generated by CMake support make -jN, BTW my CPU is > I7-4790, and after i use 'cat /proc/cpuinfo', there are 8 processors. > > All the sources, headers, etc come from the IO system, from the disk, probably you're running into the bottleneck of how long it takes to move the memory for the compiler to do work on? did you profile IO ? > Thanks a lot, > Chao > > > > -- > View this message in context: > http://cmake.3232098.n2.nabble.com/Does-Makefile-generated-by-CMake-support-make-jN-tp7593949.html > Sent from the CMake mailing list archive at Nabble.com. > -- > > 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 andrew.melo at gmail.com Wed Jul 13 00:44:49 2016 From: andrew.melo at gmail.com (Andrew Melo) Date: Tue, 12 Jul 2016 23:44:49 -0500 Subject: [CMake] Does Makefile generated by CMake support make -jN? In-Reply-To: <1468381717313-7593951.post@n2.nabble.com> References: <1468378467509-7593949.post@n2.nabble.com> <1468381717313-7593951.post@n2.nabble.com> Message-ID: On Tue, Jul 12, 2016 at 10:48 PM, Chaos Zhang wrote: > Thanks for your reply Raymond, by 'If you got 96% both times, then I would > say there's a problem.', did you mean if make performed like this, it means > this project can't use make -jN? If "make -j1" and "make -j8" ran in the same amount of time, there would be a problem. Since "make -j1" uses 96% CPU and "make -j8" uses 690% CPU, it implies that the "-j" options make compilation time scale, which is what you want. > BTW, does CMake support some options to > turn on hardware acceleration? What do you mean by "hardware acceleration"? > > Raymond Wan-2 wrote >> Hi Chao, >> >> >> On Wed, Jul 13, 2016 at 10:54 AM, Chaos Zhang < > >> zcsd2012@ > >> > wrote: >>> I was trying to compile my project using CMake, after CMake generated >>> Makefile. >>> I used `/usr/bin/time -v make` to make the Makefile, got the result: >>> 'Percent of CPU this job got: 96%'. >>> Then i used `/usr/bin/time -v make -j8` to make the Makefile, the result >>> of >>> CPU used is 'Percent of CPU this job got: 648%'. >>> So i wonder if Makefile generated by CMake support make -jN, BTW my CPU >>> is >>> I7-4790, and after i use 'cat /proc/cpuinfo', there are 8 processors. >> >> >> I'm not sure what you are asking... >> >> You ran make with -j 8 and you got a percentage greater than 96% ... >> this implies that the Makefile does support -jN, doesn't it? If you >> got 96% both times, then I would say there's a problem. >> >> Is what you're wondering why it is 648% and not 800%? I think that >> depends on the dependencies in your Makefile. It's possible that some >> of them depend on each other in such a way that 8 parallel threads is >> not possible. >> >> Also, I can't remember the value returned by /usr/bin/time -v, but I >> guess 648% is the average and not maximum. So, perhaps there are >> parts within the Makefile that only one thread could be used and then >> it gets averaged out? >> >> Ray >> -- >> >> 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 > > > > > > -- > View this message in context: http://cmake.3232098.n2.nabble.com/Does-Makefile-generated-by-CMake-support-make-jN-tp7593949p7593951.html > Sent from the CMake mailing list archive at Nabble.com. > -- > > 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 -- -- Andrew Melo From zcsd2012 at gmail.com Wed Jul 13 02:21:38 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Tue, 12 Jul 2016 23:21:38 -0700 (MST) Subject: [CMake] Does Makefile generated by CMake support make -jN? In-Reply-To: References: <1468378467509-7593949.post@n2.nabble.com> Message-ID: <1468390898520-7593954.post@n2.nabble.com> Thanks for your references Decker, the condition is it cost close to three times time after i use CMake than already exist makefile to build project. And i found the CPU didn't use effectively than exist make flow, so i wonder if CMake provide some options to use CPU more effectively. Thanks, Chao J Decker wrote > On Tue, Jul 12, 2016 at 7:54 PM, Chaos Zhang < > zcsd2012@ > > wrote: > >> Hi, all, >> >> I was trying to compile my project using CMake, after CMake generated >> Makefile. >> I used `/usr/bin/time -v make` to make the Makefile, got the result: >> 'Percent of CPU this job got: 96%'. >> Then i used `/usr/bin/time -v make -j8` to make the Makefile, the result >> of >> CPU used is 'Percent of CPU this job got: 648%'. >> So i wonder if Makefile generated by CMake support make -jN, BTW my CPU >> is >> I7-4790, and after i use 'cat /proc/cpuinfo', there are 8 processors. >> >> > All the sources, headers, etc come from the IO system, from the disk, > probably you're running into the bottleneck of how long it takes to move > the memory for the compiler to do work on? did you profile IO ? > > >> Thanks a lot, >> Chao >> >> >> >> -- >> View this message in context: >> http://cmake.3232098.n2.nabble.com/Does-Makefile-generated-by-CMake-support-make-jN-tp7593949.html >> Sent from the CMake mailing list archive at Nabble.com. >> -- >> >> 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 -- View this message in context: http://cmake.3232098.n2.nabble.com/Does-Makefile-generated-by-CMake-support-make-jN-tp7593949p7593954.html Sent from the CMake mailing list archive at Nabble.com. From zcsd2012 at gmail.com Wed Jul 13 02:39:10 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Tue, 12 Jul 2016 23:39:10 -0700 (MST) Subject: [CMake] Does Makefile generated by CMake support make -jN? In-Reply-To: References: <1468378467509-7593949.post@n2.nabble.com> <1468381717313-7593951.post@n2.nabble.com> Message-ID: <1468391950564-7593955.post@n2.nabble.com> Thanks for your analysis for me Andrew. I can't use "-j" options, i think the reason is the project i dealed with is not parallel. Thus when i use "make -jN", it couldn't work correctly every time. Obviously it caused by the Makefile generated by CMake, so i wonder if there are some CMake options to use CPU effectively. Because i found when i use already exist Makefile, just use "make", it used about 480% CPU. And when i use CMake generated Makefile, it just uesd about 96% CPU. The "hardware acceleration" i said means how to CPU more effectively in CMake. Thanks again, Chao Andrew Melo wrote > On Tue, Jul 12, 2016 at 10:48 PM, Chaos Zhang < > zcsd2012@ > > wrote: >> Thanks for your reply Raymond, by 'If you got 96% both times, then I >> would >> say there's a problem.', did you mean if make performed like this, it >> means >> this project can't use make -jN? > > If "make -j1" and "make -j8" ran in the same amount of time, there > would be a problem. Since "make -j1" uses 96% CPU and "make -j8" uses > 690% CPU, it implies that the "-j" options make compilation time > scale, which is what you want. > >> BTW, does CMake support some options to >> turn on hardware acceleration? > > What do you mean by "hardware acceleration"? > > > >> >> Raymond Wan-2 wrote >>> Hi Chao, >>> >>> >>> On Wed, Jul 13, 2016 at 10:54 AM, Chaos Zhang < >> >>> zcsd2012@ >> >>> > wrote: >>>> I was trying to compile my project using CMake, after CMake generated >>>> Makefile. >>>> I used `/usr/bin/time -v make` to make the Makefile, got the result: >>>> 'Percent of CPU this job got: 96%'. >>>> Then i used `/usr/bin/time -v make -j8` to make the Makefile, the >>>> result >>>> of >>>> CPU used is 'Percent of CPU this job got: 648%'. >>>> So i wonder if Makefile generated by CMake support make -jN, BTW my CPU >>>> is >>>> I7-4790, and after i use 'cat /proc/cpuinfo', there are 8 processors. >>> >>> >>> I'm not sure what you are asking... >>> >>> You ran make with -j 8 and you got a percentage greater than 96% ... >>> this implies that the Makefile does support -jN, doesn't it? If you >>> got 96% both times, then I would say there's a problem. >>> >>> Is what you're wondering why it is 648% and not 800%? I think that >>> depends on the dependencies in your Makefile. It's possible that some >>> of them depend on each other in such a way that 8 parallel threads is >>> not possible. >>> >>> Also, I can't remember the value returned by /usr/bin/time -v, but I >>> guess 648% is the average and not maximum. So, perhaps there are >>> parts within the Makefile that only one thread could be used and then >>> it gets averaged out? >>> >>> Ray >>> -- >>> >>> 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 >> >> >> >> >> >> -- >> View this message in context: >> http://cmake.3232098.n2.nabble.com/Does-Makefile-generated-by-CMake-support-make-jN-tp7593949p7593951.html >> Sent from the CMake mailing list archive at Nabble.com. >> -- >> >> 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 > > > > -- > -- > Andrew Melo > -- > > 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 -- View this message in context: http://cmake.3232098.n2.nabble.com/Does-Makefile-generated-by-CMake-support-make-jN-tp7593949p7593955.html Sent from the CMake mailing list archive at Nabble.com. From julien.jomier at kitware.com Wed Jul 13 09:12:31 2016 From: julien.jomier at kitware.com (Julien Jomier) Date: Wed, 13 Jul 2016 15:12:31 +0200 Subject: [CMake] ANN: CMake Course - October 10 in Lyon, France Message-ID: Kitware will be holding a CMake training course on October 10, 2016 at Kitware's office in Lyon, France. This one-day course will cover CMake, CTest, CPack and CDash. Visit our website for more information and registration details (early registration and student discounts available): http://training.kitware.fr/browse/129 Note that the course will be taught in English. If you have any questions, please contact me directly or training at kitware.fr. We are looking forward to seeing you in Lyon, Julien -- Kitware SAS 26 rue Louis Gu?rin 69100 Villeurbanne, France http://www.kitware.eu From chuck.atkins at kitware.com Wed Jul 13 15:50:20 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 13 Jul 2016 15:50:20 -0400 Subject: [CMake] Does Makefile generated by CMake support make -jN? In-Reply-To: <1468391950564-7593955.post@n2.nabble.com> References: <1468378467509-7593949.post@n2.nabble.com> <1468381717313-7593951.post@n2.nabble.com> <1468391950564-7593955.post@n2.nabble.com> Message-ID: > > Thanks for your analysis for me Andrew. I can't use "-j" options, i think > the reason is the project i dealed with is not parallel. Thus when i use "make > -jN", it couldn't work correctly every time. Obviously it caused by the > Makefile generated by CMake, so i wonder if there are some CMake options to > use CPU effectively. This usually means missing dependencies the CMakeLists.txt files. Because of this you get unpredictable results when compiling in parallel. Check your dependencies on targets, link lines, and source files and make sure they are all correct and not missing anything. > Because i found when i use already exist Makefile, just > use "make", it used about 480% CPU. The Makefile is probably explicitly adding a fixed number of -j options. CMake will not do this and instead rely on the user to call make with their desired appropriate level of parallelism. > And when i use CMake generated Makefile, it just uesd about 96% CPU. The > "hardware acceleration" i said means how to > CPU more effectively in CMake. > -jN is as good as it gets for make. That being said, you can always try a different generator, like Ninja, which tends to have quite a bit better build times in parallel. First things first though, you need to get your dependency problem squared away. That's the underlying cause of why your parallel builds with -j are unpredictable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Wed Jul 13 16:48:17 2016 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Wed, 13 Jul 2016 22:48:17 +0200 Subject: [CMake] Splitting in multiple directories In-Reply-To: References: Message-ID: <13728581.2sl0utPkkV@tuxedo.neundorf.net> On Tuesday 12 July 2016 09:00:43 portolan wrote: > Hello, > > I am new to Cmake and I have a pretty strange behaviour: I set my c+++ > project to work with a single CMakefile.txt, and now I am trying to have > a more proper version with a .txt for each subdirectory > > Pretty normal stuff, my source tree is: > > --Lib (my sources) > > --Logger (as the name says, a logger) > > --Lib_UT (Unitary tests for CxxTest) > > --Lib_UT_Runner (the Cxx-generated test runner) > > > I have a Lib_UT/CMakefile.txt and Lib_UT_Runner/CMakefile.txt, I call > them using include_directory(Lib_UT) and I guess you mean add_subdirectory() ? > include_directory(Lib_UT_Runner) and everything is fine (apart from the > runner executable being in a different directory) > > BUT is I do the same for the logger, Lib_UT_Runner has a linking error > where it cannot link to LibLogger.so. But the shared library is > correctly generated and it is on the command line : > > /usr/bin/c++ -lpthread CMakeFiles/Lib_UT_Runner.dir/Runner.cpp.o > -o Lib_UT_Runner ../Lib_UT/libLib_UT.so ../libLib.so ../libLogger.so > -lpthread > -Wl,-rpath,/home/michele/mast-devel/cmake_debug/Lib_UT:/home/michele/mast-de > vel/cmake_debug:/home/michele/mast-devel/cmake_debug/Logger > > I tried using find_library, but I always get not-found what's the error message ? Posting relevant bits of your CMakeLists.txt (related to subdirs, creating targets and linking) would be helpful too. Alex From legleux at gmail.com Wed Jul 13 18:35:10 2016 From: legleux at gmail.com (Michael Legleux) Date: Wed, 13 Jul 2016 15:35:10 -0700 Subject: [CMake] excluded from build in Visual Studio project Message-ID: I have a use case that I haven't had much luck googling. I have a project that needs to have files visible in the Visual Studio IDE but marked with the red "Excluded from build" symbol. The source files are not needed in any way for the visual studio project, but for example, they use functions defined in project source files, so they need to be searchable and updatable from the visual studio ide. I can't seem to find any nice clean way to do this with cmake (or anyway yet for that matter.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Wed Jul 13 18:40:45 2016 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 14 Jul 2016 08:40:45 +1000 Subject: [CMake] excluded from build in Visual Studio project In-Reply-To: References: Message-ID: Somewhat related, the following thread from a few days ago may be helpful: http://public.kitware.com/pipermail/cmake/2016-July/063897.html In short, you probably want to use add_custom_target() without the ALL keyword. On Thu, Jul 14, 2016 at 8:35 AM, Michael Legleux wrote: > I have a use case that I haven't had much luck googling. > > I have a project that needs to have files visible in the Visual Studio IDE > but marked with the red "Excluded from build" symbol. > The source files are not needed in any way for the visual studio project, > but for example, they use functions defined in project source files, so > they need to be searchable and updatable from the visual studio ide. > > I can't seem to find any nice clean way to do this with cmake (or anyway > yet for that matter.) > > -- > > 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 http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dumont.guillaume at gmail.com Wed Jul 13 21:08:56 2016 From: dumont.guillaume at gmail.com (Guillaume Dumont) Date: Wed, 13 Jul 2016 21:08:56 -0400 Subject: [CMake] excluded from build in Visual Studio project In-Reply-To: References: Message-ID: Hi, I think you can add any files to a library/executable target and they will show up in the IDE. If the files are actual source code files such as .cpp/.c/.cxx you can set HEADER_FILE_ONLY property on them so that they do no get compiled when the target is built the https://cmake.org/cmake/help/v3.6/prop_sf/HEADER_FILE_ONLY.html. HTH Guillaume On Wed, Jul 13, 2016 at 6:40 PM, Craig Scott wrote: > short, you probably want to use add_custom_ta -- Guillaume Dumont ========================= dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From smithbreannan at gmail.com Wed Jul 13 23:10:42 2016 From: smithbreannan at gmail.com (Breannan Smith) Date: Wed, 13 Jul 2016 20:10:42 -0700 Subject: [CMake] CMake Reports Incorrect HDF5 Libraries on OS X after 3.6.0 Upgrade In-Reply-To: References: Message-ID: Rad, I can verify that the issue is resolved in the git repo if anyone else is running into the bug. Thanks! On Tue, Jul 12, 2016 at 5:12 AM, Robert Maynard wrote: > Hi Breannan, > > You can track the status of the fix at > https://gitlab.kitware.com/cmake/cmake/merge_requests/34 > > On Mon, Jul 11, 2016 at 8:52 AM, Robert Maynard > wrote: >> Hi Breannan, >> >> I am able to reproduce this and will start digging into why this is occurring. >> >> On Sun, Jul 10, 2016 at 6:34 PM, Breannan Smith wrote: >>> After upgrading to CMake 3.6.0 from 3.5.2, CMake fails to find HDF5 on OS X. >>> >>> With 3.5.2, find_package(HDF5 REQUIRED COMPONENTS C) reports the >>> following for HDF5_LIBRARIES. Note the presences of libhdf5.dylib, in >>> this list: >>> >>> /usr/local/Cellar/hdf5/1.8.16_1/lib/libhdf5.dylib;/usr/local/opt/szip/lib/libsz.dylib;/usr/lib/libz.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib >>> >>> With 3.6.0, the same find_package command gives the following >>> HDF5_LIBRARIES. Notice that libhdf5.dylib is not even present: >>> >>> /usr/local/lib/libsz.dylib;/usr/lib/libz.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib >>> >>> The contents of the HDF5_LIBRARIES and HDF5_C_LIBRARIES are the same >>> under 3.6.0. Interestingly, the FindHDF5.cmake module does not report >>> a failure under 3.6.0 even though it fails to locate the HDF5 library. >>> >>> I did not see any changes to FindHDF5.cmake listed under the 3.6 >>> release notes [1], but diffing the module files there were extensive >>> edits made. >>> >>> Has anyone else run into this issue or found a fix? Thank you! >>> >>> [1] https://cmake.org/cmake/help/v3.6/release/3.6.html >>> -- >>> >>> 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 roman.wueger at gmx.at Thu Jul 14 05:29:53 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Thu, 14 Jul 2016 11:29:53 +0200 Subject: [CMake] OSX Code Signing best practice In-Reply-To: References: Message-ID: Is it possible to sign after your package is complete (copying resource files and so on)? I call a *.sh which is created from the CMake configure step which do the job. Best Regards Roman > Am 12.07.2016 um 18:49 schrieb Harry Mallon : > > Hello all, > > What is the current best practice for code signing OSX .apps and binaries? I am using: > > 1. MAC_OSX_BUNDLE for my .app targets. > 2. unix style executables > 3. dylibs > 4. A prefpane (which I haven't got working yet) using something like the below: > > add_library(prefpane MODULE > ${sourceFiles} > ) > > set_target_properties(codexprefpane PROPERTIES > BUNDLE YES > BUNDLE_EXTENSION prefPane > XCODE_ATTRIBUTE_WRAPPER_EXTENSION prefPane > MACOSX_BUNDLE_INFO_PLIST ${prefpane_plist_file} > ) > > I am not using the CPackBundle generator so I cannot use the signing in that. I have tried: > > 1. Using set_target_properties( .... "XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY" "${SIGN_ID}") > 2. Using an add_custom_command step. This code signs before all the Resources are copied in so the signatures are invalid > > Any ideas? > Harry > > Harry Mallon > CODEX | Software Engineer > 60 Poland Street | London | England | W1F 7NT > E harry at codexdigital.com | T +44 203 7000 989 > -- > > 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 chuck.atkins at kitware.com Thu Jul 14 09:54:21 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Thu, 14 Jul 2016 09:54:21 -0400 Subject: [CMake] CMake Reports Incorrect HDF5 Libraries on OS X after 3.6.0 Upgrade In-Reply-To: References: Message-ID: Hi Brennan, We also just got the Homebrew cmake formula updated to explicitly include the patch. See https://github.com/Homebrew/homebrew-core/pull/2968 - Chuck On Wed, Jul 13, 2016 at 11:10 PM, Breannan Smith wrote: > Rad, I can verify that the issue is resolved in the git repo if anyone > else is running into the bug. Thanks! > > On Tue, Jul 12, 2016 at 5:12 AM, Robert Maynard > wrote: > > Hi Breannan, > > > > You can track the status of the fix at > > https://gitlab.kitware.com/cmake/cmake/merge_requests/34 > > > > On Mon, Jul 11, 2016 at 8:52 AM, Robert Maynard > > wrote: > >> Hi Breannan, > >> > >> I am able to reproduce this and will start digging into why this is > occurring. > >> > >> On Sun, Jul 10, 2016 at 6:34 PM, Breannan Smith < > smithbreannan at gmail.com> wrote: > >>> After upgrading to CMake 3.6.0 from 3.5.2, CMake fails to find HDF5 on > OS X. > >>> > >>> With 3.5.2, find_package(HDF5 REQUIRED COMPONENTS C) reports the > >>> following for HDF5_LIBRARIES. Note the presences of libhdf5.dylib, in > >>> this list: > >>> > >>> > /usr/local/Cellar/hdf5/1.8.16_1/lib/libhdf5.dylib;/usr/local/opt/szip/lib/libsz.dylib;/usr/lib/libz.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib > >>> > >>> With 3.6.0, the same find_package command gives the following > >>> HDF5_LIBRARIES. Notice that libhdf5.dylib is not even present: > >>> > >>> > /usr/local/lib/libsz.dylib;/usr/lib/libz.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib > >>> > >>> The contents of the HDF5_LIBRARIES and HDF5_C_LIBRARIES are the same > >>> under 3.6.0. Interestingly, the FindHDF5.cmake module does not report > >>> a failure under 3.6.0 even though it fails to locate the HDF5 library. > >>> > >>> I did not see any changes to FindHDF5.cmake listed under the 3.6 > >>> release notes [1], but diffing the module files there were extensive > >>> edits made. > >>> > >>> Has anyone else run into this issue or found a fix? Thank you! > >>> > >>> [1] https://cmake.org/cmake/help/v3.6/release/3.6.html > >>> -- > >>> > >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tommy8927 at gmail.com Thu Jul 14 19:54:27 2016 From: tommy8927 at gmail.com (Tom Kulaga) Date: Thu, 14 Jul 2016 23:54:27 +0000 Subject: [CMake] cmake 3.5 vs 3.6 + qt Message-ID: Hi All, I'm using 3.5.2 for a qt based project and I've updated to 3.6 and the RCC feature seems to fail. Here's a summary CMAKE settings: cmake_policy(SET CMP0015 NEW) # relative linker paths cmake_policy(SET CMP0020 NEW) # linking to qmainlib # Tell CMake to run moc when necessary: set(CMAKE_AUTOMOC ON) set(CMAKE_AUTOUIC ON) set(CMAKE_AUTORCC ON) # As moc files are generated in the binary dir, tell CMake # to always look for includes there: set(CMAKE_INCLUDE_CURRENT_DIR ON) When I swtiched to 3.6, the compiler can no longer link to the generated rcc files. Anyone else face this or know what I'm doing wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From zcsd2012 at gmail.com Thu Jul 14 21:25:09 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Thu, 14 Jul 2016 18:25:09 -0700 (MST) Subject: [CMake] Does Makefile generated by CMake support make -jN? In-Reply-To: References: <1468378467509-7593949.post@n2.nabble.com> <1468381717313-7593951.post@n2.nabble.com> <1468391950564-7593955.post@n2.nabble.com> Message-ID: <1468545909848-7593966.post@n2.nabble.com> Hi, Chuck, Thanks for your generous help. Actually there is no make -j option in the already exist make flow of my project as i know so far. Because i have read the makefiles in detail, and when i make my project, the sub projects in my project executed in order. The problem i found is it cost much more time when use CMake generated Makefile to compile a single source file with gcc. I choose a passage of gcc options for each flow: In alredy exist Makfile: g++ ?some gcc options like -W...? -c -g -DMACRO1 -DMACRO2 ... -isystemdir1 -isystemdir2 ... header_include_dir1header_include_dir2 ... -MMD -MP -MF -o src.o src.cpp In CMake generated Makfile: g++ ?some gcc options like -W...? -g header_include_dir1header_include_dir2 ... -DMACRO1 -DMACRO2 ... -isystemdir1 -isystemdir2 -o src.o -c src.cpp other files when compile are also like above, but will cost much more time(2-3times), could you please give me some advices? If you need more details, please email me. Sincere thanks? Chao Chuck Atkins wrote >> >> Thanks for your analysis for me Andrew. I can't use "-j" options, i think >> the > > reason is the project i dealed with is not parallel. Thus when i use "make >> -jN", it couldn't work correctly every time. Obviously it caused by the >> Makefile generated by CMake, so i wonder if there are some CMake options >> to >> use CPU effectively. > > > This usually means missing dependencies the CMakeLists.txt files. Because > of this you get unpredictable results when compiling in parallel. Check > your dependencies on targets, link lines, and source files and make sure > they are all correct and not missing anything. > > > >> Because i found when i use already exist Makefile, just >> use "make", it used about 480% CPU. > > > The Makefile is probably explicitly adding a fixed number of -j options. > CMake will not do this and instead rely on the user to call make with > their > desired appropriate level of parallelism. > > > >> And when i use CMake generated Makefile, it just uesd about 96% CPU. The >> "hardware acceleration" i said means how to >> CPU more effectively in CMake. >> > > -jN is as good as it gets for make. That being said, you can always try a > different generator, like Ninja, which tends to have quite a bit better > build times in parallel. > > First things first though, you need to get your dependency problem squared > away. That's the underlying cause of why your parallel builds with -j are > unpredictable. > > -- > > 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 -- View this message in context: http://cmake.3232098.n2.nabble.com/Does-Makefile-generated-by-CMake-support-make-jN-tp7593949p7593966.html Sent from the CMake mailing list archive at Nabble.com. From ledocc.pub at gmail.com Fri Jul 15 04:50:36 2016 From: ledocc.pub at gmail.com (David Callu) Date: Fri, 15 Jul 2016 10:50:36 +0200 Subject: [CMake] cmake 3.5 vs 3.6 + qt In-Reply-To: References: Message-ID: Hi Tom, Same thing on my side. I call in my code functions defined in generated .cpp from moc/rcc. Functions name are based on file path used during .cpp generation. And this path change from cmake 3.5 to 3.6. You should check functions in generated .cpp files that you used in your code. HTH David 2016-07-15 1:54 GMT+02:00 Tom Kulaga : > Hi All, > > I'm using 3.5.2 for a qt based project and I've updated to 3.6 and the RCC > feature seems to fail. Here's a summary > > CMAKE settings: > > cmake_policy(SET CMP0015 NEW) # relative linker paths > > cmake_policy(SET CMP0020 NEW) # linking to qmainlib > > > # Tell CMake to run moc when necessary: > > set(CMAKE_AUTOMOC ON) > > set(CMAKE_AUTOUIC ON) > > set(CMAKE_AUTORCC ON) > > # As moc files are generated in the binary dir, tell CMake > > # to always look for includes there: > > set(CMAKE_INCLUDE_CURRENT_DIR ON) > > > When I swtiched to 3.6, the compiler can no longer link to the generated rcc files. > > > Anyone else face this or know what I'm doing wrong? > > > -- > > 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 tommy8927 at gmail.com Fri Jul 15 08:12:20 2016 From: tommy8927 at gmail.com (Tom Kulaga) Date: Fri, 15 Jul 2016 12:12:20 +0000 Subject: [CMake] cmake 3.5 vs 3.6 + qt In-Reply-To: References: Message-ID: Should this have changed in 3.6 I couldn't see anything in the change log? How can I control where they are generated? On Fri, 15 Jul 2016, 18:51 David Callu wrote: > Hi Tom, > > Same thing on my side. I call in my code functions defined in generated > .cpp from moc/rcc. > Functions name are based on file path used during .cpp generation. > And this path change from cmake 3.5 to 3.6. > > You should check functions in generated .cpp files that you used in your > code. > > HTH > David > > 2016-07-15 1:54 GMT+02:00 Tom Kulaga : > >> Hi All, >> >> I'm using 3.5.2 for a qt based project and I've updated to 3.6 and the >> RCC feature seems to fail. Here's a summary >> >> CMAKE settings: >> >> cmake_policy(SET CMP0015 NEW) # relative linker paths >> >> cmake_policy(SET CMP0020 NEW) # linking to qmainlib >> >> >> # Tell CMake to run moc when necessary: >> >> set(CMAKE_AUTOMOC ON) >> >> set(CMAKE_AUTOUIC ON) >> >> set(CMAKE_AUTORCC ON) >> >> # As moc files are generated in the binary dir, tell CMake >> >> # to always look for includes there: >> >> set(CMAKE_INCLUDE_CURRENT_DIR ON) >> >> >> When I swtiched to 3.6, the compiler can no longer link to the generated rcc files. >> >> >> Anyone else face this or know what I'm doing wrong? >> >> >> -- >> >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele.portolan at imag.fr Fri Jul 15 08:48:32 2016 From: michele.portolan at imag.fr (portolan) Date: Fri, 15 Jul 2016 14:48:32 +0200 Subject: [CMake] Splitting in multiple directories In-Reply-To: <13728581.2sl0utPkkV@tuxedo.neundorf.net> References: <13728581.2sl0utPkkV@tuxedo.neundorf.net> Message-ID: <56cf722f-37ae-c254-b626-1539b5b35df0@imag.fr> Yes, it was add_subirectory. I tried once more after cleaning up the CMakeList.txt and now it works....I must have ad some spurious settings generating the error. Thanks, Michele Le 13/07/2016 ? 22:48, Alexander Neundorf a ?crit : > On Tuesday 12 July 2016 09:00:43 portolan wrote: >> Hello, >> >> I am new to Cmake and I have a pretty strange behaviour: I set my c+++ >> project to work with a single CMakefile.txt, and now I am trying to have >> a more proper version with a .txt for each subdirectory >> >> Pretty normal stuff, my source tree is: >> >> --Lib (my sources) >> >> --Logger (as the name says, a logger) >> >> --Lib_UT (Unitary tests for CxxTest) >> >> --Lib_UT_Runner (the Cxx-generated test runner) >> >> >> I have a Lib_UT/CMakefile.txt and Lib_UT_Runner/CMakefile.txt, I call >> them using include_directory(Lib_UT) and > > I guess you mean add_subdirectory() ? > > >> include_directory(Lib_UT_Runner) and everything is fine (apart from the >> runner executable being in a different directory) >> >> BUT is I do the same for the logger, Lib_UT_Runner has a linking error >> where it cannot link to LibLogger.so. But the shared library is >> correctly generated and it is on the command line : >> >> /usr/bin/c++ -lpthread CMakeFiles/Lib_UT_Runner.dir/Runner.cpp.o >> -o Lib_UT_Runner ../Lib_UT/libLib_UT.so ../libLib.so ../libLogger.so >> -lpthread >> -Wl,-rpath,/home/michele/mast-devel/cmake_debug/Lib_UT:/home/michele/mast-de >> vel/cmake_debug:/home/michele/mast-devel/cmake_debug/Logger >> >> I tried using find_library, but I always get not-found > > what's the error message ? > > Posting relevant bits of your CMakeLists.txt (related to subdirs, creating > targets and linking) would be helpful too. > > Alex > From ewmailing at gmail.com Fri Jul 15 13:20:48 2016 From: ewmailing at gmail.com (Eric Wing) Date: Fri, 15 Jul 2016 10:20:48 -0700 Subject: [CMake] OSX Code Signing best practice In-Reply-To: References: Message-ID: On 7/12/16, Harry Mallon wrote: > Hello all, > > What is the current best practice for code signing OSX .apps and binaries? I > am using: > > 1. MAC_OSX_BUNDLE for my .app targets. > 2. unix style executables > 3. dylibs > 4. A prefpane (which I haven't got working yet) using something like the > below: > > add_library(prefpane MODULE > ${sourceFiles} > ) > > set_target_properties(codexprefpane PROPERTIES > BUNDLE YES > BUNDLE_EXTENSION prefPane > XCODE_ATTRIBUTE_WRAPPER_EXTENSION prefPane > MACOSX_BUNDLE_INFO_PLIST ${prefpane_plist_file} > ) > > I am not using the CPackBundle generator so I cannot use the signing in > that. I have tried: > > 1. Using set_target_properties( .... "XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY" > "${SIGN_ID}") > 2. Using an add_custom_command step. This code signs before all the > Resources are copied in so the signatures are invalid > > Any ideas? > Harry > I do something similar. I also don't use CPack and need the build process to respect normal Xcode run/debug/profile workflows where the app bundle is built correctly on build and not through separate CMake target steps. I have a add_custom_command as a POST_BUILD to copy and sign my frameworks, dylibs, and plugins. Then I use XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY to get Xcode to sign the rest of the bundle through the normal Xcode mechanisms. It works. I do find having to set the XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY annoying. I kind of wish the CMake generator could ignore that field and leave it to whatever the user ends up setting (and not overwrite on every update regeneration) because there are different identities you need depending on the situation and changing this all the time in CMake scripts is annoying. And I wish Xcode itself would automatically recursively sign dependencies so I don't need to copy and sign manually. -Eric From MillerHenry at JohnDeere.com Fri Jul 15 16:51:49 2016 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Fri, 15 Jul 2016 20:51:49 +0000 Subject: [CMake] find*.cmake config files, and Qt4 while cross compiling. Message-ID: <35F6921410093E4CA40D524BD5C18D4C30E24EE3@EDXMB89.jdnet.deere.com> I'm going to ask two questions, but a good answer to the first will make the second question redundant. I work with several different cmake projects that are cross compiled, and they depend on each other. Each project creates a cmake config, so we can use find_package to find the contents. Up until now we have been setting LINK_INTERFACE_LIBRARIES to "" SET_TARGET_PROPERTIES(${projectName} PROPERTIES LINK_INTERFACE_LIBRARIES ""), but for a few years this has required us to set CMP0022 to OLD. Now that we no longer support older versions of CMake I figured it was time to set this to NEW (2.12 is minimum we use and most of us are up to 3.2 (I have not tried anything newer than 3.2). This works great for libraries that provide a cmake config file when we link a library to libFoo the config includes the need to link to libFoo. However any project that we use a FindXXX.cmake to find (including cmake included like FindLibXml2.cmake) the package the config file says you need to link to /home/hank/sysroot/path/to/libFoo. When I package this build and give it to a different developer to install into his sysroot it fails because the correct path for him is /home/joe/some/other/dir/sysroot/path/to/libFoo. I found a work around: in target_link_libraries make libFoo a private link. This feels wrong though, I feel that cmake should handle this automatically. (I'm fine with mark it as private, anything better is probably not implementable) First question, how can I use libraries from a Find*.cmake file without having to mark it as private in every target_link_libraries call. I couldn't figure this out, but I was able to mitigate it for the most common package we link to. For Qt4 is you have a choice, what we were doing was: Find_package(Qt4 REQUIRED) INCLUDE(${QT_USE_FILE} TARGET_LINK_LIBRARIES(MyProject ${QT_LIBRARIES}) If you use this for you get the full path to each library in your sysroot. However if you do: Find_package(Qt4 REQUIRED) TARGET_LINK_LIBRARIES(Qt4:QtGui ...) You get just the Qt library, which would be what I want except that now the INCLUDE_DIRECTORIES for Qt libraries are not SYSTEM libraries and so I'm getting a lot of compiler warnings in qt header files which I cannot fix. Second question: how can I use the TARGET_LINK_LIBRARIES(Qt4:QtGui...) form and get the qt headers as system libraries? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarra13 at gmail.com Fri Jul 15 19:58:24 2016 From: ggarra13 at gmail.com (Gonzalo) Date: Fri, 15 Jul 2016 20:58:24 -0300 Subject: [CMake] Does Makefile generated by CMake support make -jN? In-Reply-To: <1468390898520-7593954.post@n2.nabble.com> References: <1468378467509-7593949.post@n2.nabble.com> <1468390898520-7593954.post@n2.nabble.com> Message-ID: <578978A0.702@gmail.com> El 13/07/16 a las 03:21, Chaos Zhang escribi?: > Thanks for your references Decker, the condition is it cost close to three > times time after i use CMake than already exist makefile to build project. > And i found the CPU didn't use effectively than exist make flow, so i > wonder if CMake provide some options to use CPU more effectively. > Thanks, > Chao If you are looking to speed up compilation times, you should switch from Makefiles to Ninja build files (-G Ninja). It has a much faster detection of dependencies and compiles overall much faster. From zcsd2012 at gmail.com Sun Jul 17 21:18:12 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Sun, 17 Jul 2016 18:18:12 -0700 (MST) Subject: [CMake] Does Makefile generated by CMake support make -jN? In-Reply-To: <1468545909848-7593966.post@n2.nabble.com> References: <1468378467509-7593949.post@n2.nabble.com> <1468381717313-7593951.post@n2.nabble.com> <1468391950564-7593955.post@n2.nabble.com> <1468545909848-7593966.post@n2.nabble.com> Message-ID: <1468804692804-7593973.post@n2.nabble.com> Hi, Raymond, J Decker, Andrew, Chuck, Thanks a lot for your generous help, i have found it was dependencies missing of my project, for i have not found my project was built in parallel. BTW, i have used env var "MAKEFLAGS=-j" to make in parallel, is there any way i can set "make -j" option in CMake file? For i use Qt Creator as IDE, and the CMake compile system is provided for other R&D teams, so i want to make the CMake compile system as simply and automatically as i can. Could you please give me some advice? Thanks again, Chao Chaos Zhang wrote > Hi, Chuck, > > Thanks for your generous help. > > Actually there is no make -j option in the already exist make flow of my > project as i know so far. Because i have read the makefiles in detail, > and when i make my project, the sub projects in my project executed in > order. > > The problem i found is it cost much more time when use CMake generated > Makefile to compile a single source file with gcc. I choose a passage of > gcc options for each flow: > > In alredy exist Makfile: > > g++ ?some gcc options like -W...? > -c -g -DMACRO1 -DMACRO2 ... -isystemdir1 -isystemdir2 ... > header_include_dir1header_include_dir2 ... -MMD -MP -MF -o src.o src.cpp > > In CMake generated Makfile: > > g++ ?some gcc options like -W...? > -g header_include_dir1header_include_dir2 ... -DMACRO1 -DMACRO2 ... > -isystemdir1 -isystemdir2 -o src.o -c src.cpp > > other files when compile are also like above, but will cost much more > time(2-3times), could you please give me some advices? If you need more > details, please email me. > > Sincere thanks? > Chao > Chuck Atkins wrote >>> >>> Thanks for your analysis for me Andrew. I can't use "-j" options, i >>> think >>> the >> >> reason is the project i dealed with is not parallel. Thus when i use >> "make >>> -jN", it couldn't work correctly every time. Obviously it caused by the >>> Makefile generated by CMake, so i wonder if there are some CMake options >>> to >>> use CPU effectively. >> >> >> This usually means missing dependencies the CMakeLists.txt files. >> Because >> of this you get unpredictable results when compiling in parallel. Check >> your dependencies on targets, link lines, and source files and make sure >> they are all correct and not missing anything. >> >> >> >>> Because i found when i use already exist Makefile, just >>> use "make", it used about 480% CPU. >> >> >> The Makefile is probably explicitly adding a fixed number of -j options. >> CMake will not do this and instead rely on the user to call make with >> their >> desired appropriate level of parallelism. >> >> >> >>> And when i use CMake generated Makefile, it just uesd about 96% CPU. The >>> "hardware acceleration" i said means how to >>> CPU more effectively in CMake. >>> >> >> -jN is as good as it gets for make. That being said, you can always try >> a >> different generator, like Ninja, which tends to have quite a bit better >> build times in parallel. >> >> First things first though, you need to get your dependency problem >> squared >> away. That's the underlying cause of why your parallel builds with -j >> are >> unpredictable. >> >> -- >> >> 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 -- View this message in context: http://cmake.3232098.n2.nabble.com/Does-Makefile-generated-by-CMake-support-make-jN-tp7593949p7593973.html Sent from the CMake mailing list archive at Nabble.com. From umihhgm at gmail.com Mon Jul 18 02:56:24 2016 From: umihhgm at gmail.com (Hgfjj Hhjgf) Date: Mon, 18 Jul 2016 12:56:24 +0600 Subject: [CMake] Using CMake on CLion and adding geoip library In-Reply-To: References: Message-ID: thanks for your time :) I managed to solve the problem. Thanks for your reply again. On Sat, Jun 25, 2016 at 5:50 PM, Jakob van Bethlehem < jsvanbethlehem at gmail.com> wrote: > Hej, > > According to > https://cmake.org/cmake/help/v3.4/module/CheckIncludeFile.html the > ?check_include_file? is a function provided by a module. So you?ll need to > include(CheckIncludeFile) at the beginning of your lists-file > > Sincerely, > Jakob > > On 25 Jun 2016, at 08:09, Hgfjj Hhjgf wrote: > > I am trying to use an external library (GeoIP). CMake list contains: > > message(STATUS "Looking for MaxMind GeoIP header files") > > set(CMAKE_INCLUDE_PATH "${CMAKE_INCLUDE_PATH} ${GEOIP_INCLUDE_DIR}") > check_include_file("GeoIP.h" HAVE_GEOIP_H) > check_include_file("GeoIPCity.h" HAVE_GEOIPCITY_H) > if (HAVE_GEOIP_H AND HAVE_GEOIPCITY_H) > message(STATUS "Looking for MaxMind GeoIP header files - found") > else(HAVE_GEOIP_H AND HAVE_GEOIPCITY_H) > message(FATAL_ERROR "Could not find one or more MaxMind GeoIP header files. If the MaxMind GeoIP library is installed, you can run CMake again and specify its location with -DGEOIP_INCLUDE_DIR=") > endif(HAVE_GEOIP_H AND HAVE_GEOIPCITY_H) > > message(STATUS "Looking for MaxMind GeoIP libraries") > find_library(GEOIP_LIB > NAMES GeoIP geoip > PATHS ${GEOIP_LIBRARY_DIR} > ) > if (GEOIP_LIB) > message(STATUS "Looking for MaxMind GeoIP libraries - found") > set(GEOIP_LIBRARIES ${GEOIP_LIB}) > else(GEOIP_LIB) > message(FATAL_ERROR "Could not find MaxMind GeoIP library") > endif(GEOIP_LIB) > > but getting error like "Unknown cmake command: check_include_file" > what's the problem here then? > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tiagomacarios at gmail.com Mon Jul 18 03:21:59 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Mon, 18 Jul 2016 00:21:59 -0700 Subject: [CMake] set file property from function Message-ID: Hi, Is there a way to set a property of a file/source from a function? Below seems to work file outside of a function, but seems not to work inside one. set_property( SOURCE ${AFILE} APPEND PROPERTY COMPILE_FLAGS "/wd4068" ) Do I need to CACHE it? or is it a scope problem? Thanks, Mac -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis.kornblueh at mpimet.mpg.de Mon Jul 18 07:49:47 2016 From: luis.kornblueh at mpimet.mpg.de (Luis Kornblueh) Date: Mon, 18 Jul 2016 13:49:47 +0200 Subject: [CMake] cmake and openmp Message-ID: Hi everybody, I do have a problem with OpenMP and cmake. We have a code in Fortran, which uses different modules dependent if our code gets compiled with or without OpenMP. The flags used by the respective compiler to switch on OpenMP are detected properly by the cmake find...(). But the dependency scanner does not know about and I did not found a way to tell it to use the preprocessor variable _OPENMP, which is defined by the compiler, if OpenMP is enabled. If I set _OPENMP myself with add_definitions(), the dependency scanning works as expected, but the compiler is complaining on a redefined macro, the one from cmake and the other one from the compiler. Furthermore the compiler one may contain information I don't know about and are getting hidden by my redefinition ... So, how can I define a macro for the dependency scanner only? Cheerio, Luis -- \\\\\\ (-0^0-) --------------------------oOO--(_)--OOo----------------------------- Luis Kornblueh Tel. : +49-40-41173289 Max-Planck-Institute for Meteorology Fax. : +49-40-41173298 Bundesstr. 53 D-20146 Hamburg Email: luis.kornblueh at mpimet.mpg.de Federal Republic of Germany From robert.maynard at kitware.com Mon Jul 18 09:25:34 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 18 Jul 2016 09:25:34 -0400 Subject: [CMake] set file property from function In-Reply-To: References: Message-ID: Hi Tiago, It is working for me. Here is a small gist that I used to test this: https://gist.github.com/robertmaynard/e788f040564fe4455a37d784476f7081 On Mon, Jul 18, 2016 at 3:21 AM, Tiago Macarios wrote: > Hi, > > Is there a way to set a property of a file/source from a function? > > Below seems to work file outside of a function, but seems not to work inside > one. > > set_property( > SOURCE ${AFILE} > APPEND PROPERTY COMPILE_FLAGS "/wd4068" > ) > > Do I need to CACHE it? or is it a scope problem? > > Thanks, > > Mac > > > -- > > 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 brad.king at kitware.com Mon Jul 18 13:16:49 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 18 Jul 2016 13:16:49 -0400 Subject: [CMake] cmake 3.5 vs 3.6 + qt In-Reply-To: References: Message-ID: <42584bbd-0b7b-28ff-7793-131e31a8d565@kitware.com> On 07/15/2016 04:50 AM, David Callu wrote: > 2016-07-15 1:54 GMT+02:00 Tom Kulaga: >> I'm using 3.5.2 for a qt based project and I've updated to 3.6 and the RCC feature >> seems to fail. Here's a summary >> When I swtiched to 3.6, the compiler can no longer link to the generated rcc files. > > Same thing on my side. I call in my code functions defined in generated .cpp from moc/rcc. > Functions name are based on file path used during .cpp generation. > And this path change from cmake 3.5 to 3.6. The location likely changed in the topic by Sebastian Holtermann merged here: Merge topic 'autogen-updates' https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76e793b9 The goal is to support same-named files in different subdirectories. See this issue: https://gitlab.kitware.com/cmake/cmake/issues/12873 https://cmake.org/Bug/view.php?id=12873 and discussion on the dev list here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16229 I'm not particularly familiar with rcc/AUTORCC/etc. but it is not clear why the path to the generated file matters. CMake generates a file and adds the proper references to it. Its location is an implementation detail. I don't think our documentation ever guaranteed a specific location. Please post a more complete code example that shows the failure case. Thanks, -Brad From tommy8927 at gmail.com Mon Jul 18 18:53:29 2016 From: tommy8927 at gmail.com (Tom Kulaga) Date: Mon, 18 Jul 2016 22:53:29 +0000 Subject: [CMake] cmake 3.5 vs 3.6 + qt In-Reply-To: <42584bbd-0b7b-28ff-7793-131e31a8d565@kitware.com> References: <42584bbd-0b7b-28ff-7793-131e31a8d565@kitware.com> Message-ID: I'll try and get together a minimal example to highlight the difference. On Tue, 19 Jul 2016 at 03:16 Brad King wrote: > On 07/15/2016 04:50 AM, David Callu wrote: > > 2016-07-15 1:54 GMT+02:00 Tom Kulaga: > >> I'm using 3.5.2 for a qt based project and I've updated to 3.6 and the > RCC feature > >> seems to fail. Here's a summary > >> When I swtiched to 3.6, the compiler can no longer link to the > generated rcc files. > > > > Same thing on my side. I call in my code functions defined in generated > .cpp from moc/rcc. > > Functions name are based on file path used during .cpp generation. > > And this path change from cmake 3.5 to 3.6. > > The location likely changed in the topic by Sebastian Holtermann merged > here: > > Merge topic 'autogen-updates' > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76e793b9 > > The goal is to support same-named files in different subdirectories. > See this issue: > > https://gitlab.kitware.com/cmake/cmake/issues/12873 > https://cmake.org/Bug/view.php?id=12873 > > and discussion on the dev list here: > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16229 > > I'm not particularly familiar with rcc/AUTORCC/etc. but it is not clear > why the path to the generated file matters. CMake generates a file and > adds the proper references to it. Its location is an implementation > detail. I don't think our documentation ever guaranteed a specific > location. > > Please post a more complete code example that shows the failure case. > > Thanks, > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Tue Jul 19 10:38:37 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 19 Jul 2016 09:38:37 -0500 Subject: [CMake] Interface targets with their own project in Visual Studio Message-ID: Hello, I'd like to define an INTERFACE library that has header files only but still generates its own project in Visual Studio. The only way to add headers to an interface target that I'm aware of is target_source_files(), which instead of creating a project it will cause the header files themselves to propagate to the actual targets that specify the interface target as a link dependency. Is there a way to change this behavior? If not, the only workaround I can think of is pretty old-school: add_custom_target(), but if I use that I'm not sure I can specify include directories and preprocessor definitions that will be inherited by dependencies. So it seems like I'm forced to choose one or the other. From patrick.boettcher at posteo.de Wed Jul 20 08:29:24 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Wed, 20 Jul 2016 14:29:24 +0200 Subject: [CMake] object-libraries and compile-dependencies to other target Message-ID: <20160720142924.239e8236@posteo.de> Hi list, I'm using an object-library to generate a list of .o-files instead of archives which I use to link into several executable. Even though it is only an object-library it has compile-dependencies to other targets - this includes include-paths, compile-definitions and compile-features. I can't (or I don't know how) use target_link_libraries() with my object-library. What can I do to make it work? I'm exploring generator-expressions, but this seems redundant as I need to list all dependencies again. best regards, -- Patrick. From theodoridisgr at gmail.com Wed Jul 20 09:02:04 2016 From: theodoridisgr at gmail.com (Theodoros Theodoridis) Date: Wed, 20 Jul 2016 15:02:04 +0200 Subject: [CMake] Using clang-tidy with cmake 3.6.0 In-Reply-To: References: Message-ID: <885bd82e-9233-d256-8590-31b3b12e1e18@gmail.com> Hello everyone, I am trying to use the new _CLANG_TIDY property but I can't figure out the proper syntax. How can I specify the checks I want? I tried setting the checks in set_target_properties(target PROPERTIES CXX_CLANG_TIDY "checks to be performed") but cmake would complain with "wrong number of arguments". I would appreciate any help. Thanks, Theodor From jeremy.soumagne at thalesgroup.com Wed Jul 20 11:30:51 2016 From: jeremy.soumagne at thalesgroup.com (SOUMAGNE Jeremy) Date: Wed, 20 Jul 2016 17:30:51 +0200 Subject: [CMake] [CMAKE] Call macro in CMake as last step Message-ID: <33B849CF20810A469877EF96767F6C8167664D6004@THSONEA01CMS30P.one.grp> Hi all, I'm trying to emulate a custom global target (like the CMake install target). The only that came through is by only writing commands in a global variable throughout the cmakelists and at the very end, the last line in the top cmakelists.txt does an include(final) to create the target with all the commands previously produced. I would like to know if there is a way of doing this as the last step without the need to be called explicitly at the end of the CMakeLists.txt. To prevent all the developer to change their CMake to add this line. I saw a similarly thread on stackoverflow, but I was wondering if since a better approach was implemented. (link: http://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0ahUKEwi6xffHqoLOAhWFVRoKHQUBCH4QFgguMAI&url=http%3A%2F%2Fstackoverflow.com%2Fquestions%2F15760580%2Fexecute-command-or-macro-in-cmake-as-last-step-before-configure-step-finishes&usg=AFQjCNGHo0jkrpqw5vm7nx2_YzhJtRtenQ&bvm=bv.127521224,d.d2s) Best regards, jeremy From robert.maynard at kitware.com Wed Jul 20 13:49:52 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 20 Jul 2016 13:49:52 -0400 Subject: [CMake] object-libraries and compile-dependencies to other target In-Reply-To: <20160720142924.239e8236@posteo.de> References: <20160720142924.239e8236@posteo.de> Message-ID: Hi Patrick, Can you provide a simple example of what you are trying to do, and where it is failing? On Wed, Jul 20, 2016 at 8:29 AM, Patrick Boettcher wrote: > Hi list, > > I'm using an object-library to generate a list of .o-files instead of > archives which I use to link into several executable. > > Even though it is only an object-library it has compile-dependencies to > other targets - this includes include-paths, compile-definitions and > compile-features. > > I can't (or I don't know how) use target_link_libraries() with my > object-library. > > What can I do to make it work? I'm exploring generator-expressions, but > this seems redundant as I need to list all dependencies again. > > best regards, > -- > Patrick. > > -- > > 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 tiagomacarios at gmail.com Wed Jul 20 14:02:08 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Wed, 20 Jul 2016 11:02:08 -0700 Subject: [CMake] skip install of subdirectory Message-ID: Hi, I have a project which uses git submodules to manage it's dependencies. Right now we want to add a installer to it, problem we have is that some of the dependencies have their own "install" directives. Is there a way to ignore a project install command? Long version case it is unclear: main project submodule - has a install directive myCode - actual code, links statically to submodule above I would like to only issue the install of myCode. is there a way to tell cmake or cpack to ignore "submodule" install directives? Tiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Wed Jul 20 15:09:07 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 20 Jul 2016 12:09:07 -0700 (PDT) Subject: [CMake] skip install of subdirectory In-Reply-To: References: Message-ID: On 2016-07-20 11:02-0700 Tiago Macarios wrote: > Hi, > > I have a project which uses git submodules to manage it's dependencies. > Right now we want to add a installer to it, problem we have is that some of > the dependencies have their own "install" directives. Is there a way to > ignore a project install command? > > Long version case it is unclear: > > main project > submodule - has a install directive > myCode - actual code, links statically to submodule above > > I would like to only issue the install of myCode. is there a way to tell > cmake or cpack to ignore "submodule" install directives? Hi Tiago: You could brute force it by surrounding each install directive in submodule by if(INSTALL_SUBMODULE) .... endif(INSTALL_SUBMODULE) Then add option(INSTALL_SUBMODULE, "Install submodule?" OFF) to your top-level CMakeLists.txt file. Then because of that OFF, by default users would not install submodule, but if users desired that install, they could specify the -DINSTALL_SUBMODULE=ON option on the cmake command line. Or you could choose to default to ON. Note, I have characterized the above as brute force, but in fact the method is completely flexible, and most mature CMake projects use this kind of option-based method a lot. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From robert.maynard at kitware.com Wed Jul 20 16:02:13 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 20 Jul 2016 16:02:13 -0400 Subject: [CMake] Using clang-tidy with cmake 3.6.0 In-Reply-To: <885bd82e-9233-d256-8590-31b3b12e1e18@gmail.com> References: <885bd82e-9233-d256-8590-31b3b12e1e18@gmail.com> Message-ID: I believe the correct form is: set_target_properties(example PROPERTIES CXX_CLANG_TIDY "${path_to_tidy} -some -args") On Wed, Jul 20, 2016 at 9:02 AM, Theodoros Theodoridis wrote: > Hello everyone, > > I am trying to use the new _CLANG_TIDY property but I can't figure > out the proper syntax. How can I specify the checks I want? > > I tried setting the checks in set_target_properties(target PROPERTIES > CXX_CLANG_TIDY "checks to be performed") but cmake would complain with > "wrong number of arguments". > > I would appreciate any help. > > Thanks, > Theodor > > -- > > 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 tamas.kenez at gmail.com Wed Jul 20 16:26:52 2016 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Wed, 20 Jul 2016 22:26:52 +0200 Subject: [CMake] Why is target installation done in 2 separate steps? In-Reply-To: References: Message-ID: I believe you can install and assign multiple targets in different subdirectories to a single export: /foo/CMakeLists.txt: install(TARGETS foo EXPORT mylib-targets ...) /bar/CMakeLists.txt install(TARGETS bar EXPORT mylib-targets ...) /CMakeLists.txt install(EXPORT mylib-targets ...) On Mon, Jul 11, 2016 at 12:26 AM, Robert Dailey wrote: > Documentation states, that to export a file that imports your targets, > you must do roughly: > > install(TARGETS fubar EXPORT fubar-targets) > install(EXPORT fubar-targets DESTINATION lib/cmake/fubar) > > Why is this done in two steps? Based on reading the install() > documentation, I don't see how the install(TARGETS) command is useful > without the corresponding install(EXPORT). > > Can someone explain why these are separate commands instead of 1 > complete command? Thanks in advance. > -- > > 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 bill.hoffman at kitware.com Wed Jul 20 16:29:19 2016 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 20 Jul 2016 16:29:19 -0400 Subject: [CMake] Using clang-tidy with cmake 3.6.0 In-Reply-To: References: <885bd82e-9233-d256-8590-31b3b12e1e18@gmail.com> Message-ID: On 7/20/2016 4:02 PM, Robert Maynard wrote: > I believe the correct form is: > > set_target_properties(example PROPERTIES CXX_CLANG_TIDY > "${path_to_tidy} -some -args") No, that won't work. You want it to be a semi-colon separated list of arguments. Not space separated. https://cmake.org/cmake/help/v3.6/prop_tgt/LANG_CLANG_TIDY.html#prop_tgt:_CLANG_TIDY In a ctest script it would be done something like this: set(DASHBOARD_CLANG_TIDAY "/path/to/clang-tidy" "-arg1" "-arg2") Then put this in the cache: "CMAKE_CXX_CLANG_TIDY:STRING=${DASHBOARD_CLANG_TIDY}" -Bill From tiagomacarios at gmail.com Wed Jul 20 16:39:52 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Wed, 20 Jul 2016 13:39:52 -0700 Subject: [CMake] skip install of subdirectory In-Reply-To: References: Message-ID: Hi Alan, Thanks a lot! Yeah I was thinking about something along those lines, but i was wondering if there is a solution that does not involve modifying the submodules. On Wed, Jul 20, 2016 at 12:09 PM, Alan W. Irwin wrote: > On 2016-07-20 11:02-0700 Tiago Macarios wrote: > > Hi, >> >> I have a project which uses git submodules to manage it's dependencies. >> Right now we want to add a installer to it, problem we have is that some >> of >> the dependencies have their own "install" directives. Is there a way to >> ignore a project install command? >> >> Long version case it is unclear: >> >> main project >> submodule - has a install directive >> myCode - actual code, links statically to submodule above >> >> I would like to only issue the install of myCode. is there a way to tell >> cmake or cpack to ignore "submodule" install directives? >> > > Hi Tiago: > > You could brute force it by surrounding each install directive in > submodule by > > if(INSTALL_SUBMODULE) > .... > endif(INSTALL_SUBMODULE) > > Then add > > option(INSTALL_SUBMODULE, "Install submodule?" OFF) > > to your top-level CMakeLists.txt file. > > Then because of that OFF, by default users would not install > submodule, but if users desired that install, they could specify the > -DINSTALL_SUBMODULE=ON option on the cmake command line. Or you could > choose to default to ON. > > Note, I have characterized the above as brute force, but in fact the > method is completely flexible, and most mature CMake projects use this > kind of option-based method a lot. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.boettcher at posteo.de Thu Jul 21 05:30:48 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Thu, 21 Jul 2016 11:30:48 +0200 Subject: [CMake] object-libraries and compile-dependencies to other target In-Reply-To: References: <20160720142924.239e8236@posteo.de> Message-ID: <20160721113048.1a6fdd8e@posteo.de> On Wed, 20 Jul 2016 13:49:52 -0400 Robert Maynard wrote: > Hi Patrick, > > Can you provide a simple example of what you are trying to do, and > where it is failing? ----- add_library(lib1 STATIC ) target_include_directories(lib1 PUBLIC lib1-dir) target_compile_features(lib1 PUBLIC cxx_nonstatic_member_init) target_compile_definitions(lib1 PUBLIC FLAG) * lib2 and lib3 like lib1 * # runtime needs include-dirs of lib2 and lib3 add_library(runtime OBJECT file1.cpp) target_link_libraries(runtime INTERFACE lib2 lib3) # fails # so I manually add them: target_include_directories(runtime PRIVATE $) # and the same for target_compile_features and # the INTERFACE_COMPILE_FEATURES property - for all libraries. add_executable(exe exe1.cpp exe2.cpp $) target_link_libraries(exe lib1 lib2 lib3) ----- You might ask, why I need to make an object-library here. This is because of a problem I encounter on some platforms where the linking fails when runtime is a static library. In runtime there is a function which is required by lib2, on the problematic platforms the only way to be sure that the linker is not throwing away this function before it has been referenced, is by passing it as .o-file to the link-line. regards, -- Patrick. From nicholas11braden at gmail.com Thu Jul 21 06:15:51 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Thu, 21 Jul 2016 05:15:51 -0500 Subject: [CMake] FindFreetype works with MinGW but not Visual Studio? Message-ID: I'm having a weird issue that is driving me crazy. I've attached a minimal test case - it downloads and builds Freetype 2.6.4 as static and then configures a project that just calls find_package(Freetype REQUIRED). If the attachment is not there, you can find the two text files here: https://gist.github.com/LB--/34d9dd2d9888fa4479bc9ef61183502c Save "my-project-CMakeLists.txt" as "CMakeLists.txt" in a "my-project" directory next to the other CMakeLists.txt When I build with MinGW (cmake -G "MinGW Makefiles") everything works smoothly and the find_package command works flawlessly. However, when I build with Visual Studio (cmake -G "Visual Studio 14 2015 Win64") I get this error message: Could NOT find Freetype (missing: FREETYPE_LIBRARY) (found version "2.6.4") Looking in the install prefix, in the lib folder MinGW has a "libfreetype.a" and MSVC has a "freetyped.lib". Both should be acceptable according to the source code of the FindFreetype module: https://github.com/Kitware/CMake/blob/v3.6.0/Modules/FindFreetype.cmake Here are my build logs: MinGW: https://gist.github.com/LB--/b4f1413ba72181de7710b6f916c399f8 MSVC: https://gist.github.com/LB--/14a2f65dd069aa59c2a5dacd840f3535 I'm using CMake 3.6.0, MinGW-w64 GCC 6.1.0, and Visual Studio 2015 Update 3 - all on a Windows 10 Pro 64-bit system (build 10586.494). Does anyone know what is causing this? Why can't the find module discover the library archive when building with Visual Studio? For now I have been working around the issue by manually specifying FREETYPE_LIBRARY, which works, but is not desireable. Thanks for your time, Nicholas "LB" Braden -------------- next part -------------- A non-text attachment was scrubbed... Name: find-freetype.zip Type: application/zip Size: 987 bytes Desc: not available URL: From robert.maynard at kitware.com Thu Jul 21 08:41:01 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 21 Jul 2016 08:41:01 -0400 Subject: [CMake] object-libraries and compile-dependencies to other target In-Reply-To: <20160721113048.1a6fdd8e@posteo.de> References: <20160720142924.239e8236@posteo.de> <20160721113048.1a6fdd8e@posteo.de> Message-ID: Hi Patrick, This looks to be another permutation on issue #14778 (https://gitlab.kitware.com/cmake/cmake/issues/14778). Unfortunately currently you will need to manually propagate the include/flags/etc to the OBJECT library. On Thu, Jul 21, 2016 at 5:30 AM, Patrick Boettcher wrote: > On Wed, 20 Jul 2016 13:49:52 -0400 > Robert Maynard wrote: > >> Hi Patrick, >> >> Can you provide a simple example of what you are trying to do, and >> where it is failing? > > ----- > add_library(lib1 STATIC ) > target_include_directories(lib1 PUBLIC lib1-dir) > target_compile_features(lib1 PUBLIC cxx_nonstatic_member_init) > target_compile_definitions(lib1 PUBLIC FLAG) > > * lib2 and lib3 like lib1 * > > # runtime needs include-dirs of lib2 and lib3 > add_library(runtime OBJECT file1.cpp) > target_link_libraries(runtime INTERFACE lib2 lib3) # fails > > # so I manually add them: > > target_include_directories(runtime PRIVATE > $) > # and the same for target_compile_features and > # the INTERFACE_COMPILE_FEATURES property - for all libraries. > > add_executable(exe exe1.cpp exe2.cpp $) > target_link_libraries(exe lib1 lib2 lib3) > > ----- > > You might ask, why I need to make an object-library here. This is > because of a problem I encounter on some platforms where the linking > fails when runtime is a static library. In runtime there is a function > which is required by lib2, on the problematic platforms the only way to > be sure that the linker is not throwing away this function before it has > been referenced, is by passing it as .o-file to the link-line. > > regards, > -- > Patrick. From brad.king at kitware.com Thu Jul 21 09:33:35 2016 From: brad.king at kitware.com (Brad King) Date: Thu, 21 Jul 2016 09:33:35 -0400 Subject: [CMake] cmake 3.5 vs 3.6 + qt In-Reply-To: References: <42584bbd-0b7b-28ff-7793-131e31a8d565@kitware.com> Message-ID: <39babb57-8d5f-e735-1f6a-4e7ebe801b26@kitware.com> On 07/18/2016 06:53 PM, Tom Kulaga wrote: > I'll try and get together a minimal example to highlight the difference. This has now been reported with additional information here: https://gitlab.kitware.com/cmake/cmake/issues/16209 We will have to revert the offending changes until another solution is found. -Brad From bballet at ivsweb.com Thu Jul 21 11:29:46 2016 From: bballet at ivsweb.com (Benjamin Ballet) Date: Thu, 21 Jul 2016 17:29:46 +0200 Subject: [CMake] cmake-3.5.2-win32-x86.exe : broken download link Message-ID: Hi On https://cmake.org/download/ It should be cmake-3.5.2-win32-x86.msi I guess -- *Benjamin BALLET* Ing?nieur R&D *ACTIVISU* 19, rue Klock - 92110 Clichy *> Standard T?l* : 01 44 69 37 37 *>* www.activisu.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stuart_Mentzer at objexx.com Thu Jul 21 11:41:36 2016 From: Stuart_Mentzer at objexx.com (Stuart Mentzer) Date: Thu, 21 Jul 2016 11:41:36 -0400 Subject: [CMake] FindFreetype works with MinGW but not Visual Studio? In-Reply-To: References: Message-ID: <83929b7a-f870-298f-6fce-d81f34be8bed@objexx.com> On 7/21/2016 6:15 AM, Nicholas Braden wrote: > I'm having a weird issue that is driving me crazy. I've attached a > minimal test case - it downloads and builds Freetype 2.6.4 as static > and then configures a project that just calls find_package(Freetype > REQUIRED). If the attachment is not there, you can find the two text > files here: > https://gist.github.com/LB--/34d9dd2d9888fa4479bc9ef61183502c > Save "my-project-CMakeLists.txt" as "CMakeLists.txt" in a "my-project" > directory next to the other CMakeLists.txt > > When I build with MinGW (cmake -G "MinGW Makefiles") everything works > smoothly and the find_package command works flawlessly. > > However, when I build with Visual Studio (cmake -G "Visual Studio 14 > 2015 Win64") I get this error message: > Could NOT find Freetype (missing: FREETYPE_LIBRARY) (found version "2.6.4") > > Looking in the install prefix, in the lib folder MinGW has a > "libfreetype.a" and MSVC has a "freetyped.lib". Both should be > acceptable according to the source code of the FindFreetype module: > https://github.com/Kitware/CMake/blob/v3.6.0/Modules/FindFreetype.cmake > > Here are my build logs: > MinGW: https://gist.github.com/LB--/b4f1413ba72181de7710b6f916c399f8 > MSVC: https://gist.github.com/LB--/14a2f65dd069aa59c2a5dacd840f3535 > > I'm using CMake 3.6.0, MinGW-w64 GCC 6.1.0, and Visual Studio 2015 > Update 3 - all on a Windows 10 Pro 64-bit system (build 10586.494). > > Does anyone know what is causing this? Why can't the find module > discover the library archive when building with Visual Studio? > > For now I have been working around the issue by manually specifying > FREETYPE_LIBRARY, which works, but is not desireable. > > Thanks for your time, > Nicholas "LB" Braden > > Hi Nicholas, I ran in to the same issue: it is due to the 'd' suffix on the debug lib name not being handled. We've got a fixed up FindFreetype.cmake on deck for the next release in https://github.com/Kitware/CMake/blob/next/Modules/FindFreetype.cmake that you can drop into your 3.6.0 installation for now. Stuart From robert.maynard at kitware.com Thu Jul 21 11:53:47 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 21 Jul 2016 11:53:47 -0400 Subject: [CMake] cmake-3.5.2-win32-x86.exe : broken download link In-Reply-To: References: Message-ID: Thanks for reporting the broken link. I have corrected the broken link on the download page. On Thu, Jul 21, 2016 at 11:29 AM, Benjamin Ballet via CMake wrote: > Hi > > On https://cmake.org/download/ > > It should be cmake-3.5.2-win32-x86.msi I guess > > -- > Benjamin BALLET > Ing?nieur R&D > > ACTIVISU > 19, rue Klock - 92110 Clichy >> Standard T?l : 01 44 69 37 37 >> www.activisu.com > > -- > > 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 tommy8927 at gmail.com Thu Jul 21 17:04:31 2016 From: tommy8927 at gmail.com (Tom Kulaga) Date: Thu, 21 Jul 2016 21:04:31 +0000 Subject: [CMake] cmake 3.5 vs 3.6 + qt In-Reply-To: <39babb57-8d5f-e735-1f6a-4e7ebe801b26@kitware.com> References: <42584bbd-0b7b-28ff-7793-131e31a8d565@kitware.com> <39babb57-8d5f-e735-1f6a-4e7ebe801b26@kitware.com> Message-ID: Thanks On Thu, 21 Jul 2016, 23:33 Brad King wrote: > On 07/18/2016 06:53 PM, Tom Kulaga wrote: > > I'll try and get together a minimal example to highlight the difference. > > This has now been reported with additional information here: > > https://gitlab.kitware.com/cmake/cmake/issues/16209 > > We will have to revert the offending changes until another > solution is found. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas11braden at gmail.com Thu Jul 21 20:33:50 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Thu, 21 Jul 2016 19:33:50 -0500 Subject: [CMake] FindFreetype works with MinGW but not Visual Studio? In-Reply-To: <83929b7a-f870-298f-6fce-d81f34be8bed@objexx.com> References: <83929b7a-f870-298f-6fce-d81f34be8bed@objexx.com> Message-ID: Ah thanks! I was looking at the master version of FindFreetype.cmake and saw that fix already there, adding to the confusion. I had changed the link in my message to the 3.6.0 tag at the last moment. Thanks for your time! Nicholas "LB" Braden On Thu, Jul 21, 2016 at 10:41 AM, Stuart Mentzer wrote: > On 7/21/2016 6:15 AM, Nicholas Braden wrote: >> >> I'm having a weird issue that is driving me crazy. I've attached a >> minimal test case - it downloads and builds Freetype 2.6.4 as static >> and then configures a project that just calls find_package(Freetype >> REQUIRED). If the attachment is not there, you can find the two text >> files here: >> https://gist.github.com/LB--/34d9dd2d9888fa4479bc9ef61183502c >> Save "my-project-CMakeLists.txt" as "CMakeLists.txt" in a "my-project" >> directory next to the other CMakeLists.txt >> >> When I build with MinGW (cmake -G "MinGW Makefiles") everything works >> smoothly and the find_package command works flawlessly. >> >> However, when I build with Visual Studio (cmake -G "Visual Studio 14 >> 2015 Win64") I get this error message: >> Could NOT find Freetype (missing: FREETYPE_LIBRARY) (found version >> "2.6.4") >> >> Looking in the install prefix, in the lib folder MinGW has a >> "libfreetype.a" and MSVC has a "freetyped.lib". Both should be >> acceptable according to the source code of the FindFreetype module: >> https://github.com/Kitware/CMake/blob/v3.6.0/Modules/FindFreetype.cmake >> >> Here are my build logs: >> MinGW: https://gist.github.com/LB--/b4f1413ba72181de7710b6f916c399f8 >> MSVC: https://gist.github.com/LB--/14a2f65dd069aa59c2a5dacd840f3535 >> >> I'm using CMake 3.6.0, MinGW-w64 GCC 6.1.0, and Visual Studio 2015 >> Update 3 - all on a Windows 10 Pro 64-bit system (build 10586.494). >> >> Does anyone know what is causing this? Why can't the find module >> discover the library archive when building with Visual Studio? >> >> For now I have been working around the issue by manually specifying >> FREETYPE_LIBRARY, which works, but is not desireable. >> >> Thanks for your time, >> Nicholas "LB" Braden >> >> > Hi Nicholas, > > I ran in to the same issue: it is due to the 'd' suffix on the debug lib > name not being handled. We've got a fixed up FindFreetype.cmake on deck for > the next release in > https://github.com/Kitware/CMake/blob/next/Modules/FindFreetype.cmake that > you can drop into your 3.6.0 installation for now. > > Stuart > -- > > 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 kamen.lilov at chaosgroup.com Thu Jul 21 12:27:05 2016 From: kamen.lilov at chaosgroup.com (Kamen Lilov) Date: Thu, 21 Jul 2016 16:27:05 +0000 Subject: [CMake] Ninja generator bug when handling Windows .dll without associated import .lib Message-ID: Hello, Apologies if this is a duplicate, I searched the net to the best of my ability but was unable to find references to this bug. When a Windows .DLL is generated, the Microsoft linker may sometimes decide that no import library needs to be built. This happens often in one of our projects, we have many .dll's that tie themselves into our infrastructure during static class initialization and export no functions (although they do work and get called via class method pointers from elsewhere) The Ninja CMake generator seems to always emit a dependency on an associated import library along with the .dll file. This causes Ninja to think that a just-built .dll is out of sync (as it can't find the import library file) and relink it, even though it is not dirty. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kamen.lilov at chaosgroup.com Fri Jul 22 08:19:21 2016 From: kamen.lilov at chaosgroup.com (Kamen Lilov) Date: Fri, 22 Jul 2016 12:19:21 +0000 Subject: [CMake] Ninja generator bug when handling Windows .dll without associated import .lib Message-ID: Hello, Apologies if this is a duplicate, I searched the net but was unable to find references to this bug. When a Windows .DLL is generated, the Microsoft linker may sometimes decide that no import library needs to be built. This happens often in one of our projects, we have many .dll's that tie themselves into our infrastructure during static class initialization and export no functions (although they do work and get called via class method pointers from elsewhere) The Ninja CMake generator seems to always emit a dependency on an associated import library along with the .dll file. This causes Ninja to think that a just-built .dll is out of sync (as it can't find the import library file) and relink it, even though it is not dirty. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Fri Jul 22 11:35:16 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 22 Jul 2016 11:35:16 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.6.1 available for download Message-ID: We are pleased to announce that CMake 3.6.1 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ * The CPack NSIS generator's configuration file template was fixed to quote the path to the uninstaller tool used by the "CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL" option. This avoids depending on an insecure Windows feature to run an uninstaller tool with a space in the path. Thanks for your support! ------------------------------------------------------------------------- Changes in 3.6.1 since 3.6.0: Alex Turbov (1): CPack/RPM: Add missed CPACK_RPM_FILE_NAME fallback variable Brad King (6): Restore find_(library|file|path) search of PATH itself VS: Fix VS 2015 .vcxproj debug setting for v90 toolset (#15986) Ninja: Do not force response files when no sysconf(3) limit is used CPack: Add compatibility for incorrect CPACK_INSTALL_CMAKE_PROJECTS value Autogen: Revert changes to generate moc/rcc in subdirectories CMake 3.6.1 Chuck Atkins (3): FindHDF5: Fix h5cc arg parsing to work with homebrew on Mac FindHDF5: Properly fail when required components are not found. FindHDF5: Cleanup inconsistent use of HDF5_ROOT Justin Clift (1): NSIS: Quote uninstaller path when executing it in a shell From soth1985 at gmail.com Fri Jul 22 17:07:06 2016 From: soth1985 at gmail.com (Victor Rykov) Date: Sat, 23 Jul 2016 04:07:06 +0700 Subject: [CMake] XCode generator and .metal shader files Message-ID: Hi, After adding a .metal file to a target via add_executable the metal file does not get pushed to the generated project`s Compile Sources queue and subsequently does not compile during project build unless I add the file to the queue manually from Xcode, I`ve tried setting compile flags on the .metal file as I`ve seen people mention that it works: set(MetalTriangle_SHADERS Shaders.metal) set_source_files_properties(${MetalTriangle_SHADERS} PROPERTIES COMPILE_FLAGS "-fno-fast-math") but unfortunately it did not help, is there any workaround to this problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From theodoridisgr at gmail.com Sun Jul 24 12:38:07 2016 From: theodoridisgr at gmail.com (Theodoros Theodoridis) Date: Sun, 24 Jul 2016 18:38:07 +0200 Subject: [CMake] Using clang-tidy with cmake 3.6.0 In-Reply-To: References: <885bd82e-9233-d256-8590-31b3b12e1e18@gmail.com> Message-ID: <1aabd353-db0a-acfc-4f9d-fdcc78a175e9@gmail.com> Thanks for the answer. However, I still can't get it to work: I tried using set_target_properties(target PROPERTIES CXX_CLANG_TIDY "/usr/local/bin/clang-tidy -checks='llvm*'") and the error I got was: /usr/bin/cmake -E __run_iwyu --tidy="/usr/local/bin/clang-tidy -checks='llvm*'" --source=.... ... Error running '/usr/local/bin/clang-tidy -checks='llvm*'' On 07/20/2016 10:02 PM, Robert Maynard wrote: > I believe the correct form is: > > set_target_properties(example PROPERTIES CXX_CLANG_TIDY > "${path_to_tidy} -some -args") > > On Wed, Jul 20, 2016 at 9:02 AM, Theodoros Theodoridis > wrote: >> Hello everyone, >> >> I am trying to use the new _CLANG_TIDY property but I can't figure >> out the proper syntax. How can I specify the checks I want? >> >> I tried setting the checks in set_target_properties(target PROPERTIES >> CXX_CLANG_TIDY "checks to be performed") but cmake would complain with >> "wrong number of arguments". >> >> I would appreciate any help. >> >> Thanks, >> Theodor >> >> -- >> >> 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 theodoridisgr at gmail.com Sun Jul 24 12:42:47 2016 From: theodoridisgr at gmail.com (Theodoros Theodoridis) Date: Sun, 24 Jul 2016 18:42:47 +0200 Subject: [CMake] Using clang-tidy with cmake 3.6.0 In-Reply-To: References: <885bd82e-9233-d256-8590-31b3b12e1e18@gmail.com> Message-ID: <6c555d03-3492-1e02-5a03-56e2aea29d6a@gmail.com> Oh, I am sorry. For some reason I did not notice the second reply. Thanks From konstantin at podsvirov.pro Sun Jul 24 16:15:17 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Sun, 24 Jul 2016 23:15:17 +0300 Subject: [CMake] Fwd: [Review Request] [Draft] CMake project for QtIFW In-Reply-To: <25141468865865@web4m.yandex.ru> Message-ID: <66131469391317@web9h.yandex.ru> Hello guys! I like CMake and Qt and i initial write and now support CPack IFW generator. For more project integrations i create sugestion: https://bugreports.qt.io/browse/QTIFW-876 And start work on it: https://codereview.qt-project.org/#/c/165493 It's draft, but any feedback will be appreciated. -- Regards, Konstantin Podsvirov From azharudd at codeaurora.org Mon Jul 25 16:39:30 2016 From: azharudd at codeaurora.org (Azharuddin Mohammed) Date: Mon, 25 Jul 2016 13:39:30 -0700 Subject: [CMake] What is a utility target ? Message-ID: <2cea01d1e6b4$a5a2b2a0$f0e817e0$@codeaurora.org> Hi CMake Policy CMP0039 (https://cmake.org/cmake/help/v3.0/policy/CMP0039.html) mentions that "Utility targets may not have link dependencies" . Can someone please explain what does "utility targets" mean ? Thanks - Azhar -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Mon Jul 25 16:52:28 2016 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 26 Jul 2016 06:52:28 +1000 Subject: [CMake] What is a utility target ? In-Reply-To: <2cea01d1e6b4$a5a2b2a0$f0e817e0$@codeaurora.org> References: <2cea01d1e6b4$a5a2b2a0$f0e817e0$@codeaurora.org> Message-ID: In the context of that particular part of the CMake documentation, it is referring to targets that are not created by add_library() or add_executable(). Targets created by add_custom_target() are not something CMake knows what to do with if you give them to the target_link_libraries() command, since these custom targets may not (and typically won't) correspond to a physical file being created (that's what add_custom_command() is for). So the term *utility target* can be thought of as being a custom target you create for convenience, but not something which actually corresponds to a library or executable. Examples of utility targets that CMake will automatically create for you include things like *all*, *test*, *package*, etc. On Tue, Jul 26, 2016 at 6:39 AM, Azharuddin Mohammed < azharudd at codeaurora.org> wrote: > Hi > > > > CMake Policy CMP0039 ( > https://cmake.org/cmake/help/v3.0/policy/CMP0039.html) mentions that ?Utility > targets may not have link dependencies? . Can someone please explain what > does ?utility targets? mean ? > > > > Thanks > > > > - > > Azhar > > -- > > 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 http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmh_users-groups at molconn.com Mon Jul 25 20:57:16 2016 From: lmh_users-groups at molconn.com (LMH) Date: Mon, 25 Jul 2016 20:57:16 -0400 Subject: [CMake] problem building a qhull project with cmake under cygwin Message-ID: <5796B56C.3020304@molconn.com> Hello, I am trying to compute the convex hull of a high dimensional space (46D x 2000 rows). The qhull app available in cygwin/math is based on relatively old code and runs out of memory. I found another version the is supposed to be able to do higher dimensions. https://bitbucket.org/tomilov/quickhull/src This version is set up to build with cmake and seems to need clang, so I installed both cmake and clang from the cygwin installer. The installed version of cmake is 3.3.2. If I run clang --version, I don't get any output so I'm not sure what is up with that. At any rate, in cygwin I tried to build the application with , cmake ./src note, I had to copy CMakeLists.txt into the src directory to get this to work. If I don't do that, I get the error, CMake Error: The source directory "/cygdrive/g/shared_data/SMD/ATomilov_quickhull/tomilov-quickhull-7faf277d6cc2_cmake/src" does not appear to contain CMakeLists.txt. For what ever reason, the archive downloaded from the bitbucket link above does not have CMakeLists.txt file in the src directory but rather on the next level up. When I have copied the CMakeLists.txt file into ./src, cmake runs but I get the error, CMake Error at CMakeLists.txt:11 (message): only clang supported currently this comes from the conditional, if(NOT "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang") message(FATAL_ERROR "only clang supported currently") endif() in CMakeLists.txt. I have installed clang from cygwin, but I still get the same error. I added the following line to CMakeLists.txt, message(STATUS "${CMAKE_CXX_COMPILER_ID}") and I get "GNU" as the value for CMAKE_CXX_COMPILER_ID, at least that is the value if I got the syntax correct for the message statement. It looks like I need to point CMAKE_CXX_COMPILER_ID to clang, but I am not sure how to do that. I don't know if the problem is with the CMakeLists.txt file, the way I am calling cmake, or with my local cygwin configuration. Suggestions would be appreciated. LMH From gjasny at googlemail.com Tue Jul 26 19:03:12 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 27 Jul 2016 01:03:12 +0200 Subject: [CMake] XCode generator and .metal shader files In-Reply-To: References: Message-ID: <82f1837b-ea8f-1dbd-a5db-f06ec4c00de3@googlemail.com> Hello, On 22/07/16 23:07, Victor Rykov wrote: > After adding a .metal file to a target via add_executable the metal file > does not get pushed to the generated project`s Compile Sources queue and > subsequently does not compile during project build unless I add the file to > the queue manually from Xcode, I`ve tried setting compile flags on the > .metal file as I`ve seen people mention that it works: > > set(MetalTriangle_SHADERS Shaders.metal) > > set_source_files_properties(${MetalTriangle_SHADERS} PROPERTIES > COMPILE_FLAGS "-fno-fast-math") > > > but unfortunately it did not help, is there any workaround to this problem? Does it help to set the source files LANGUAGE property to C or C++ via https://cmake.org/cmake/help/v3.6/prop_sf/LANGUAGE.html ? Thanks, Gregor From Jakub.Golebiewski at dnvgl.com Tue Jul 26 03:38:09 2016 From: Jakub.Golebiewski at dnvgl.com (Golebiewski, Jakub) Date: Tue, 26 Jul 2016 07:38:09 +0000 Subject: [CMake] CMake updates timestamp when there are missing files. Message-ID: Hi, I've noticed a weird (but maybe expected) behavior. My colleague forgot to edit CMakeLists.txt file for a library from which he deleted a .cpp file. As expected cmake failed with an error message during build. But next build after that passed without issues. CMake didn't run even though the file was still missing. It seems that previous (failed) cmake run updated timestamp anyway. I'm using CMake 3.2.3 with "Visual Studio 2010 Win64" generator. Is this expected behavior? Can I somehow prevent that? Regards, Jakub Golebiewski ************************************************************************************** This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited. ************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From azharudd at codeaurora.org Wed Jul 27 15:36:18 2016 From: azharudd at codeaurora.org (Azharuddin Mohammed) Date: Wed, 27 Jul 2016 12:36:18 -0700 Subject: [CMake] What is a utility target ? In-Reply-To: References: <2cea01d1e6b4$a5a2b2a0$f0e817e0$@codeaurora.org> Message-ID: <39a301d1e83e$25b1f110$7115d330$@codeaurora.org> Thanks for the explanation, Craig. Is there a way to detect if the target was a physical file created using add_library/add_executable, or a utility target created using add_custom_target in order to conditionally call the target_link_libraries command ? There is the condition if(TARGET target-name) , but according to the documentation it returns true for any existing logical target name such as those created by the add_executable(), add_library(), or add_custom_target() commands. From: Craig Scott [mailto:craig.scott at crascit.com] Sent: Monday, July 25, 2016 1:52 PM To: Azharuddin Mohammed Cc: CMake Subject: Re: [CMake] What is a utility target ? In the context of that particular part of the CMake documentation, it is referring to targets that are not created by add_library() or add_executable(). Targets created by add_custom_target() are not something CMake knows what to do with if you give them to the target_link_libraries() command, since these custom targets may not (and typically won't) correspond to a physical file being created (that's what add_custom_command() is for). So the term utility target can be thought of as being a custom target you create for convenience, but not something which actually corresponds to a library or executable. Examples of utility targets that CMake will automatically create for you include things like all, test, package, etc. On Tue, Jul 26, 2016 at 6:39 AM, Azharuddin Mohammed > wrote: Hi CMake Policy CMP0039 (https://cmake.org/cmake/help/v3.0/policy/CMP0039.html) mentions that ?Utility targets may not have link dependencies? . Can someone please explain what does ?utility targets? mean ? Thanks - Azhar -- 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 http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Wed Jul 27 17:15:14 2016 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 28 Jul 2016 07:15:14 +1000 Subject: [CMake] What is a utility target ? In-Reply-To: <39a301d1e83e$25b1f110$7115d330$@codeaurora.org> References: <2cea01d1e6b4$a5a2b2a0$f0e817e0$@codeaurora.org> <39a301d1e83e$25b1f110$7115d330$@codeaurora.org> Message-ID: There may be a way to tell, but nothing is coming to mind at the moment. Maybe someone else on the list can chime in? On Thu, Jul 28, 2016 at 5:36 AM, Azharuddin Mohammed < azharudd at codeaurora.org> wrote: > Thanks for the explanation, Craig. Is there a way to detect if the target > was a physical file created using add_library/add_executable, or a > utility target created using add_custom_target in order to conditionally > call the target_link_libraries command ? There is the condition if(TARGET > target-name) , but according to the documentation it returns true for any existing > logical target name such as those created by the *add_executable()* > > , *add_library()* > , > or *add_custom_target()* > > commands. > > > > *From:* Craig Scott [mailto:craig.scott at crascit.com] > *Sent:* Monday, July 25, 2016 1:52 PM > *To:* Azharuddin Mohammed > *Cc:* CMake > *Subject:* Re: [CMake] What is a utility target ? > > > > In the context of that particular part of the CMake documentation, it is > referring to targets that are not created by add_library() or > add_executable(). Targets created by add_custom_target() are not something > CMake knows what to do with if you give them to the target_link_libraries() > command, since these custom targets may not (and typically won't) > correspond to a physical file being created (that's what > add_custom_command() is for). So the term *utility target* can be thought > of as being a custom target you create for convenience, but not something > which actually corresponds to a library or executable. Examples of utility > targets that CMake will automatically create for you include things like > *all*, *test*, *package*, etc. > > > > > > On Tue, Jul 26, 2016 at 6:39 AM, Azharuddin Mohammed < > azharudd at codeaurora.org> wrote: > > Hi > > > > CMake Policy CMP0039 ( > https://cmake.org/cmake/help/v3.0/policy/CMP0039.html) mentions that ?Utility > targets may not have link dependencies? . Can someone please explain what > does ?utility targets? mean ? > > > > Thanks > > > > - > > Azhar > > > -- > > 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 > > http://crascit.com > -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From legleux at gmail.com Wed Jul 27 18:49:01 2016 From: legleux at gmail.com (Michael Legleux) Date: Wed, 27 Jul 2016 15:49:01 -0700 Subject: [CMake] exporting targets from build tree Message-ID: I have 2 projects (one built with cmake, one in the process of being converted to using it) Project A (built with cmake) builds lib_a that Project B requires. I'm thinking I'm doing something wrong around here: project(lib_a) ... add_library(lib_a STATIC ${SRC}) target_link_libraries(${PROJECT_NAME} PRIVATE lib_b ) export(TARGETS lib_a FILE lib_a.cmake) cmake complains that lib_b is not in the target export set. I do not WANT it exported and it is not required by project b. I simply want lib_a to be found/used by Project B via find_package(Project A) I do not want to have to install/ or create a package for this behavior, just allow another project to reference the libs in the build tree and headers in the source tree. I can't seem to find the correct way to express this with cmake despite looking at many solutions of near similar functionality. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Thu Jul 28 12:04:42 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 28 Jul 2016 11:04:42 -0500 Subject: [CMake] Interface targets with their own project in Visual Studio In-Reply-To: References: Message-ID: On Tue, Jul 19, 2016 at 9:38 AM, Robert Dailey wrote: > Hello, > > I'd like to define an INTERFACE library that has header files only but > still generates its own project in Visual Studio. The only way to add > headers to an interface target that I'm aware of is > target_source_files(), which instead of creating a project it will > cause the header files themselves to propagate to the actual targets > that specify the interface target as a link dependency. > > Is there a way to change this behavior? > > If not, the only workaround I can think of is pretty old-school: > add_custom_target(), but if I use that I'm not sure I can specify > include directories and preprocessor definitions that will be > inherited by dependencies. So it seems like I'm forced to choose one > or the other. Anyone have any thoughts on this please? From Dvir.Yitzchaki at ceva-dsp.com Thu Jul 28 16:24:32 2016 From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki) Date: Thu, 28 Jul 2016 20:24:32 +0000 Subject: [CMake] Interface targets with their own project in Visual Studio In-Reply-To: References: Message-ID: <71350F7ED6EBB54AA2D182B26086A1B60114AE2A35@ILMAIL1.corp.local> You can use add_library(STATIC) and add set_target_properties( PROPERTIES LINKER_LANGUAGE CXX) You won't be able to link to the target but you can use INTERFACE_INCLUDE_DIRECTORIES etc. Regards, Dvir Yitzchaki Debugger Software Engineer, SDT -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert Dailey Sent: Thursday, July 28, 2016 7:05 PM To: CMake Subject: Re: [CMake] Interface targets with their own project in Visual Studio On Tue, Jul 19, 2016 at 9:38 AM, Robert Dailey wrote: > Hello, > > I'd like to define an INTERFACE library that has header files only but > still generates its own project in Visual Studio. The only way to add > headers to an interface target that I'm aware of is > target_source_files(), which instead of creating a project it will > cause the header files themselves to propagate to the actual targets > that specify the interface target as a link dependency. > > Is there a way to change this behavior? > > If not, the only workaround I can think of is pretty old-school: > add_custom_target(), but if I use that I'm not sure I can specify > include directories and preprocessor definitions that will be > inherited by dependencies. So it seems like I'm forced to choose one > or the other. Anyone have any thoughts on this please? -- 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 Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Fri Jul 29 02:16:49 2016 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Fri, 29 Jul 2016 06:16:49 +0000 Subject: [CMake] add_subdirectory with EXCLUDE_FROM_ALL and cmake --build (Visual Studio) Message-ID: <8D981219EEA621479C112DA9BDC39A8E636F7596@EXMBS1.ad.igd.fraunhofer.de> I just noticed the following issue: If I do an add_subdirectory([...] EXCLUDE_FROM_ALL) and generate a VS (2015) solution, projects added in that subdirectory generate an entirely separate solution (and therefore do not appear in the main solution at all) in the corresponding binary dir subfolder. This causes a cmake -build ${CMAKE_BINARY_DIR} to fail, unlike other generators. Is this intended behavior? It seems odd not to have the targets in the same solution at all Johannes Mueller-Roemer Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From leventelist at gmail.com Fri Jul 29 06:45:09 2016 From: leventelist at gmail.com (Lev) Date: Fri, 29 Jul 2016 12:45:09 +0200 Subject: [CMake] custom build Message-ID: <20160729124509.32dca112@jive> Dear cmake users, Could you please help me how to make cmake to produce a generic build system? What I want to do is running simple shell command on files. Namely, I want to generate sqlite database from a sql file. It all works from the command line, I just can't figure out how to make cmake to do the right thing. I started to do something like this: add_custom_target(foo.sqlite foo.sql) add_custom_command(OUTPUT foo.sqlite MAIN_DEPENDENCY foo.sql COMMAND "cat foo.sql | sqlite3 -batch foo.sqlite") but it doesn't do anything when I issue "make". Any help appreciated. Levente -- 73 de HA5OGL Op.: Levente From dumont.guillaume at gmail.com Fri Jul 29 08:50:13 2016 From: dumont.guillaume at gmail.com (Guillaume Dumont) Date: Fri, 29 Jul 2016 08:50:13 -0400 Subject: [CMake] custom build In-Reply-To: <20160729124509.32dca112@jive> References: <20160729124509.32dca112@jive> Message-ID: As per CMake documentation your custom target should depend on the output of the custom command. So it should look more like this: add_custom_command(OUTPUT foo.sqlite MAIN_DEPENDENCY foo.sql COMMAND "cat foo.sql | sqlite3 -batch foo.sqlite") add_custom_target(foo_sqlite DEPENDS foo.sqlite) HTH Guillaume On Fri, Jul 29, 2016 at 6:45 AM, Lev wrote: > Dear cmake users, > > > Could you please help me how to make cmake to produce a generic build > system? > > What I want to do is running simple shell command on files. Namely, I want > to > generate sqlite database from a sql file. It all works from the command > line, > I just can't figure out how to make cmake to do the right thing. > > I started to do something like this: > > add_custom_target(foo.sqlite foo.sql) > > add_custom_command(OUTPUT foo.sqlite > MAIN_DEPENDENCY foo.sql > COMMAND "cat foo.sql | > sqlite3 -batch foo.sqlite") > > but it doesn't do anything when I issue "make". > > Any help appreciated. > > Levente > > -- > 73 de HA5OGL > Op.: Levente > -- > > 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 > -- Guillaume Dumont ========================= dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From leventelist at gmail.com Fri Jul 29 09:30:39 2016 From: leventelist at gmail.com (Lev) Date: Fri, 29 Jul 2016 15:30:39 +0200 Subject: [CMake] custom build In-Reply-To: References: <20160729124509.32dca112@jive> Message-ID: <20160729153039.168e2616@jive> On Fri, 29 Jul 2016 08:13:08 -0400 "Elizabeth A. Fischer" wrote: > Did you run "cmake" first before "make"? Yes... thanks. > Have you considered just using "make" instead? The big benefits of > CMake are: > 1. Can find link dependencies, which might be in different places on > different systems. > 2. Adjust for the different command line options required by > different compilers. > > So far, I don't see either of those issues in your problem. I would > consider just using plain "make" here. Yes, I considered that solution. Then I have to make the upper level CMakeLists.txt/build system to run "make" in that directory, and somehow make my global variables visible in that Makefile. Seems to be harder than hacking the CMakeLists.txt. And, I want to have a consistent build system. Lev -- 73 de HA5OGL Op.: Levente From leventelist at gmail.com Fri Jul 29 09:50:53 2016 From: leventelist at gmail.com (Lev) Date: Fri, 29 Jul 2016 15:50:53 +0200 Subject: [CMake] custom build In-Reply-To: References: <20160729124509.32dca112@jive> Message-ID: <20160729155053.28d9bb30@jive> On Fri, 29 Jul 2016 08:50:13 -0400 Guillaume Dumont wrote: > add_custom_command(OUTPUT foo.sqlite > MAIN_DEPENDENCY > foo.sql COMMAND "cat foo.sql | > sqlite3 -batch foo.sqlite") > > add_custom_target(foo_sqlite > DEPENDS foo.sqlite) Thanks, that helps. It works somehow. Minor issue, that the double quotes is not necessary. However, the target builds only if I explicitly say 'make foo_sqlite'. So far so good. Is there any way I can make it build if I just say 'make'? And, there are more then one sqlite database to build, how can I make the rule to be generic? Can I say *.sql, *.sqlite? Thanks, Levente -- 73 de HA5OGL Op.: Levente From ggarra13 at gmail.com Fri Jul 29 10:35:51 2016 From: ggarra13 at gmail.com (Gonzalo) Date: Fri, 29 Jul 2016 11:35:51 -0300 Subject: [CMake] CMakeRelink.dir fails on make package on Ninja Message-ID: <2f110997-8d39-56b1-1ed6-bc712421f045@gmail.com> On Linux (Kubuntu 16.04) I am trying to pack my program (no cross compiling), and I am running into the following with the Ninja Generator and a custom library (that is also built in the project): [2/2] Run CPack packaging tool... CPack: Create package using DEB CPack: Install projects CPack: - Install project: Project CMake Error at /media/Linux/code/applications/mrViewer/BUILD/Linux-4.4.0-31-generic-64/Release/tmp/libACESclip/cmake_install.cmake:36 (file): file INSTALL cannot find "/media/Linux/code/applications/mrViewer/BUILD/Linux-4.4.0-31-generic-64/Release/tmp/libACESclip/CMakeFiles/CMakeRelink.dir/libACESclip.so.0.2.6". Call Stack (most recent call first): /media/Linux/code/applications/mrViewer/BUILD/Linux-4.4.0-31-generic-64/Release/tmp/cmake_install.cmake:37 (include) CPack Error: Error when generating package: Project FAILED: cd /media/Linux/code/applications/mrViewer/BUILD/Linux-4.4.0-31-generic-64/Release/tmp && /usr/local/bin/cpack --config ./CPackConfig.cmake ninja: build stopped: subcommand failed. When run with -G 'Unix Makefiles' the packaging works. It is not a permissions problem. I am using the attached "mk" bash script to run the compilation. -- Gonzalo Garramu?o ggarra13 at gmail.com -------------- next part -------------- #!/bin/bash --norc # # Determine CPU architecture # KERNEL=`uname -s` if [[ $KERNEL == CYGWIN* ]]; then KERNEL=Windows RELEASE=(`cmd /c 'ver'`) RELEASE=${RELEASE[3]%.[0-9]*} elif [[ $KERNEL == MINGW* ]]; then RELEASE=(`cmd /c 'ver'`) #RELEASE=${RELEASE[3]%.[0-9]*} RELEASE=${RELEASE[3]/]/} KERNEL=Windows else RELEASE=`uname -r` fi if [[ "$RELEASE" == "" ]]; then $RELEASE=`cmd.exe /c 'ver'` echo $RELEASE echo "Could not determine OS version" exit 1 fi CMAKE_OPTS=${CMAKE_OPTS=""} export CMAKE_NATIVE_ARCH=32 export CMAKE_BUILD_TYPE=Release export OS_32_BITS=1 export OS_64_BITS= export LDFLAGS= export CXXFLAGS= if [ $KERNEL == 'Windows' ]; then arch=`wmic OS get OSArchitecture` if [[ $arch == *64* ]]; then CMAKE_NATIVE_ARCH=64 export OS_64_BITS=1 fi else arch=`uname -a` fi if [[ $arch == *x86_64* ]]; then CMAKE_NATIVE_ARCH=64 export OS_64_BITS=1 else if [[ $arch == *ia64* ]]; then CMAKE_NATIVE_ARCH=64 export OS_64_BITS=1 unset OS_32_BITS fi fi export CMAKE_BUILD_ARCH=$CMAKE_NATIVE_ARCH OS=$KERNEL-$RELEASE usage() { cat < use a different cmake generator (default: Ninja) debug|release|reldebug|small debug - build a debug build release - build a release build (default) reldebug - build a release build with debug information small - build a small release build both|32|64 Builds both 32/64 bit versions, 32-bit only, 64-bit only (default: $CMAKE_BUILD_ARCH) cache - Cleans all CMakeCache.txt files swig - Cleans all swig files clean - Cleans BUILD/$OS-$CMAKE_BUILD_ARCH/$CMAKE_BUILD_TYPE cmake - Runs cmake only. EOF exit 1 } clean_cache() { if [ $CMAKE_BUILD_ARCH == 'Both' ]; then CMAKE_BUILD_ARCH=32 clean_cache CMAKE_BUILD_ARCH=64 clean_cache CMAKE_BUILD_ARCH=Both return fi builddir=BUILD/$OS-$CMAKE_BUILD_ARCH/$CMAKE_BUILD_TYPE if [ ! -d $builddir ]; then return fi echo echo "Removing old cmake caches $builddir..." echo # Remove cache files find $builddir -name CMakeCache.txt -exec rm {} \; # Remove makefiles find $builddir -name Makefile -exec rm {} \; } clean_swig() { if [ $CMAKE_BUILD_ARCH == 'Both' ]; then CMAKE_BUILD_ARCH=32 clean_swig CMAKE_BUILD_ARCH=64 clean_swig CMAKE_BUILD_ARCH=Both return fi # Remove swig wrappers builddir=BUILD/$OS-$CMAKE_BUILD_ARCH/$CMAKE_BUILD_TYPE echo echo "Removing old swig wrappers $builddir..." echo find $builddir -name '*_wrap.*' -exec rm {} \; } # # Parse command-line options # clean=0 cache=0 if [[ $OS == Windows* ]]; then cmake_generator=Ninja #cmake_generator="NMake Makefiles" else cmake_generator=Ninja fi opts='' RUN_MAKE=1 while [ $# -gt 0 ]; do case $1 in 64) shift CMAKE_BUILD_ARCH=64 ;; 32) shift CMAKE_BUILD_ARCH=32 ;; both) shift CMAKE_BUILD_ARCH='Both' ;; cache) shift cache=1 ;; clean) if [ -r CMakeLists.txt ]; then shift if [ -d BUILD ]; then clean=1 fi else break fi ;; cmake) shift RUN_MAKE=0 ;; debug) shift export CMAKE_BUILD_TYPE=Debug ;; release) shift export CMAKE_BUILD_TYPE=Release ;; small) shift export CMAKE_BUILD_TYPE=MinSizeRel ;; swig) shift clean_swig ;; -h) shift usage ;; --help) shift usage ;; -j) shift if [ $# == 0 ]; then echo "Missing parameter for -j!" usage fi CMAKE_PROCS=$1 shift ;; -q) shift opts="" ;; -v) shift opts="VERBOSE=1" ;; -G) shift cmake_generator=$1 shift ;; --) shift break ;; *) break ;; esac done # # Simple function to run a command and print it out # run_cmd() { echo echo "> $*" echo eval command $* } # # Function to just run make on a dir with a Makefile # run_make() { if [ $RUN_MAKE == 0 ]; then return fi cmd='' if [[ $cmake_generator == NMake* ]]; then cmd="nmake $@" elif [[ $cmake_generator == Visual* ]]; then return else cmd="ninja -j ${CMAKE_PROCS=2} $@" fi run_cmd $cmd status=$? if [ $status != 0 ]; then cd ../../../.. exit $status fi cd ../../../.. } # # Function to run cmake and then run make on generated Makefile # run_cmake() { builddir=$PWD/BUILD/$OS-$CMAKE_BUILD_ARCH/$CMAKE_BUILD_TYPE installdir=$builddir/install if [[ $OS == Windows* ]]; then installdir="F:/code/lib/Windows_${CMAKE_BUILD_ARCH}" fi if [ ! -d $installdir ]; then cmd="mkdir -p $installdir" run_cmd $cmd fi echo "Buildir ${builddir}" if [ ! -d $builddir ]; then cmd="mkdir -p $builddir $builddir/bin $builddir/lib $builddir/tmp" run_cmd $cmd fi cmd="cd $builddir/tmp" run_cmd $cmd if [ -r Makefile ]; then run_make $@ return fi pwd=$PWD if [[ $cmake_generator == *Makefile* ]]; then cmake_opts="-DCMAKE_BUILD_TYPE=$CMAKE_BUILD_TYPE" else cmake_opts="-DCMAKE_BUILD_TYPE=$CMAKE_BUILD_TYPE -DCMAKE_CFG_INTDIR=/$CMAKE_BUILD_TYPE" fi cmd="cmake ../../../.. -DCMAKE_INSTALL_PREFIX=$installdir -DEXECUTABLE_OUTPUT_PATH=$builddir/bin -DLIBRARY_OUTPUT_PATH=$builddir/lib -DCMAKE_LIBRARY_PATH=$builddir/lib -DCMAKE_NATIVE_ARCH=$CMAKE_NATIVE_ARCH -DCMAKE_BUILD_ARCH=$CMAKE_BUILD_ARCH ${cmake_opts} -G '${cmake_generator}'" run_cmd $cmd status=$? if [ $status != 0 ]; then cd ../../../.. exit $status fi run_make $@ } # # Function used to clean the build directory and exit # run_clean() { if [ $CMAKE_BUILD_ARCH == "Both" ]; then if [ "$OS_64_BITS" == "1" ]; then CMAKE_BUILD_ARCH=64 run_clean fi if [ "$OS_32_BITS" == "1" ]; then CMAKE_BUILD_ARCH=32 run_clean fi CMAKE_BUILD_ARCH=Both return fi builddir=BUILD/$OS-$CMAKE_BUILD_ARCH/$CMAKE_BUILD_TYPE/tmp if [ -d $builddir ]; then if [ -e ninja.build ]; then run_make clean fi rm -rf $builddir/* echo "-------------------------------" echo "Cleaned $builddir" echo "-------------------------------" clean_cache fi } # # Main routine # if [ $clean == 1 ]; then run_clean exit 0 elif [ $cache == 1 ]; then clean_cache fi if [ -r Makefile ]; then run_make $opts $@ else if [ ! -r CMakeLists.txt ]; then echo "No Makefile or CMakeLists.txt in current directory!" exit 1 fi if [ ! -d BUILD ]; then mkdir BUILD fi if [ $CMAKE_BUILD_ARCH == 'Both' ]; then if [ "$OS_32_BITS" == "1" ]; then export CMAKE_BUILD_ARCH=32 if [ "$OS_64_BITS" == "1" ]; then export LDFLAGS=-m32 export CXXFLAGS=-m32 export CFLAGS=-m32 fi run_cmake $opts $@ fi if [ "$OS_64_BITS" == "1" ]; then export CMAKE_BUILD_ARCH=64 export LDFLAGS= export CXXFLAGS= export CFLAGS= run_cmake $opts $@ fi else run_cmake $opts $@ fi fi From annulen at yandex.ru Fri Jul 29 11:01:07 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 29 Jul 2016 18:01:07 +0300 Subject: [CMake] CMakeRelink.dir fails on make package on Ninja In-Reply-To: <2f110997-8d39-56b1-1ed6-bc712421f045@gmail.com> References: <2f110997-8d39-56b1-1ed6-bc712421f045@gmail.com> Message-ID: <1279521469804467@web23j.yandex.ru> 29.07.2016, 17:36, "Gonzalo" : > On Linux (Kubuntu 16.04) I am trying to pack my program (no cross > compiling), and I am running into the following with the Ninja Generator > and a custom library (that is also built in the project): > > [2/2] Run CPack packaging tool... > CPack: Create package using DEB > CPack: Install projects > CPack: - Install project: Project > CMake Error at > /media/Linux/code/applications/mrViewer/BUILD/Linux-4.4.0-31-generic-64/Release/tmp/libACESclip/cmake_install.cmake:36 > (file): > ???file INSTALL cannot find > "/media/Linux/code/applications/mrViewer/BUILD/Linux-4.4.0-31-generic-64/Release/tmp/libACESclip/CMakeFiles/CMakeRelink.dir/libACESclip.so.0.2.6". > Call Stack (most recent call first): > /media/Linux/code/applications/mrViewer/BUILD/Linux-4.4.0-31-generic-64/Release/tmp/cmake_install.cmake:37 > (include) > > CPack Error: Error when generating package: Project > FAILED: cd > /media/Linux/code/applications/mrViewer/BUILD/Linux-4.4.0-31-generic-64/Release/tmp > && /usr/local/bin/cpack --config ./CPackConfig.cmake > ninja: build stopped: subcommand failed. > > When run with -G 'Unix Makefiles' the packaging works. It is not a > permissions problem. > > I am using the attached "mk" bash script to run the compilation. I'm getting similar error with Ninja generator on a different project [1]. I'm using cmake 2.8.12.2 as shipped by Ubuntu 14.04. Problem does not reproduce always, I haven't investigated yet if it is purely random or reproduces in some particular conditions. [1] https://github.com/annulen/webkit > > -- > Gonzalo Garramu?o > ggarra13 at gmail.com > > ,-- > > 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 chuck.atkins at kitware.com Fri Jul 29 11:42:16 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Fri, 29 Jul 2016 11:42:16 -0400 Subject: [CMake] custom build In-Reply-To: <20160729155053.28d9bb30@jive> References: <20160729124509.32dca112@jive> <20160729155053.28d9bb30@jive> Message-ID: Hi Lev, However, the target builds only if I explicitly say 'make foo_sqlite'. So > far > so good. Is there any way I can make it build if I just say 'make'? > See the add_custom_target documentation for the ALL option, https://cmake.org/cmake/help/v3.6/command/add_custom_target.html And, there are more then one sqlite database to build, how can I make the > rule to be generic? Can I say *.sql, *.sqlite? > The problem with using wild cards is that they won't be sensitive to make detecting file changes. For example, if you add a new file then CMake won't automatically re-run because the *.sql statement hasn't changed. You should also be able to replace the separate custom_target and custom_command with a single custom_target: add_custom_target(foo ALL sqlite3 -init foo.sql foo.sqlite) You could also wrap the call in a macro for convience: macro(add_sqlite_target name) add_custom_target(${name} ALL sqlite3 -init ${CMAKE_CURRENT_SOURCE_DIR}/${name}.sql ${CMAKE_CURRENT_BINARY_DIR}/${name}.sqlite BYPRODUCTS ${CMAKE_CURRENT_BINARY_DIR}/${name}.sqlite SOURCES ${name}.sql) endmacro() add_sqlite_target(fooA) add_sqlite_target(fooB) add_sqlite_target(fooC) add_sqlite_target(fooD) Note the addition of BYPRODUCTS and SOURCES. This adds additional dependency information if you decided to either a) make other targets that consume the database or b) have other targets that produce the source code. - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Sat Jul 30 10:57:52 2016 From: matt.mccormick at kitware.com (Matt McCormick) Date: Sat, 30 Jul 2016 10:57:52 -0400 Subject: [CMake] Visual Studio 2008 / VS Compiler for Python In-Reply-To: References: Message-ID: Hi, Following up to the list for posterity with information summarized by Jc on scikit-build: https://github.com/scikit-build/scikit-build/issues/34#issuecomment-230070388 Setting the environment and using NMake generator will work. Visual Studio generator can not be used with "Microsoft C++ Compiler for Python 2.7" because neither devenv or msbuild are provided. HTH, Matt On Wed, May 11, 2016 at 10:34 AM, Michael Sarahan wrote: > In compiling TBB, a conda-forge contributor ran across issues with CMake not > finding the VS compiler for VS 2008 Win64. > > https://github.com/conda-forge/staged-recipes/pull/533 > > The exact error is at > https://ci.appveyor.com/project/conda-forge/staged-recipes/build/1.0.2118/job/t2axdaotmty35j6k#L216 > > Appveyor is an interesting platform, in that they install VS 2008 Express, > then the VS compiler for Python (which adds the 64-bit compilation support). > > How does CMake find compilers? Does it need extra instruction of some sort > here? > > This is occurring in the context of a conda build, so we have already run > the appropriate vcvars*.bat script by the time CMake runs > (https://ci.appveyor.com/project/conda-forge/staged-recipes/build/1.0.2118/job/t2axdaotmty35j6k#L185) > - but I'm not sure that really influences CMake's ability to find the > compiler. > > Any guidance much appreciated. > > Best, > Michael > > -- > > 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 yaronct at gmail.com Sat Jul 30 11:04:54 2016 From: yaronct at gmail.com (Yaron Cohen-Tal) Date: Sat, 30 Jul 2016 18:04:54 +0300 Subject: [CMake] FindLibXml2.cmake: rename "LIBXML2_DEFINITIONS" Message-ID: Hi, In FindLibXml2.cmake, the name of the variable "LIBXML2_DEFINITIONS" is confusing coz it describes actually what should be added to the "COMPILE_FLAGS" property, not "COMPILE_DEFINITIONS". I think it should b renamed to "LIBXML2_COMPILE_FLAGS". If u wish, I can submit a patch. Thanx, Yaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiri.hoogland at gmail.com Sat Jul 30 13:45:34 2016 From: jiri.hoogland at gmail.com (Jiri Hoogland) Date: Sat, 30 Jul 2016 13:45:34 -0400 Subject: [CMake] running ctest from a different directory than the build directory Message-ID: Hi, I would like to be able in a similar manner as I can run cmake like cmake -H -B cmake --build to run ctest like ctest --build Obviously running ctest from the will work, but it would be nice if I can just tell ctest where to look for its configuration file and where the test executables are located. >From the documentation it is not very clear (or I might not have looked in the right place) if this is possible at all or not. It would great if somebody could shed some light on if this is possible or not ? Many thanks, Jiri -------------- next part -------------- An HTML attachment was scrubbed... URL: From soth1985 at gmail.com Sun Jul 31 00:03:10 2016 From: soth1985 at gmail.com (Victor Rykov) Date: Sun, 31 Jul 2016 11:03:10 +0700 Subject: [CMake] XCode generator and .metal shader files In-Reply-To: <82f1837b-ea8f-1dbd-a5db-f06ec4c00de3@googlemail.com> References: <82f1837b-ea8f-1dbd-a5db-f06ec4c00de3@googlemail.com> Message-ID: Thanks for a tip, Cmake generates correct project with regard to shaders if I set LANGUAGE to METAL set_source_files_properties(${MetalTriangle_SHADERS} PROPERTIES LANGUAGE METAL) On Wed, Jul 27, 2016 at 6:03 AM, Gregor Jasny wrote: > Hello, > > On 22/07/16 23:07, Victor Rykov wrote: > > After adding a .metal file to a target via add_executable the metal file > > does not get pushed to the generated project`s Compile Sources queue and > > subsequently does not compile during project build unless I add the file > to > > the queue manually from Xcode, I`ve tried setting compile flags on the > > .metal file as I`ve seen people mention that it works: > > > > set(MetalTriangle_SHADERS Shaders.metal) > > > > set_source_files_properties(${MetalTriangle_SHADERS} PROPERTIES > > COMPILE_FLAGS "-fno-fast-math") > > > > > > but unfortunately it did not help, is there any workaround to this > problem? > > Does it help to set the source files LANGUAGE property to C or C++ via > https://cmake.org/cmake/help/v3.6/prop_sf/LANGUAGE.html ? > > Thanks, > Gregor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpgupta98 at gmail.com Sun Jul 31 03:19:38 2016 From: kpgupta98 at gmail.com (Kapil Gupta) Date: Sun, 31 Jul 2016 12:49:38 +0530 Subject: [CMake] problem creating cmake for ns3 library Message-ID: Hi, I am working on ns3 library (https://www.nsnam.org/ns-3-25) and wanted to create cmake based project for it. Here is the setup for the project : https://github.com/kneelb4darth/qosManet . The library is correctly installed. .so files : /usr/lib exec : /usr/local/bin lib : /usr/local/lib headers : /usr/include/ns3.25/ns3/ But when I run the code using cmake, I get this error : ``` -- Looking for ns3/core-module.h - found -- Looking for lib ns3-core -- Looking for lib ns3-core - not found -- Warning: To use NS-3 Please install ns3 at least version 3.10 ( http://www.nsnam.org/releases/) ERROR NS3 not found CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: NS3_LIBRARIES (ADVANCED) linked by target "tutifruti" in directory /home/cortana/Desktop/qosManet -- Configuring incomplete, errors occurred! See also "/home/cortana/Desktop/qosManet/build/CMakeFiles/CMakeOutput.log". ``` What can I do to remove this error and make the cmake work ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Sun Jul 31 05:24:29 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sun, 31 Jul 2016 11:24:29 +0200 Subject: [CMake] problem creating cmake for ns3 library In-Reply-To: References: Message-ID: On 31.07.2016 09:19, Kapil Gupta wrote: > > -- Looking for lib ns3-core > -- Looking for lib ns3-core - not found > There might be more issues but to start with: In https://github.com/kneelb4darth/qosManet/blob/master/cmake/FindNS3.cmake#L23 NAME should be NAMES. Same here: https://github.com/kneelb4darth/qosManet/blob/master/cmake/FindNS3.cmake#L30 Beyond that the module seems to break a few conventions (e.g. using plural names for cache variables or automatic extension of include and link directories); you might want to take a look at: https://cmake.org/cmake/help/v3.6/manual/cmake-developer.7.html#find-modules Nils