From yegor_sub1 at visionsystems.de Wed Jul 1 06:27:55 2015 From: yegor_sub1 at visionsystems.de (Yegor Yefremov) Date: Wed, 01 Jul 2015 12:27:55 +0200 Subject: [CMake] CMake toolchain file for multiarch environment (Debian 8) Message-ID: <5593C0AB.5010307@visionsystems.de> I'm trying to construct a suitable toolchain for CMake 3.0.2. I took Buildroot's toochain.cmake and trying to tweak it: set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR armv7l) # specify the cross compiler SET(CMAKE_C_COMPILER "/usr/bin/arm-linux-gnueabihf-gcc") SET(CMAKE_CXX_COMPILER "/usr/bin/arm-linux-gnueabihf-g++") set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os ${CMAKE_C_FLAGS}" CACHE STRING "Buildroot CFLAGS") set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os ${CMAKE_CXX_FLAGS}" CACHE STRING "Buildroot CXXFLAGS") set(CMAKE_EXE_LINKER_FLAGS " ${CMAKE_EXE_LINKER_FLAGS}" CACHE STRING "Buildroot LDFLAGS") set(CMAKE_INSTALL_SO_NO_EXE 0) set(CMAKE_PROGRAM_PATH "/usr/bin") set(CMAKE_FIND_ROOT_PATH "/usr/lib/arm-linux-gnueabihf/cmake") set(CMAKE_PREFIX_PATH "/usr/lib/arm-linux-gnueabihf/cmake") set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(ENV{PKG_CONFIG_SYSROOT_DIR} "/usr/lib/arm-linux-gnueabihf/") I have following problem with Qt5, i.e.Qt5WidgetsConfig.cmake will be found with proper CMAKE_FIND_ROOT_PATH, but then something is missing for CMake to work properly : CMake Error at /usr/lib/arm-linux-gnueabihf/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake:100 (find_package): Could not find a package configuration file provided by "Qt5Gui" (requested version 5.3.2) with any of the following names: Qt5GuiConfig.cmake qt5gui-config.cmake Add the installation prefix of "Qt5Gui" to CMAKE_PREFIX_PATH or set "Qt5Gui_DIR" to a directory containing one of the above files. If "Qt5Gui" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): CMakeLists.txt:23 (FIND_PACKAGE) Regards, Yegor From fuehrer at polymetric.de Wed Jul 1 12:28:21 2015 From: fuehrer at polymetric.de (=?UTF-8?B?QmVuZWRpa3QgRsO8aHJlcg==?=) Date: Wed, 01 Jul 2015 18:28:21 +0200 Subject: [CMake] How to find libraries with custom folder structure Message-ID: <55941525.6020202@polymetric.de> Hi, my jpeg-6b is located in the following folder structure: \libs --\jpeg-6b ----\include ----\lib ------\x64 --------\debug --------\release How can I find the needed files here? The standard FindJPEG in the CMake folder seems to expect a different folder structure and so doesn't find all components. I've tried to write a custom FindJPEG but it seems like it always prefers the standard FindJPEG over my custom one. Do I have to put it into a specific location? The current folder is definitely known to my CMake scripts because I have other script files which are correctly loaded from there. Thanks From Joseph.Gagnon at ll.mit.edu Wed Jul 1 12:54:25 2015 From: Joseph.Gagnon at ll.mit.edu (Gagnon, Joseph - 0553 - MITLL) Date: Wed, 1 Jul 2015 16:54:25 +0000 Subject: [CMake] Problems loading and using external library Message-ID: Let me describe the situation a little. I have a small C++ project with the source files distributed within a small directory hierarchy. I am using JetBrains CLion as the development IDE on a Linux (CentOS 6.6) platform. CLion bundles CMake 3.2.2 in its distribution. I have successfully built the project and produced a static library (.a) file. For identification purposes, let's call this project LLXCC. Now, I've created a separate project that will implement unit tests using Google Test. Let's call this project LLXCC_TEST. I have set up the test project to build with CMake as well. I was not sure of the correct way to make the header files and library file for the project described above (LLXCC) available to the test project. I finally came up with something that CMake does not complain about, but I'm not sure if it's really the right way to do it. Below is what I am doing in the master CMakeLists.txt of the test project: The intent here is to import the project that will be tested. The set_target_properties call sets the path to the libLLXCC.a file. # Add LLXCC. add_library(LLXCC STATIC IMPORTED) set_target_properties(LLXCC PROPERTIES IMPORTED_LOCATION $ENV{HOME}/ClionProjects/llxcc/build/debug/Debug) Adding the path to the project's header files root path. # Add external include paths. include_directories($ENV{HOME}/ClionProjects/llxcc) Later, after adding the text executable (via add_executable), I provide the LLXCC library for linking. target_link_libraries(LLXCC_TEST LLXCC) The problem I'm running into is that the compiler cannot find one of the header files being included in the project being tested - LLXCC. So, to be clear, this is not an issue including a header file in one of the source files in LLXCC_TEST, but in LLXCC which has already been built and provided to LLXCC_TEST via a library file. My first guess is that I'm missing some configuration in the CMakeLists.txt file that resolves the include path problem in LLXCC. The LLXCC project compiles, links and builds just fine. I shouldn't have to change how headers are included in the LLXCC project just to make the LLXCC_TEST build happy. Should the LLXCC project be "packaged" in some way so that it can be "imported" or referenced by LLXCC_TEST in a better way? Is there a different way to make LLXCC available (both header files and library files) to LLXCC_TEST? Although there seems to be a lot of information that can be found regarding CMake, it is still difficult to find information for topics that seem to be pretty basic and important. I am open to any suggestions. Thanks, Joe Gagnon Engineer II Group 53 - Secure Resilient Systems and Technology MIT Lincoln Laboratory Lexington, MA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5625 bytes Desc: not available URL: From nicolasbock at gmail.com Wed Jul 1 14:28:30 2015 From: nicolasbock at gmail.com (Nicolas Bock) Date: Wed, 1 Jul 2015 12:28:30 -0600 Subject: [CMake] warn if features used that require >cmake-x.y Message-ID: Hi, is there a way to get CMake to warn if a feature is used that requires a cmake version greater than some version x.y? Thanks, nick From michael.stuermer at schaeffler.com Thu Jul 2 00:10:17 2015 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Thu, 2 Jul 2015 04:10:17 +0000 Subject: [CMake] How to find libraries with custom folder structure In-Reply-To: <55941525.6020202@polymetric.de> References: <55941525.6020202@polymetric.de> Message-ID: <4797EDAAB4843944A70CA99A7DE7D8BD0400C280@DE012432.schaeffler.com> Did you add the directory where your find script is in to the CMAKE_MODULE_PATH? To verify your script is called, just add a "message("executing my module")" or so on top of your script, this always works very well for me when I'm not sure. See here for more info about the CMAKE_MODULE_PATH: http://www.cmake.org/cmake/help/v3.3/variable/CMAKE_MODULE_PATH.html?highlight=cmake_module_path best regards, Michael > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Benedikt > F?hrer > Sent: Wednesday, July 01, 2015 6:28 PM > To: cmake at cmake.org > Subject: [CMake] How to find libraries with custom folder structure > > Hi, > > my jpeg-6b is located in the following folder structure: > > \libs > --\jpeg-6b > ----\include > ----\lib > ------\x64 > --------\debug > --------\release > > How can I find the needed files here? The standard FindJPEG in the > CMake folder seems to expect a different folder structure and so > doesn't find all components. I've tried to write a custom FindJPEG but > it seems like it always prefers the standard FindJPEG over my custom > one. Do I have to put it into a specific location? The current folder > is definitely known to my CMake scripts because I have other script > files which are correctly loaded from there. > > Thanks > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From michael.stuermer at schaeffler.com Thu Jul 2 00:13:40 2015 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Thu, 2 Jul 2015 04:13:40 +0000 Subject: [CMake] warn if features used that require >cmake-x.y In-Reply-To: References: Message-ID: <4797EDAAB4843944A70CA99A7DE7D8BD0400C298@DE012432.schaeffler.com> Have a look at cmake_minimum_required() and cmake_policy(). I think with these both it should be possible to verify you are using a cmake version that provides all features which are required by your project. See here: http://www.cmake.org/cmake/help/v3.3/command/cmake_minimum_required.html?#command:cmake_minimum_required and here: http://www.cmake.org/cmake/help/v3.3/command/cmake_policy.html best regards, Michael > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Nicolas Bock > Sent: Wednesday, July 01, 2015 8:29 PM > To: cmake at cmake.org > Subject: [CMake] warn if features used that require >cmake-x.y > > Hi, > > is there a way to get CMake to warn if a feature is used that requires > a cmake version greater than some version x.y? > > Thanks, > > nick > -- > > 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 gurenchan at gmail.com Thu Jul 2 09:49:02 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Thu, 2 Jul 2015 21:49:02 +0800 Subject: [CMake] CMake fails on linking. Message-ID: Hi guys I wrote up this post on stackoverflow can I get some help sorting out why this project isn't linking properly? https://stackoverflow.com/questions/31186399/cmake-linking-errors Best -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarra13 at gmail.com Thu Jul 2 10:12:23 2015 From: ggarra13 at gmail.com (Gonzalo Garramuno) Date: Thu, 02 Jul 2015 11:12:23 -0300 Subject: [CMake] CMake fails on linking. In-Reply-To: References: Message-ID: <559546C7.80808@gmail.com> On 02/07/15 10:49, Owen Alanzo Hogarth wrote: > Hi guys > > I wrote up this post on stackoverflow can I get some help sorting out > why this project isn't linking properly? > > https://stackoverflow.com/questions/31186399/cmake-linking-errors > > Best > > You are missing the link libraries (OpenGL and SDL). Not sure on the Mac how these are called. -- Gonzalo Garramu?o From cliffyapp at gmail.com Thu Jul 2 17:06:57 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Thu, 2 Jul 2015 17:06:57 -0400 Subject: [CMake] Problem with CMake 3.3.0-rc3 Message-ID: When running the BRL-CAD configure process with the latest CMake release candidate, the first configure pass completes successfully. The second pass fails almost immediately with the error: CMake Error at CMakeLists.txt:120 (configure_file): Unknown CMake command "configure_file". Configuring incomplete, errors occurred! Has anyone else seen this? Cheers, CY From glenn.coombs at gmail.com Fri Jul 3 03:40:45 2015 From: glenn.coombs at gmail.com (Glenn Coombs) Date: Fri, 3 Jul 2015 08:40:45 +0100 Subject: [CMake] Cannot add target-level dependencies to non-existent target In-Reply-To: References: Message-ID: I've not come across the target_sources command before - is it new in 3.1.3 ? From reading the documentation it looks like it allows one to add sources to a target *after* the target has been created via add_library or add_executable. If that is true then that could be a very useful command. I will investigate further but it could be just what I need. -- Glenn On 30 June 2015 at 22:34, Stephen Kelly wrote: > Glenn Coombs wrote: > > > I am getting the error in the subject. The code I have looks like this: > > > > if (PRE_COMPILED_HEADERS_FOUND) > > ADD_PRECOMPILED_HEADER(${header_pch} ${source_pch} sources > > systemc) > > endif() > > > > add_library(systemc ${sources} ${sources_no_pch} ${headers}) > > > > Use target_sources after the target is created. > > add_library(systemc ${sources} ${headers}) > if (PRE_COMPILED_HEADERS_FOUND) > ADD_PRECOMPILED_HEADER(${header_pch} ${source_pch} pch_files systemc) > target_sources(systemc PRIVATE ${pch_files}) > endif() > > Thanks, > > Steve. > > > -- > > 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 glenn.coombs at gmail.com Fri Jul 3 04:33:42 2015 From: glenn.coombs at gmail.com (Glenn Coombs) Date: Fri, 3 Jul 2015 09:33:42 +0100 Subject: [CMake] warn if features used that require >cmake-x.y In-Reply-To: <4797EDAAB4843944A70CA99A7DE7D8BD0400C298@DE012432.schaeffler.com> References: <4797EDAAB4843944A70CA99A7DE7D8BD0400C298@DE012432.schaeffler.com> Message-ID: I don't think policies are sufficient. I just tried using the new target_sources command that was introduced in CMake 3.1.0 in a CMakeLists.txt file that specified cmake_minimum_required(VERSION 3.0) and it didn't warn that the CMakeLists.txt file wouldn't work with CMake 3.0. I think if you want to guarantee that it will work with CMake x.y then you must always use CMake x.y instead of using newer versions and hoping they will tell you if you have used something that won't work on the older version you require. On 2 July 2015 at 05:13, Stuermer, Michael SP/HZA-ZSEP < michael.stuermer at schaeffler.com> wrote: > Have a look at cmake_minimum_required() and cmake_policy(). I think with > these both it should be possible to verify you are using a cmake version > that provides all features which are required by your project. > > See here: > > > http://www.cmake.org/cmake/help/v3.3/command/cmake_minimum_required.html?#command:cmake_minimum_required > > and here: > > http://www.cmake.org/cmake/help/v3.3/command/cmake_policy.html > > best regards, > Michael > > > > -----Original Message----- > > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Nicolas Bock > > Sent: Wednesday, July 01, 2015 8:29 PM > > To: cmake at cmake.org > > Subject: [CMake] warn if features used that require >cmake-x.y > > > > Hi, > > > > is there a way to get CMake to warn if a feature is used that requires > > a cmake version greater than some version x.y? > > > > Thanks, > > > > nick > > -- > > > > 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 d.dewald at dsfishlabs.com Fri Jul 3 06:00:16 2015 From: d.dewald at dsfishlabs.com (Daniel Dewald) Date: Fri, 3 Jul 2015 10:00:16 +0000 Subject: [CMake] Icon and Launch image support for iOS apps Message-ID: Howdy folks, I'm currently in the process of converting our internal projects from premake to cmake. The process is almost complete. However I've been stuck on a seemingly simple problem the last few days that I could need some help /advise on. Since premake as well as CMake don't have an option to integrate Icon and LaunchImage support for iOS builds in XCode, we have a bash script, that patches the generated project files, to insert the appropriate lines to enable the icon support (this basically is 1.) copying the images into the app folder 2.) including the prepared xcasset file into the resource "folder" of the project (not the target) and 3.) creating a "Copy Bundle Resources" build phase step with the .xcassets file in the target's build phases tab). The script is currently run after cmake is done (in our projects batch file) and this works fine so far for premake as well as cmake. The problem now is that if something is changed, cmake will regenerate the project files and erase those changes. The logical idea would be to execute the script whenever cmake is run. However there is no such functionality in cmake as far as anyone could tell me. Anybody has any clue as to whether cmake supports anything in that area. All ow this has to be done BEFORE the build process is started and AFTER the project files have been created. Otherwise it won't work. We really need this because some genius from Apple decided it would be a good idea for the apps to decide what resolution an app should use on whatever lauch image resolution was choosen O_o. Greetz Daniel -- Daniel Dewald Build Engineer ____________________________________________________________________________________ Deep Silver FISHLABS Koch Media GmbH Ludwig-Erhard-Stra?e 1 | 20459 Hamburg | Germany (Time zone UTC +1) Fon: +49.40.88 88 00 - 227 | Fax: - 166 Mail: d.dewald at dsfishlabs.com | Web: www.dsfishlabs.com District Court Munich HRB 105290 | Managing Partner Dr. Klemens Kundratitz, Stefan Kapelari ____________________________________________________________________________________ ________________________________ Diese E-mail enth?lt VERTRAULICHE UND PERS?NLICHE INFORMATIONEN und/oder PRIVILEGIERTE UND VERTRAULICHE MITTEILUNGEN, die ausschlie?lich f?r die angesprochenen Empf?nger bestimmt sind. Ohne ausdr?ckliche schriftliche Zustimmung des Absenders d?rfen diese Informationen und Mitteilungen nicht an irgendeinen Dritten au?erhalb der Organisation des Empf?ngers weitergeleitet oder zur Kenntnis gebracht werden. Wenn Sie diese E-mail versehentlich empfangen haben, teilen Sie dies bitte dem Absender umgehend telefonisch oder durch R?cksendung dieser E-mail mit, und zerst?ren Sie die Mail sowie Ihre evtl. R?ckmail bitte anschlie?end, ohne eine Kopie zu erstellen. Koch Media ?bernimmt keinerlei Verantwortung f?r m?gliche Verluste oder Besch?digungen, resultierend aus virus-infizierten E-mails bzw. Viren in Anh?ngen. This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient and, therefore, may not be retransmitted to any party outside of the recipient's organization without the prior written consent of the sender. If you have received this e-mail in error please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Koch Media accepts no liability for any losses or damages resulting from infected e-mail transmissions and viruses in e-mail attachment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Fri Jul 3 14:21:25 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Fri, 03 Jul 2015 20:21:25 +0200 Subject: [CMake] warn if features used that require >cmake-x.y In-Reply-To: References: <4797EDAAB4843944A70CA99A7DE7D8BD0400C298@DE012432.schaeffler.com> Message-ID: <4203610.gykr3D4mrl@tuxedo.neundorf.net> On Friday, July 03, 2015 09:33:42 Glenn Coombs wrote: > I don't think policies are sufficient. I just tried using the new > target_sources command that was introduced in CMake 3.1.0 in a > CMakeLists.txt file that specified cmake_minimum_required(VERSION 3.0) and > it didn't warn that the CMakeLists.txt file wouldn't work with CMake 3.0. > I think if you want to guarantee that it will work with CMake x.y then you > must always use CMake x.y instead of using newer versions and hoping they > will tell you if you have used something that won't work on the older > version you require. ...or a nightly build using the minimum required versions of everything the project needs. Alex From a.neundorf-work at gmx.net Fri Jul 3 14:23:26 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Fri, 03 Jul 2015 20:23:26 +0200 Subject: [CMake] warn if features used that require >cmake-x.y In-Reply-To: <4797EDAAB4843944A70CA99A7DE7D8BD0400C298@DE012432.schaeffler.com> References: <4797EDAAB4843944A70CA99A7DE7D8BD0400C298@DE012432.schaeffler.com> Message-ID: <2033107.thO4iEs2ZJ@tuxedo.neundorf.net> On Thursday, July 02, 2015 04:13:40 Stuermer, Michael SP/HZA-ZSEP wrote: > Have a look at cmake_minimum_required() and cmake_policy(). I think with > these both it should be possible to verify you are using a cmake version > that provides all features which are required by your project. no, what he is talking about is the other way round. He wants to make sure nobody accidentially introduces cmake code which requires a newer version of cmake than what cmake_minimum_required() states. I think that's really hard to implement, but it would be nice to have. Alex From digitalriptide at gmail.com Fri Jul 3 16:55:33 2015 From: digitalriptide at gmail.com (digitalriptide) Date: Fri, 3 Jul 2015 16:55:33 -0400 Subject: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions Message-ID: If I enable C++11 for some target via set_target_properties( SomeTarget PROPERTIES CXX_STANDARD 11 ) set_target_properties( SomeTarget PROPERTIES CXX_STANDARD_REQUIRED ON ) with GCC, the code will then compile with -std=gnu++11. Compiling with -std=gnu++11 enables C++11 *and* the GNU extensions. Is there an option that will result in -std=c++11 in lieu of -std=gnu++11, to build without the the GNU extensions? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Jul 3 18:20:30 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sat, 04 Jul 2015 00:20:30 +0200 Subject: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions In-Reply-To: References: Message-ID: <55970AAE.2000809@gmail.com> On 03.07.2015 22:55, digitalriptide wrote: > If I enable C++11 for some target via > set_target_properties( SomeTarget PROPERTIES CXX_STANDARD 11 ) > set_target_properties( SomeTarget PROPERTIES CXX_STANDARD_REQUIRED ON ) > with GCC, the code will then compile with -std=gnu++11. Compiling with > -std=gnu++11 enables C++11 *and* the GNU extensions. Is there an > option that will result in -std=c++11 in lieu of -std=gnu++11, to > build without the the GNU extensions? > There is http://www.cmake.org/cmake/help/v3.2/prop_tgt/CXX_EXTENSIONS.html Nils From scott at towel42.com Sat Jul 4 03:16:57 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Sat, 4 Jul 2015 07:16:57 +0000 Subject: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions In-Reply-To: References: Message-ID: This is why I don?t use the CXX_STANDARD and instead use the CXX_FLAGS and add the flag I need. From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of digitalriptide Sent: Friday, July 3, 2015 1:56 PM To: cmake at cmake.org Subject: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions If I enable C++11 for some target via set_target_properties( SomeTarget PROPERTIES CXX_STANDARD 11 ) set_target_properties( SomeTarget PROPERTIES CXX_STANDARD_REQUIRED ON ) with GCC, the code will then compile with -std=gnu++11. Compiling with -std=gnu++11 enables C++11 *and* the GNU extensions. Is there an option that will result in -std=c++11 in lieu of -std=gnu++11, to build without the the GNU extensions? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Sat Jul 4 06:40:39 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Sat, 04 Jul 2015 12:40:39 +0200 Subject: [CMake] warn if features used that require >cmake-x.y In-Reply-To: <2033107.thO4iEs2ZJ@tuxedo.neundorf.net> References: <4797EDAAB4843944A70CA99A7DE7D8BD0400C298@DE012432.schaeffler.com> <2033107.thO4iEs2ZJ@tuxedo.neundorf.net> Message-ID: Am 3. Juli 2015 20:23:26 MESZ, schrieb Alexander Neundorf : >On Thursday, July 02, 2015 04:13:40 Stuermer, Michael SP/HZA-ZSEP >wrote: >> Have a look at cmake_minimum_required() and cmake_policy(). I think >with >> these both it should be possible to verify you are using a cmake >version >> that provides all features which are required by your project. > >no, what he is talking about is the other way round. >He wants to make sure nobody accidentially introduces cmake code which >requires a newer version of cmake than what cmake_minimum_required() >states. > >I think that's really hard to implement, but it would be nice to have. This would also involve all variables and properties and all find modules. I'd say that the only way to make sure that it works with that version is to actually test it... HS From kgt at lanl.gov Sat Jul 4 15:52:42 2015 From: kgt at lanl.gov (Thompson, KT) Date: Sat, 4 Jul 2015 19:52:42 +0000 Subject: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions In-Reply-To: References: Message-ID: <0458DF31F610EF42BFC78C497E806C7B45A223F9@ECS-EXG-P-MB03.win.lanl.gov> Try setting CMAKE_CXX_EXTENSIONS this to OFF. http://www.cmake.org/cmake/help/v3.2/prop_tgt/CXX_EXTENSIONS.html#prop_tgt:CXX_EXTENSIONS From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom Sent: Saturday, July 04, 2015 1:17 AM To: digitalriptide; cmake at cmake.org Subject: Re: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions This is why I don?t use the CXX_STANDARD and instead use the CXX_FLAGS and add the flag I need. From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of digitalriptide Sent: Friday, July 3, 2015 1:56 PM To: cmake at cmake.org Subject: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions If I enable C++11 for some target via set_target_properties( SomeTarget PROPERTIES CXX_STANDARD 11 ) set_target_properties( SomeTarget PROPERTIES CXX_STANDARD_REQUIRED ON ) with GCC, the code will then compile with -std=gnu++11. Compiling with -std=gnu++11 enables C++11 *and* the GNU extensions. Is there an option that will result in -std=c++11 in lieu of -std=gnu++11, to build without the the GNU extensions? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From digitalriptide at gmail.com Sat Jul 4 17:13:33 2015 From: digitalriptide at gmail.com (digitalriptide) Date: Sat, 4 Jul 2015 17:13:33 -0400 Subject: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions In-Reply-To: <0458DF31F610EF42BFC78C497E806C7B45A223F9@ECS-EXG-P-MB03.win.lanl.gov> References: <0458DF31F610EF42BFC78C497E806C7B45A223F9@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: Thank you for the pointers, adding set( CMAKE_CXX_EXTENSIONS OFF ) to the root CMakeLists.txt disabled the extensions through the project. On Sat, Jul 4, 2015 at 3:52 PM, Thompson, KT wrote: > Try setting CMAKE_CXX_EXTENSIONS this to OFF. > > > > > http://www.cmake.org/cmake/help/v3.2/prop_tgt/CXX_EXTENSIONS.html#prop_tgt:CXX_EXTENSIONS > > > > *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Scott Aron > Bloom > *Sent:* Saturday, July 04, 2015 1:17 AM > *To:* digitalriptide; cmake at cmake.org > *Subject:* Re: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions > > > > This is why I don?t use the CXX_STANDARD and instead use the CXX_FLAGS and > add the flag I need. > > > > *From:* CMake [mailto:cmake-bounces at cmake.org ] *On > Behalf Of *digitalriptide > *Sent:* Friday, July 3, 2015 1:56 PM > *To:* cmake at cmake.org > *Subject:* [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions > > > > If I enable C++11 for some target via > > set_target_properties( SomeTarget PROPERTIES CXX_STANDARD 11 ) > > set_target_properties( SomeTarget PROPERTIES CXX_STANDARD_REQUIRED ON ) > > with GCC, the code will then compile with -std=gnu++11. Compiling with > -std=gnu++11 enables C++11 *and* the GNU extensions. Is there an option > that will result in -std=c++11 in lieu of -std=gnu++11, to build without > the the GNU extensions? > > > > Thank you! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Sun Jul 5 12:07:15 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Sun, 5 Jul 2015 12:07:15 -0400 Subject: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions In-Reply-To: References: <0458DF31F610EF42BFC78C497E806C7B45A223F9@ECS-EXG-P-MB03.win.lanl.gov> Message-ID: <2CFB682E-53CA-478D-A1BE-E8EC34F75BEB@bluequartz.net> Is there a project wide CXX_STANDARD_REQUIRED that I can set? I am wanting to migrate our project to C++ 11 and would rather set something in the project root rather than find every place where our own and our customers plugin codes create a target. Thanks Mike Jackson On Jul 4, 2015, at 5:13 PM, digitalriptide wrote: > Thank you for the pointers, adding > set( CMAKE_CXX_EXTENSIONS OFF ) > to the root CMakeLists.txt disabled the extensions through the project. > > On Sat, Jul 4, 2015 at 3:52 PM, Thompson, KT wrote: > Try setting CMAKE_CXX_EXTENSIONS this to OFF. > > > > http://www.cmake.org/cmake/help/v3.2/prop_tgt/CXX_EXTENSIONS.html#prop_tgt:CXX_EXTENSIONS > > > > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Scott Aron Bloom > Sent: Saturday, July 04, 2015 1:17 AM > To: digitalriptide; cmake at cmake.org > Subject: Re: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions > > > > This is why I don?t use the CXX_STANDARD and instead use the CXX_FLAGS and add the flag I need. > > > > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of digitalriptide > Sent: Friday, July 3, 2015 1:56 PM > To: cmake at cmake.org > Subject: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions > > > > If I enable C++11 for some target via > > set_target_properties( SomeTarget PROPERTIES CXX_STANDARD 11 ) > > set_target_properties( SomeTarget PROPERTIES CXX_STANDARD_REQUIRED ON ) > > with GCC, the code will then compile with -std=gnu++11. Compiling with -std=gnu++11 enables C++11 *and* the GNU extensions. Is there an option that will result in -std=c++11 in lieu of -std=gnu++11, to build without the the GNU extensions? > > > > Thank you! > > > -- > > 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 roman.wueger at gmx.at Sun Jul 5 14:24:02 2015 From: roman.wueger at gmx.at (=?iso-8859-1?Q?Roman_W=FCger?=) Date: Sun, 5 Jul 2015 20:24:02 +0200 Subject: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions In-Reply-To: <2CFB682E-53CA-478D-A1BE-E8EC34F75BEB@bluequartz.net> References: <0458DF31F610EF42BFC78C497E806C7B45A223F9@ECS-EXG-P-MB03.win.lanl.gov> <2CFB682E-53CA-478D-A1BE-E8EC34F75BEB@bluequartz.net> Message-ID: <003c01d0b74f$c5d25660$51770320$@gmx.at> Hi, you must set the following in the root CMakeLists.txt file: set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED ON) Did you mean that? http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_CXX_STANDARD.html http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_CXX_STANDARD_REQUIRED.ht ml Best Regards Roman Von: CMake [mailto:cmake-bounces at cmake.org] Im Auftrag von Michael Jackson Gesendet: Sonntag, 05. Juli 2015 18:07 An: cmake at cmake.org Betreff: Re: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions Is there a project wide CXX_STANDARD_REQUIRED that I can set? I am wanting to migrate our project to C++ 11 and would rather set something in the project root rather than find every place where our own and our customers plugin codes create a target. Thanks Mike Jackson On Jul 4, 2015, at 5:13 PM, digitalriptide > wrote: Thank you for the pointers, adding set( CMAKE_CXX_EXTENSIONS OFF ) to the root CMakeLists.txt disabled the extensions through the project. On Sat, Jul 4, 2015 at 3:52 PM, Thompson, KT > wrote: Try setting CMAKE_CXX_EXTENSIONS this to OFF. http://www.cmake.org/cmake/help/v3.2/prop_tgt/CXX_EXTENSIONS.html#prop_tgt:C XX_EXTENSIONS From: CMake [mailto:cmake-bounces at cmake.org ] On Behalf Of Scott Aron Bloom Sent: Saturday, July 04, 2015 1:17 AM To: digitalriptide; cmake at cmake.org Subject: Re: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions This is why I don?t use the CXX_STANDARD and instead use the CXX_FLAGS and add the flag I need. From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of digitalriptide Sent: Friday, July 3, 2015 1:56 PM To: cmake at cmake.org Subject: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions If I enable C++11 for some target via set_target_properties( SomeTarget PROPERTIES CXX_STANDARD 11 ) set_target_properties( SomeTarget PROPERTIES CXX_STANDARD_REQUIRED ON ) with GCC, the code will then compile with -std=gnu++11. Compiling with -std=gnu++11 enables C++11 *and* the GNU extensions. Is there an option that will result in -std=c++11 in lieu of -std=gnu++11, to build without the the GNU extensions? Thank you! -- 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 mike.jackson at bluequartz.net Sun Jul 5 14:56:43 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Sun, 05 Jul 2015 14:56:43 -0400 Subject: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions In-Reply-To: <003c01d0b74f$c5d25660$51770320$@gmx.at> References: <0458DF31F610EF42BFC78C497E806C7B45A223F9@ECS-EXG-P-MB03.win.lanl.gov> <2CFB682E-53CA-478D-A1BE-E8EC34F75BEB@bluequartz.net> <003c01d0b74f$c5d25660$51770320$@gmx.at> Message-ID: <55997DEB.7000501@bluequartz.net> Cool, I think that is what I want. -- Mike Jackson Roman W?ger wrote: > Hi, > > you must set the following in the root CMakeLists.txt file: > > set(CMAKE_CXX_STANDARD 11) > > set(CMAKE_CXX_STANDARD_REQUIRED ON) > > Did you mean that? > > http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_CXX_STANDARD.html > > http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_CXX_STANDARD_REQUIRED.html > > Best Regards > > Roman > > *Von:*CMake [mailto:cmake-bounces at cmake.org] *Im Auftrag von *Michael > Jackson > *Gesendet:* Sonntag, 05. Juli 2015 18:07 > *An:* cmake at cmake.org > *Betreff:* Re: [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions > > Is there a project wide CXX_STANDARD_REQUIRED that I can set? I am > wanting to migrate our project to C++ 11 and would rather set something > in the project root rather than find every place where our own and our > customers plugin codes create a target. > > Thanks > > Mike Jackson > > On Jul 4, 2015, at 5:13 PM, digitalriptide > wrote: > > > > Thank you for the pointers, adding > > set( CMAKE_CXX_EXTENSIONS OFF ) > > to the root CMakeLists.txt disabled the extensions through the project. > > On Sat, Jul 4, 2015 at 3:52 PM, Thompson, KT > wrote: > > Try setting CMAKE_CXX_EXTENSIONS this to OFF. > > http://www.cmake.org/cmake/help/v3.2/prop_tgt/CXX_EXTENSIONS.html#prop_tgt:CXX_EXTENSIONS > > *From:*CMake [mailto:cmake-bounces at cmake.org > ] *On Behalf Of *Scott Aron Bloom > *Sent:* Saturday, July 04, 2015 1:17 AM > *To:* digitalriptide; cmake at cmake.org > *Subject:* Re: [CMake] Setting CXX_STANDARD 11 Enables GNU > Extensions > > This is why I don?t use the CXX_STANDARD and instead use the > CXX_FLAGS and add the flag I need. > > *From:*CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of > *digitalriptide > *Sent:* Friday, July 3, 2015 1:56 PM > *To:* cmake at cmake.org > *Subject:* [CMake] Setting CXX_STANDARD 11 Enables GNU Extensions > > If I enable C++11 for some target via > > set_target_properties( SomeTarget PROPERTIES CXX_STANDARD 11 ) > > set_target_properties( SomeTarget PROPERTIES > CXX_STANDARD_REQUIRED ON ) > > with GCC, the code will then compile with -std=gnu++11. > Compiling with -std=gnu++11 enables C++11 *and* the GNU > extensions. Is there an option that will result in -std=c++11 in > lieu of -std=gnu++11, to build without the the GNU extensions? > > Thank you! > > -- > > 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 gurenchan at gmail.com Mon Jul 6 03:48:37 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Mon, 6 Jul 2015 15:48:37 +0800 Subject: [CMake] cmake linking errors in simple project Message-ID: I created this simple project but I am having linking errors. Everything builds correctly but when I try to add my lib to my main.c cmake complains about linking errors. Here's what the project looks like: http://pastebin.com/22bCsuiE if i #include "time_utils.h" in my main.c I get this error: Scanning dependencies of target launcher [ 50%] Building C object CMakeFiles/launcher.dir/main.c.o /Users/xx/project/main.c:2:10: fatal error: 'time_utils.h' file not found #include "time_utils.h" if I remove that line from the main.c it builds properly. I though adding this line TARGET_LINK_LIBRARIES(auncher time_utils) to my cmakelists.txt it would find the library but seems not. How can I make sure that the library is found and properly linked? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwan.work at gmail.com Mon Jul 6 03:53:36 2015 From: rwan.work at gmail.com (Raymond Wan) Date: Mon, 6 Jul 2015 15:53:36 +0800 Subject: [CMake] cmake linking errors in simple project In-Reply-To: References: Message-ID: Hi Owen, On Mon, Jul 6, 2015 at 3:48 PM, Owen Alanzo Hogarth wrote: > I created this simple project but I am having linking errors. Everything > builds correctly but when I try to add my lib to my main.c cmake complains > about linking errors. > > Here's what the project looks like: http://pastebin.com/22bCsuiE > > if i #include "time_utils.h" in my main.c I get this error: > > Scanning dependencies of target launcher > [ 50%] Building C object CMakeFiles/launcher.dir/main.c.o > /Users/xx/project/main.c:2:10: fatal error: 'time_utils.h' file not found > #include "time_utils.h" > > if I remove that line from the main.c it builds properly. I though adding > this line TARGET_LINK_LIBRARIES(auncher time_utils) to my cmakelists.txt it > would find the library but seems not. How can I make sure that the library > is found and properly linked? Perhaps you can try adding: INCLUDE_DIRECTORIES () It looks like the problem is with compiling main.c. That's when it is looking for the header files. It isn't linking yet. That is what TARGET_LINK_LIBRARIES is for. Not sure if this is the right solution, but maybe you can give it a try; that is what I'm doing. Ray From jcook at cray.com Mon Jul 6 08:44:18 2015 From: jcook at cray.com (Justin Cook) Date: Mon, 6 Jul 2015 12:44:18 +0000 Subject: [CMake] adding file extensions for languages Message-ID: Hello, I was trying to add some file extensions for the Fortran language (.ftn), but I was not able to get past some errors even after trying a few different options including appending to CMAKE_Fortran_SOURCE_FILE_EXTENSIONS in a toolchain file. Ideas on how to get around the following error(s)? It looks like set_target_property might work, but I'd rather just add the extension to work as any other accepted extension. -- Configuring done CMake Error: CMake can not determine linker language for target: ftn_mpi_hello CMake Error: Cannot determine link language for target "ftn_mpi_hello". -- Generating done Thanks, Justin From Nicholas.Crast at saabsensis.com Mon Jul 6 08:41:57 2015 From: Nicholas.Crast at saabsensis.com (Crast, Nicholas) Date: Mon, 6 Jul 2015 12:41:57 +0000 Subject: [CMake] Preventing CMakeLists from being too similar Message-ID: <36A43B0E1E88D84791516F9D44BC483327F20F11@corpmail01.corp.sensis.com> Hi guys, I have a question for you about general practices. I have a top level directory with a bunch of modules inside: Nick | |module1 |module2 |module3 Module1, module2, and module3 are subdirectories inside of the nick directory. Each module directory contains src,inc and test (gtest unit test files). These modules are pretty similar in structure, meaning the CMakeLists files are almost identical. Is there any way to make some sort of generic CMakeLists file that I can call with arguments for all 3 modules? I'm having the same issue with unit tests, where the unit test section for my CMakeLists is essentially identical between the modules. Thoughts? -Nick ---------------------------------------- Nick Crast Software Engineer Saab Sensis Corporation Phone: 315-445-5703 Email: Nicholas.Crast at saabsensis.com This message is intended only for the addressee and may contain information that is company confidential or privileged. Any technical data in this message may be exported only in accordance with the U.S. International Traffic in Arms Regulations (22 CFR Parts 120-130) or the Export Administration Regulations (15 CFR Parts 730-774). Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message. If you have received this email in error, please delete it, and advise the sender immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.wirtz at simtech.uni-stuttgart.de Mon Jul 6 09:30:54 2015 From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz) Date: Mon, 06 Jul 2015 15:30:54 +0200 Subject: [CMake] Preventing CMakeLists from being too similar In-Reply-To: <36A43B0E1E88D84791516F9D44BC483327F20F11@corpmail01.corp.sensis.com> References: <36A43B0E1E88D84791516F9D44BC483327F20F11@corpmail01.corp.sensis.com> Message-ID: <559A830E.3070008@simtech.uni-stuttgart.de> Hey, there's several options. - the easiest is probably to create inclusion files on the Nick level, put the identical functionality in there and include them in the modules. - a bit "cleaner" ist to create a e.g. Macros.cmake file on the Nick level, put the identical functionality in there and invoke the macros from the sub-level; that's more like a "separation of concerns / encapsulation" approach. - if your modules need to be self-contained (without knowing to be inside the "Nick" folder), you could think of setting up a template on Nick level and have that being configured into the module folders with appropriate different values inserted. i'd go for the second option myself. cheers Daniel Dr. Daniel Wirtz Dipl. Math. Dipl. Inf. SRC SimTech Pfaffenwaldring 5a +49 711 685 60044 On 07/06/2015 02:41 PM, Crast, Nicholas wrote: > > Hi guys, > > I have a question for you about general practices. I have a top level > directory with a bunch of modules inside: > > Nick > > | > > |module1 > > |module2 > > |module3 > > Module1, module2, and module3 are subdirectories inside of the nick > directory. Each module directory contains src,inc and test (gtest unit > test files). > > These modules are pretty similar in structure, meaning the CMakeLists > files are almost identical. Is there any way to make some sort of > generic CMakeLists file that I can call with arguments for all 3 > modules? I?m having the same issue with unit tests, where the unit > test section for my CMakeLists is essentially identical between the > modules. > > Thoughts? > > -Nick > > ---------------------------------------- > > Nick Crast > > Software Engineer > > Saab Sensis Corporation > > Phone: 315-445-5703 > > Email: Nicholas.Crast at saabsensis.com > > > > /This message is intended only for the addressee and may contain > information that is company confidential or privileged. Any technical > data in this message may be exported only in accordance with the U.S. > International Traffic in Arms Regulations (22 CFR Parts 120-130) or > the Export Administration Regulations (15 CFR Parts 730-774). > Unauthorized use is strictly prohibited and may be unlawful. If you > are not the intended recipient, or the person responsible for > delivering to the intended recipient, you should not read, copy, > disclose or otherwise use this message. If you have received this > email in error, please delete it, and advise the sender immediately. / > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Jul 6 11:53:05 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Jul 2015 11:53:05 -0400 Subject: [CMake] Problem with CMake 3.3.0-rc3 In-Reply-To: References: Message-ID: <559AA461.5070104@kitware.com> On 07/02/2015 05:06 PM, Clifford Yapp wrote: > When running the BRL-CAD configure process with the latest CMake > release candidate, the first configure pass completes successfully. > The second pass fails almost immediately with the error: > > CMake Error at CMakeLists.txt:120 (configure_file): > Unknown CMake command "configure_file". Thanks for testing the RC! I cannot reproduce that, but BRL-CAD is a huge project with many configuration options. What exact version did you build, on what platform, and with what cmake command line? I see the top-level CMakeLists.txt file in BRL-CAD is using undocumented and unsupported behavior by re-defining many core commands as functions, including configure_file: > function(add_library name) > _add_library(${name} ${ARGN}) ... > function(add_executable name) > _add_executable(${name} ${ARGN}) ... > function(add_custom_target name) > _add_custom_target(${name} ${ARGN}) ... > function(configure_file file targetfile) > _configure_file(${file} ${targetfile} ${ARGN}) ... > function(add_subdirectory name) > _add_subdirectory(${name} ${ARGN}) ... > function(message) > _message(${ARGN}) The ability to do that is meant only for local debugging and is not documented. I see comments justifying it with a link to old discussion here: http://www.cmake.org/pipermail/cmake/2010-September/039388.html but unfortunately that advice was wrong. BRL-CAD should be using its own names for those. Or, someone could come to the cmake developers list to discuss how to add functionality to CMake to overcome the need for such wrapper functions. Still, if we can easily fix 3.3 to not regress existing BRL-CAD releases then we should do so. Can you use the above information to strip it down to a minimal example showing the problem? Thanks, -Brad From cedric.doucet at inria.fr Tue Jul 7 06:52:55 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Tue, 7 Jul 2015 12:52:55 +0200 (CEST) Subject: [CMake] Downloading several files with ExternalProject_Add In-Reply-To: <1588957393.2232175.1436266260920.JavaMail.zimbra@inria.fr> Message-ID: <1702043325.2233917.1436266375074.JavaMail.zimbra@inria.fr> Hello! I would like to download and compile a pair of C files (foo.h, foo.c) thanks to the ExternalProject_Add function. However, only one URL can be provided. What is the cleanest way to handle such a case? Cheers, C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.steinke at gmail.com Tue Jul 7 12:36:20 2015 From: jan.steinke at gmail.com (Jan Steinke) Date: Tue, 07 Jul 2015 16:36:20 +0000 Subject: [CMake] cmake: Duplicate file name conflict Message-ID: Dear all, I came across a problem, for me it seems that cmake does not allow header files to be have the same name. Or am I doing something wrong? I have two projects, a library and an application. Both have files with similar content, but the same file names. I am using cmake to compile the app and the aim is that cmake also compiles the library if it doesn't yet exist. I was stuck for a few days on that problem until I figured out that it was due to the same file names. When renaming the files in my application it builds correctly. Before I switched to cmake a week ago, I used qmake integrated into Qt Creator, and it compiled just fine. Is it wanted behavior, that cmake does not allow the same file names? Am I doing something wrong? Altough it works with renaming the files I would like to find a "cleaner" way that prevents this from happening in the future, having same file names is nothing you can prevent if you work in a team. I hope you are able to help me, Jan -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at borho.org Tue Jul 7 15:36:25 2015 From: steve at borho.org (Steve Borho) Date: Tue, 7 Jul 2015 14:36:25 -0500 Subject: [CMake] linking static libs into shared libs on Linux Message-ID: <20150707193625.GG130244@borho.org> Hello, I am the technical lead for x265 (HEVC encoder) and we have used cmake successfully since the beginning of the project. There are a few rough edges that we've had to work around (uninstall rules, yasm support in MSVC, etc) but in general it has worked pretty well. x265 can support a number of bit-depth options, but these are compile time decisions. You must chose at build time whether the encoder will use 8bit, 10bit, or 12bit color samples internally. Recently we've resolved the naming conflicts and thus allow these multiple builds of libx265 to be linked together into a single binary. The way the multilib build process currently works is it creates 8bit/ 10bit/ and 12bit/ folders, then runs cmake in each seperately (with different options) so there are three distinct build folders. It builds 10bit and 12bit first, outputting only static libraries, then finally it builds the 8bit folder and adds the 10bit and 12bit static libraries to the 8bit shared library link target. This works well on Windows and Mac but on x86_64 Linux I get this error: /bin/ld: common/CMakeFiles/common.dir/x86/pixel-a.asm.o: relocation R_X86_64_PC32 against symbol `x265_pw_1' can not be used when making a shared object; recompile with -fPIC (in a nutshell, the 10bit and 12bit static libs are no longer position independent) I figure there are multiple potential solutions for this and would welcome pointers for any of them 1 - is there a way for the project to re-include itself? If so we could have the 8bit build simply build the 10 and 12bit object libraries and link with those directly and bypass the creation of static libraries. This would perhaps be optimal since you would end up with a single Makefile driving the whole build. 2 - is there some invocation that will force cmake to build the static libraries such that they are still safe for linking into a shared library? I've already tried these unsuccessfully: set(CMAKE_POSITION_INDEPENDENT_CODE TRUE) set_target_properties(x265-static PROPERTIES POSITION_INDEPENDENT_CODE TRUE) set_target_properties(x265-static PROPERTIES LINK_FLAGS "-fPIC") 3 - is there another intermediate format that cmake can output that preserves -fPIC, or some way to access the object libraries of the other external builds? 4 - is there any post-processing that can be done on the static libs to make them safe for shared libs again (guessing this is not likely) (note: I'm building on Centos 7, but this does not appear to be distribution dependent, and I've tried cmake 2.8.11 and 3.2.3) Thanks -- Steve Borho PS: Our source code is at https://bitbucket.org/multicoreware/x265 From neaman at nod-labs.com Tue Jul 7 16:41:44 2015 From: neaman at nod-labs.com (Neamah) Date: Tue, 7 Jul 2015 13:41:44 -0700 (MST) Subject: [CMake] Building OpenCV on Mac OS X Yosemite with CMake Message-ID: <1436301704644-7590991.post@n2.nabble.com> Hi, I've been set up with OpenCV for about a month now (I'm using it on Mac and on Android too), but I recently tried rebuilding OpenCV on both Mac and Android and I haven't been able to due to multiple CMake errors. Here's what I see when I try building: cd opencv/platforms rm -rf build_android_arm sh ./scripts/cmake_android_arm.sh CMake Error at platforms/android/android.toolchain.cmake:530 (message): It is not possible to change the path to the NDK on subsequent CMake run. You must remove all generated files from your build folder first. Call Stack (most recent call first): /opt/local/share/cmake-3.2/Modules/CMakeDetermineSystem.cmake:98 (include) CMakeLists.txt:88 (project) CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_CXX_COMPILER_ENV_VAR CMake Error: Could not find cmake module file: /Users/nodlabs/nod/src/thirdparty/opencv/CMakeFiles/3.2.3/CMakeCXXCompiler.cmake CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_C_COMPILER_ENV_VAR CMake Error: Could not find cmake module file: /Users/nodlabs/nod/src/thirdparty/opencv/CMakeFiles/3.2.3/CMakeCCompiler.cmake -- Configuring incomplete, errors occurred! Can anybody please shed light on what's going on? I'm not sure how this has been working just fine and doesn't anymore. I tried reinstalling the android-ndk from scratch, but that didn't work either. -- View this message in context: http://cmake.3232098.n2.nabble.com/Building-OpenCV-on-Mac-OS-X-Yosemite-with-CMake-tp7590991.html Sent from the CMake mailing list archive at Nabble.com. From a.neundorf-work at gmx.net Tue Jul 7 16:37:58 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Tue, 07 Jul 2015 22:37:58 +0200 Subject: [CMake] linking static libs into shared libs on Linux In-Reply-To: <20150707193625.GG130244@borho.org> References: <20150707193625.GG130244@borho.org> Message-ID: <2386859.OemUkUF2nW@tuxedo.neundorf.net> On Tuesday, July 07, 2015 14:36:25 Steve Borho wrote: > Hello, I am the technical lead for x265 (HEVC encoder) and we have used > cmake successfully since the beginning of the project. There are a few > rough edges that we've had to work around (uninstall rules, yasm support > in MSVC, etc) but in general it has worked pretty well. > > x265 can support a number of bit-depth options, but these are compile > time decisions. You must chose at build time whether the encoder will > use 8bit, 10bit, or 12bit color samples internally. Recently we've > resolved the naming conflicts and thus allow these multiple builds of > libx265 to be linked together into a single binary. > > The way the multilib build process currently works is it creates 8bit/ > 10bit/ and 12bit/ folders, then runs cmake in each seperately (with > different options) so there are three distinct build folders. It builds > 10bit and 12bit first, outputting only static libraries, then finally it > builds the 8bit folder and adds the 10bit and 12bit static libraries to > the 8bit shared library link target. > > This works well on Windows and Mac but on x86_64 Linux I get this error: > > /bin/ld: common/CMakeFiles/common.dir/x86/pixel-a.asm.o: relocation > R_X86_64_PC32 against symbol `x265_pw_1' can not be used when making a > shared object; recompile with -fPIC > > (in a nutshell, the 10bit and 12bit static libs are no longer position > independent) > > I figure there are multiple potential solutions for this and would > welcome pointers for any of them > > 1 - is there a way for the project to re-include itself? If so we could > have the 8bit build simply build the 10 and 12bit object libraries and > link with those directly and bypass the creation of static libraries. > This would perhaps be optimal since you would end up with a single > Makefile driving the whole build. > > 2 - is there some invocation that will force cmake to build the static > libraries such that they are still safe for linking into a shared > library? > > I've already tried these unsuccessfully: > set(CMAKE_POSITION_INDEPENDENT_CODE TRUE) > set_target_properties(x265-static PROPERTIES POSITION_INDEPENDENT_CODE > TRUE) set_target_properties(x265-static PROPERTIES LINK_FLAGS "-fPIC") > > 3 - is there another intermediate format that cmake can output that > preserves -fPIC, or some way to access the object libraries of the > other external builds? > > 4 - is there any post-processing that can be done on the static libs to > make them safe for shared libs again (guessing this is not likely) did you already have a look at the "object libraries" (created using add_library(... OBJECT...) ? Those basically just build the object files, and can later be used to link into other targets. Alex From dank at kegel.com Tue Jul 7 17:04:28 2015 From: dank at kegel.com (Dan Kegel) Date: Tue, 7 Jul 2015 14:04:28 -0700 Subject: [CMake] linking static libs into shared libs on Linux In-Reply-To: <20150707193625.GG130244@borho.org> References: <20150707193625.GG130244@borho.org> Message-ID: On Tue, Jul 7, 2015 at 12:36 PM, Steve Borho wrote: > /bin/ld: common/CMakeFiles/common.dir/x86/pixel-a.asm.o: relocation > R_X86_64_PC32 against symbol `x265_pw_1' can not be used when making a > shared object; recompile with -fPIC > ... > 2 - is there some invocation that will force cmake to build the static > libraries such that they are still safe for linking into a shared > library? > > I've already tried these unsuccessfully: > set(CMAKE_POSITION_INDEPENDENT_CODE TRUE) > set_target_properties(x265-static PROPERTIES POSITION_INDEPENDENT_CODE TRUE) > set_target_properties(x265-static PROPERTIES LINK_FLAGS "-fPIC") > > 3 - is there another intermediate format that cmake can output that > preserves -fPIC, or some way to access the object libraries of the > other external builds? Try set_target_properties(x265-static PROPERTIES COMPILE_FLAGS "-fPIC") Alternately, something like set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC") when compiling the files in question. From steve at borho.org Tue Jul 7 17:19:31 2015 From: steve at borho.org (Steve Borho) Date: Tue, 7 Jul 2015 16:19:31 -0500 Subject: [CMake] linking static libs into shared libs on Linux In-Reply-To: <2386859.OemUkUF2nW@tuxedo.neundorf.net> References: <20150707193625.GG130244@borho.org> <2386859.OemUkUF2nW@tuxedo.neundorf.net> Message-ID: <20150707211931.GK130244@borho.org> On 07/07, Alexander Neundorf wrote: > On Tuesday, July 07, 2015 14:36:25 Steve Borho wrote: > > Hello, I am the technical lead for x265 (HEVC encoder) and we have used > > cmake successfully since the beginning of the project. There are a few > > rough edges that we've had to work around (uninstall rules, yasm support > > in MSVC, etc) but in general it has worked pretty well. > > > > x265 can support a number of bit-depth options, but these are compile > > time decisions. You must chose at build time whether the encoder will > > use 8bit, 10bit, or 12bit color samples internally. Recently we've > > resolved the naming conflicts and thus allow these multiple builds of > > libx265 to be linked together into a single binary. > > > > The way the multilib build process currently works is it creates 8bit/ > > 10bit/ and 12bit/ folders, then runs cmake in each seperately (with > > different options) so there are three distinct build folders. It builds > > 10bit and 12bit first, outputting only static libraries, then finally it > > builds the 8bit folder and adds the 10bit and 12bit static libraries to > > the 8bit shared library link target. > > > > This works well on Windows and Mac but on x86_64 Linux I get this error: > > > > /bin/ld: common/CMakeFiles/common.dir/x86/pixel-a.asm.o: relocation > > R_X86_64_PC32 against symbol `x265_pw_1' can not be used when making a > > shared object; recompile with -fPIC > > > > (in a nutshell, the 10bit and 12bit static libs are no longer position > > independent) > > > > I figure there are multiple potential solutions for this and would > > welcome pointers for any of them > > > > 1 - is there a way for the project to re-include itself? If so we could > > have the 8bit build simply build the 10 and 12bit object libraries and > > link with those directly and bypass the creation of static libraries. > > This would perhaps be optimal since you would end up with a single > > Makefile driving the whole build. > > > > 2 - is there some invocation that will force cmake to build the static > > libraries such that they are still safe for linking into a shared > > library? > > > > I've already tried these unsuccessfully: > > set(CMAKE_POSITION_INDEPENDENT_CODE TRUE) > > set_target_properties(x265-static PROPERTIES POSITION_INDEPENDENT_CODE > > TRUE) set_target_properties(x265-static PROPERTIES LINK_FLAGS "-fPIC") > > > > 3 - is there another intermediate format that cmake can output that > > preserves -fPIC, or some way to access the object libraries of the > > other external builds? > > > > 4 - is there any post-processing that can be done on the static libs to > > make them safe for shared libs again (guessing this is not likely) > > did you already have a look at the "object libraries" (created using > add_library(... OBJECT...) ? Those basically just build the object files, and > can later be used to link into other targets. We use object libraries internally, but I don't know how the 8bit build can access the object libraries from the 10bit or 12bit builds. -- Steve Borho From steve at borho.org Tue Jul 7 17:25:36 2015 From: steve at borho.org (Steve Borho) Date: Tue, 7 Jul 2015 16:25:36 -0500 Subject: [CMake] linking static libs into shared libs on Linux In-Reply-To: References: <20150707193625.GG130244@borho.org> Message-ID: <20150707212536.GL130244@borho.org> On 07/07, Dan Kegel wrote: > On Tue, Jul 7, 2015 at 12:36 PM, Steve Borho wrote: > > /bin/ld: common/CMakeFiles/common.dir/x86/pixel-a.asm.o: relocation > > R_X86_64_PC32 against symbol `x265_pw_1' can not be used when making a > > shared object; recompile with -fPIC > > ... > > 2 - is there some invocation that will force cmake to build the static > > libraries such that they are still safe for linking into a shared > > library? > > > > I've already tried these unsuccessfully: > > set(CMAKE_POSITION_INDEPENDENT_CODE TRUE) > > set_target_properties(x265-static PROPERTIES POSITION_INDEPENDENT_CODE TRUE) > > set_target_properties(x265-static PROPERTIES LINK_FLAGS "-fPIC") > > > > 3 - is there another intermediate format that cmake can output that > > preserves -fPIC, or some way to access the object libraries of the > > other external builds? > > Try > set_target_properties(x265-static PROPERTIES COMPILE_FLAGS "-fPIC") > > Alternately, something like > set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC") > when compiling the files in question. sadly that didn't help. We're already adding -fPIC to the compile flags for the two object libraries. This way one set of objects can be used to output the shared library and the static library. So the C++ files are already compiled with -fPIC. It is only a problem when we need to link a static library from one build into the shared library of another build. The static library itself no longer supports PIC. -- Steve Borho From dank at kegel.com Tue Jul 7 17:58:27 2015 From: dank at kegel.com (Dan Kegel) Date: Tue, 7 Jul 2015 14:58:27 -0700 Subject: [CMake] linking static libs into shared libs on Linux In-Reply-To: <20150707212536.GL130244@borho.org> References: <20150707193625.GG130244@borho.org> <20150707212536.GL130244@borho.org> Message-ID: On Tue, Jul 7, 2015 at 2:25 PM, Steve Borho wrote: > We're already adding -fPIC to the compile flags for the two object > libraries. This way one set of objects can be used to output the shared > library and the static library. So the C++ files are already compiled > with -fPIC. It is only a problem when we need to link a static library > from one build into the shared library of another build. The static > library itself no longer supports PIC. Really? I didn't think ar was in the habit of modifying machine code like that. At this point maybe the thing to do is make a toy example that reproduces the problem. (Ideally something truly stipped down, like https://github.com/dankegel/winezeug/tree/master/cmake_examples/ex7 ) - Dan From petr.kmoch at gmail.com Wed Jul 8 03:03:47 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 8 Jul 2015 09:03:47 +0200 Subject: [CMake] cmake: Duplicate file name conflict In-Reply-To: References: Message-ID: Hi Jan, it'simpossible to answer such questions without seeing your setup. Can you post your CMakeList and your directory structure? Petr On Tue, Jul 7, 2015 at 6:36 PM, Jan Steinke wrote: > Dear all, > I came across a problem, for me it seems that cmake does not allow header > files to be have the same name. Or am I doing something wrong? > > I have two projects, a library and an application. Both have files with > similar content, but the same file names. I am using cmake to compile the > app and the aim is that cmake also compiles the library if it doesn't yet > exist. I was stuck for a few days on that problem until I figured out that > it was due to the same file names. When renaming the files in my > application it builds correctly. Before I switched to cmake a week ago, I > used qmake integrated into Qt Creator, and it compiled just fine. > > Is it wanted behavior, that cmake does not allow the same file names? Am I > doing something wrong? Altough it works with renaming the files I would > like to find a "cleaner" way that prevents this from happening in the > future, having same file names is nothing you can prevent if you work in a > team. > > I hope you are able to help me, > Jan > -- > Jan > -- > > 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 jan.steinke at gmail.com Wed Jul 8 03:46:46 2015 From: jan.steinke at gmail.com (Jan Steinke) Date: Wed, 08 Jul 2015 07:46:46 +0000 Subject: [CMake] cmake: Duplicate file name conflict In-Reply-To: References: Message-ID: Hi Peter, Thanks for your quick reply. My file structure is as such someFolder/ library/code/include/*sameName.h* library/code/include/anotherName.h library/code/source/sameName.cpp library/code/source/anotherName.cpp application/code/include/*sameName.h* application/code/include/yetAnotherName.h application/code/source/*sameName.cpp* application/code/source/yetAnotherName.cpp *My CMakeLists.txt for the library:* cmake_minimum_required(VERSION 3.0 FATAL_ERROR) project(library) set(Headers include/sameName.h include/anotherName.h) set(Sources source/sameName.cpp sources/anotherName.h) set(CMAKE_AUTOMOC ON) include_directories(include) add_library(${PROJECT_NAME} STATIC ${Headers} ${Sources}) target_link_libraries(${PROJECT_NAME}) *CMakeLists.txt for the application:* cmake_minimum_required(VERSION 3.0 FATAL_ERROR) project(application) set(Headers include/sameName.h include/yetAnotherName.h) set(Sources source/sameName.cpp source/yetAnotherName.cpp) set(CMAKE_AUTOMOC ON) set(CMAKE_AUTORCC ON) set(LIBRARY_ROOT ${PROJECT_SOURCE_DIR}/../../library) include_directories(include) include_directories(include/remotes) include_directories($LIBRARY_ROOT}/code/include) include_directories(${PROJECT_BINARY_DIR} add_subdirectory(${LIBRARY_ROOT}/code library) add_executable(${PROJECT_NAME} ${Forms} ${Headers} resources/${PROJECT_NAME}.qrc ${Sources}) target_link_libraries(${PROJECT_NAME} library) I hope that helps understanding my problem. Since the content of sameName.h and sameName.cpp of the library is different from those of the application it doesn't build. However, it would be confusing to name them differently since their job is the same. Thanks in advance, Jan On Wed, Jul 8, 2015 at 9:03 AM Petr Kmoch wrote: > Hi Jan, > > it'simpossible to answer such questions without seeing your setup. Can you > post your CMakeList and your directory structure? > > Petr > > On Tue, Jul 7, 2015 at 6:36 PM, Jan Steinke wrote: > >> Dear all, >> I came across a problem, for me it seems that cmake does not allow header >> files to be have the same name. Or am I doing something wrong? >> >> I have two projects, a library and an application. Both have files with >> similar content, but the same file names. I am using cmake to compile the >> app and the aim is that cmake also compiles the library if it doesn't yet >> exist. I was stuck for a few days on that problem until I figured out that >> it was due to the same file names. When renaming the files in my >> application it builds correctly. Before I switched to cmake a week ago, I >> used qmake integrated into Qt Creator, and it compiled just fine. >> >> Is it wanted behavior, that cmake does not allow the same file names? Am >> I doing something wrong? Altough it works with renaming the files I would >> like to find a "cleaner" way that prevents this from happening in the >> future, having same file names is nothing you can prevent if you work in a >> team. >> >> I hope you are able to help me, >> Jan >> -- >> Jan >> > -- >> >> 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 >> > > -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Wed Jul 8 03:58:53 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 8 Jul 2015 09:58:53 +0200 Subject: [CMake] cmake: Duplicate file name conflict In-Reply-To: References: Message-ID: I can't see anything obviously wrong with your setup. Can you post the error you're getting as well? The only candidate for trouble I can think of is AUTOMOC. I don't have experience with that, but is it possible the name clash comes from AUTOMOC-generated files? Petr On Wed, Jul 8, 2015 at 9:46 AM, Jan Steinke wrote: > Hi Peter, > Thanks for your quick reply. > > My file structure is as such > someFolder/ > library/code/include/*sameName.h* > library/code/include/anotherName.h > library/code/source/sameName.cpp > library/code/source/anotherName.cpp > > application/code/include/*sameName.h* > application/code/include/yetAnotherName.h > application/code/source/*sameName.cpp* > application/code/source/yetAnotherName.cpp > > *My CMakeLists.txt for the library:* > cmake_minimum_required(VERSION 3.0 FATAL_ERROR) > project(library) > set(Headers include/sameName.h > include/anotherName.h) > > set(Sources source/sameName.cpp > sources/anotherName.h) > set(CMAKE_AUTOMOC ON) > include_directories(include) > add_library(${PROJECT_NAME} STATIC ${Headers} ${Sources}) > target_link_libraries(${PROJECT_NAME}) > > *CMakeLists.txt for the application:* > cmake_minimum_required(VERSION 3.0 FATAL_ERROR) > project(application) > set(Headers include/sameName.h > include/yetAnotherName.h) > set(Sources source/sameName.cpp > source/yetAnotherName.cpp) > set(CMAKE_AUTOMOC ON) > set(CMAKE_AUTORCC ON) > set(LIBRARY_ROOT ${PROJECT_SOURCE_DIR}/../../library) > > include_directories(include) > include_directories(include/remotes) > include_directories($LIBRARY_ROOT}/code/include) > include_directories(${PROJECT_BINARY_DIR} > > add_subdirectory(${LIBRARY_ROOT}/code library) > add_executable(${PROJECT_NAME} ${Forms} ${Headers} > resources/${PROJECT_NAME}.qrc ${Sources}) > target_link_libraries(${PROJECT_NAME} library) > > I hope that helps understanding my problem. Since the content of > sameName.h and sameName.cpp of the library is different from those of the > application it doesn't build. However, it would be confusing to name them > differently since their job is the same. > > Thanks in advance, > Jan > > On Wed, Jul 8, 2015 at 9:03 AM Petr Kmoch wrote: > >> Hi Jan, >> >> it'simpossible to answer such questions without seeing your setup. Can >> you post your CMakeList and your directory structure? >> >> Petr >> >> On Tue, Jul 7, 2015 at 6:36 PM, Jan Steinke >> wrote: >> >>> Dear all, >>> I came across a problem, for me it seems that cmake does not allow >>> header files to be have the same name. Or am I doing something wrong? >>> >>> I have two projects, a library and an application. Both have files with >>> similar content, but the same file names. I am using cmake to compile the >>> app and the aim is that cmake also compiles the library if it doesn't yet >>> exist. I was stuck for a few days on that problem until I figured out that >>> it was due to the same file names. When renaming the files in my >>> application it builds correctly. Before I switched to cmake a week ago, I >>> used qmake integrated into Qt Creator, and it compiled just fine. >>> >>> Is it wanted behavior, that cmake does not allow the same file names? Am >>> I doing something wrong? Altough it works with renaming the files I would >>> like to find a "cleaner" way that prevents this from happening in the >>> future, having same file names is nothing you can prevent if you work in a >>> team. >>> >>> I hope you are able to help me, >>> Jan >>> -- >>> Jan >>> >> -- >>> >>> 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 >>> >> >> -- > Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.steinke at gmail.com Wed Jul 8 04:14:15 2015 From: jan.steinke at gmail.com (Jan Steinke) Date: Wed, 08 Jul 2015 08:14:15 +0000 Subject: [CMake] cmake: Duplicate file name conflict In-Reply-To: References: Message-ID: Thank you Petr! AUTOMOC is the culprit. That pointed me in the right direction. I was able to find this and this . It seems as if it is something that can't be changed due to the design of AUTOMOC. On Wed, Jul 8, 2015 at 9:58 AM Petr Kmoch wrote: > I can't see anything obviously wrong with your setup. Can you post the > error you're getting as well? > > The only candidate for trouble I can think of is AUTOMOC. I don't have > experience with that, but is it possible the name clash comes from > AUTOMOC-generated files? > > Petr > > On Wed, Jul 8, 2015 at 9:46 AM, Jan Steinke wrote: > >> Hi Peter, >> Thanks for your quick reply. >> >> My file structure is as such >> someFolder/ >> library/code/include/*sameName.h* >> library/code/include/anotherName.h >> library/code/source/sameName.cpp >> library/code/source/anotherName.cpp >> >> application/code/include/*sameName.h* >> application/code/include/yetAnotherName.h >> application/code/source/*sameName.cpp* >> application/code/source/yetAnotherName.cpp >> >> *My CMakeLists.txt for the library:* >> cmake_minimum_required(VERSION 3.0 FATAL_ERROR) >> project(library) >> set(Headers include/sameName.h >> include/anotherName.h) >> >> set(Sources source/sameName.cpp >> sources/anotherName.h) >> set(CMAKE_AUTOMOC ON) >> include_directories(include) >> add_library(${PROJECT_NAME} STATIC ${Headers} ${Sources}) >> target_link_libraries(${PROJECT_NAME}) >> >> *CMakeLists.txt for the application:* >> cmake_minimum_required(VERSION 3.0 FATAL_ERROR) >> project(application) >> set(Headers include/sameName.h >> include/yetAnotherName.h) >> set(Sources source/sameName.cpp >> source/yetAnotherName.cpp) >> set(CMAKE_AUTOMOC ON) >> set(CMAKE_AUTORCC ON) >> set(LIBRARY_ROOT ${PROJECT_SOURCE_DIR}/../../library) >> >> include_directories(include) >> include_directories(include/remotes) >> include_directories($LIBRARY_ROOT}/code/include) >> include_directories(${PROJECT_BINARY_DIR} >> >> add_subdirectory(${LIBRARY_ROOT}/code library) >> add_executable(${PROJECT_NAME} ${Forms} ${Headers} >> resources/${PROJECT_NAME}.qrc ${Sources}) >> target_link_libraries(${PROJECT_NAME} library) >> >> I hope that helps understanding my problem. Since the content of >> sameName.h and sameName.cpp of the library is different from those of the >> application it doesn't build. However, it would be confusing to name them >> differently since their job is the same. >> >> Thanks in advance, >> Jan >> >> On Wed, Jul 8, 2015 at 9:03 AM Petr Kmoch wrote: >> >>> Hi Jan, >>> >>> it'simpossible to answer such questions without seeing your setup. Can >>> you post your CMakeList and your directory structure? >>> >>> Petr >>> >>> On Tue, Jul 7, 2015 at 6:36 PM, Jan Steinke >>> wrote: >>> >>>> Dear all, >>>> I came across a problem, for me it seems that cmake does not allow >>>> header files to be have the same name. Or am I doing something wrong? >>>> >>>> I have two projects, a library and an application. Both have files with >>>> similar content, but the same file names. I am using cmake to compile the >>>> app and the aim is that cmake also compiles the library if it doesn't yet >>>> exist. I was stuck for a few days on that problem until I figured out that >>>> it was due to the same file names. When renaming the files in my >>>> application it builds correctly. Before I switched to cmake a week ago, I >>>> used qmake integrated into Qt Creator, and it compiled just fine. >>>> >>>> Is it wanted behavior, that cmake does not allow the same file names? >>>> Am I doing something wrong? Altough it works with renaming the files I >>>> would like to find a "cleaner" way that prevents this from happening in the >>>> future, having same file names is nothing you can prevent if you work in a >>>> team. >>>> >>>> I hope you are able to help me, >>>> Jan >>>> -- >>>> Jan >>>> >>> -- >>>> >>>> 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 >>>> >>> >>> -- >> Jan > > > -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghleclerc at gmail.com Wed Jul 8 10:58:06 2015 From: ghleclerc at gmail.com (Ghyslain Leclerc) Date: Wed, 8 Jul 2015 10:58:06 -0400 Subject: [CMake] Segmentation fault Message-ID: Hello, I think I have found a ?bug? in CMake and as suggested in the Mantis Bug Tracker, I am writing here on the list before actually filing the bug report in case it?s actually not a bug. I have also searched in the already filed bugs for a few minutes to see if it already exists and it does not seem to. Here is the bug: I have used the following call in my CMakeLists.txt: set_property( TARGET cli PROPERTY LINK_LIBRARIES ${CUR_LINK_LIBS} ) When the CUR_LINK_LIBS variable is empty, CMake crashed with a segmentation fault. Naively, I would have expected a CMake error saying incorrect number of arguments or something like that, which CMake does all the time. Maybe this is normal behaviour for set_property. I am running CMake?3.2.3 compiled/installed via Macports on OSX 10.10.4 and Xcode 6.4. Thanks, Ghyslain From steve at borho.org Wed Jul 8 13:11:17 2015 From: steve at borho.org (Steve Borho) Date: Wed, 8 Jul 2015 12:11:17 -0500 Subject: [CMake] linking static libs into shared libs on Linux In-Reply-To: References: <20150707193625.GG130244@borho.org> <20150707212536.GL130244@borho.org> Message-ID: <20150708171117.GN8498@borho.org> On 07/07, Dan Kegel wrote: > On Tue, Jul 7, 2015 at 2:25 PM, Steve Borho wrote: > > We're already adding -fPIC to the compile flags for the two object > > libraries. This way one set of objects can be used to output the shared > > library and the static library. So the C++ files are already compiled > > with -fPIC. It is only a problem when we need to link a static library > > from one build into the shared library of another build. The static > > library itself no longer supports PIC. > > Really? I didn't think ar was in the habit of modifying machine code like that. > > At this point maybe the thing to do is make a toy example that reproduces > the problem. (Ideally something truly stipped down, like > https://github.com/dankegel/winezeug/tree/master/cmake_examples/ex7 ) This rings a bell for me. We encountered this link failure once before. A little back history: Our project has two main source folders, common/ and encoder/, each with its own CMakeLists file. Originally we built each folder into a static library and then the root level CMakeLists file linked them into a shared library, static library, or executable. This broke when we introduced yasm-compiled assembly objects into the common/ folder. We begain getting these same exact PIC errors when trying to link the static common.lib and encoder.lib into libx265.so. And this is when we were forced to use cmake's object libraries. Now common/ and encoder/ generate object libraries and the root level CMakeLists links those objects into the final targets and this seemed to work ok. So the yasm objects are somehow the root cause. -- Steve Borho From jlagrone at smu.edu Wed Jul 8 13:14:50 2015 From: jlagrone at smu.edu (John LaGrone) Date: Wed, 8 Jul 2015 12:14:50 -0500 Subject: [CMake] Finding internal libraries Message-ID: <559D5A8A.2030708@smu.edu> I am trying to build a library along with examples on how to use the library. For simplicity, let's say the structure is CMakeLists.txt src/ CMakeLists.txt foo.c foo.h examples/ CMakeLists.txt ex1/ CMakeLists.txt ex1.c ex2/ CMakeLists.txt ex2.c The cmake files for the examples are simple and look like cmake_minimum_required(VERSION 2.8.12 FATAL_ERROR) project(ex1) find_package(foo REQUIRED) add_executable(ex1.x ex1.c) target_link_libraries(ex1.x foo) As I currently have it, I can built the library "foo" and install it with all the configuration files, etc. that it needs and everything with that process seems fine. I can then build the examples and everything works fine with that process as well. However, if I try to build the examples and the library at the same time, the configuration fails because it cannot find the library "foo" for examples because it has not been compiled. I know I can build everything at once and it will work, but I would like to keep the cmake files for the examples essentially as they are so they can serve as a simple example of how an user might link to the library. Can this be done through Cmake or should I just write the documentation to indicate that the library needs to be compiled/installed then the examples can be built? Thanks, John From brad.king at kitware.com Wed Jul 8 13:28:38 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Jul 2015 13:28:38 -0400 Subject: [CMake] Segmentation fault In-Reply-To: References: Message-ID: <559D5DC6.4020702@kitware.com> On 07/08/2015 10:58 AM, Ghyslain Leclerc wrote: > I think I have found a bug in CMake and as suggested in the > Mantis Bug Tracker, I am writing here on the list before > actually filing the bug report in case it?s actually not a bug. > I have also searched in the already filed bugs for a few minutes > to see if it already exists and it does not seem to. Great, thanks. > I have used the following call in my CMakeLists.txt: > set_property( TARGET cli PROPERTY LINK_LIBRARIES ${CUR_LINK_LIBS} ) > > When the CUR_LINK_LIBS variable is empty, CMake crashed with a > segmentation fault. CMake is supposed to just set the property to empty in that case. It does so for most properties but LINK_LIBRARIES has special handling which has this bug. I've drafted a fix: set_property: Fix crash when setting LINK_LIBRARIES to nothing http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7aa9e80e I've queued this for merge to the 'release' branch for 3.3. Thanks, -Brad From dank at kegel.com Wed Jul 8 13:29:51 2015 From: dank at kegel.com (Dan Kegel) Date: Wed, 8 Jul 2015 10:29:51 -0700 Subject: [CMake] linking static libs into shared libs on Linux In-Reply-To: <20150708171117.GN8498@borho.org> References: <20150707193625.GG130244@borho.org> <20150707212536.GL130244@borho.org> <20150708171117.GN8498@borho.org> Message-ID: So maybe the yasm source needs to have a keyword or two added to select PIC addressing mode? Random googling finds suggestions at http://cvs.tortall.net/pipermail/bug-yasm/2011-October/000086.html On Wed, Jul 8, 2015 at 10:11 AM, Steve Borho wrote: > On 07/07, Dan Kegel wrote: >> On Tue, Jul 7, 2015 at 2:25 PM, Steve Borho wrote: >> > We're already adding -fPIC to the compile flags for the two object >> > libraries. This way one set of objects can be used to output the shared >> > library and the static library. So the C++ files are already compiled >> > with -fPIC. It is only a problem when we need to link a static library >> > from one build into the shared library of another build. The static >> > library itself no longer supports PIC. >> >> Really? I didn't think ar was in the habit of modifying machine code like that. >> >> At this point maybe the thing to do is make a toy example that reproduces >> the problem. (Ideally something truly stipped down, like >> https://github.com/dankegel/winezeug/tree/master/cmake_examples/ex7 ) > > This rings a bell for me. We encountered this link failure once before. > A little back history: > > Our project has two main source folders, common/ and encoder/, each with > its own CMakeLists file. Originally we built each folder into a static > library and then the root level CMakeLists file linked them into a > shared library, static library, or executable. > > This broke when we introduced yasm-compiled assembly objects into the > common/ folder. We begain getting these same exact PIC errors when > trying to link the static common.lib and encoder.lib into libx265.so. > And this is when we were forced to use cmake's object libraries. Now > common/ and encoder/ generate object libraries and the root level > CMakeLists links those objects into the final targets and this seemed to > work ok. > > So the yasm objects are somehow the root cause. > > -- > Steve Borho From steveire at gmail.com Wed Jul 8 14:28:00 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 08 Jul 2015 20:28 +0200 Subject: [CMake] Finding internal libraries References: <559D5A8A.2030708@smu.edu> Message-ID: John LaGrone wrote: > However, if I try to build the > examples and the library at the same time, the configuration fails > because it cannot find the library "foo" for examples because it has not > been compiled. > > I know I can build everything at once and it will work, ... I don't understand. Does building the examples and lib (ie, 'everything') together work or not? Thanks, Steve. From steve at borho.org Wed Jul 8 14:37:32 2015 From: steve at borho.org (Steve Borho) Date: Wed, 8 Jul 2015 13:37:32 -0500 Subject: [CMake] linking static libs into shared libs on Linux In-Reply-To: References: <20150707193625.GG130244@borho.org> <20150707212536.GL130244@borho.org> <20150708171117.GN8498@borho.org> Message-ID: <20150708183732.GC232639@borho.org> On 07/08, Dan Kegel wrote: > So maybe the yasm source needs to have a keyword or two > added to select PIC addressing mode? > > Random googling finds suggestions at > http://cvs.tortall.net/pipermail/bug-yasm/2011-October/000086.html Thanks for all the help. Upon further debugging with 'make VERBOSE=1' I discovered that when multilib was adding its extra link path it was overwriting the linux link flags instead of appending to them. There was a one-line fix for it. Cheers -- Steve Borho From steveire at gmail.com Wed Jul 8 14:55:38 2015 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 08 Jul 2015 20:55:38 +0200 Subject: [CMake] cmake-qt: controlling includes order References: <5591269F.8060706@classdesign.com> <5593319F.2090708@classdesign.com> Message-ID: Bill Somerville wrote: > Also this is all due to a > Mac issue where having MacPorts Qt4 installed causes it to be pulled in > when some other MacPorts library is used, in this case FFTW3. Most of > our developers work on Windows and Linux and are not going to know that > this abomination is required to stop the Mac build breaking. Yes, I've hit this issue before too. I filed http://public.kitware.com/Bug/view.php?id=15643 to track it. > I see target_include_directories() has a BEFORE option but no AFTER > option, I would have thought that is necessary to be the equivalent of > the directory level include_directories() command. > > It would also help to understand how the Qt5 include directories get > added when they are not specified at all, i.e. when something like: > > add_executable(hello main.cpp) > target_link_libraries(hello Qt5::Widgets) > > is used alone. In this case: add_executable(hello main.cpp) target_include_directories(hello PRIVATE /opt/foo) target_link_libraries(hello Qt5::Widgets) target_include_directories(hello PRIVATE /opt/bar) the order will be -I/opt/foo -I/opt/bar -I/opt/qt5/include/Qt5Widgets etc... When generating the list of directories to include, the ordered contents of the INCLUDE_DIRECTORIES property is processed first, and after that, the include directories of any ordered linked targets are appended. The ordering is the order of each different set of commands. Hope that helps. If you think the documentation can be clarified here, please contribute a patch, possibly to the cmake-buildsystem manual. Thanks, Steve. From andrew.amaclean at gmail.com Wed Jul 8 19:51:34 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 9 Jul 2015 09:51:34 +1000 Subject: [CMake] Sphinx warning. Message-ID: The latest version of Sphinx generates this warning when building CMake from the master: "WARNING: 'default' html theme has been renamed to 'classic'. Please change your html_theme setting either to the new 'alabaster' default theme, or to 'classic' to keep using the old default." See: https://github.com/sphinx-doc/sphinx/issues/1346#issuecomment-75538604 I'm not sure but it may be possible to import version_info from sphinx into the conf.py containing the version of Sphinx that is installed, and then use that in an if statement. Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Wed Jul 8 20:35:35 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 9 Jul 2015 10:35:35 +1000 Subject: [CMake] Sphinx warning. (Andrew Maclean) Message-ID: Attached is a modified conf.py.in that solves this issue. Tested in Python 2.7 and Sphinx 1.3. Regards Andrew > > ---------- Forwarded message ---------- > From: Andrew Maclean > To: "cmake at cmake.org" > Cc: > Date: Thu, 9 Jul 2015 09:51:34 +1000 > Subject: [CMake] Sphinx warning. > The latest version of Sphinx generates this warning when building CMake > from the master: > "WARNING: 'default' html theme has been renamed to 'classic'. Please > change your html_theme setting either to the new 'alabaster' default theme, > or to 'classic' to keep using the old default." > > See: > https://github.com/sphinx-doc/sphinx/issues/1346#issuecomment-75538604 > > I'm not sure but it may be possible to import version_info from sphinx > into the conf.py containing the version of Sphinx that is installed, and > then use that in an if statement. > > Regards > Andrew > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > > -- > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: conf.py.in.zip Type: application/zip Size: 1251 bytes Desc: not available URL: From ruslan_baratov at yahoo.com Wed Jul 8 21:55:32 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 09 Jul 2015 04:55:32 +0300 Subject: [CMake] Icon and Launch image support for iOS apps In-Reply-To: References: Message-ID: <559DD494.8040802@yahoo.com> On 03-Jul-15 13:00, Daniel Dewald wrote: > > Howdy folks, > > I?m currently in the process of converting our internal projects from > premake to cmake. The process is almost complete. However I?ve been > stuck on a seemingly simple problem the last few days that I could > need some help /advise on. Since premake as well as CMake don?t have > an option to integrate Icon and LaunchImage support for iOS builds in > XCode, we have a bash script, that patches the generated project > files, to insert the appropriate lines to enable the icon support > (this basically is 1.) copying the images into the app folder 2.) > including the prepared xcasset file into the resource ?folder? of the > *project* (not the target) and 3.) creating a ?Copy Bundle Resources? > build phase step with the .xcassets file in the target?s build phases > tab). The script is currently run after cmake is done (in our projects > batch file) and this works fine so far for premake as well as cmake. > The problem now is that if something is changed, cmake will regenerate > the project files and erase those changes. The logical idea would be > to execute the script whenever cmake is run. However there is no such > functionality in cmake as far as anyone could tell me. Anybody has any > clue as to whether cmake supports anything in that area. All ow this > has to be done *BEFORE* the build process is started and *AFTER* the > project files have been created. Otherwise it won?t work. We really > need this because some genius from Apple decided it would be a good > idea for the apps to decide what resolution an app should use on > whatever lauch image resolution was choosen O_o. > I have no idea about .xcassets but you can use default icon names and just add them to the RESOURCE property of the target. Launch images can be set in template plist.in file (which became Info.plist of your application). This might be helpful: * https://github.com/forexample/testapp * https://github.com/ruslo/weather Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Thu Jul 9 00:00:42 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 8 Jul 2015 21:00:42 -0700 Subject: [CMake] Create space delimited string with $ genex Message-ID: <559DF1EA.8050404@googlemail.com> Hello, in my build process I need to call a compiler like tool with the same include directories as a certain target. I tried the following: cmake_minimum_required(VERSION 3.2) project(cmake-genex C) add_library(dummy dummy.c foo.c) target_include_directories(dummy PUBLIC foo bar) set(prop "$") set(lst "$<$:-I$>") add_custom_command(OUTPUT foo.c COMMAND echo ${lst} ) Unfortunately this results in an escaped space before the -I : echo -I/Users/gjasny/src/cmake-genex/foo\ -I/Users/gjasny/src/cmake-genex/bar Is there a way to convince CMake not to escape the space? It looks like whatever I do, the generator expression is handled like a single string. Thanks, Gregor From jlagrone at smu.edu Thu Jul 9 11:18:43 2015 From: jlagrone at smu.edu (John LaGrone) Date: Thu, 9 Jul 2015 10:18:43 -0500 Subject: [CMake] Finding internal libraries In-Reply-To: References: Message-ID: <559E90D3.3000908@smu.edu> On 07/08/2015 06:52 PM, cmake-request at cmake.org wrote: >> cmake_minimum_required(VERSION 2.8.12 FATAL_ERROR) >> project(ex1) >> find_package(foo REQUIRED) >> add_executable(ex1.x ex1.c) >> target_link_libraries(ex1.x foo) > > I don't understand. Does building the examples and lib (ie, 'everything') > together work or not? > > Thanks, > > Steve. If I remove the "find_package(foo REQUIRED)" line or don't make it required, everything compiles. With the find_package command in place, the build fails at the configuration stage because it cannot find the package foo since it has not been built/installed. I think this makes perfect sense, but was wondering if there was a way to keep the find_package commands in the examples because it more accurately reflects a typical usage and hence makes for a better example. Thanks, John From cliffyapp at gmail.com Thu Jul 9 13:43:18 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Thu, 9 Jul 2015 13:43:18 -0400 Subject: [CMake] Problem with CMake 3.3.0-rc3 In-Reply-To: <559AA461.5070104@kitware.com> References: <559AA461.5070104@kitware.com> Message-ID: On Mon, Jul 6, 2015 at 11:53 AM, Brad King wrote: > Still, if we can easily fix 3.3 to not regress existing BRL-CAD > releases then we should do so. Can you use the above information > to strip it down to a minimal example showing the problem? OK, more info - it looks like the problem is limited to the CMake GUI configure (although I haven't been able to test ccmake, the basic cmake works) and the test file is pretty simple: # Minimum required version of CMake CMAKE_MINIMUM_REQUIRED(VERSION 2.8) # Set CMake project name project(TEST) configure_file(test test1) function(configure_file file targetfile) _configure_file(${file} ${targetfile} ${ARGN}) endfunction(configure_file) configure_file(test test2) Having the first configure_file before the redefinition and the second after it seems to do it in the GUI, but only on the second configure pass. Cheers, CY From bob_bachman at intercept.com Thu Jul 9 14:19:12 2015 From: bob_bachman at intercept.com (Bob Bachman) Date: Thu, 9 Jul 2015 18:19:12 +0000 (UTC) Subject: [CMake] Can't find wxWidgets Message-ID: We've upgraded from wxWidgets 2.8.10 to 3.0.2 and our CMake scripts can no longer find the required wxWidgets libs. The wxWidgets shared object files have been built and exist in the same directory structure as the 2.8.10 version. Any help would be greatly appreciated. Thank you Here is the find_package line used in our CMakeLists.txt file IF(UNIX) find_package( wxWidgets REQUIRED base core xrc net adv xml html qa aui ) ELSE(UNIX) find_package( wxWidgets REQUIRED base core xrc net adv xml html qa aui ) ENDIF(UNIX) The errors are below: -- Turning off rpaths -- /home/mzx_bldr/mozaix_svn/engineering/common_src/src/wxWidgets- 3.0.2/buildgtk/wx-config CMake Error at /home/mzx_bldr/cmake_versions/cmake-3.2.3-Linux- i386/share/cmake-3.2/Modules/FindPackageHandleStandardArgs.cmake:138 (message): Could NOT find wxWidgets (missing: wxWidgets_FOUND) Call Stack (most recent call first): /home/mzx_bldr/cmake_versions/cmake-3.2.3-Linux-i386/share/cmake- 3.2/Modules/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE) /home/mzx_bldr/cmake_versions/cmake-3.2.3-Linux-i386/share/cmake- 3.2/Modules/FindwxWidgets.cmake:870 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:386 (find_package) From brad.king at kitware.com Thu Jul 9 14:41:28 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 09 Jul 2015 14:41:28 -0400 Subject: [CMake] Problem with CMake 3.3.0-rc3 In-Reply-To: References: <559AA461.5070104@kitware.com> Message-ID: <559EC058.6000209@kitware.com> On 07/09/2015 01:43 PM, Clifford Yapp wrote: > OK, more info - it looks like the problem is limited to the CMake GUI > configure (although I haven't been able to test ccmake, the basic > cmake works) and the test file is pretty simple: Thanks. I've narrowed it down to this session: ------------------------------------------------------------- $ cat ../CMakeLists.txt cmake_minimum_required(VERSION 3.2) project(Sample NONE) message("message") function(message) _message(${ARGN}) endfunction() $ cmake-gui .. (click configure twice) ------------------------------------------------------------- It bisects to this commit: cmake: Simplify command clean up loop. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=97e53ebb Steve, please take a look. It looks like the cmState methods RemoveUserDefinedCommands and RenameCommand need to work better together. This needs to be fixed for 3.3. Thanks, -Brad From hobbes1069 at gmail.com Thu Jul 9 14:46:37 2015 From: hobbes1069 at gmail.com (Richard Shaw) Date: Thu, 9 Jul 2015 13:46:37 -0500 Subject: [CMake] Can't find wxWidgets In-Reply-To: References: Message-ID: On Thu, Jul 9, 2015 at 1:19 PM, Bob Bachman wrote: > We've upgraded from wxWidgets 2.8.10 to 3.0.2 and our CMake scripts can no > longer find the required wxWidgets libs. The wxWidgets shared object files > have been built and exist in the same directory structure as the 2.8.10 > version. Any help would be greatly appreciated. Thank you Double check that the wx-config script has not changed names... On Fedora we allow both to be installed so on 3.X the wx-config script is renamed to wx-config-3.0 so I have to do something like: $ cmake -DwxWidgets_CONFIG_EXECUTABLE=/usr/bin/wx-config.3.0 and everything works as usual. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob_bachman at intercept.com Thu Jul 9 15:10:07 2015 From: bob_bachman at intercept.com (Bob Bachman) Date: Thu, 9 Jul 2015 19:10:07 +0000 (UTC) Subject: [CMake] Can't find wxWidgets References: Message-ID: Richard Shaw writes: > > On Thu, Jul 9, 2015 at 1:19 PM, Bob Bachman wrote:We've upgraded from wxWidgets 2.8.10 to 3.0.2 and our CMake scripts can no > longer find the required wxWidgets libs. The wxWidgets shared object files > have been built and exist in the same directory structure as the 2.8.10 > version. Any help would be greatly appreciated. Thank you > > Double check that the wx-config script has not changed names... On Fedora we allow both to be installed so on 3.X the wx-config script is renamed to wx- config-3.0 so I have to do something like: > > $ cmake -DwxWidgets_CONFIG_EXECUTABLE=/usr/bin/wx-config.3.0 > > and everything works as usual. > > Thanks, > Richard > > Okay, thanks. That doesn't seem to be the problem. The wx-config script located in the buildgtk directory is a soft link. wx-config -> lib/wx/config/inplace-gtk2-unicode-3.0 From hobbes1069 at gmail.com Thu Jul 9 15:17:18 2015 From: hobbes1069 at gmail.com (Richard Shaw) Date: Thu, 9 Jul 2015 14:17:18 -0500 Subject: [CMake] Can't find wxWidgets In-Reply-To: References: Message-ID: On Thu, Jul 9, 2015 at 2:10 PM, Bob Bachman wrote: > Richard Shaw writes: > > On Thu, Jul 9, 2015 at 1:19 PM, Bob Bachman JXEU3b3ms+Tby3iVrkZq2A at public.gmane.org> wrote:We've upgraded from > wxWidgets > 2.8.10 to 3.0.2 and our CMake scripts can no > > longer find the required wxWidgets libs. The wxWidgets shared object > files > > have been built and exist in the same directory structure as the 2.8.10 > > version. Any help would be greatly appreciated. Thank you > > > > Double check that the wx-config script has not changed names... On > Fedora we > allow both to be installed so on 3.X the wx-config script is renamed to wx- > config-3.0 so I have to do something like: > > > > $ cmake -DwxWidgets_CONFIG_EXECUTABLE=/usr/bin/wx-config.3.0 > > > > and everything works as usual. > > Okay, thanks. That doesn't seem to be the problem. The wx-config script > located in the buildgtk directory is a soft link. > > wx-config -> lib/wx/config/inplace-gtk2-unicode-3.0 Ok, so that's not what's going on... Is this a custom build of wxWidgets? Is wx-config located in /usr/bin or somewhere else? Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob_bachman at intercept.com Thu Jul 9 15:32:40 2015 From: bob_bachman at intercept.com (Bob Bachman) Date: Thu, 9 Jul 2015 19:32:40 +0000 (UTC) Subject: [CMake] Can't find wxWidgets References: Message-ID: Richard Shaw writes: > > On Thu, Jul 9, 2015 at 2:10 PM, Bob Bachman wrote:Richard Shaw ...> writes:> On Thu, Jul 9, 2015 at 1:19 PM, Bob Bachman wrote:We've upgraded from wxWidgets2.8.10 to 3.0.2 and our CMake scripts can no > > longer find the required wxWidgets libs. The wxWidgets shared object files > > have been built and exist in the same directory structure as the 2.8.10 > > version. Any help would be greatly appreciated. Thank you > > > > Double check that the wx-config script has not changed names... On Fedora we > allow both to be installed so on 3.X the wx-config script is renamed to wx- > config-3.0 so I have to do something like: > > > > $ cmake -DwxWidgets_CONFIG_EXECUTABLE=/usr/bin/wx-config.3.0 > > > > and everything works as usual.Okay, thanks. That doesn't seem to be the problem. The wx-config script > located in the buildgtk directory is a soft link. > wx-config -> lib/wx/config/inplace-gtk2-unicode-3.0 > > Ok, so that's not what's going on... Is this a custom build of wxWidgets? Is wx-config located in /usr/bin or somewhere else?? > > Thanks, > Richard > > We build wxWidgets here. It's not located in /usr/bin. Here's our build process. from the wxWidgets-3.0.2 directory, 1. mkdir buildgtk 2. cd buildgtk 3. ../configure --with-gtk --without-gnomeprint 3. make The wx-config script is then found in the buildgtk directory. Thanks, Bob From hobbes1069 at gmail.com Thu Jul 9 15:56:13 2015 From: hobbes1069 at gmail.com (Richard Shaw) Date: Thu, 9 Jul 2015 14:56:13 -0500 Subject: [CMake] Can't find wxWidgets In-Reply-To: References: Message-ID: On Thu, Jul 9, 2015 at 2:32 PM, Bob Bachman wrote: > Richard Shaw writes: > > Ok, so that's not what's going on... Is this a custom build of wxWidgets? > Is wx-config located in /usr/bin or somewhere else? > > We build wxWidgets here. It's not located in /usr/bin. Here's our build > process. > > from the wxWidgets-3.0.2 directory, > 1. mkdir buildgtk > 2. cd buildgtk > 3. ../configure --with-gtk --without-gnomeprint > 3. make > > The wx-config script is then found in the buildgtk directory. Ok, so how did you tell cmake to find wx-config when you were running 2.8.x? It only looks in whatever the default cmake search paths... Looking at Modules/FindwxWidgets.cmake #----------------------------------------------------------------- # UNIX: Start actual work. #----------------------------------------------------------------- # Support cross-compiling, only search in the target platform. find_program(wxWidgets_CONFIG_EXECUTABLE NAMES wx-config wx-config-3.0 wx-config-2.9 wx-config-2.8 DOC "Location of wxWidgets library configuration provider binary (wx-config)." ONLY_CMAKE_FIND_ROOT_PATH ) ---end--- Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob_bachman at intercept.com Thu Jul 9 16:09:26 2015 From: bob_bachman at intercept.com (Bob Bachman) Date: Thu, 9 Jul 2015 20:09:26 +0000 (UTC) Subject: [CMake] Can't find wxWidgets References: Message-ID: Richard Shaw writes: > > On Thu, Jul 9, 2015 at 2:32 PM, Bob Bachman wrote:Richard Shaw ...> writes:> Ok, so that's not what's going on... Is this a custom build of wxWidgets? > Is wx-config located in /usr/bin or somewhere else??We build wxWidgets here. It's not located in /usr/bin. Here's our build > process. > from the wxWidgets-3.0.2 directory, > 1. mkdir buildgtk > 2. cd buildgtk > 3. ../configure --with-gtk --without-gnomeprint > 3. make > The wx-config script is then found in the buildgtk directory. > > Ok, so how did you tell cmake to find wx-config when you were running 2.8.x? It only looks in whatever the default cmake search paths... > > Looking at Modules/FindwxWidgets.cmake > #----------------------------------------------------------------- > # UNIX: Start actual work. > #----------------------------------------------------------------- > # Support cross-compiling, only search in the target platform. > find_program(wxWidgets_CONFIG_EXECUTABLE > NAMES wx-config wx-config-3.0 wx-config-2.9 wx-config-2.8 > DOC "Location of wxWidgets library configuration provider binary (wx-config)." > ONLY_CMAKE_FIND_ROOT_PATH > )---end---Thanks,Richard > > It's defined in the CMakeLists.txt file and stored in the CMakeCache.txt file. //Path to a program. wxWidgets_CONFIG_EXECUTABLE:FILEPATH=/home/mzx_bldr/mozaix_svn/engineering/c ommon_src/src/wxWidgets-3.0.2/buildgtk/wx-config Thanks, Bob From hobbes1069 at gmail.com Fri Jul 10 10:50:28 2015 From: hobbes1069 at gmail.com (Richard Shaw) Date: Fri, 10 Jul 2015 09:50:28 -0500 Subject: [CMake] Can't find wxWidgets In-Reply-To: References: Message-ID: On Thu, Jul 9, 2015 at 3:09 PM, Bob Bachman wrote: > > It's defined in the CMakeLists.txt file and stored in the CMakeCache.txt > file. > > //Path to a program. > > wxWidgets_CONFIG_EXECUTABLE:FILEPATH=/home/mzx_bldr/mozaix_svn/engineering/c > ommon_src/src/wxWidgets-3.0.2/buildgtk/wx-config Ok, useful information to have... Only thing I can think of at this point is to start adding some debug tests such as after the above line try: if(EXISTS ${ wxWidgetsCONFIG_EXECUTABLE}) message("Found wx-config") else() message("wx-config not found") Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From email at jochen-baier.de Fri Jul 10 15:23:53 2015 From: email at jochen-baier.de (Jochen Baier) Date: Fri, 10 Jul 2015 21:23:53 +0200 Subject: [CMake] Windows CE deployment of additional files to the device Message-ID: <55A01BC9.9030205@jochen-baier.de> Hi, Window CE Visual Studio 2008 projects have the option to specify additional files to deploy to the connected device after the build process (and before executing). For example needed DLLs. The part in the .vsproj looks like that: Do somebody know if can generate this withs CMake? Thanks Jochen From branch at arlut.utexas.edu Fri Jul 10 18:12:12 2015 From: branch at arlut.utexas.edu (Ed Branch) Date: Fri, 10 Jul 2015 17:12:12 -0500 Subject: [CMake] Create space delimited string with $ genex Message-ID: <55A0433C.9070007@arlut.utexas.edu> > Hello, > > in my build process I need to call a compiler like tool with the same > include directories as a certain target. > > I tried the following: > > > cmake_minimum_required(VERSION 3.2) > project(cmake-genex C) > add_library(dummy dummy.c foo.c) > target_include_directories(dummy PUBLIC foo bar) > > set(prop "$") > set(lst "$<$:-I$>") > > add_custom_command(OUTPUT foo.c > COMMAND echo ${lst} > ) > > Unfortunately this results in an escaped space before the -I : > echo -I/Users/gjasny/src/cmake-genex/foo\ > -I/Users/gjasny/src/cmake-genex/bar > > Is there a way to convince CMake not to escape the space? It looks like > whatever I do, the generator expression is handled like a single string. > > Thanks, > Gregor A bug related to this problem is on the backlog [1]. A workaround is attached to the bug report [2], and an example usage of the workaround is in the comments. [1] http://public.kitware.com/Bug/view.php?id=14353 [2] http://public.kitware.com/Bug/file_download.php?file_id=5436&type=bug From steveire at gmail.com Sat Jul 11 05:07:52 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 11 Jul 2015 11:07:52 +0200 Subject: [CMake] Problem with CMake 3.3.0-rc3 References: <559AA461.5070104@kitware.com> <559EC058.6000209@kitware.com> Message-ID: Brad King wrote: > Steve, please take a look. It looks like the cmState methods > RemoveUserDefinedCommands and RenameCommand need to work better > together. This needs to be fixed for 3.3. Fixed with http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f2ee169d cmState: Restore renamed commands on cleanup Thanks, Steve. From jsvanbethlehem at gmail.com Sat Jul 11 08:20:18 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Sat, 11 Jul 2015 14:20:18 +0200 Subject: [CMake] Windows CE deployment of additional files to the device In-Reply-To: <55A01BC9.9030205@jochen-baier.de> References: <55A01BC9.9030205@jochen-baier.de> Message-ID: Hej Jochen, My first guess would be to have a look at the add_custom_command(TARGET ) function, see http://www.cmake.org/cmake/help/v3.0/command/add_custom_command.html . In your situation this would work out something like the following: add_custom_command(TARGET DeploymentTool POST_BUILD COMMAND cmake -E copy Library.dll c:\localDir\l$ENV{CSIDL_PROGRAM_FILES}\KepapTest ) This is just guessing at the details - in particular I don?t know from the top of my head if you can acces CSIDL_PROGRAM_FILES from within CMake. But I think this could you get started at least. Sincerely, Jakob > On 10 Jul 2015, at 21:23, Jochen Baier wrote: > > Hi, > > Window CE Visual Studio 2008 projects have the option to specify additional files to deploy to the connected device after the build process (and before executing). For example needed DLLs. The part in the .vsproj looks like that: > > ForceDirty="-1" > RemoteDirectory="" > RegisterOutput="0" > AdditionalFiles="Library.dll|c:\localDir\|%CSIDL_PROGRAM_FILES%\KepapTest"/> > > Do somebody know if can generate this withs CMake? > > > Thanks Jochen > -- > > 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 gurenchan at gmail.com Sun Jul 12 08:14:27 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Sun, 12 Jul 2015 20:14:27 +0800 Subject: [CMake] opening files relative to cmake build directory Message-ID: I have a little project that's setup like this project main.c build resources source .../module1 .../module2 .../etc main.c loads dynamic libs from under the source folder. I am trying to open up a file using c fopen I create a function to get the base resource path which returns: /Users/me/projectresources/ I call get resource with test.txt it'll return a string like this: /Users/me/project/resources/test.txt but with my fopen command I get null error Error while opening the file. : No such file or directory When I use the c command to find current working directory it returns: Current Directory = /Users/me/project/build/ how can I set up cmake to allow me to either use the full file path as in Users/me/project/resources/[filename] or a relative filename so that I can open my files? Best, Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Mon Jul 13 03:26:10 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 13 Jul 2015 09:26:10 +0200 Subject: [CMake] Finding internal libraries In-Reply-To: <559E90D3.3000908@smu.edu> References: <559E90D3.3000908@smu.edu> Message-ID: Hi John. I have no first-hand experience with it, but I believe the ExternalProject module could be just what you're looking for ( http://www.cmake.org/cmake/help/v3.2/module/ExternalProject.html ). It allows you to configure and build several projects at build time under a CMake "superbuild" master project, while the "subprojects" themselves remain unaware of this setup. Petr On Thu, Jul 9, 2015 at 5:18 PM, John LaGrone wrote: > On 07/08/2015 06:52 PM, cmake-request at cmake.org wrote: > > cmake_minimum_required(VERSION 2.8.12 FATAL_ERROR) >>> project(ex1) >>> find_package(foo REQUIRED) >>> add_executable(ex1.x ex1.c) >>> target_link_libraries(ex1.x foo) >>> >> >> I don't understand. Does building the examples and lib (ie, 'everything') >> together work or not? >> >> Thanks, >> >> Steve. >> > > If I remove the "find_package(foo REQUIRED)" line or don't make it > required, everything compiles. With the find_package command in place, the > build fails at the configuration stage because it cannot find the package > foo since it has not been built/installed. I think this makes perfect > sense, but was wondering if there was a way to keep the find_package > commands in the examples because it more accurately reflects a typical > usage and hence makes for a better example. > > Thanks, > John > > > -- > > 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 bob_bachman at intercept.com Mon Jul 13 09:58:13 2015 From: bob_bachman at intercept.com (Bob Bachman) Date: Mon, 13 Jul 2015 13:58:13 +0000 (UTC) Subject: [CMake] Can't find wxWidgets References: Message-ID: Richard Shaw writes: > > On Thu, Jul 9, 2015 at 3:09 PM, Bob Bachman wrote: > It's defined in the CMakeLists.txt file and stored in the CMakeCache.txt > file. > //Path to a program. > wxWidgets_CONFIG_EXECUTABLE:FILEPATH=/home/mzx_bldr/mozaix_svn/engineering/c > ommon_src/src/wxWidgets-3.0.2/buildgtk/wx-config > > Ok, useful information to have... > > Only thing I can think of at this point is to start adding some debug tests such as after the above line try: > > if(EXISTS ${ wxWidgetsCONFIG_EXECUTABLE}) > ? message("Found wx-config") > else() > ? message("wx-config not found") > > Thanks, > Richard > > I can see that it is finding the wxWidgets config executable because it prints it out right before it fails. (See second line below). So I believe I'll have to start debugging this script and see where it's failing. Thanks very much for your help! Bob -- Turning off rpaths -- /home/mzx_bldr/mozaix_svn/engineering/common_src/src/wxWidgets- 3.0.2/buildgtk/wx-config CMake Error at /home/mzx_bldr/cmake_versions/cmake-3.2.3-Linux- i386/share/cmake-3.2/Modules/FindPackageHandleStandardArgs.cmake:138 (message): Could NOT find wxWidgets (missing: wxWidgets_FOUND) Call Stack (most recent call first): /home/mzx_bldr/cmake_versions/cmake-3.2.3-Linux-i386/share/cmake- 3.2/Modules/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE) /home/mzx_bldr/cmake_versions/cmake-3.2.3-Linux-i386/share/cmake- 3.2/Modules/FindwxWidgets.cmake:870 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:386 (find_package) From cliffyapp at gmail.com Mon Jul 13 10:26:28 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Mon, 13 Jul 2015 10:26:28 -0400 Subject: [CMake] Is there any way to set a build-type specific install path for multiconfig tools? Message-ID: One challenge we've experienced with CMake is properly controlling the installation path when using multi-config tools like Visual Studio or Xcode. Since I'm in the middle of re-examining our more gnarly CMake logic anyway, I thought I'd raise this one and see if anybody knows of a good solution. The problem is as follows - for multi-config build tools, the build profile (Release, Debug, etc.) is selected at build time, not CMake configure time. Consequently, if one wishes to change the CMAKE_INSTALL_PREFIX based on the current build configuration (our convention for default install paths is to use /parent_dirs/rel- for release builds and /parent_dirs/dev- for development builds) that change has to happen at build time. To the best of my knowledge there is no good way to do this in CMake currently. The closest I could come when I tried originally was to insert a variable into the CMAKE_INSTALL_PREFIX path that evaluated to the current build configuration (IIRC) but that wasn't quite correct per our convention. I finally settled on a rather scary trick where I created a custom build target that would manually rewrite all of the generated CMake build files (via running a CMake script) to use the desired path, and that build target becomes flagged for a re-run every time the build configuration in the build tool is changed. In essence, I'm post processing the CMake generated build files. The "preferred" solution to this (I think) would be to have CMAKE_${CFG_TYPE}_INSTALL_PREFIX variables that could be set the same way the C/CXX flag variables have per-configuration versions. That way the CMakeLists.txt file could simply specify the target install paths for each configuration and have then written directly to the appropriate output build files. However, to the best of my knowledge there is no existing CMake feature that currently supports this. Has anyone else encountered the problem? If not, would the devs consider adding a per-config CMAKE_INSTALL_PREFIX feature for the multi-config tools? Thanks, CY From DLRdave at aol.com Mon Jul 13 12:05:40 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 13 Jul 2015 12:05:40 -0400 Subject: [CMake] Is there any way to set a build-type specific install path for multiconfig tools? In-Reply-To: References: Message-ID: I think this should be achievable somehow with CMAKE_INSTALL_PREFIX set to "/parent_dirs" and then using appropriate DESTINATION and CONFIGURATIONS arguments to the CMake install commands. Have you tried using the CONFIGURATIONS args to the install command? On Mon, Jul 13, 2015 at 10:26 AM, Clifford Yapp wrote: > One challenge we've experienced with CMake is properly controlling the > installation path when using multi-config tools like Visual Studio or > Xcode. Since I'm in the middle of re-examining our more gnarly CMake > logic anyway, I thought I'd raise this one and see if anybody knows of > a good solution. > > The problem is as follows - for multi-config build tools, the build > profile (Release, Debug, etc.) is selected at build time, not CMake > configure time. Consequently, if one wishes to change the > CMAKE_INSTALL_PREFIX based on the current build configuration (our > convention for default install paths is to use > /parent_dirs/rel- for release builds and > /parent_dirs/dev- for development builds) that change has to > happen at build time. > > To the best of my knowledge there is no good way to do this in CMake > currently. The closest I could come when I tried originally was to > insert a variable into the CMAKE_INSTALL_PREFIX path that evaluated to > the current build configuration (IIRC) but that wasn't quite correct > per our convention. I finally settled on a rather scary trick where I > created a custom build target that would manually rewrite all of the > generated CMake build files (via running a CMake script) to use the > desired path, and that build target becomes flagged for a re-run every > time the build configuration in the build tool is changed. In > essence, I'm post processing the CMake generated build files. > > The "preferred" solution to this (I think) would be to have > CMAKE_${CFG_TYPE}_INSTALL_PREFIX variables that could be set the same > way the C/CXX flag variables have per-configuration versions. That > way the CMakeLists.txt file could simply specify the target install > paths for each configuration and have then written directly to the > appropriate output build files. However, to the best of my knowledge > there is no existing CMake feature that currently supports this. > > Has anyone else encountered the problem? If not, would the devs > consider adding a per-config CMAKE_INSTALL_PREFIX feature for the > multi-config tools? > > Thanks, > CY > -- > > 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 cliffyapp at gmail.com Mon Jul 13 12:29:24 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Mon, 13 Jul 2015 12:29:24 -0400 Subject: [CMake] Is there any way to set a build-type specific install path for multiconfig tools? In-Reply-To: References: Message-ID: On Mon, Jul 13, 2015 at 12:05 PM, David Cole wrote: > I think this should be achievable somehow with CMAKE_INSTALL_PREFIX > set to "/parent_dirs" and then using appropriate DESTINATION and > CONFIGURATIONS arguments to the CMake install commands. > > Have you tried using the CONFIGURATIONS args to the install command? We haven't tried altering the install commands, but there's a difficulty there - we don't always control all the CMake code in our build. We include some 3rd party libraries and try to keep their code as close to "vanilla" as possible, which means it would be vastly preferable not to need to track down and redo all the install commands in that code whenever we needed to re-sync. Thanks, CY From jamesbigler at gmail.com Mon Jul 13 12:45:44 2015 From: jamesbigler at gmail.com (James Bigler) Date: Mon, 13 Jul 2015 10:45:44 -0600 Subject: [CMake] file(GENERATE) and executable permissions Message-ID: Is it possible to set the generated file's executable permissions when using file(GENERATE)? I'm trying to generate shell scripts, and I want the executable bit set. Thanks, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From micha.hergarden at gmail.com Mon Jul 13 12:46:39 2015 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Mon, 13 Jul 2015 18:46:39 +0200 Subject: [CMake] opening files relative to cmake build directory In-Reply-To: References: Message-ID: <55A3EB6F.3070706@gmail.com> On 07/12/2015 02:14 PM, Owen Alanzo Hogarth wrote: > I have a little project that's setup like this > > project > main.c > build > resources > source > .../module1 > .../module2 > .../etc > > main.c loads dynamic libs from under the source folder. > > I am trying to open up a file using c fopen > > > I create a function to get the base resource path > which returns: /Users/me/projectresources/ > > I call get resource with test.txt > it'll return a string like this: /Users/me/project/resources/test.txt > > but with my fopen command I get null error > Error while opening the file. > : No such file or directory > > When I use the c command to find current working directory > it returns: > Current Directory = /Users/me/project/build/ > > how can I set up cmake to allow me to either use the full file path as > in Users/me/project/resources/[filename] > > or a relative filename so that I can open my files? > > Best, > Owen > > > > Hello Owen, Take a look at: http://www.cmake.org/Wiki/CMake_Useful_Variables In your case CMAKE_SOURCE_DIR may do what you want. You can create a project configuration file and use #cmakedefine and CONFIGURE_FILE() to create defines to use in your source file. That would provide you with a fixed location, suitable for the build you are running now. What is the purpose of the resources.txt. Is this something you need during the creation of your executable? Or do you need it during the execution of the program? Regards, Micha -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From micha.hergarden at gmail.com Mon Jul 13 13:02:06 2015 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Mon, 13 Jul 2015 19:02:06 +0200 Subject: [CMake] Fwd: Re: Re: opening files relative to cmake build directory In-Reply-To: References: Message-ID: <55A3EF0E.9050202@gmail.com> -------- Forwarded Message -------- Subject: Re: Re: [CMake] opening files relative to cmake build directory Date: Mon, 13 Jul 2015 17:00:52 +0000 From: Owen Alanzo Hogarth To: Micha Hergarden Resources.txt is a test but it's mainly going to be used for assets at runtime. Maybe in the future I might have other directories but this is the only one for now. On Tue, Jul 14, 2015, 00:53 Micha Hergarden > wrote: Sorry, I forgot to put you on the reply as well. Regards, Micha -------- Forwarded Message -------- Subject: Re: [CMake] opening files relative to cmake build directory Date: Mon, 13 Jul 2015 18:46:39 +0200 From: Micha Hergarden To: cmake at cmake.org On 07/12/2015 02:14 PM, Owen Alanzo Hogarth wrote: > I have a little project that's setup like this > > project > main.c > build > resources > source > .../module1 > .../module2 > .../etc > > main.c loads dynamic libs from under the source folder. > > I am trying to open up a file using c fopen > > > I create a function to get the base resource path > which returns: /Users/me/projectresources/ > > I call get resource with test.txt > it'll return a string like this: /Users/me/project/resources/test.txt > > but with my fopen command I get null error > Error while opening the file. > : No such file or directory > > When I use the c command to find current working directory > it returns: > Current Directory = /Users/me/project/build/ > > how can I set up cmake to allow me to either use the full file > path as in Users/me/project/resources/[filename] > > or a relative filename so that I can open my files? > > Best, > Owen > > > > Hello Owen, Take a look at: http://www.cmake.org/Wiki/CMake_Useful_Variables In your case CMAKE_SOURCE_DIR may do what you want. You can create a project configuration file and use #cmakedefine and CONFIGURE_FILE() to create defines to use in your source file. That would provide you with a fixed location, suitable for the build you are running now. What is the purpose of the resources.txt. Is this something you need during the creation of your executable? Or do you need it during the execution of the program? Regards, Micha -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From micha.hergarden at gmail.com Mon Jul 13 13:13:30 2015 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Mon, 13 Jul 2015 19:13:30 +0200 Subject: [CMake] Fwd: Re: Re: opening files relative to cmake build directory In-Reply-To: <55A3EF0E.9050202@gmail.com> References: <55A3EF0E.9050202@gmail.com> Message-ID: <55A3F1BA.7070307@gmail.com> In that case you can disregard my first reply. If it is a file to be used at runtime, then I would use file(COPY ...) or install() to export the recources.txt from your source directory to your build directory. Then you will have a flexible way that will also work in other setups. It may seem wastefull to copy files when you already have them in your source, but keeping build files and source files separate makes it really easy to clean up or to have multiple build directories. In my opinion this feature is one of the virtues of cmake. Regards, Micha On 07/13/2015 07:02 PM, Micha Hergarden wrote: > > > > -------- Forwarded Message -------- > Subject: Re: Re: [CMake] opening files relative to cmake build directory > Date: Mon, 13 Jul 2015 17:00:52 +0000 > From: Owen Alanzo Hogarth > To: Micha Hergarden > > > > Resources.txt is a test but it's mainly going to be used for assets at > runtime. Maybe in the future I might have other directories but this > is the only one for now. > > > On Tue, Jul 14, 2015, 00:53 Micha Hergarden > wrote: > > Sorry, > > I forgot to put you on the reply as well. > > Regards, > Micha > > > > -------- Forwarded Message -------- > Subject: Re: [CMake] opening files relative to cmake build directory > Date: Mon, 13 Jul 2015 18:46:39 +0200 > From: Micha Hergarden > > To: cmake at cmake.org > > > > On 07/12/2015 02:14 PM, Owen Alanzo Hogarth wrote: >> I have a little project that's setup like this >> >> project >> main.c >> build >> resources >> source >> .../module1 >> .../module2 >> .../etc >> >> main.c loads dynamic libs from under the source folder. >> >> I am trying to open up a file using c fopen >> >> >> I create a function to get the base resource path >> which returns: /Users/me/projectresources/ >> >> I call get resource with test.txt >> it'll return a string like this: /Users/me/project/resources/test.txt >> >> but with my fopen command I get null error >> Error while opening the file. >> : No such file or directory >> >> When I use the c command to find current working directory >> it returns: >> Current Directory = /Users/me/project/build/ >> >> how can I set up cmake to allow me to either use the full file >> path as in Users/me/project/resources/[filename] >> >> or a relative filename so that I can open my files? >> >> Best, >> Owen >> >> >> >> > Hello Owen, > > Take a look at: http://www.cmake.org/Wiki/CMake_Useful_Variables > > In your case CMAKE_SOURCE_DIR may do what you want. You can create > a project configuration file and use #cmakedefine and > CONFIGURE_FILE() to create defines to use in your source file. > That would provide you with a fixed location, suitable for the > build you are running now. > > What is the purpose of the resources.txt. Is this something you > need during the creation of your executable? Or do you need it > during the execution of the program? > > Regards, > Micha > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From DLRdave at aol.com Mon Jul 13 13:45:21 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 13 Jul 2015 13:45:21 -0400 Subject: [CMake] Is there any way to set a build-type specific install path for multiconfig tools? In-Reply-To: References: Message-ID: A few more ideas: The other "no need to modify CMake" way to achieve this (although it may be considered "too ugly" or non-ideal by some) would be to force the use of a single configuration per build tree, and use the proper value for CMAKE_INSTALL_PREFIX in each build tree. Your developers may not like that, but it would sure make the problem at hand disappear. The other thing to consider is that the file cmake_install.cmake, generated at the top of your build tree contains code like the following: # Set the install prefix if(NOT DEFINED CMAKE_INSTALL_PREFIX) set(CMAKE_INSTALL_PREFIX "C:/Program Files (x86)/Tutorial") endif() In the end, installing your project is ultimately a call of some sort to "cmake -P cmake_install.cmake" -- you could simply install your project with a custom call to that script which passes in the proper value for CMAKE_INSTALL_PREFIX using -D... The above generated code allows you to override it by passing it in when the script is called. The Visual Studio command for the INSTALL project looks like this: "C:\Program Files (x86)\CMake\bin\cmake.exe" -DBUILD_TYPE=$(Configuration) -P cmake_install.cmake You could easily write a custom target / custom command that is an alternate "configuration-prefixed" install as: "C:\Program Files (x86)\CMake\bin\cmake.exe" -DBUILD_TYPE=$(Configuration) -DCMAKE_INSTALL_PREFIX=config-specific-value-here -P cmake_install.cmake HTH, David C. On Mon, Jul 13, 2015 at 12:29 PM, Clifford Yapp wrote: > On Mon, Jul 13, 2015 at 12:05 PM, David Cole wrote: >> I think this should be achievable somehow with CMAKE_INSTALL_PREFIX >> set to "/parent_dirs" and then using appropriate DESTINATION and >> CONFIGURATIONS arguments to the CMake install commands. >> >> Have you tried using the CONFIGURATIONS args to the install command? > > We haven't tried altering the install commands, but there's a > difficulty there - we don't always control all the CMake code in our > build. We include some 3rd party libraries and try to keep their code > as close to "vanilla" as possible, which means it would be vastly > preferable not to need to track down and redo all the install commands > in that code whenever we needed to re-sync. > > Thanks, > CY From bob_bachman at intercept.com Mon Jul 13 14:38:15 2015 From: bob_bachman at intercept.com (Bob Bachman) Date: Mon, 13 Jul 2015 18:38:15 +0000 (UTC) Subject: [CMake] Can't find wxWidgets References: Message-ID: Richard Shaw writes: > > On Thu, Jul 9, 2015 at 3:09 PM, Bob Bachman wrote: > It's defined in the CMakeLists.txt file and stored in the CMakeCache.txt > file. > //Path to a program. > wxWidgets_CONFIG_EXECUTABLE:FILEPATH=/home/mzx_bldr/mozaix_svn/engineering/c > ommon_src/src/wxWidgets-3.0.2/buildgtk/wx-config > > Ok, useful information to have... > > Only thing I can think of at this point is to start adding some debug tests such as after the above line try: > > if(EXISTS ${ wxWidgetsCONFIG_EXECUTABLE}) > ? message("Found wx-config") > else() > ? message("wx-config not found") > > Thanks, > Richard > > Hello Richard. I'm wondering if you can explain what's happening below. The first line is in our CMakeLists.txt file. It calls "find_package" with the required libs. 1. find_package( wxWidgets REQUIRED base core xrc net adv xml html qa aui ) The second line is in the file FindwxWidgets.cmake and calls the routine FindPackageHandleStandardArgs with three operands but no libs (i.e base core ... etc). 2. FIND_PACKAGE_HANDLE_STANDARD_ARGS(wxWidgets DEFAULT_MSG wxWidgets_FOUND) The final line is function definition and is in the file FindPackageHandleStandardArgs.cmake and is where the process fails. 3. FUNCTION(FIND_PACKAGE_HANDLE_STANDARD_ARGS _NAME _FIRST_ARG) When I placed the line message(STATUS ${_FIRST_ARG}) in this function and run it. I see "DEFAULT_MSG". It seems that line 2 should be calling a different version of this routine, one that contains the list of lib names. Any idea of what is going on here. Thanks, Bob From robert.maynard at kitware.com Mon Jul 13 16:18:11 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 13 Jul 2015 16:18:11 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.3.0-rc4 is now ready! Message-ID: I am proud to announce the fourth CMake 3.3 release candidate. Sources and binaries are available at: http://www.cmake.org/download/ Documentation is available at: http://www.cmake.org/cmake/help/v3.3 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.3/release/3.3.html Some of the more significant features of CMake 3.3 are: * The "if()" command learned a new "IN_LIST" operator that evaluates to true if a given element is contained in a named list. * The "add_dependencies()" command learned to allow dependencies to be added to *interface libraries*. Dependencies added to an interface library are followed transitively in its place since the target itself does not build. * The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable. * The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN" target properties now affect compilation in sources of all target types. See policy "CMP0063". * A "_INCLUDE_WHAT_YOU_USE" target property and supporting "CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell the *Makefile Generators* and the "Ninja" generator to run "include- what-you-use" along with the compiler for "C" and "CXX" languages. Deprecated and Removed Features: * The "ctest_build()" and "build_command()" commands no longer tell "make" tools to ignore errors with the "-i" option. Previously this was done for *Makefile Generators* but not others. See policy "CMP0061". * The "Visual Studio 7" generator (.NET 2002) is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 6" generator is now deprecated and will be removed in a future version of CMake. * The "add_definitions()" command no longer causes a "DEFINITIONS" directory property to be populated. See policy "CMP0059". CMake 3.3 Release Notes *********************** Changes made since CMake 3.2 include the following. New Features ============ Generators ---------- * The *Makefile Generators* now add ".DELETE_ON_ERROR" to the makefiles that contain the actual build rules for files on disk. This tells GNU make to remove rule outputs when their recipe modifies an output but fails. * The *Visual Studio Generators* learned to support ".xaml" source files and automatically associate them with corresponding ".h" and ".cpp" sources. * A new experimental "Green Hills MULTI" generator was added on Windows. Green Hills MULTI is an IDE for embedded real-time systems. Commands -------- * The "add_dependencies()" command learned to allow dependencies to be added to *interface libraries*. Dependencies added to an interface library are followed transitively in its place since the target itself does not build. * The "execute_process()" command learned to support specifying the same file for "OUTPUT_FILE" and "ERROR_FILE". * The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new "LIST_DIRECTORIES " option to specify whether the glob result should include directories. * The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable. * The "if()" command learned a new "IN_LIST" operator that evaluates to true if a given element is contained in a named list. * The "install(EXPORT)" and "export()" commands learned to export targets that populate the "INTERFACE_SOURCES" target property. * The "install(TARGETS)" command learned to support generator expressions in the "DESTINATION" value. Variables --------- * The version of some Fortran compilers is now detected and stored in the "CMAKE_Fortran_COMPILER_VERSION" variable. * The *Visual Studio Generators* learned a new "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" option to put the "INSTALL" target in the default build of a solution (".sln") file. Properties ---------- * A "CROSSCOMPILING_EMULATOR" target property and supporting "CMAKE_CROSSCOMPILING_EMULATOR" variable were introduced to allow target platform binaries to run on the host during cross compiling. * A "_INCLUDE_WHAT_YOU_USE" target property and supporting "CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell the *Makefile Generators* and the "Ninja" generator to run "include- what-you-use" along with the compiler for "C" and "CXX" languages. * The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN" target properties now affect compilation in sources of all target types. See policy "CMP0063". * The "XCODE_ATTRIBUTE_" target property learned to support generator expressions. Modules ------- * The "CheckFortranCompilerFlag" module was introduced to check "Fortran" compiler flags, much like the "CheckCCompilerFlag" module already does for "C". * The "ExternalData" module learned a new "ExternalData_NO_SYMLINKS" option to disable use of symbolic links to populate the real data files and use copies instead. * The "ExternalData" module learned a new "RECURSE:" option in "DATA{}" references specifying directories. This allows an entire directory tree of associated files to be matched. * The "ExternalData" module learned a new URL template placeholder "%(algo:)" to allow custom mapping from algorithm name to URL component through configuration of new "ExternalData_URL_ALGO__" variables. This allows more flexibility in remote URLs. * The "ExternalProject" module learned to replace tokens like "" in the "BYPRODUCTS" of each step. * The "ExternalProject" module APIs learned to support "generator expressions" when using "LOG_*" options and in CMake initial cache options. * The "FindBoost" module now tracks the directories containing libraries separately for RELEASE and DEBUG configurations. * The "FindCUDA" module now defaults to using the static CUDA runtime library if it is available. A new "CUDA_USE_STATIC_CUDA_RUNTIME" option is offered to control this behavior. * The "FindMatlab" module was completely rewritten. It learned about versions and components and to find Matlab in a more precise and multiplatform way. The module now offers APIs to create mex extensions, documentation, and unit tests. * The "FindPackageHandleStandardArgs" module "FIND_PACKAGE_HANDLE_STANDARD_ARGS" function now always populates both the "_FOUND" and "_FOUND" variables (the latter for backwards compatibility). The "FOUND_VAR" option is now ignored except to enforce its allowed values. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_SYSTEM_RUNTIME_COMPONENT" option to specify the installation component. Generator Expressions --------------------- * A new "COMPILE_LANGUAGE" generator expression was introduced to allow specification of compile options for target files based on the "LANGUAGE" of each source file. Due to limitations of the underlying native build tools, this feature has varying support across generators. See the "cmake-generator-expressions(7)" manual for details. CTest ----- * The "ctest(1)" tool learned a new "--repeat-until-fail " option to help find sporadic test failures. * The "CTestCoverageCollectGCOV" module learned to support the same "CTEST_CUSTOM_COVERAGE_EXCLUDE" option as the "ctest_coverage()" command. CPack ----- * The "cpack(1)" "IFW" generator and the "CPackIFW" module learned to support Qt Framework Installer 2.0 tools. * The "CPackDeb" module learned a new "CPACK_DEBIAN__PACKAGE_SHLIBDEPS" variable to specify per-component use of "dpkg-shlibdeps". * The "CPackDeb" module learned a new "CPACK_DEBIAN__PACKAGE_DEPENDS" option to specify per- component dependencies. * The "CPackRPM" module learned to package symbolic links more cleanly and now supports directory symlinks with recent "rpmbuild" versions. * The "CPackRPM" module learned a new "CPACK_RPM_ADDITIONAL_MAN_DIRS" variable to specify directories containing man pages for the brp- compress RPM macro. * The "CPackRPM" module learned a new "CPACK_RPM__PACKAGE_ARCHITECTURE" variable to specify a component-specific package architecture. * The CPack WIX generator learned the new "CPACK_START_MENU_SHORTCUTS", "CPACK_DESKTOP_SHORTCUTS" and "CPACK_STARTUP_SHORTCUTS" installed file properties which can be used to install shorcuts in the Start Menu, on the Desktop and in the Startup Folder respectively. Other ----- * The "Compile Features" functionality is now aware of features supported by GNU compilers on Windows, versions 4.4 through 5.0. * The "cmake(1)" "-E tar" command learned a new "--format" option to specify the archive format to be written. * On OS X, CMake learned to create XCTest bundles to test Frameworks and App Bundles within Xcode. The "FindXCTest" module provides convenience functions to handle "XCTEST" bundles. Deprecated and Removed Features =============================== * On OS X the "cmake-gui(1)" no longer has the "Install For Command Line Use" menu item. Instead there is a "How to Install For Command Line Use" menu item that shows an informational dialog box explaining how to make the command line tools available. For example: /Applications/CMake.app/Contents/bin/cmake-gui --install * The "ctest_build()" and "build_command()" commands no longer tell "make" tools to ignore errors with the "-i" option. Previously this was done for *Makefile Generators* but not others. See policy "CMP0061". * The "Visual Studio 10 2010" generator no longer checks for running VS IDEs with the project open or asks them to reload. This was originally done for VS 10 because it had been done for VS 7 through 9 to avoid prompting for every project in a solution. Since VS >= 10 allow the whole solution to reload at once they do not need CMake to help them. * The "Visual Studio 7" generator (.NET 2002) is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 6" generator is now deprecated and will be removed in a future version of CMake. * The "find_package()" command no longer considers project build trees recently configured in a "cmake-gui(1)". This was previously done only on Windows and is now never done. The "NO_CMAKE_BUILDS_PATH" option is now ignored if given and effectively always on. Projects may populate the *User Package Registry* to aid users building multiple dependent projects one after another. * The "add_definitions()" command no longer causes a "DEFINITIONS" directory property to be populated. See policy "CMP0059". * With Visual Studio 7, 8, and 9 generators the value of the "$(OutDir)" placeholder no longer evaluates to the configuration name. Projects should use "$(ConfigurationName)" for that instead. * Using the output of "export()" with the "install(FILES)" command is no longer allowed. See policy "CMP0062" for details. Other Changes ============= * The "Ninja" generator now requires that calls to the "add_custom_command()" and "add_custom_target()" commands use the "BYPRODUCTS" option to explicitly specify any files generated by the custom commands that are not listed as outputs (perhaps because their timestamps are allowed to be older than the inputs). See policy "CMP0058". * Build-time progress output of *Makefile Generators* has been improved. It no longer mixes progress and build rule messages during parallel builds. The link rule messages now have progress and are displayed as bold green instead of bold red (since red is often associated with an error message). * The "CMAKE_CFG_INTDIR" variable value for Visual Studio 7, 8, and 9 is now "$(ConfigurationName)" instead of "$(OutDir)". This should have no effect on the intended use cases of the variable. * Linking to library files by a full path in an implicit linker search directory (e.g. "/usr/lib/libfoo.a") no longer asks the linker to search for the library (e.g. "-lfoo") and now links by full path. See policy "CMP0060". ------------------------------------------------------------------- Changes made since CMake 3.3.0-rc3: Brad King (4): Fortran: Fix passing of preprocessor definitions to dependency scanner Check*CompilerFlag: Revert to previous method used to pass flags (#15641) set_property: Fix crash when setting LINK_LIBRARIES to nothing CMake 3.3.0-rc4 Konstantin Podsvirov (1): CPackIFW: Load module to set CPACK_IFW_FRAMEWORK_VERSION Sean Brennan (1): FindMPI: Extend Intel-MPI 5+ workaround for recent GCCs Stephen Kelly (1): cmState: Restore renamed commands on cleanup. Tamas Kenez (1): FindMatlab: Fix documentation section header underline style ------------------------------------------------------------------- From d3ck0r at gmail.com Mon Jul 13 18:17:53 2015 From: d3ck0r at gmail.com (J Decker) Date: Mon, 13 Jul 2015 15:17:53 -0700 Subject: [CMake] Is there any way to set a build-type specific install path for multiconfig tools? In-Reply-To: References: Message-ID: On Mon, Jul 13, 2015 at 10:45 AM, David Cole via CMake wrote: > A few more ideas: > > > The other "no need to modify CMake" way to achieve this (although it > may be considered "too ugly" or non-ideal by some) would be to force > the use of a single configuration per build tree, and use the proper > value for CMAKE_INSTALL_PREFIX in each build tree. > > Your developers may not like that, but it would sure make the problem > at hand disappear. > > This is/was my preferred way to do this. And yes, other developers had problems grasping the issue. And resulted in many mixed-mode builds. And actually going this way removed complication of installing 'bin/release' and 'bin/debug' sort of destinations. The idea of making an install that installs from a install won't work; the inbetween could still be corrupted from partial release/debug mode builds. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cliffyapp at gmail.com Mon Jul 13 23:53:11 2015 From: cliffyapp at gmail.com (Clifford Yapp) Date: Mon, 13 Jul 2015 23:53:11 -0400 Subject: [CMake] Problem with CMake 3.3.0-rc3 In-Reply-To: References: <559AA461.5070104@kitware.com> <559EC058.6000209@kitware.com> Message-ID: On Sat, Jul 11, 2015 at 5:07 AM, Stephen Kelly wrote: > Brad King wrote: > >> Steve, please take a look. It looks like the cmState methods >> RemoveUserDefinedCommands and RenameCommand need to work better >> together. This needs to be fixed for 3.3. > > Fixed with > > http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f2ee169d > cmState: Restore renamed commands on cleanup Confirmed in rc4 - thanks! CY From andrew.amaclean at gmail.com Tue Jul 14 00:57:31 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 14 Jul 2015 14:57:31 +1000 Subject: [CMake] Patch for Sphinx warning message Message-ID: This patch fixes this warning when building CMake from the master: "WARNING: 'default' html theme has been renamed to 'classic'. Please change your html_theme setting either to the new 'alabaster' default theme, or to 'classic' to keep using the old default." It ensures that the "classic" theme is used for versions greater then 1.2 and "default" otherwise. Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_sphinx_warning.patch Type: application/octet-stream Size: 1216 bytes Desc: not available URL: From j.kreuzberger at procitec.de Tue Jul 14 04:12:55 2015 From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=) Date: Tue, 14 Jul 2015 10:12:55 +0200 Subject: [CMake] Code Coverage of CMake Scripts Message-ID: Hi! i just want to get coverage information from the configure step itself to find uncovered cmake makros and scripts. The --trace option seems to be the way to do it. is there any tool/script available to get these information in a good report? BEST solution would be something like lgov or govr :-) Thanks for any suggestions :-) Joerg From pelegs at gmail.com Tue Jul 14 07:51:58 2015 From: pelegs at gmail.com (Peleg Bar-Sapir) Date: Tue, 14 Jul 2015 13:51:58 +0200 Subject: [CMake] Linking own header files to a source code Message-ID: Hello, I'm trying to configure my own library (called "libtrace") to a test file I made. My source library contains the following files: libtrace.h -- Header file for the libtrace library. libtrace.cc -- Source file for the libtrace library. test01.cc -- A test file that uses libtrace. CMakeLists.txt -- CMake's config file. I also have a MySQL connector linked to my project (in the manner Daniel Schepler had helped me with back in late April) - so CMakeLists.txt looks like this: ....................................................................... cmake_minimum_required(VERSION 2.8) project( Test ) set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/Modules/") find_package( MySQL REQUIRED ) target_link_libraries( Test ${MYSQL_LIBRARY} ) include_directories(${MYSQL_INCLUDE_DIR}) ....................................................................... ...I cannot seem to connect my own library with nay success (I followed the tutorial from here: http://www.cmake.org/cmake-tutorial/ ). It keeps giving me errors. Any help with ordering the CMakeLists.txt file would be greatly appreciated. Thanks, Peleg Bar Sapir -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob_bachman at intercept.com Tue Jul 14 10:51:53 2015 From: bob_bachman at intercept.com (Bob Bachman) Date: Tue, 14 Jul 2015 14:51:53 +0000 (UTC) Subject: [CMake] Can't find wxWidgets References: Message-ID: I just wanted to close out this thread. The problem turned out to be DOS line endings in the wx-config file. The following line in the wxWidgets- 3.0.2/buildgtk/lib/wx/config directory fixed the problem. dos2unix inplace-gtk2-unicode-3.0 inplace-gtk2-unicode-3.0 Thanks for your help. Bob From paul at mad-scientist.net Tue Jul 14 11:01:45 2015 From: paul at mad-scientist.net (Paul Smith) Date: Tue, 14 Jul 2015 11:01:45 -0400 Subject: [CMake] Why does changing -G not change generators? Message-ID: <1436886105.5338.59.camel@mad-scientist.net> We have a situation where people are sometimes wanting to switch between different generators: from Xcode to Unix Makefiles, or from Visual Studio 2010 to Visual Studio 2012, etc. If they have an already-configured workspace then run "cmake -G" with a different generator, it appears to be a no-op: no error is generated but no changes are made and the previous generator is still used. This doesn't seem right to me... shouldn't giving a new generator type on the command line change the output for the new generator? I'm using CMake 3.1.0... maybe this has changed since? Cheers! From DLRdave at aol.com Tue Jul 14 11:27:06 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 14 Jul 2015 11:27:06 -0400 Subject: [CMake] Why does changing -G not change generators? In-Reply-To: <1436886105.5338.59.camel@mad-scientist.net> References: <1436886105.5338.59.camel@mad-scientist.net> Message-ID: It's just something you can't change without wiping the build tree entirely. It should probably actually produce an error or warning of some sort to avoid confusion such as this... D On Tue, Jul 14, 2015 at 11:01 AM, Paul Smith wrote: > We have a situation where people are sometimes wanting to switch between > different generators: from Xcode to Unix Makefiles, or from Visual > Studio 2010 to Visual Studio 2012, etc. > > If they have an already-configured workspace then run "cmake -G" with a > different generator, it appears to be a no-op: no error is generated but > no changes are made and the previous generator is still used. > > This doesn't seem right to me... shouldn't giving a new generator type > on the command line change the output for the new generator? I'm using > CMake 3.1.0... maybe this has changed since? > > Cheers! > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From rainer.poisel at gmail.com Tue Jul 14 11:28:38 2015 From: rainer.poisel at gmail.com (Rainer Poisel) Date: Tue, 14 Jul 2015 17:28:38 +0200 Subject: [CMake] Exporting/Publishing settings (e. g. include directories) from subdirectories Message-ID: Hi list, I have a project that consists of several subdirectories. For example: project-dir +- component1 | +- src | +- include-dir1 | +- include-dir2 +- component2 Let's say I want "component2" to add "include-dir1" and "include-dir2" from "component1" as include directories without "component2" knowing that these two directories exist. Therefore my question: Is there a way to import project settings/properties which have been exported from other subdirectories? And is cmake intended to be used like that? I don't know whether I use the correct terms here but I hope that the idea is clear. Regards, Rainer From DLRdave at aol.com Tue Jul 14 11:39:09 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 14 Jul 2015 11:39:09 -0400 Subject: [CMake] Is there any way to set a build-type specific install path for multiconfig tools? In-Reply-To: References: Message-ID: Most of the variables that have a per-config variation on the name end with "_" ( see the page documenting CMake variables, and search it for "config" to get a sense of which variables these are... http://www.cmake.org/cmake/help/v3.3/manual/cmake-variables.7.html ) -- soooo, if you do prepare any patches for consideration, I would say use "CMAKE_INSTALL_PREFIX_" as the names of the alternate variables. I don't know what the consensus opinion will be, but I think CMAKE_INSTALL_PREFIX is already difficult to understand fully as-is, and I would hesitate to add per-config complexity to it. I am certain there are others with different opinions on the matter, though. We'll see if anybody else chimes in. D On Tue, Jul 14, 2015 at 7:52 AM, Clifford Yapp wrote: > On Mon, Jul 13, 2015 at 1:45 PM, David Cole wrote: > >> The other "no need to modify CMake" way to achieve this (although it >> may be considered "too ugly" or non-ideal by some) would be to force >> the use of a single configuration per build tree, and use the proper >> value for CMAKE_INSTALL_PREFIX in each build tree. >> >> Your developers may not like that, but it would sure make the problem >> at hand disappear. > > It would, but I think I would agree that's a fairly ugly solution - at > least, it violates assumptions a dev might reasonably make in the > multi-config workflow. What I have in place now does the job and > works (or at least, it did the last time I tried it) so I can stick > with it if need be, but I figured it was worth raising the question to > see if there either already existed a cleaner way or there was a way > to add a "clean" way that would be acceptable to the devs. > >> The other thing to consider is that the file cmake_install.cmake, >> generated at the top of your build tree contains code like the >> following: >> >> # Set the install prefix >> if(NOT DEFINED CMAKE_INSTALL_PREFIX) >> set(CMAKE_INSTALL_PREFIX "C:/Program Files (x86)/Tutorial") >> endif() >> >> In the end, installing your project is ultimately a call of some sort >> to "cmake -P cmake_install.cmake" -- you could simply install your >> project with a custom call to that script which passes in the proper >> value for CMAKE_INSTALL_PREFIX using -D... The above generated code >> allows you to override it by passing it in when the script is called. >> >> The Visual Studio command for the INSTALL project looks like this: >> >> "C:\Program Files (x86)\CMake\bin\cmake.exe" >> -DBUILD_TYPE=$(Configuration) -P cmake_install.cmake >> >> You could easily write a custom target / custom command that is an >> alternate "configuration-prefixed" install as: >> >> "C:\Program Files (x86)\CMake\bin\cmake.exe" >> -DBUILD_TYPE=$(Configuration) >> -DCMAKE_INSTALL_PREFIX=config-specific-value-here -P >> cmake_install.cmake > > Can that bit of code be controlled from the CMakeLists.txt file, or > would I need to manually overwrite it in some fashion after it is > generated? > > If a patch were prepared to use variables like > CMAKE_DEBUG_INSTALL_PREFIX, would the devs consider it? That still > feels to me like it's probably the "right" solution given how CMake > handles this for things like C flags, unless it causes too many other > problems... > > Thanks, > CY From brad.king at kitware.com Tue Jul 14 13:13:13 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 14 Jul 2015 13:13:13 -0400 Subject: [CMake] Patch for Sphinx warning message In-Reply-To: References: Message-ID: <55A54329.6010603@kitware.com> On 07/14/2015 12:57 AM, Andrew Maclean wrote: > This patch fixes this warning when building CMake from the master: > "WARNING: 'default' html theme has been renamed to 'classic'. Applied with slight tweaks: Utilities/Sphinx: Use 'classic' theme for Sphinx >= 1.3 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e59a7d7e Thanks, -Brad From micha.hergarden at gmail.com Tue Jul 14 13:19:39 2015 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Tue, 14 Jul 2015 19:19:39 +0200 Subject: [CMake] Linking own header files to a source code In-Reply-To: References: Message-ID: <55A544AB.20306@gmail.com> Hello, You don't seem to tell cmake what executable you want and what sources it is made up of. Take a look at the 'add_executable' and 'add_library' commands. To create an executable from the sources, you may want to do something like: add_executable(test01 test01.cc) And for the library: add_library(trace libtrace.h libtrace.cc) Add these statements between the 'find_package' and 'target_link_libraries' statements. If you then run cmake, two actual build targets get generated which you can see with 'make help' if you are using make. Regards, Micha On 07/14/2015 01:51 PM, Peleg Bar-Sapir wrote: > Hello, > > I'm trying to configure my own library (called "libtrace") to a test > file I made. > > My source library contains the following files: > libtrace.h -- Header file for the libtrace library. > libtrace.cc -- Source file for the libtrace library. > test01.cc -- A test file that uses libtrace. > CMakeLists.txt -- CMake's config file. > > I also have a MySQL connector linked to my project (in the manner > Daniel Schepler had helped me with back in late April) - so > CMakeLists.txt looks like this: > ....................................................................... > cmake_minimum_required(VERSION 2.8) > project( Test ) > > set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} > "${CMAKE_SOURCE_DIR}/cmake/Modules/") > > find_package( MySQL REQUIRED ) > target_link_libraries( Test ${MYSQL_LIBRARY} ) > include_directories(${MYSQL_INCLUDE_DIR}) > ....................................................................... > > ...I cannot seem to connect my own library with nay success (I > followed the tutorial from here: http://www.cmake.org/cmake-tutorial/ > ). It keeps giving me errors. > > Any help with ordering the CMakeLists.txt file would be greatly > appreciated. > > > Thanks, > > Peleg Bar Sapir > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From swirley161 at gmail.com Tue Jul 14 15:48:04 2015 From: swirley161 at gmail.com (Stephen Sorley) Date: Tue, 14 Jul 2015 15:48:04 -0400 Subject: [CMake] Problems wth Linux tar.gz packages on cmake.org Message-ID: For some reason, all the tar.gz packages on cmake.org are being downloaded by google chrome as unzipped tar's (though the .tar.gz extension is preserved). I only see this behavior with chrome and cmake.org. If I use firefox, or if I download a tar.gz from somewhere else (the CMake github "releases" page, for example), I do not observe this problem. Thanks, Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Tue Jul 14 17:14:10 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Tue, 14 Jul 2015 23:14:10 +0200 Subject: [CMake] Using ExternalProject_Add when CMakeFiles.txt is not in the root directory. Message-ID: I am attempting to use ExternalDependencies_Add with the last Protobuf version (v3.0.0) which is in alpha3 (I'm using the master branch actually)[1]. If you don't already know: contrary to previous Protobuf version, v3.x provides cmake scripts (and also makes CMake's FindProtobuf module unusuable if you build Protobuf using CMake BTW). I am having trouble figuring out how to ExternalProject_add work in this case: the CMakeFiles.txt is not in the root directory of Protobuf sources, it is in ./cmake/ [2] So at build time, after download, I obviously get: >CUSTOMBUILD : CMake error : The source directory "blahblah/install_protobuf" does not appear to contain CMakeLists.txt. I tried several approaches using this as a base: ExternalProject_Add( install_protobuf PREFIX ${NETRUSH_DEPENDENCIES_DIR}/protobuf GIT_REPOSITORY https://github.com/google/protobuf.git GIT_TAG master CMAKE_CACHE_ARGS -DBUILD_TESTING:bool=FALSE ) I tried setting SOURCE_DIR but failed to make it work mainly because I'm not sure what value to set exactly, and SOURCE_DIR cmake Does not seem to work. I was wondering if there is some args I could pass to CMake using CMAKE_ARGS but from the cmake[3] page in the doc I don't see anything that match exactly, or I might be misunderstanding something. I found this recommandation from Miklos Espak from 8th February 2015: "Specify a patch command that creates a toplevel cmake list with one 'add_subdirectory(A)' line." It seems to work, but it also means that the repository is modified, which is something I want to avoid. Also it's really a hack for passing the right working directory to cmake. Is there a simpler way to do it that I missed? Thanks for your time. Jo?l Lamotte [1] https://github.com/google/protobuf [2] https://github.com/google/protobuf/tree/master/cmake [3] http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html#manual:cmake(1) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Wed Jul 15 00:20:26 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Tue, 14 Jul 2015 21:20:26 -0700 (MST) Subject: [CMake] Finding internal libraries In-Reply-To: <559D5A8A.2030708@smu.edu> References: <559D5A8A.2030708@smu.edu> Message-ID: <1436934026969-7591056.post@n2.nabble.com> John LaGrone wrote > cmake_minimum_required(VERSION 2.8.12 FATAL_ERROR) > project(ex1) > find_package(foo REQUIRED) > add_executable(ex1.x ex1.c) > target_link_libraries(ex1.x foo) Just check that library exists already: if(NOT TARGET foo) find_package(foo REQUIRED) endif() -- View this message in context: http://cmake.3232098.n2.nabble.com/Finding-internal-libraries-tp7591003p7591056.html Sent from the CMake mailing list archive at Nabble.com. From d3ck0r at gmail.com Wed Jul 15 03:18:54 2015 From: d3ck0r at gmail.com (J Decker) Date: Wed, 15 Jul 2015 00:18:54 -0700 Subject: [CMake] Linking own header files to a source code In-Reply-To: <55A544AB.20306@gmail.com> References: <55A544AB.20306@gmail.com> Message-ID: and INCLUDE_DIRECTORIES On Tue, Jul 14, 2015 at 10:19 AM, Micha Hergarden wrote: > Hello, > > You don't seem to tell cmake what executable you want and what sources it > is made up of. Take a look at the 'add_executable' and 'add_library' > commands. To create an executable from the sources, you may want to do > something like: add_executable(test01 test01.cc) > And for the library: add_library(trace libtrace.h libtrace.cc) > > Add these statements between the 'find_package' and > 'target_link_libraries' statements. If you then run cmake, two actual build > targets get generated which you can see with 'make help' if you are using > make. > > Regards, > Micha > > > On 07/14/2015 01:51 PM, Peleg Bar-Sapir wrote: > > Hello, > > I'm trying to configure my own library (called "libtrace") to a test file > I made. > > My source library contains the following files: > libtrace.h -- Header file for the libtrace library. > libtrace.cc -- Source file for the libtrace library. > test01.cc -- A test file that uses libtrace. > CMakeLists.txt -- CMake's config file. > > I also have a MySQL connector linked to my project (in the manner Daniel > Schepler had helped me with back in late April) - so CMakeLists.txt looks > like this: > ....................................................................... > cmake_minimum_required(VERSION 2.8) > project( Test ) > > set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} > "${CMAKE_SOURCE_DIR}/cmake/Modules/") > > find_package( MySQL REQUIRED ) > target_link_libraries( Test ${MYSQL_LIBRARY} ) > include_directories(${MYSQL_INCLUDE_DIR}) > ....................................................................... > > ...I cannot seem to connect my own library with nay success (I followed > the tutorial from here: http://www.cmake.org/cmake-tutorial/ ). It keeps > giving me errors. > > Any help with ordering the CMakeLists.txt file would be greatly > appreciated. > > > Thanks, > > Peleg Bar Sapir > > > > > -- > > 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 brad.king at kitware.com Wed Jul 15 09:54:01 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 15 Jul 2015 09:54:01 -0400 Subject: [CMake] Patch for Sphinx warning message In-Reply-To: <55A54329.6010603@kitware.com> References: <55A54329.6010603@kitware.com> Message-ID: <55A665F9.9020709@kitware.com> On 07/14/2015 01:13 PM, Brad King wrote: > Applied with slight tweaks: > Utilities/Sphinx: Use 'classic' theme for Sphinx >= 1.3 > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e59a7d7e [snip] On 07/14/2015 06:56 PM, Andrew Maclean wrote: > Thanks, that looks much better than what I did! I had to revert it because other places in the sphinx config reference 'default': $ git grep -E 'default\>' -- Utilities/Sphinx/ Utilities/Sphinx/apply_qthelp_css_workaround.cmake:file(READ "${CSS_DIR}/default.css" DefaultCssContent) Utilities/Sphinx/apply_qthelp_css_workaround.cmake: "@import url(\"default.css\")" "${DefaultCssContent}" Utilities/Sphinx/conf.py.in:html_theme = 'default' Utilities/Sphinx/static/cmake.css:@import url("default.css"); The change above only worked in local testing because some files were left around in the build tree from the old configuration. Switching the theme name to 'classic' while still being compatible with Sphinx <= 1.2 would require a dedicated effort to make the entire static/ directory and other supporting scripts all configured based on the Sphinx version. It looks like even sphinx upstream has dropped the warning: theming: do not warn if theme is "default" https://github.com/sphinx-doc/sphinx/commit/034c4e942451fad40350ae3bb3beda6c63a49064 -Brad From jsvanbethlehem at gmail.com Wed Jul 15 15:30:41 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Wed, 15 Jul 2015 21:30:41 +0200 Subject: [CMake] Exporting/Publishing settings (e. g. include directories) from subdirectories In-Reply-To: References: Message-ID: <2FF3C860-793A-4D40-BB9E-75CA445EFC81@gmail.com> Hej Rainer, > > project-dir > +- component1 > | +- src > | +- include-dir1 > | +- include-dir2 > +- component2 > > Let's say I want "component2" to add "include-dir1" and "include-dir2" > from "component1" as include directories without "component2" knowing > that these two directories exist. > There is no way this is possible afaik, because if component2 uses any header file in one of the include directories, you would need to pass these directories to your compiler (most of the times using a -I or /I option depending on the OS). However, is it maybe possible that what you?re *really* asking is, whether it would be possible to say something like: target_link_libraries(component1 component2) *without* explicitly spilling out the include directories, which would look something like: target_include_directories(component1 PRIVATE $) then the answer would be ?yes?. You?d need to study the concept of IMPORTed and EXPORTed targets in CMake, see for instance http://www.cmake.org/cmake/help/v3.0/command/add_executable.html , http://www.cmake.org/cmake/help/v3.0/command/add_library.html and http://www.cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets These concepts were originally created to nicely handle external dependencies (check out for instance the Qt5 documentation on integration with CMake, see http://doc.qt.io/qt-5/cmake-manual.html - you simply link with the proper Qt5 library, and these are set up such that automatically all required include folders are added to the list of include locations to build your component). However, with some work (essentially, creating some wrapper functions/macros) it can just as easily be made to work for dependencies inside a project. I don?t know about details, I just know that the infrastructure guys in the team I?m working in, made it work like that (borrowing a lot from the CMake files that come with Qt5) and it works like a charm! > Therefore my question: Is there a way to import project > settings/properties which have been exported from other > subdirectories? And is cmake intended to be used like that? > > I don't know whether I use the correct terms here but I hope that the > idea is clear. If you meant to ask what I wrote above, then the question was entirely correct, but the idea clear (in particular because I use it that way) and yes, there is a way. Whether CMake is ?intended to be used like that I really wouldn?t know. My feeling is that this is definitely not the original intention of the feature. However, looking at how it works, this approach certainly also will not break as long as the feature is there. Sincerely, Jakob van Bethlehem -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Wed Jul 15 17:06:34 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 16 Jul 2015 07:06:34 +1000 Subject: [CMake] Patch for Sphinx warning message In-Reply-To: <55A665F9.9020709@kitware.com> References: <55A54329.6010603@kitware.com> <55A665F9.9020709@kitware.com> Message-ID: No worries, I should have wiped my build directory before testing too. On 15 Jul 2015 11:54 pm, "Brad King" wrote: > On 07/14/2015 01:13 PM, Brad King wrote: > > Applied with slight tweaks: > > Utilities/Sphinx: Use 'classic' theme for Sphinx >= 1.3 > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e59a7d7e > [snip] > On 07/14/2015 06:56 PM, Andrew Maclean wrote: > > Thanks, that looks much better than what I did! > > I had to revert it because other places in the sphinx config > reference 'default': > > $ git grep -E 'default\>' -- Utilities/Sphinx/ > Utilities/Sphinx/apply_qthelp_css_workaround.cmake:file(READ > "${CSS_DIR}/default.css" DefaultCssContent) > Utilities/Sphinx/apply_qthelp_css_workaround.cmake: "@import > url(\"default.css\")" "${DefaultCssContent}" > Utilities/Sphinx/conf.py.in:html_theme = 'default' > Utilities/Sphinx/static/cmake.css:@import url("default.css"); > > The change above only worked in local testing because some files > were left around in the build tree from the old configuration. > > Switching the theme name to 'classic' while still being compatible > with Sphinx <= 1.2 would require a dedicated effort to make the > entire static/ directory and other supporting scripts all configured > based on the Sphinx version. > > It looks like even sphinx upstream has dropped the warning: > > theming: do not warn if theme is "default" > > https://github.com/sphinx-doc/sphinx/commit/034c4e942451fad40350ae3bb3beda6c63a49064 > > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiandingzhe at 163.com Fri Jul 17 09:08:46 2015 From: jiandingzhe at 163.com (Xi Yang) Date: Fri, 17 Jul 2015 21:08:46 +0800 (CST) Subject: [CMake] config-specific compiler definitions don't work properly Message-ID: <718a0b2e.1229a.14e9c21a2b5.Coremail.jiandingzhe@163.com> Hi everyone! I'm trying to use config-specific definitions, but it seems doesn't work in VS2013. This is the CMakeLists.txt: cmake_minimum_required(VERSION 3.0) set_property(DIRECTORY PROPERTY COMPILE_DEFINITIONS_DEBUG FOO ) set_property(DIRECTORY PROPERTY COMPILE_DEFINITIONS_RELEASE BAR ) add_executable(main main.cpp) set_target_properties(main PROPERTIES COMPILE_DEFINITIONS_DEBUG FOO COMPILE_DEFINITIONS_RELEASE BAR ) Both target property and directory property are tried. And this is the source code main.cpp: #ifdef FOO #error got foo #endif #ifdef BAR #error got bar #endif int main(int argc, char** argv) { return 0; } If the definitions are sent to compilers, it should die with foo on Debug config, and die with bar on Release config. However, it finished compilation on both Debug and Release. I also have a look at the command line parameters of the Debug and Release config, it don't have "/D FOO" and "/D BAR". Thanks for a lot! -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Jul 17 09:33:20 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 17 Jul 2015 15:33:20 +0200 Subject: [CMake] config-specific compiler definitions don't work properly In-Reply-To: <718a0b2e.1229a.14e9c21a2b5.Coremail.jiandingzhe@163.com> References: <718a0b2e.1229a.14e9c21a2b5.Coremail.jiandingzhe@163.com> Message-ID: <55A90420.6090705@gmail.com> On 17.07.2015 15:08, Xi Yang wrote: > I'm trying to use config-specific definitions, but it seems doesn't > work in VS2013. > > This is the CMakeLists.txt: > > cmake_minimum_required(VERSION 3.0) > > set_property(DIRECTORY PROPERTY COMPILE_DEFINITIONS_DEBUG > FOO > ) > > set_property(DIRECTORY PROPERTY COMPILE_DEFINITIONS_RELEASE > BAR > ) When requiring CMake >= 3.0 those properties are ignored due to policy CMP0043: http://www.cmake.org/cmake/help/v3.0/policy/CMP0043.html The documentation for the policy explains both reasoning for removal of these properties and what new code should do instead. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Fri Jul 17 09:42:50 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 17 Jul 2015 15:42:50 +0200 Subject: [CMake] config-specific compiler definitions don't work properly In-Reply-To: <718a0b2e.1229a.14e9c21a2b5.Coremail.jiandingzhe@163.com> References: <718a0b2e.1229a.14e9c21a2b5.Coremail.jiandingzhe@163.com> Message-ID: Hi. Looking at the documentation ( http://www.cmake.org/cmake/help/v3.3/manual/cmake-properties.7.html#properties-on-directories , http://www.cmake.org/cmake/help/v3.3/manual/cmake-properties.7.html#properties-on-targets ), you will find that neither the directory property nor the target property COMPILE_DEFINITIONS has per-configuration variants. They do support generator expressions, however, so you could use these instead: set_property(DIRECTORY PROPERTY COMPILE_DEFINITIONS $<$:FOO> $<$:BAR>) Petr On Fri, Jul 17, 2015 at 3:08 PM, Xi Yang wrote: > Hi everyone! > > I'm trying to use config-specific definitions, but it seems doesn't work > in VS2013. > > This is the CMakeLists.txt: > > cmake_minimum_required(VERSION 3.0) > > set_property(DIRECTORY PROPERTY COMPILE_DEFINITIONS_DEBUG > FOO > ) > > set_property(DIRECTORY PROPERTY COMPILE_DEFINITIONS_RELEASE > BAR > ) > > add_executable(main main.cpp) > set_target_properties(main > PROPERTIES > COMPILE_DEFINITIONS_DEBUG FOO > COMPILE_DEFINITIONS_RELEASE BAR > ) > > Both target property and directory property are tried. And this is the > source code main.cpp: > > #ifdef FOO > #error got foo > #endif > > #ifdef BAR > #error got bar > #endif > > int main(int argc, char** argv) > { > return 0; > } > > If the definitions are sent to compilers, it should die with foo on Debug > config, and die with bar on Release config. However, it finished > compilation on both Debug and Release. > > I also have a look at the command line parameters of the Debug and Release > config, it don't have "/D FOO" and "/D BAR". > > Thanks for a lot! > > > > -- > > 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 greenc at fnal.gov Fri Jul 17 11:27:19 2015 From: greenc at fnal.gov (Chris Green) Date: Fri, 17 Jul 2015 10:27:19 -0500 Subject: [CMake] "Utility' targets with ninja generator? Message-ID: <55A91ED7.4010700@fnal.gov> Hi, With "UNIX Makefiles" I'm used to being able to cd into a subdirectory containing e.g. a C++ source file for which I need to examine the pre-processed source and typing something like, "make MyClass.i" I can also compile (for fast development cycle and clarity purposes) a single source file and even use tab completion for targets of this nature (with shell completion suitably enabled). This is all great, and improves my productivity measurably. Is there equivalent functionality for the Ninja generator (I'm currently using CMake 3.2.1, but could upgrade to a more recent version easily if appropriate), or can there be (even if only with the new ninja 1.6.0)? My inability to find same is pretty much the only reason I haven't abandoned make in favor of ninja entirely. Thanks for any help, Chris. -- Chris Green , FNAL CS/SCD/ADSS/SSI/TAC; 'phone (630) 840-2167; Skype: chris.h.green; IM: greenc at jabber.fnal.gov, chissgreen (AIM), chris.h.green (Google Talk). From rcdailey.lists at gmail.com Fri Jul 17 12:25:54 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 17 Jul 2015 11:25:54 -0500 Subject: [CMake] Toolchain file for VS2013 + November CTP compiler toolset? Message-ID: Hello, How would I define a toolchain file for the Visual Studio 2013 generator that also defines the toolset for that generator to be the November CTP compiler? I'd rather use a toolchain for this than do -D definitions when I invoke cmake to generate. Thanks in advance. From mjklaim at gmail.com Fri Jul 17 12:53:38 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Fri, 17 Jul 2015 18:53:38 +0200 Subject: [CMake] ExternalProject_Add_StepDependencies parallel download/cloning Message-ID: I am setting up a bunch of dependencies using ExternalProject module. One of the dependencies, say A, needs another dependency B to be built before A can be built. ExternalProject_Add_StepDependencies solves the problem fine. However, I did it this way: ExternalProject_Add_StepDependencies( A configure B ) Because I wanted A and B repositories to be cloned in parallel, as it should be safe to do so. Only A's configure step require that B be built and installed first. As A and B have very big repositories, it might help to have them be downloaded concurrently. Is there a way to do this? Jo?l Lamotte -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Fri Jul 17 13:48:46 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 17 Jul 2015 13:48:46 -0400 Subject: [CMake] ExternalProject_Add_StepDependencies parallel download/cloning In-Reply-To: References: Message-ID: I have adopted the technique of splitting a project into two ExternalProject_Add calls, the first of which is named "download-${projectName}" with empty configure, build and install stages, and the second of which is named ${projectName} with an empty download step (using DOWNLOAD_COMMAND ""). Then, the "real" project depends on the download-only project, and ALL download-only projects can occur in parallel (to the limit of the number of parallel jobs...) The other benefit of doing it this way is you can have a single "download-all" external project which depends on all your individual download-only projects. This comes in handy if you want to download everything all at once and then go offline with it. Or, if you want to share the same download step with multiple downstream configure/build/install commands (for example, ALL configurations for ALL architectures, each combination of which is a separate EP_Add call...) HTH, David C. On Fri, Jul 17, 2015 at 12:53 PM, Klaim - Jo?l Lamotte wrote: > I am setting up a bunch of dependencies using ExternalProject module. > One of the dependencies, say A, needs another dependency B to be built > before A can be built. > ExternalProject_Add_StepDependencies solves the problem fine. > > However, I did it this way: > > ExternalProject_Add_StepDependencies( A configure B ) > > Because I wanted A and B repositories to be cloned in parallel, as it should > be > safe to do so. Only A's configure step require that B be built and installed > first. > As A and B have very big repositories, it might help to have them be > downloaded > concurrently. > > Is there a way to do this? > > Jo?l Lamotte > > > -- > > 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 blowekamp at mail.nih.gov Fri Jul 17 14:06:49 2015 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Fri, 17 Jul 2015 14:06:49 -0400 Subject: [CMake] Using ExternalProject_Add when CMakeFiles.txt is not in the root directory. In-Reply-To: References: Message-ID: <0D775E6B-0B95-4128-9364-5CF17F9E8E56@mail.nih.gov> Hello, David Cole just said the solution in another post. You can split the project into two, with the first one being just the download step, the second is the configuration and build. This should allow you to configure the paths for your project correctly. I need to do this for my project too. Thanks for the question to get me paying attention here, and finding the answer is another post :) Brad On Jul 14, 2015, at 5:14 PM, Klaim - Jo?l Lamotte wrote: > I am attempting to use ExternalDependencies_Add with the last Protobuf version (v3.0.0) which is in alpha3 (I'm using the master branch actually)[1]. > If you don't already know: contrary to previous Protobuf version, v3.x provides > cmake scripts (and also makes CMake's FindProtobuf module unusuable if you build Protobuf using CMake BTW). > > I am having trouble figuring out how to ExternalProject_add work in this case: > the CMakeFiles.txt is not in the root directory of Protobuf sources, it is in ./cmake/ [2] > So at build time, after download, I obviously get: > > >CUSTOMBUILD : CMake error : The source directory "blahblah/install_protobuf" does not appear to contain CMakeLists.txt. > > I tried several approaches using this as a base: > > ExternalProject_Add( install_protobuf > PREFIX ${NETRUSH_DEPENDENCIES_DIR}/protobuf > GIT_REPOSITORY https://github.com/google/protobuf.git > GIT_TAG master > > CMAKE_CACHE_ARGS > -DBUILD_TESTING:bool=FALSE > ) > > > I tried setting SOURCE_DIR but failed to make it work mainly because I'm > not sure what value to set exactly, and > > SOURCE_DIR cmake > > Does not seem to work. > > I was wondering if there is some args I could pass to CMake using CMAKE_ARGS > but from the cmake[3] page in the doc I don't see anything that match exactly, or > I might be misunderstanding something. > > I found this recommandation from Miklos Espak from 8th February 2015: > "Specify a patch command that creates a toplevel cmake list with one 'add_subdirectory(A)' line." > > It seems to work, but it also means that the repository is modified, which is something > I want to avoid. Also it's really a hack for passing the right working directory to cmake. > > Is there a simpler way to do it that I missed? > > Thanks for your time. > > Jo?l Lamotte > > > [1] https://github.com/google/protobuf > [2] https://github.com/google/protobuf/tree/master/cmake > [3] http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html#manual:cmake(1) > -- > > 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 mjklaim at gmail.com Fri Jul 17 21:06:47 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Sat, 18 Jul 2015 03:06:47 +0200 Subject: [CMake] ExternalProject_Add_StepDependencies parallel download/cloning In-Reply-To: References: Message-ID: On 17 July 2015 at 19:48, David Cole wrote: > I have adopted the technique of splitting a project into two > ExternalProject_Add calls, the first of which is named > "download-${projectName}" with empty configure, build and install > stages, and the second of which is named ${projectName} with an empty > download step (using DOWNLOAD_COMMAND ""). > > Then, the "real" project depends on the download-only project, and ALL > download-only projects can occur in parallel (to the limit of the > number of parallel jobs...) > > The other benefit of doing it this way is you can have a single > "download-all" external project which depends on all your individual > download-only projects. This comes in handy if you want to download > everything all at once and then go offline with it. Or, if you want to > share the same download step with multiple downstream > configure/build/install commands (for example, ALL configurations for > ALL architectures, each combination of which is a separate EP_Add > call...) > > > HTH, > David C. > > Very interesting, I didn't think about that. I'll experiment with it ASAP, thanks for the suggestion. > > > On Fri, Jul 17, 2015 at 12:53 PM, Klaim - Jo?l Lamotte > wrote: > > I am setting up a bunch of dependencies using ExternalProject module. > > One of the dependencies, say A, needs another dependency B to be built > > before A can be built. > > ExternalProject_Add_StepDependencies solves the problem fine. > > > > However, I did it this way: > > > > ExternalProject_Add_StepDependencies( A configure B ) > > > > Because I wanted A and B repositories to be cloned in parallel, as it > should > > be > > safe to do so. Only A's configure step require that B be built and > installed > > first. > > As A and B have very big repositories, it might help to have them be > > downloaded > > concurrently. > > > > Is there a way to do this? > > > > Jo?l Lamotte > > > > > > -- > > > > 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 mjklaim at gmail.com Fri Jul 17 21:12:15 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Sat, 18 Jul 2015 03:12:15 +0200 Subject: [CMake] Using ExternalProject_Add when CMakeFiles.txt is not in the root directory. In-Reply-To: <0D775E6B-0B95-4128-9364-5CF17F9E8E56@mail.nih.gov> References: <0D775E6B-0B95-4128-9364-5CF17F9E8E56@mail.nih.gov> Message-ID: On 17 July 2015 at 20:06, Bradley Lowekamp wrote: > Hello, > > David Cole just said the solution in another post. > > You can split the project into two, with the first one being just the > download step, the second is the configuration and build. This should allow > you to configure the paths for your project correctly. > > I am not 100% sure that the split can solve this problem too, but I will try it. Now that I have the split trick in mind, it seems to match my initial assumption that ExternalProjects should have a "download only" function/macro separated from the other steps, so that it is possible to compose complex setup in easier ways than hacking ExternalProjects_Add parametters and using clunky patches. > I need to do this for my project too. Thanks for the question to get me > paying attention here, and finding the answer is another post :) > > Brad > > On Jul 14, 2015, at 5:14 PM, Klaim - Jo?l Lamotte > wrote: > > I am attempting to use ExternalDependencies_Add with the last Protobuf > version (v3.0.0) which is in alpha3 (I'm using the master branch > actually)[1]. > If you don't already know: contrary to previous Protobuf version, v3.x > provides > cmake scripts (and also makes CMake's FindProtobuf module unusuable if you > build Protobuf using CMake BTW). > > I am having trouble figuring out how to ExternalProject_add work in this > case: > the CMakeFiles.txt is not in the root directory of Protobuf sources, it is > in ./cmake/ [2] > So at build time, after download, I obviously get: > > >CUSTOMBUILD : CMake error : The source directory > "blahblah/install_protobuf" does not appear to contain CMakeLists.txt. > > I tried several approaches using this as a base: > > ExternalProject_Add( install_protobuf > PREFIX ${NETRUSH_DEPENDENCIES_DIR}/protobuf > GIT_REPOSITORY https://github.com/google/protobuf.git > GIT_TAG master > > CMAKE_CACHE_ARGS > -DBUILD_TESTING:bool=FALSE > ) > > > I tried setting SOURCE_DIR but failed to make it work mainly because I'm > not sure what value to set exactly, and > > SOURCE_DIR cmake > > Does not seem to work. > > I was wondering if there is some args I could pass to CMake using > CMAKE_ARGS > but from the cmake[3] page in the doc I don't see anything that match > exactly, or > I might be misunderstanding something. > > I found this recommandation from Miklos Espak from 8th February 2015: > "Specify a patch command that creates a toplevel cmake list with one > 'add_subdirectory(A)' line." > > It seems to work, but it also means that the repository is modified, which > is something > I want to avoid. Also it's really a hack for passing the right working > directory to cmake. > > Is there a simpler way to do it that I missed? > > Thanks for your time. > > Jo?l Lamotte > > > [1] https://github.com/google/protobuf > [2] https://github.com/google/protobuf/tree/master/cmake > [3] > http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html#manual:cmake(1) > -- > > 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 agouaillard at gmail.com Sat Jul 18 02:17:48 2015 From: agouaillard at gmail.com (Alexandre GOUAILLARD) Date: Fri, 17 Jul 2015 23:17:48 -0700 Subject: [CMake] grep at build time? Message-ID: dear all, I'm trying to use cmake as a super build script for another library build system. Using add_custom_command and add_custom_target I have managed to handle most of the steps so far. My libraries and executable are being built as requested across platform. Now I'm trying to import the generated tests. Some of the generated executables during the build step are self-contained tests that I would like to run using ctest and send to a dashboard. So far I have hardcoded the revision of the code i'm fetching, and the corresponding list of tests. However those tests change pretty often, and I would like to have something more flexible there. How could I grep the list of tests (knowing that they all end up with ".isolated" a grep would do), and loop through the resulting list "add_test"ing them one by one AT CMAKE BUILD TIME, after a previous target has been built? I googled around, tried a few things, but couldn't figure out a way to make it happen. thanks in advance for all advice. Alex. -- Alex. Gouaillard, PhD, PhD, MBA ------------------------------------------------------------------------------------ CTO - Temasys Communications, S'pore / Mountain View President - CoSMo Software, Cambridge, MA ------------------------------------------------------------------------------------ sg.linkedin.com/agouaillard - -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Sat Jul 18 11:48:05 2015 From: DLRdave at aol.com (David Cole) Date: Sat, 18 Jul 2015 11:48:05 -0400 Subject: [CMake] Using ExternalProject_Add when CMakeFiles.txt is not in the root directory. In-Reply-To: References: <0D775E6B-0B95-4128-9364-5CF17F9E8E56@mail.nih.gov> Message-ID: The split technique should be able to help in this scenario as well, because for the second project, which builds the code downloaded by the first project, you can specify a different SOURCE_DIR value... (A sub directory of the first project's source dir, for example.) It would be nice if EP stuff were more compose-able. If you have any good ideas for making it so, this and the dev list are the right places to mention them. D On Friday, July 17, 2015, Klaim - Jo?l Lamotte wrote: > > > On 17 July 2015 at 20:06, Bradley Lowekamp > wrote: > >> Hello, >> >> David Cole just said the solution in another post. >> >> You can split the project into two, with the first one being just the >> download step, the second is the configuration and build. This should allow >> you to configure the paths for your project correctly. >> >> > I am not 100% sure that the split can solve this problem too, but I will > try it. > > Now that I have the split trick in mind, it seems to match my initial > assumption that ExternalProjects should have a "download only" > function/macro > separated from the other steps, so that it is possible to compose complex > setup in easier ways than hacking ExternalProjects_Add parametters and > using clunky patches. > > >> I need to do this for my project too. Thanks for the question to get me >> paying attention here, and finding the answer is another post :) >> >> Brad >> >> On Jul 14, 2015, at 5:14 PM, Klaim - Jo?l Lamotte > > wrote: >> >> I am attempting to use ExternalDependencies_Add with the last Protobuf >> version (v3.0.0) which is in alpha3 (I'm using the master branch >> actually)[1]. >> If you don't already know: contrary to previous Protobuf version, v3.x >> provides >> cmake scripts (and also makes CMake's FindProtobuf module unusuable if >> you build Protobuf using CMake BTW). >> >> I am having trouble figuring out how to ExternalProject_add work in this >> case: >> the CMakeFiles.txt is not in the root directory of Protobuf sources, it >> is in ./cmake/ [2] >> So at build time, after download, I obviously get: >> >> >CUSTOMBUILD : CMake error : The source directory >> "blahblah/install_protobuf" does not appear to contain CMakeLists.txt. >> >> I tried several approaches using this as a base: >> >> ExternalProject_Add( install_protobuf >> PREFIX ${NETRUSH_DEPENDENCIES_DIR}/protobuf >> GIT_REPOSITORY https://github.com/google/protobuf.git >> GIT_TAG master >> >> CMAKE_CACHE_ARGS >> -DBUILD_TESTING:bool=FALSE >> ) >> >> >> I tried setting SOURCE_DIR but failed to make it work mainly because I'm >> not sure what value to set exactly, and >> >> SOURCE_DIR cmake >> >> Does not seem to work. >> >> I was wondering if there is some args I could pass to CMake using >> CMAKE_ARGS >> but from the cmake[3] page in the doc I don't see anything that match >> exactly, or >> I might be misunderstanding something. >> >> I found this recommandation from Miklos Espak from 8th February 2015: >> "Specify a patch command that creates a toplevel cmake list with one >> 'add_subdirectory(A)' line." >> >> It seems to work, but it also means that the repository is modified, >> which is something >> I want to avoid. Also it's really a hack for passing the right working >> directory to cmake. >> >> Is there a simpler way to do it that I missed? >> >> Thanks for your time. >> >> Jo?l Lamotte >> >> >> [1] https://github.com/google/protobuf >> [2] https://github.com/google/protobuf/tree/master/cmake >> [3] >> http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html#manual:cmake(1) >> -- >> >> 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 yaronct at gmail.com Sun Jul 19 02:38:38 2015 From: yaronct at gmail.com (Yaron Cohen-Tal) Date: Sun, 19 Jul 2015 09:38:38 +0300 Subject: [CMake] How to find a specific version of a library? Message-ID: Hi, For example, I currently have both versions 2 and 3 of the GLFW library installed on my Linux computer, named "libglfw.so.2" and "libglfw.so.3". Is it possible to tell CMake to find a specific version of GLFW (say, version 3), and it would be smart enough to look for "libglfw.so.3" or "libglfw.so.3.*" or "libglfw.so.3.*.*"? (Or something equivalent in Mac and Windows) Thanx, Yaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Sun Jul 19 06:06:39 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sun, 19 Jul 2015 12:06:39 +0200 Subject: [CMake] How to find a specific version of a library? In-Reply-To: References: Message-ID: <55AB76AF.6040306@gmail.com> On 19.07.2015 08:38, Yaron Cohen-Tal wrote: > Hi, > > For example, I currently have both versions 2 and 3 of the GLFW > library installed on my Linux computer, named "libglfw.so.2" and > "libglfw.so.3". Is it possible to tell CMake to find a specific > version of GLFW (say, version 3), and it would be smart enough to look > for "libglfw.so.3" or "libglfw.so.3.*" or "libglfw.so.3.*.*"? (Or > something equivalent in Mac and Windows) Those are SONAMEs of the library intended for the runtime loader. Any number of those may be present in the same installation prefix to satisfy runtime dependencies. By convention only one version within that prefix may be available for development at a time. For that a symlink from libglfw.so to the actual library will be present and required header files matching that version will be present. Hence libglfw.so is intended for development and its presence implies that appropriate headers should be available as well. The sole presence of libglfw.so.2 or libglfw.so.3 neither implies that headers will be available nor do you know which of those versions those headers would be for. Nils From yaronct at gmail.com Sun Jul 19 08:02:17 2015 From: yaronct at gmail.com (Yaron Cohen-Tal) Date: Sun, 19 Jul 2015 15:02:17 +0300 Subject: [CMake] How to find a specific version of a library? In-Reply-To: <55AB76AF.6040306@gmail.com> References: <55AB76AF.6040306@gmail.com> Message-ID: Ok, I get it. But I still don't understand (and this has nothing to do with CMake) why is it so that "By convention only one version within that prefix may be available for development at a time". If I want to develop one project that uses GLFW 2 and one project that uses GLFW 3, I need to have both installed. I could just link one project with "libglfw.so.2" and the other with "libglfw.so.3". But my system (Debian) doesn't let me do that, as the development packages of GLFW 2 and GLFW 3 conflict (they both contain the symlink "libglfw.so"). Do u have any idea why it's like that, and if it has a workaround? (Other than building from source) On Sun, Jul 19, 2015 at 1:06 PM, Nils Gladitz wrote: > On 19.07.2015 08:38, Yaron Cohen-Tal wrote: > >> Hi, >> >> For example, I currently have both versions 2 and 3 of the GLFW library >> installed on my Linux computer, named "libglfw.so.2" and "libglfw.so.3". Is >> it possible to tell CMake to find a specific version of GLFW (say, version >> 3), and it would be smart enough to look for "libglfw.so.3" or >> "libglfw.so.3.*" or "libglfw.so.3.*.*"? (Or something equivalent in Mac and >> Windows) >> > > Those are SONAMEs of the library intended for the runtime loader. > Any number of those may be present in the same installation prefix to > satisfy runtime dependencies. > > By convention only one version within that prefix may be available for > development at a time. > For that a symlink from libglfw.so to the actual library will be present > and required header files matching that version will be present. > > Hence libglfw.so is intended for development and its presence implies that > appropriate headers should be available as well. > The sole presence of libglfw.so.2 or libglfw.so.3 neither implies that > headers will be available nor do you know which of those versions those > headers would be for. > > Nils > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Sun Jul 19 08:54:45 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sun, 19 Jul 2015 14:54:45 +0200 Subject: [CMake] How to find a specific version of a library? In-Reply-To: References: <55AB76AF.6040306@gmail.com> Message-ID: <55AB9E15.5050107@gmail.com> On 19.07.2015 14:02, Yaron Cohen-Tal wrote: > Ok, I get it. But I still don't understand (and this has nothing to do > with CMake) why is it so that "By convention only one version within > that prefix may be available for development at a time". If I want to > develop one project that uses GLFW 2 and one project that uses GLFW 3, > I need to have both installed. I could just link one project with > "libglfw.so.2" and the other with "libglfw.so.3". But my system > (Debian) doesn't let me do that, as the development packages of GLFW 2 > and GLFW 3 conflict (they both contain the symlink "libglfw.so"). Do u > have any idea why it's like that, and if it has a workaround? (Other > than building from source) Having multiple versions of a library available for development at the same time within the same installation prefix requires disambiguation for the library names and include files at the filesystem level. Library developers might allow for this by adding a version number to the library name (before the suffix) and include directory (e.g. Qt, GTK, SDL, Python). Most often this is limited to major releases where porting from one version to the next is non-trivial. This isn't something that distributions can (or rather should) add if it hasn't been part of the library's design. It is in the interest of library developers and distributions to minimize the number of versions and permutations to maintain. You can work around this somewhat by installing custom versions into isolated distinct (version specific) installation prefixes. Nils From yaronct at gmail.com Sun Jul 19 10:39:18 2015 From: yaronct at gmail.com (Yaron Cohen-Tal) Date: Sun, 19 Jul 2015 17:39:18 +0300 Subject: [CMake] How to assign a boolean expression to a variable? Message-ID: I want to set "FOO" to "TRUE" iff both "COND_A" and "COND_B" are true.I tried the following: set (FOO (${COND_A} AND ${COND_B})) but then FOO get's a value like "(;TRUE;AND;TRUE;)" instead of "TRUE". So I had to write instead: if (${COND_A} AND ${COND_B}) set (FOO TRUE) else () set (FOO FALSE) endif () Is there a better way? Thanx, Yaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Sun Jul 19 10:49:31 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sun, 19 Jul 2015 16:49:31 +0200 Subject: [CMake] How to assign a boolean expression to a variable? In-Reply-To: References: Message-ID: <55ABB8FB.3060205@gmail.com> On 19.07.2015 16:39, Yaron Cohen-Tal wrote: > I want to set "FOO" to "TRUE" iff both "COND_A" and "COND_B" are > true.I tried the following: > > set (FOO (${COND_A} AND ${COND_B})) The AND operator is handled and implemented by the if() and while() commands and hence not available elsewhere. > > but then FOO get's a value like "(;TRUE;AND;TRUE;)" instead of "TRUE". > So I had to write instead: > > if (${COND_A} AND ${COND_B}) > set (FOO TRUE) > else () > set (FOO FALSE) > endif () > > Is there a better way? > Depending on context you might omit the else() block given that if(FOO) will evaluate false if FOO is not a defined variable. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Sun Jul 19 18:52:56 2015 From: ewmailing at gmail.com (Eric Wing) Date: Sun, 19 Jul 2015 15:52:56 -0700 Subject: [CMake] Possible to dynamically construct macro/function names to invoke? Message-ID: I would like to dynamically construct a macro or function name to invoke. I basically have a core CMake system I want users to be able to extend/plug stuff into without knowing about a lot of the core CMake implementation. Callback functions would be an easy way for me to accomplish this. As an example, # In my core code, I have a macro designed to callback other macros macro(DO_PACKAGE _TARGET_NAME) foreach(callback ${DO_PACKAGE_CALLBACK_LIST}) DO_PACKAGE_FOR_${callback}(${_TARGET_NAME}) endforeach() endmacro(BLURRR_PACKAGE_EXTRAS) ### Also in my core code, I pick an appropriate time to trigger my macro to call user callbacks DERIVE_SOME_NAME() ADD_EXECUTABLE(${SOME_NAME} ...) DO_PACKAGE(${SOME_NAME}) # So in user modules provided by others, they follow a convention where # they define a macro DO_PACKAGE_ appended by their module name. macro(DO_PACKAGE_FOR_MYMODULE _TARGET_NAME) MESSAGE("in mymod callback") # do stuff endmacro() # And I make them add their module name to a global list so I can call it back at the right time list(APPEND DO_PACKAGE_CALLBACK_LIST "MYMODULE") So in my attempts to do this, I'm getting errors like: Parse error. Expected a command name, got unquoted argument with text Is there way to do this (or something similar)? Thanks, Eric From finjulhich at gmail.com Mon Jul 20 11:16:29 2015 From: finjulhich at gmail.com (MM) Date: Mon, 20 Jul 2015 16:16:29 +0100 Subject: [CMake] refering to top-level project as a target in a subdir's cmakelists.txt Message-ID: I want to refer to == toplevl cmakelists file === PROJECT(prj) ADD_SUBDIRECTORY(dir1) ==dir1 cmakelists.txt=== ADD_CUSTOM_COMMAND( TARGET prj # this doesn't work ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From micha.hergarden at gmail.com Mon Jul 20 13:52:52 2015 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Mon, 20 Jul 2015 19:52:52 +0200 Subject: [CMake] refering to top-level project as a target in a subdir's cmakelists.txt In-Reply-To: References: Message-ID: <55AD3574.3050805@gmail.com> On 07/20/2015 05:16 PM, MM wrote: > I want to refer to > > == toplevl cmakelists file === > PROJECT(prj) > ADD_SUBDIRECTORY(dir1) > > ==dir1 cmakelists.txt=== > ADD_CUSTOM_COMMAND( TARGET prj # this doesn't work > ) > > In what way do you want to refer to it? You may want to use the DEPENDS parameter here. Do I understand correctly that you want to add a custom command that depends on the whole project the custom command is part of? Does that not imply a cyclic dependency? Regards, Micha -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From finjulhich at gmail.com Mon Jul 20 14:36:15 2015 From: finjulhich at gmail.com (MM) Date: Mon, 20 Jul 2015 19:36:15 +0100 Subject: [CMake] refering to top-level project as a target in a subdir's cmakelists.txt In-Reply-To: <55AD3574.3050805@gmail.com> References: <55AD3574.3050805@gmail.com> Message-ID: On 20 July 2015 at 18:52, Micha Hergarden wrote: > On 07/20/2015 05:16 PM, MM wrote: > > I want to refer to > > == toplevl cmakelists file === > PROJECT(prj) > ADD_SUBDIRECTORY(dir1) > > ==dir1 cmakelists.txt=== > ADD_CUSTOM_COMMAND( TARGET prj # this doesn't work > ) > > > In what way do you want to refer to it? You may want to use the DEPENDS > parameter here. Do I understand correctly that you want to add a custom > command that depends on the whole project the custom command is part of? > Does that not imply a cyclic dependency? > > Regards, > Micha > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finjulhich at gmail.com Mon Jul 20 14:37:45 2015 From: finjulhich at gmail.com (MM) Date: Mon, 20 Jul 2015 19:37:45 +0100 Subject: [CMake] refering to top-level project as a target in a subdir's cmakelists.txt In-Reply-To: References: <55AD3574.3050805@gmail.com> Message-ID: > > On 20 July 2015 at 18:52, Micha Hergarden > wrote: > >> On 07/20/2015 05:16 PM, MM wrote: >> >> I want to refer to >> >> == toplevl cmakelists file === >> PROJECT(prj) >> ADD_SUBDIRECTORY(dir1) >> >> ==dir1 cmakelists.txt=== >> ADD_CUSTOM_COMMAND( TARGET prj # this doesn't work >> ) >> >> >> In what way do you want to refer to it? You may want to use the DEPENDS >> parameter here. Do I understand correctly that you want to add a custom >> command that depends on the whole project the custom command is part of? >> Does that not imply a cyclic dependency? >> >> Regards, >> Micha >> > > Apologies for the mis-click, Maybe right about the cyclic dependency, I used instead a cmakefile-local custom target to run all the time... with ALL. Yes i have a DEPENDS. What I want is this command to run post build of the entire project (my top level project), this command produces a sql file, and I want it only to run if any of its dependencies changed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From berteun at gmail.com Mon Jul 20 15:45:05 2015 From: berteun at gmail.com (Berteun Damman) Date: Mon, 20 Jul 2015 21:45:05 +0200 Subject: [CMake] Difference in CMake 2.8 / 3.1+ behaviour when looking at SOURCES property Message-ID: Hi, Consider the following example make file (it assumes a foo.txt and foo.cc -- can be both empty) are present: cmake_minimum_required(VERSION 2.8.12) add_library(lib_example STATIC "foo.cc" "foo.txt") get_target_property(sources lib_example SOURCES) foreach(source ${sources}) MESSAGE("${source}") endforeach() When using CMake 2.8.12, you'll see: build$ cmake .. foo.cc /home/berteun/tmp/cmake/foo.txt Note that it displays the full path for foo.txt! With later CMake versions (3.1 and up is my suspicion), it will display: build$ cmake .. foo.cc foo.txt I tried looking trough the release notes, and I've found that add_library gained support for generator expressions in 3.1, but I haven't found any explicit mention that would explain this behaviour. Does anyone know why it changed? And secondly, is there a way to get the 2.8 behaviour back? To be precise, I'd like to get accumulate the various .txt from different targets (including targets the current target depends on); in CMake 2.8 this was doable by collecting the dependencies, iterating over these targets and making a list of the .txt files; these would contain the full path. From 3.1 onwards, this is not the case; so if you do a get_filename_component on them requesting the absolue path, you won't get the actual path anymore, you'll get a path that is a combination of the current targets source directory and the filename. So the more general question is, is there a canonical way to get the full path to a source file by looking at the SOURCES of a target? It seems that for some filetypes this happened to work by accident in CMake 2.8 and 3.0? Thanks, -Berteun From byrn at hdfgroup.org Mon Jul 20 17:10:29 2015 From: byrn at hdfgroup.org (Allen Byrne) Date: Mon, 20 Jul 2015 16:10:29 -0500 Subject: [CMake] Fortran build dependency on Windows Message-ID: <10512773.0BPFRloMbh@byrn.ad.hdfgroup.org> We have encountered a problem on Windows, Visual Studio 2012(VS2013) with Intel Fortran 15. We generate a f90 file that must be compiled after another file because of module dependencies. See attached for a small example that demonstrates the issue. We use the OBJECT_DEPENDS property as follows; set_source_files_properties (${HDF5_F90_BINARY_DIR}/H5_gen.F90 PROPERTIES OBJECT_DEPENDS "${f90_F_BASE_SRCS}" ) This works fine on Linux and if we build within Visual Studio. If we build on the command line the DEPENDS seems to be ignored. Environment: Windows 7, Visual Studio 2012, Intel Fortran 15, and CMake 3.1 Allen Byrne The HDF Group -------------- next part -------------- A non-text attachment was scrubbed... Name: cmakeFtest.tar Type: application/x-tar Size: 10240 bytes Desc: not available URL: From roman.wueger at gmx.at Tue Jul 21 04:12:34 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 21 Jul 2015 10:12:34 +0200 Subject: [CMake] CTest threshold exceeds 1024 bytes Message-ID: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> Hello, when I run CTest from the command line with the same parameters as on the build server, then everything is working fine. If I run the command on the build server then I get a message which says that the threshold of 1024 bytes are exceeded. The output are "debug" messages and not failures. I have the output on CDash and on Jenkins. Here is the command which I call: "ctest -C Release --output-on-failure --no-compress-output -T test" Is there a way to get the full output without modifying every CMake Script of about ~ 35 projects? Thanks in advance Best Regards Roman From steven.wesley.wilson at gmail.com Tue Jul 21 08:19:42 2015 From: steven.wesley.wilson at gmail.com (Steven Wilson) Date: Tue, 21 Jul 2015 08:19:42 -0400 Subject: [CMake] OS X framework headers with capital letters Message-ID: I've noticed that CMake 3.3.0-rc3 will not install a header file in a Mac OS X framework if the header file starts with a capital letter (either that or has the same name as the framework). For example if I have the following: set(FOO_HEADER_FILES "foo.h;bar.h;bat.h;Foo.h;Foo.hpp") add_library(Foo SHARED ${FOO_SOURCE_FILES}) set_target_properties(Foo PROPERTIES FRAMEWORK ON OUTPUT_NAME Foo PUBLIC_HEADER "${FOO_HEADER_FILES}" ) install(TARGETS Foo FRAMEWORK DESTINATION "frameworks") Then when running 'make install' or the install target from Xcode, the installation step silently does not install Foo.h or Foo.hpp. This behavior seems arbitrary, wrong, and completely annoying. Comments? -------------- next part -------------- An HTML attachment was scrubbed... URL: From biddisco at cscs.ch Tue Jul 21 08:53:37 2015 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Tue, 21 Jul 2015 12:53:37 +0000 Subject: [CMake] find_package and lib/cmake/Foo Message-ID: <50320452A334BD42A5EC72BAD21450993C6F7CD9@MBX210.d.ethz.ch> I've asked this before, but never resolved it... if I stall package Foo into CMAKE_INSTALL_PREFIX=/my/path/prefix and generate /my/path/prefix/lib/cmake/Foo/FooConfig.cmake etc then with Foo_DIR=/my/path/prefix Foo_ROOT=/my/path/prefix find_package(Foo) does not find package Foo One needs to set Foo_DIR=/my/path/prefix/lib/cmake/Foo or Foo_ROOT=/my/path/prefix/lib/cmake/Foo but it specifically states in the documentation http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html "One place it looks is: /lib/cmake/Foo*/ where Foo* is a case-insensitive globbing expression" if I set(CMAKE_FIND_DEBUG_MODE 1) then I do not see it searching in my prefix with any extra /lib/cmake/ paths. Is the documentation wrong, or have I missed something? thanks JB -- John Biddiscombe, email:biddisco @.at.@ cscs.ch http://www.cscs.ch/ CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07 Via Trevano 131, 6900 Lugano, Switzerland | Fax: +41 (91) 610.82.82 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Tue Jul 21 09:30:38 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 21 Jul 2015 08:30:38 -0500 Subject: [CMake] Toolchain file for VS2013 + November CTP compiler toolset? In-Reply-To: References: Message-ID: On Fri, Jul 17, 2015 at 11:25 AM, Robert Dailey wrote: > Hello, > > How would I define a toolchain file for the Visual Studio 2013 > generator that also defines the toolset for that generator to be the > November CTP compiler? > > I'd rather use a toolchain for this than do -D definitions when I > invoke cmake to generate. > > Thanks in advance. Any thoughts on this? I'd actually rather specify the toolset within my root CMakeLists.txt script (since when generating our code, you *must* use the November CTP compiler when selecting the MSVC12 generator). However the documentation states it should not be set from within the CMake script. Ideas? The toolchain file is not necessary if it's valid to set the CMAKE_GENERATOR_TOOLSET variable within the CMakeLists.txt script (before or after the first project() call?) From biddisco at cscs.ch Tue Jul 21 09:43:10 2015 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Tue, 21 Jul 2015 13:43:10 +0000 Subject: [CMake] find_package and lib/cmake/Foo In-Reply-To: <50320452A334BD42A5EC72BAD21450993C6F7CD9@MBX210.d.ethz.ch> References: <50320452A334BD42A5EC72BAD21450993C6F7CD9@MBX210.d.ethz.ch> Message-ID: <50320452A334BD42A5EC72BAD21450993C6F7D84@MBX210.d.ethz.ch> Just to follow up my own question. I have found the answer export Foo_DIR=/my/path/prefix followed by cmake ... will correctly locate the package unfortunately, cmake -DFoo_DIR=/my/path/prefix will not. Is there a reason why the cmake variable is not searched, whereas the env var is? thanks JB From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Biddiscombe, John A. Sent: 21 July 2015 14:54 To: cmake at cmake.org Subject: [CMake] find_package and lib/cmake/Foo I've asked this before, but never resolved it... if I stall package Foo into CMAKE_INSTALL_PREFIX=/my/path/prefix and generate /my/path/prefix/lib/cmake/Foo/FooConfig.cmake etc then with Foo_DIR=/my/path/prefix Foo_ROOT=/my/path/prefix find_package(Foo) does not find package Foo One needs to set Foo_DIR=/my/path/prefix/lib/cmake/Foo or Foo_ROOT=/my/path/prefix/lib/cmake/Foo but it specifically states in the documentation http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html "One place it looks is: /lib/cmake/Foo*/ where Foo* is a case-insensitive globbing expression" if I set(CMAKE_FIND_DEBUG_MODE 1) then I do not see it searching in my prefix with any extra /lib/cmake/ paths. Is the documentation wrong, or have I missed something? thanks JB -- John Biddiscombe, email:biddisco @.at.@ cscs.ch http://www.cscs.ch/ CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07 Via Trevano 131, 6900 Lugano, Switzerland | Fax: +41 (91) 610.82.82 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Jul 21 09:53:07 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jul 2015 09:53:07 -0400 Subject: [CMake] CTest threshold exceeds 1024 bytes In-Reply-To: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> Message-ID: <55AE4EC3.8050607@kitware.com> On 07/21/2015 04:12 AM, Roman W?ger wrote: > Is there a way to get the full output without modifying every > CMake Script of about ~ 35 projects? CTest always truncates the output of passing tests unless the test output contains the literal text "CTEST_FULL_OUTPUT". This was done long ago to limit the size of submissions of passed tests. CTest will have to be taught an option to skip this. Take a look at the definition and uses of CleanTestOutput in Source/CTest. There are already variables like CustomMaximumPassedTestOutputSize internally but it looks like there is no way to configure them at runtime. -Brad From dank at kegel.com Tue Jul 21 10:35:34 2015 From: dank at kegel.com (Dan Kegel) Date: Tue, 21 Jul 2015 07:35:34 -0700 Subject: [CMake] OS X framework headers with capital letters In-Reply-To: References: Message-ID: It can't installiert both foo.h and Foo.h in the mac, better correct your example. Am 21.07.2015 5:19 vorm. schrieb "Steven Wilson" < steven.wesley.wilson at gmail.com>: > I've noticed that CMake 3.3.0-rc3 will not install a header file in a Mac > OS X framework if the header file starts with a capital letter (either that > or has the same name as the framework). > > For example if I have the following: > > > set(FOO_HEADER_FILES "foo.h;bar.h;bat.h;Foo.h;Foo.hpp") > > add_library(Foo SHARED ${FOO_SOURCE_FILES}) > > set_target_properties(Foo PROPERTIES > FRAMEWORK ON > OUTPUT_NAME Foo > PUBLIC_HEADER "${FOO_HEADER_FILES}" > ) > > install(TARGETS Foo > FRAMEWORK DESTINATION "frameworks") > > > Then when running 'make install' or the install target from Xcode, the > installation step silently does not install Foo.h or Foo.hpp. > > This behavior seems arbitrary, wrong, and completely annoying. > > Comments? > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Jul 21 10:38:16 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 21 Jul 2015 10:38:16 -0400 Subject: [CMake] find_package and lib/cmake/Foo In-Reply-To: <50320452A334BD42A5EC72BAD21450993C6F7D84@MBX210.d.ethz.ch> References: <50320452A334BD42A5EC72BAD21450993C6F7CD9@MBX210.d.ethz.ch> <50320452A334BD42A5EC72BAD21450993C6F7D84@MBX210.d.ethz.ch> Message-ID: Have you tried setting CMAKE_PREFIX_PATH (http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_PREFIX_PATH.html) as a -D option on the initial configure? On Tue, Jul 21, 2015 at 9:43 AM, Biddiscombe, John A. wrote: > Just to follow up my own question. I have found the answer > > export Foo_DIR=/my/path/prefix > > followed by cmake ... will correctly locate the package > > > > unfortunately, > > cmake -DFoo_DIR=/my/path/prefix > > will not. > > > > Is there a reason why the cmake variable is not searched, whereas the env > var is? > > > > thanks > > > > JB > > > > > > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Biddiscombe, John > A. > Sent: 21 July 2015 14:54 > To: cmake at cmake.org > Subject: [CMake] find_package and lib/cmake/Foo > > > > I?ve asked this before, but never resolved it... > > > > if I stall package Foo into > > CMAKE_INSTALL_PREFIX=/my/path/prefix > > and generate > > /my/path/prefix/lib/cmake/Foo/FooConfig.cmake > > etc > > > > then with > > Foo_DIR=/my/path/prefix > > Foo_ROOT=/my/path/prefix > > find_package(Foo) > > does not find package Foo > > > > One needs to set > > Foo_DIR=/my/path/prefix/lib/cmake/Foo > > or > > Foo_ROOT=/my/path/prefix/lib/cmake/Foo > > > > but it specifically states in the documentation > http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html ?One place > it looks is: /lib/cmake/Foo*/ where Foo* is a case-insensitive > globbing expression? > > > > if I > > set(CMAKE_FIND_DEBUG_MODE 1) > > then I do not see it searching in my prefix with any extra /lib/cmake/ > paths. > > > > Is the documentation wrong, or have I missed something? > > > > thanks > > > > JB > > > > > > -- > > John Biddiscombe, email:biddisco @.at.@ cscs.ch > > http://www.cscs.ch/ > > CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07 > > Via Trevano 131, 6900 Lugano, Switzerland | Fax: +41 (91) 610.82.82 > > > > > -- > > 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 mike.jackson at bluequartz.net Tue Jul 21 10:59:25 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 21 Jul 2015 10:59:25 -0400 Subject: [CMake] OS X framework headers with capital letters In-Reply-To: References: Message-ID: <3D0F8840-FF64-426D-BEEC-B9C47644C7B0@bluequartz.net> to be very precise, OS X is a "Case Preserving but NOT Case sensitive" be default. OS X can be made to be case sensitive but no one actually recommends it. this means that on OS X foo.h and Foo.h resolve to be the same file, where as on Linux they would be 2 different files. You would have the same issues on Windows. Mike Jackson On Jul 21, 2015, at 10:35 AM, Dan Kegel wrote: > It can't installiert both foo.h and Foo.h in the mac, better correct your example. > Am 21.07.2015 5:19 vorm. schrieb "Steven Wilson" : > I've noticed that CMake 3.3.0-rc3 will not install a header file in a Mac OS X framework if the header file starts with a capital letter (either that or has the same name as the framework). > > For example if I have the following: > > > set(FOO_HEADER_FILES "foo.h;bar.h;bat.h;Foo.h;Foo.hpp") > > add_library(Foo SHARED ${FOO_SOURCE_FILES}) > > set_target_properties(Foo PROPERTIES > FRAMEWORK ON > OUTPUT_NAME Foo > PUBLIC_HEADER "${FOO_HEADER_FILES}" > ) > > install(TARGETS Foo > FRAMEWORK DESTINATION "frameworks") > > > Then when running 'make install' or the install target from Xcode, the installation step silently does not install Foo.h or Foo.hpp. > > This behavior seems arbitrary, wrong, and completely annoying. > > Comments? > > -- > > 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 brad.king at kitware.com Tue Jul 21 11:07:19 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jul 2015 11:07:19 -0400 Subject: [CMake] Difference in CMake 2.8 / 3.1+ behaviour when looking at SOURCES property In-Reply-To: References: Message-ID: <55AE6027.4040208@kitware.com> On 07/20/2015 03:45 PM, Berteun Damman wrote: > Note that it displays the full path for foo.txt! With later CMake > versions (3.1 and up is my suspicion), it will display: > > build$ cmake .. > foo.cc > foo.txt > > I tried looking trough the release notes, and I've found that > add_library gained support for generator expressions in 3.1, but I > haven't found any explicit mention that would explain this behaviour. It was likely changed as part of the topics merged here: Merge topic 'target-transitive-sources' http://cmake.org/gitweb?p=cmake.git;a=commit;h=5376151a Merge topic 'target-sources-refactor' http://cmake.org/gitweb?p=cmake.git;a=commit;h=93054aa8 I've added the author to Cc. > Does anyone know why it changed? The full path to sources is now determined at generate time to accommodate generator expressions. Unfortunately this incompatibility was not noticed during development or the 6 weeks of 3.1 release candidates posted for testing. Now we've had 3 releases with the new behavior so trying to change it now will just become incompatible for projects expecting the current behavior. Technically the documentation in CMake 3.0 and below guaranteed only that the list returned is suitable for passing to set_source_files_properties, which it still is. > And secondly, is there a way to get the 2.8 behaviour back? Not currently, though you can compute the source file locations yourself if you know the source/build directories corresponding to the CMakeLists.txt where the target is defined. There is discussion recently about exposing more information for that here: Listing source-tree files encountered http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13676/focus=13734 > So the more general question is, is there a canonical way to get the > full path to a source file by looking at the SOURCES of a target? It is not possible to get this information at configure time because full paths are not determined until generate time (since 3.1). Of course if you list the .txt files in your add_library calls with ${CMAKE_CURRENT_SOURCE_DIR}/foo.txt then it will be a full path when collected back from SOURCES later. -Brad From steven.wesley.wilson at gmail.com Tue Jul 21 12:15:39 2015 From: steven.wesley.wilson at gmail.com (Steven Wilson) Date: Tue, 21 Jul 2015 12:15:39 -0400 Subject: [CMake] OS X framework headers with capital letters In-Reply-To: <3D0F8840-FF64-426D-BEEC-B9C47644C7B0@bluequartz.net> References: <3D0F8840-FF64-426D-BEEC-B9C47644C7B0@bluequartz.net> Message-ID: Not to be picky, but the issue of case sensitivity ignores the original question. If it helps someone think about the issue better, change: set(FOO_HEADER_FILES "foo.h;bar.h;bat.h;Foo.h;Foo.hpp") to set(FOO_HEADER_FILES "bar.h;bat.h;Foo.h;Foo.hpp") Thanks, Steve On Tue, Jul 21, 2015 at 10:59 AM, Michael Jackson < mike.jackson at bluequartz.net> wrote: > to be very precise, > OS X is a "Case Preserving but NOT Case sensitive" be default. OS X > can be made to be case sensitive but no one actually recommends it. > > this means that on OS X foo.h and Foo.h resolve to be the same file, where > as on Linux they would be 2 different files. You would have the same issues > on Windows. > > Mike Jackson > > > On Jul 21, 2015, at 10:35 AM, Dan Kegel wrote: > > It can't installiert both foo.h and Foo.h in the mac, better correct your > example. > Am 21.07.2015 5:19 vorm. schrieb "Steven Wilson" < > steven.wesley.wilson at gmail.com>: > >> I've noticed that CMake 3.3.0-rc3 will not install a header file in a Mac >> OS X framework if the header file starts with a capital letter (either that >> or has the same name as the framework). >> >> For example if I have the following: >> >> >> set(FOO_HEADER_FILES "foo.h;bar.h;bat.h;Foo.h;Foo.hpp") >> >> add_library(Foo SHARED ${FOO_SOURCE_FILES}) >> >> set_target_properties(Foo PROPERTIES >> FRAMEWORK ON >> OUTPUT_NAME Foo >> PUBLIC_HEADER "${FOO_HEADER_FILES}" >> ) >> >> install(TARGETS Foo >> FRAMEWORK DESTINATION "frameworks") >> >> >> Then when running 'make install' or the install target from Xcode, the >> installation step silently does not install Foo.h or Foo.hpp. >> >> This behavior seems arbitrary, wrong, and completely annoying. >> >> Comments? >> >> -- >> >> 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 mike.jackson at bluequartz.net Tue Jul 21 12:49:00 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 21 Jul 2015 12:49:00 -0400 Subject: [CMake] OS X framework headers with capital letters In-Reply-To: References: Message-ID: Well the definitely removes the case sensitivity issue. Do you have a compact example that shows the failure? I took a look in our project and we don't have any cases like this. I would find it a very odd and subtle bug it this really were an issue. one of those edge cases that just did not get tested. Mike Jackson On Jul 21, 2015, at 8:19 AM, Steven Wilson wrote: > I've noticed that CMake 3.3.0-rc3 will not install a header file in a Mac OS X framework if the header file starts with a capital letter (either that or has the same name as the framework). > > For example if I have the following: > > > set(FOO_HEADER_FILES "foo.h;bar.h;bat.h;Foo.h;Foo.hpp") > > add_library(Foo SHARED ${FOO_SOURCE_FILES}) > > set_target_properties(Foo PROPERTIES > FRAMEWORK ON > OUTPUT_NAME Foo > PUBLIC_HEADER "${FOO_HEADER_FILES}" > ) > > install(TARGETS Foo > FRAMEWORK DESTINATION "frameworks") > > > Then when running 'make install' or the install target from Xcode, the installation step silently does not install Foo.h or Foo.hpp. > > This behavior seems arbitrary, wrong, and completely annoying. > > Comments? > -- > > 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 DLRdave at aol.com Tue Jul 21 12:51:22 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 21 Jul 2015 12:51:22 -0400 Subject: [CMake] OS X framework headers with capital letters In-Reply-To: References: <3D0F8840-FF64-426D-BEEC-B9C47644C7B0@bluequartz.net> Message-ID: Are you saying the file does not exist in the installed framework, or that you do not see "copying Foo.h" in the install output ...? This seems very unlikely. The header files are supposed to be in the framework in the build tree, and the built framework in its entirety is supposed to be recursively copied at install time ... Are you running on a Mac volume with a case sensitive file system or not? Are the source header files in question named with the case you've listed in the CMakeLists file? Does this reproduce if you add another header file named "AnotherHeader.h" and add it into the mix, say listing it first in the list of header files? On Tue, Jul 21, 2015 at 12:15 PM, Steven Wilson wrote: > Not to be picky, but the issue of case sensitivity ignores the original > question. > > If it helps someone think about the issue better, change: > > set(FOO_HEADER_FILES "foo.h;bar.h;bat.h;Foo.h;Foo.hpp") > > to > > set(FOO_HEADER_FILES "bar.h;bat.h;Foo.h;Foo.hpp") > > > Thanks, > > Steve > > On Tue, Jul 21, 2015 at 10:59 AM, Michael Jackson > wrote: >> >> to be very precise, >> OS X is a "Case Preserving but NOT Case sensitive" be default. OS X >> can be made to be case sensitive but no one actually recommends it. >> >> this means that on OS X foo.h and Foo.h resolve to be the same file, where >> as on Linux they would be 2 different files. You would have the same issues >> on Windows. >> >> Mike Jackson >> >> >> On Jul 21, 2015, at 10:35 AM, Dan Kegel wrote: >> >> It can't installiert both foo.h and Foo.h in the mac, better correct your >> example. >> >> Am 21.07.2015 5:19 vorm. schrieb "Steven Wilson" >> : >>> >>> I've noticed that CMake 3.3.0-rc3 will not install a header file in a Mac >>> OS X framework if the header file starts with a capital letter (either that >>> or has the same name as the framework). >>> >>> For example if I have the following: >>> >>> >>> set(FOO_HEADER_FILES "foo.h;bar.h;bat.h;Foo.h;Foo.hpp") >>> >>> add_library(Foo SHARED ${FOO_SOURCE_FILES}) >>> >>> set_target_properties(Foo PROPERTIES >>> FRAMEWORK ON >>> OUTPUT_NAME Foo >>> PUBLIC_HEADER "${FOO_HEADER_FILES}" >>> ) >>> >>> install(TARGETS Foo >>> FRAMEWORK DESTINATION "frameworks") >>> >>> >>> Then when running 'make install' or the install target from Xcode, the >>> installation step silently does not install Foo.h or Foo.hpp. >>> >>> This behavior seems arbitrary, wrong, and completely annoying. >>> >>> Comments? >>> >>> -- >>> >>> 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 >> >> > > > -- > > 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 Tue Jul 21 13:06:52 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jul 2015 13:06:52 -0400 Subject: [CMake] Fortran build dependency on Windows In-Reply-To: <10512773.0BPFRloMbh@byrn.ad.hdfgroup.org> References: <10512773.0BPFRloMbh@byrn.ad.hdfgroup.org> Message-ID: <55AE7C2C.1040602@kitware.com> On 07/20/2015 05:10 PM, Allen Byrne wrote: > We use the OBJECT_DEPENDS property as follows; > > Environment: Windows 7, Visual Studio 2012, Intel Fortran 15, and CMake 3.1 It looks like OBJECT_DEPENDS is not fully implemented for VS >= 10. I'll look at fixing that. Meanwhile you can work around the problem by moving generation of the source file to a custom target and then use add_dependencies to make sure that is built before the target that compiles the source. -Brad From micha.hergarden at gmail.com Tue Jul 21 13:11:36 2015 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Tue, 21 Jul 2015 19:11:36 +0200 Subject: [CMake] grep at build time? In-Reply-To: References: Message-ID: <55AE7D48.3030601@gmail.com> On 07/18/2015 08:17 AM, Alexandre GOUAILLARD wrote: > dear all, > > I'm trying to use cmake as a super build script for another library > build system. > > Using add_custom_command and add_custom_target I have managed to > handle most of the steps so far. My libraries and executable are being > built as requested across platform. > > Now I'm trying to import the generated tests. Some of the generated > executables during the build step are self-contained tests that I > would like to run using ctest and send to a dashboard. So far I have > hardcoded the revision of the code i'm fetching, and the corresponding > list of tests. However those tests change pretty often, and I would > like to have something more flexible there. > > How could I grep the list of tests (knowing that they all end up with > ".isolated" a grep would do), and loop through the resulting list > "add_test"ing them one by one AT CMAKE BUILD TIME, after a previous > target has been built? > > I googled around, tried a few things, but couldn't figure out a way to > make it happen. > > thanks in advance for all advice. > > Alex. > > -- > Alex. Gouaillard, PhD, PhD, MBA > ------------------------------------------------------------------------------------ > CTO - Temasys Communications, S'pore / Mountain View > President - CoSMo Software, Cambridge, MA > ------------------------------------------------------------------------------------ > sg.linkedin.com/agouaillard > > * > > > > Hello Alex, Do you mean grepping or globbing? Both can be done at configuration time using the FILE command. You could perform a file(glob) followed by a file(strings) in a loop. I'm not sure what you mean by cmake build time. Cmake will generate a buildsystem (configuration time) and the buildsystem will do the actual building (build time). Regards, Micha -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From micha.hergarden at gmail.com Tue Jul 21 13:14:46 2015 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Tue, 21 Jul 2015 19:14:46 +0200 Subject: [CMake] Possible to dynamically construct macro/function names to invoke? In-Reply-To: References: Message-ID: <55AE7E06.8080908@gmail.com> On 07/20/2015 12:52 AM, Eric Wing wrote: > I would like to dynamically construct a macro or function name to > invoke. I basically have a core CMake system I want users to be able > to extend/plug stuff into without knowing about a lot of the core > CMake implementation. Callback functions would be an easy way for me > to accomplish this. > > As an example, > > # In my core code, I have a macro designed to callback other macros > macro(DO_PACKAGE _TARGET_NAME) > foreach(callback ${DO_PACKAGE_CALLBACK_LIST}) > DO_PACKAGE_FOR_${callback}(${_TARGET_NAME}) > endforeach() > endmacro(BLURRR_PACKAGE_EXTRAS) > > > ### Also in my core code, I pick an appropriate time to trigger my > macro to call user callbacks > DERIVE_SOME_NAME() > ADD_EXECUTABLE(${SOME_NAME} ...) > DO_PACKAGE(${SOME_NAME}) > > > > # So in user modules provided by others, they follow a convention where > # they define a macro DO_PACKAGE_ appended by their module name. > macro(DO_PACKAGE_FOR_MYMODULE _TARGET_NAME) > MESSAGE("in mymod callback") > # do stuff > endmacro() > > # And I make them add their module name to a global list so I can call > it back at the right time > list(APPEND DO_PACKAGE_CALLBACK_LIST "MYMODULE") > > > So in my attempts to do this, I'm getting errors like: > Parse error. Expected a command name, got unquoted argument with text > > Is there way to do this (or something similar)? > > Thanks, > Eric I don't think this functionality is supported (although I haven't checked if it is possible to redefine a function in cmake). Perhaps you could create a system where you import a cmake module supplied by the external developers if it exists? If you can define an interface you could check if the functions exist in the module? Regards, Micha -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From dank at kegel.com Tue Jul 21 13:26:40 2015 From: dank at kegel.com (Dan Kegel) Date: Tue, 21 Jul 2015 10:26:40 -0700 Subject: [CMake] Option to halt on first error? Message-ID: A user was confused just now by cmake continuing to output lots and lots of stuff after an error. How can we convince cmake to stop immediately upon first error? The error in this case was CMake Error at CMakeLists.txt:690 (add_executable): add_executable cannot create target "ImageClotTest" because another target with the same name already exists. The existing target is an executable created in source directory "/Users/buildbot/slave-state/osx107/g-speak-rbb-osx107-1/yovo-osx107-iz/build/libBasement/tests". See documentation for policy CMP0002 for more details. Call Stack (most recent call first): libMedia/tests/CMakeLists.txt:15 (generate_tests) Something like SET(CMAKE_ALL_ERRORS_FATAL TRUE) that caused cmake to immediately stop processing after outputting an error would be great. Presumably it exists, but I haven't found it yet...? From steven.wesley.wilson at gmail.com Tue Jul 21 13:39:51 2015 From: steven.wesley.wilson at gmail.com (Steven Wilson) Date: Tue, 21 Jul 2015 13:39:51 -0400 Subject: [CMake] OS X framework headers with capital letters In-Reply-To: References: <3D0F8840-FF64-426D-BEEC-B9C47644C7B0@bluequartz.net> Message-ID: I am saying the file does not exist in the either installed framework or in the framework in the build directory. CMake is not moving the header files that start with a capital letter into the framework headers directory. Now I did double check and it *is* moving the .hpp header that matches the name of the framework (Foo.hpp in the example case), but it is not copying Foo.h. In addition I tried adding two more arbitrary headers called AnotherHeader.h and AnotherHeader.hpp and neither of those get included in the framework either. The example I have posted is just an example. My actual source files do not share names where case sensitivity is a problem. The file names in the real project do not collide in any form. I am running on a a Mac with the HFS+ system without case sensitivity. On Tue, Jul 21, 2015 at 12:51 PM, David Cole wrote: > Are you saying the file does not exist in the installed framework, or > that you do not see "copying Foo.h" in the install output ...? This > seems very unlikely. The header files are supposed to be in the > framework in the build tree, and the built framework in its entirety > is supposed to be recursively copied at install time ... > > Are you running on a Mac volume with a case sensitive file system or not? > > Are the source header files in question named with the case you've > listed in the CMakeLists file? > > Does this reproduce if you add another header file named > "AnotherHeader.h" and add it into the mix, say listing it first in the > list of header files? > > > > > > On Tue, Jul 21, 2015 at 12:15 PM, Steven Wilson > wrote: > > Not to be picky, but the issue of case sensitivity ignores the original > > question. > > > > If it helps someone think about the issue better, change: > > > > set(FOO_HEADER_FILES "foo.h;bar.h;bat.h;Foo.h;Foo.hpp") > > > > to > > > > set(FOO_HEADER_FILES "bar.h;bat.h;Foo.h;Foo.hpp") > > > > > > Thanks, > > > > Steve > > > > On Tue, Jul 21, 2015 at 10:59 AM, Michael Jackson > > wrote: > >> > >> to be very precise, > >> OS X is a "Case Preserving but NOT Case sensitive" be default. OS X > >> can be made to be case sensitive but no one actually recommends it. > >> > >> this means that on OS X foo.h and Foo.h resolve to be the same file, > where > >> as on Linux they would be 2 different files. You would have the same > issues > >> on Windows. > >> > >> Mike Jackson > >> > >> > >> On Jul 21, 2015, at 10:35 AM, Dan Kegel wrote: > >> > >> It can't installiert both foo.h and Foo.h in the mac, better correct > your > >> example. > >> > >> Am 21.07.2015 5:19 vorm. schrieb "Steven Wilson" > >> : > >>> > >>> I've noticed that CMake 3.3.0-rc3 will not install a header file in a > Mac > >>> OS X framework if the header file starts with a capital letter (either > that > >>> or has the same name as the framework). > >>> > >>> For example if I have the following: > >>> > >>> > >>> set(FOO_HEADER_FILES "foo.h;bar.h;bat.h;Foo.h;Foo.hpp") > >>> > >>> add_library(Foo SHARED ${FOO_SOURCE_FILES}) > >>> > >>> set_target_properties(Foo PROPERTIES > >>> FRAMEWORK ON > >>> OUTPUT_NAME Foo > >>> PUBLIC_HEADER "${FOO_HEADER_FILES}" > >>> ) > >>> > >>> install(TARGETS Foo > >>> FRAMEWORK DESTINATION "frameworks") > >>> > >>> > >>> Then when running 'make install' or the install target from Xcode, the > >>> installation step silently does not install Foo.h or Foo.hpp. > >>> > >>> This behavior seems arbitrary, wrong, and completely annoying. > >>> > >>> Comments? > >>> > >>> -- > >>> > >>> 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 > >> > >> > > > > > > -- > > > > 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 brad.king at kitware.com Tue Jul 21 16:17:39 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Jul 2015 16:17:39 -0400 Subject: [CMake] Fortran build dependency on Windows In-Reply-To: <55AE7C2C.1040602@kitware.com> References: <10512773.0BPFRloMbh@byrn.ad.hdfgroup.org> <55AE7C2C.1040602@kitware.com> Message-ID: <55AEA8E3.30206@kitware.com> On 07/21/2015 01:06 PM, Brad King wrote: > It looks like OBJECT_DEPENDS is not fully implemented for VS >= 10. > I'll look at fixing that. It turns out that is because .vcxproj files do not support it. The ClCompile task is documented here: https://msdn.microsoft.com/en-us/library/ee862477.aspx and it does not support an AdditionalInputs field. The documentation of OBJECT_DEPENDS will have to be updated accordingly. > Meanwhile you can work around the problem by moving generation of > the source file to a custom target and then use add_dependencies to > make sure that is built before the target that compiles the source. Please let me know if this works for you or if you find another workaround. Thanks, -Brad From DLRdave at aol.com Tue Jul 21 16:30:45 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 21 Jul 2015 16:30:45 -0400 Subject: [CMake] OS X framework headers with capital letters In-Reply-To: References: <3D0F8840-FF64-426D-BEEC-B9C47644C7B0@bluequartz.net> Message-ID: Try putting ${FOO_HEADER_FILES} in the add_library call, too. I reproduced this by adding a file, with **ANY** name, to the PUBLIC_HEADER list of the [CMake/Tests/Framework/CMakeLists.txt](https://github.com/Kitware/CMake/blob/master/Tests/Framework/CMakeLists.txt) file... but NOT adding it to the list of sources given to add_library. It would appear from this experiment that the header files for a framework must be listed as sources of the library **and** added to the PUBLIC_HEADER target property. (I am guessing that you have the other header files that are working already in your FOO_SOURCE_FILES variable. Either that, or I'm missing something still...) HTH, David C. On Tue, Jul 21, 2015 at 1:39 PM, Steven Wilson wrote: > I am saying the file does not exist in the either installed framework or in > the framework in the build directory. CMake is not moving the header files > that start with a capital letter into the framework headers directory. Now > I did double check and it *is* moving the .hpp header that matches the name > of the framework (Foo.hpp in the example case), but it is not copying Foo.h. > In addition I tried adding two more arbitrary headers called AnotherHeader.h > and AnotherHeader.hpp and neither of those get included in the framework > either. > > The example I have posted is just an example. My actual source files do not > share names where case sensitivity is a problem. The file names in the > real project do not collide in any form. I am running on a a Mac with the > HFS+ system without case sensitivity. > > > > On Tue, Jul 21, 2015 at 12:51 PM, David Cole wrote: >> >> Are you saying the file does not exist in the installed framework, or >> that you do not see "copying Foo.h" in the install output ...? This >> seems very unlikely. The header files are supposed to be in the >> framework in the build tree, and the built framework in its entirety >> is supposed to be recursively copied at install time ... >> >> Are you running on a Mac volume with a case sensitive file system or not? >> >> Are the source header files in question named with the case you've >> listed in the CMakeLists file? >> >> Does this reproduce if you add another header file named >> "AnotherHeader.h" and add it into the mix, say listing it first in the >> list of header files? >> >> >> >> >> >> On Tue, Jul 21, 2015 at 12:15 PM, Steven Wilson >> wrote: >> > Not to be picky, but the issue of case sensitivity ignores the original >> > question. >> > >> > If it helps someone think about the issue better, change: >> > >> > set(FOO_HEADER_FILES "foo.h;bar.h;bat.h;Foo.h;Foo.hpp") >> > >> > to >> > >> > set(FOO_HEADER_FILES "bar.h;bat.h;Foo.h;Foo.hpp") >> > >> > >> > Thanks, >> > >> > Steve >> > >> > On Tue, Jul 21, 2015 at 10:59 AM, Michael Jackson >> > wrote: >> >> >> >> to be very precise, >> >> OS X is a "Case Preserving but NOT Case sensitive" be default. OS X >> >> can be made to be case sensitive but no one actually recommends it. >> >> >> >> this means that on OS X foo.h and Foo.h resolve to be the same file, >> >> where >> >> as on Linux they would be 2 different files. You would have the same >> >> issues >> >> on Windows. >> >> >> >> Mike Jackson >> >> >> >> >> >> On Jul 21, 2015, at 10:35 AM, Dan Kegel wrote: >> >> >> >> It can't installiert both foo.h and Foo.h in the mac, better correct >> >> your >> >> example. >> >> >> >> Am 21.07.2015 5:19 vorm. schrieb "Steven Wilson" >> >> : >> >>> >> >>> I've noticed that CMake 3.3.0-rc3 will not install a header file in a >> >>> Mac >> >>> OS X framework if the header file starts with a capital letter (either >> >>> that >> >>> or has the same name as the framework). >> >>> >> >>> For example if I have the following: >> >>> >> >>> >> >>> set(FOO_HEADER_FILES "foo.h;bar.h;bat.h;Foo.h;Foo.hpp") >> >>> >> >>> add_library(Foo SHARED ${FOO_SOURCE_FILES}) >> >>> >> >>> set_target_properties(Foo PROPERTIES >> >>> FRAMEWORK ON >> >>> OUTPUT_NAME Foo >> >>> PUBLIC_HEADER "${FOO_HEADER_FILES}" >> >>> ) >> >>> >> >>> install(TARGETS Foo >> >>> FRAMEWORK DESTINATION "frameworks") >> >>> >> >>> >> >>> Then when running 'make install' or the install target from Xcode, the >> >>> installation step silently does not install Foo.h or Foo.hpp. >> >>> >> >>> This behavior seems arbitrary, wrong, and completely annoying. >> >>> >> >>> Comments? >> >>> >> >>> -- >> >>> >> >>> 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 >> >> >> >> >> > >> > >> > -- >> > >> > 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 steven.wesley.wilson at gmail.com Tue Jul 21 16:59:25 2015 From: steven.wesley.wilson at gmail.com (Steven Wilson) Date: Tue, 21 Jul 2015 16:59:25 -0400 Subject: [CMake] OS X framework headers with capital letters In-Reply-To: References: <3D0F8840-FF64-426D-BEEC-B9C47644C7B0@bluequartz.net> Message-ID: Thanks David, That change appears to have corrected the issue. Steve On Tue, Jul 21, 2015 at 4:30 PM, David Cole wrote: > Try putting ${FOO_HEADER_FILES} in the add_library call, too. > > I reproduced this by adding a file, with **ANY** name, to the > PUBLIC_HEADER list of the > [CMake/Tests/Framework/CMakeLists.txt]( > https://github.com/Kitware/CMake/blob/master/Tests/Framework/CMakeLists.txt > ) > file... but NOT adding it to the list of sources given to add_library. > > It would appear from this experiment that the header files for a > framework must be listed as sources of the library **and** added to > the PUBLIC_HEADER target property. > > (I am guessing that you have the other header files that are working > already in your FOO_SOURCE_FILES variable. Either that, or I'm missing > something still...) > > > HTH, > David C. > > > > On Tue, Jul 21, 2015 at 1:39 PM, Steven Wilson > wrote: > > I am saying the file does not exist in the either installed framework or > in > > the framework in the build directory. CMake is not moving the header > files > > that start with a capital letter into the framework headers directory. > Now > > I did double check and it *is* moving the .hpp header that matches the > name > > of the framework (Foo.hpp in the example case), but it is not copying > Foo.h. > > In addition I tried adding two more arbitrary headers called > AnotherHeader.h > > and AnotherHeader.hpp and neither of those get included in the framework > > either. > > > > The example I have posted is just an example. My actual source files do > not > > share names where case sensitivity is a problem. The file names in the > > real project do not collide in any form. I am running on a a Mac with > the > > HFS+ system without case sensitivity. > > > > > > > > On Tue, Jul 21, 2015 at 12:51 PM, David Cole wrote: > >> > >> Are you saying the file does not exist in the installed framework, or > >> that you do not see "copying Foo.h" in the install output ...? This > >> seems very unlikely. The header files are supposed to be in the > >> framework in the build tree, and the built framework in its entirety > >> is supposed to be recursively copied at install time ... > >> > >> Are you running on a Mac volume with a case sensitive file system or > not? > >> > >> Are the source header files in question named with the case you've > >> listed in the CMakeLists file? > >> > >> Does this reproduce if you add another header file named > >> "AnotherHeader.h" and add it into the mix, say listing it first in the > >> list of header files? > >> > >> > >> > >> > >> > >> On Tue, Jul 21, 2015 at 12:15 PM, Steven Wilson > >> wrote: > >> > Not to be picky, but the issue of case sensitivity ignores the > original > >> > question. > >> > > >> > If it helps someone think about the issue better, change: > >> > > >> > set(FOO_HEADER_FILES "foo.h;bar.h;bat.h;Foo.h;Foo.hpp") > >> > > >> > to > >> > > >> > set(FOO_HEADER_FILES "bar.h;bat.h;Foo.h;Foo.hpp") > >> > > >> > > >> > Thanks, > >> > > >> > Steve > >> > > >> > On Tue, Jul 21, 2015 at 10:59 AM, Michael Jackson > >> > wrote: > >> >> > >> >> to be very precise, > >> >> OS X is a "Case Preserving but NOT Case sensitive" be default. > OS X > >> >> can be made to be case sensitive but no one actually recommends it. > >> >> > >> >> this means that on OS X foo.h and Foo.h resolve to be the same file, > >> >> where > >> >> as on Linux they would be 2 different files. You would have the same > >> >> issues > >> >> on Windows. > >> >> > >> >> Mike Jackson > >> >> > >> >> > >> >> On Jul 21, 2015, at 10:35 AM, Dan Kegel wrote: > >> >> > >> >> It can't installiert both foo.h and Foo.h in the mac, better correct > >> >> your > >> >> example. > >> >> > >> >> Am 21.07.2015 5:19 vorm. schrieb "Steven Wilson" > >> >> : > >> >>> > >> >>> I've noticed that CMake 3.3.0-rc3 will not install a header file in > a > >> >>> Mac > >> >>> OS X framework if the header file starts with a capital letter > (either > >> >>> that > >> >>> or has the same name as the framework). > >> >>> > >> >>> For example if I have the following: > >> >>> > >> >>> > >> >>> set(FOO_HEADER_FILES "foo.h;bar.h;bat.h;Foo.h;Foo.hpp") > >> >>> > >> >>> add_library(Foo SHARED ${FOO_SOURCE_FILES}) > >> >>> > >> >>> set_target_properties(Foo PROPERTIES > >> >>> FRAMEWORK ON > >> >>> OUTPUT_NAME Foo > >> >>> PUBLIC_HEADER "${FOO_HEADER_FILES}" > >> >>> ) > >> >>> > >> >>> install(TARGETS Foo > >> >>> FRAMEWORK DESTINATION "frameworks") > >> >>> > >> >>> > >> >>> Then when running 'make install' or the install target from Xcode, > the > >> >>> installation step silently does not install Foo.h or Foo.hpp. > >> >>> > >> >>> This behavior seems arbitrary, wrong, and completely annoying. > >> >>> > >> >>> Comments? > >> >>> > >> >>> -- > >> >>> > >> >>> 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 > >> >> > >> >> > >> > > >> > > >> > -- > >> > > >> > 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 byrn at hdfgroup.org Tue Jul 21 17:03:11 2015 From: byrn at hdfgroup.org (Allen Byrne) Date: Tue, 21 Jul 2015 16:03:11 -0500 Subject: [CMake] Fortran build dependency on Windows In-Reply-To: <55AEA8E3.30206@kitware.com> References: <10512773.0BPFRloMbh@byrn.ad.hdfgroup.org> <55AE7C2C.1040602@kitware.com> <55AEA8E3.30206@kitware.com> Message-ID: <2555903.ghTdlc3SNv@byrn.ad.hdfgroup.org> Initial test seems to work, Will wait for the Nightly tests to verify that using custom target works. Allen On Tuesday, July 21, 2015 04:17:39 PM Brad King wrote: > On 07/21/2015 01:06 PM, Brad King wrote: > > It looks like OBJECT_DEPENDS is not fully implemented for VS >= 10. > > I'll look at fixing that. > > It turns out that is because .vcxproj files do not support it. > The ClCompile task is documented here: > > https://msdn.microsoft.com/en-us/library/ee862477.aspx > > and it does not support an AdditionalInputs field. The documentation > of OBJECT_DEPENDS will have to be updated accordingly. > > > Meanwhile you can work around the problem by moving generation of > > the source file to a custom target and then use add_dependencies to > > make sure that is built before the target that compiles the source. > > Please let me know if this works for you or if you find another > workaround. > > Thanks, > -Brad From roman.wueger at gmx.at Tue Jul 21 18:16:37 2015 From: roman.wueger at gmx.at (=?iso-8859-1?Q?Roman_W=FCger?=) Date: Wed, 22 Jul 2015 00:16:37 +0200 Subject: [CMake] CTest threshold exceeds 1024 bytes In-Reply-To: <55AE4EC3.8050607@kitware.com> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> Message-ID: <015401d0c402$ea609040$bf21b0c0$@gmx.at> Hi Brad, I've attached a patch which learns CTest to handle it. I hope this patch could be merged. Best Regards Roman > -----Urspr?ngliche Nachricht----- > Von: Brad King [mailto:brad.king at kitware.com] > Gesendet: Dienstag, 21. Juli 2015 15:53 > An: Roman W?ger > Cc: CMake Developer MailingList; CMake MailingList > Betreff: Re: [CMake] CTest threshold exceeds 1024 bytes > > On 07/21/2015 04:12 AM, Roman W?ger wrote: > > Is there a way to get the full output without modifying every CMake > > Script of about ~ 35 projects? > > CTest always truncates the output of passing tests unless the test output > contains the literal text "CTEST_FULL_OUTPUT". > This was done long ago to limit the size of submissions of passed tests. > > CTest will have to be taught an option to skip this. Take a look at the > definition and uses of CleanTestOutput in Source/CTest. > There are already variables like CustomMaximumPassedTestOutputSize > internally but it looks like there is no way to configure them at runtime. > > -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CTest-learned-to-limit-the-output-of-passed-and-fail.patch Type: application/octet-stream Size: 2949 bytes Desc: not available URL: From jiandingzhe at 163.com Wed Jul 22 07:22:32 2015 From: jiandingzhe at 163.com (Xi Yang) Date: Wed, 22 Jul 2015 19:22:32 +0800 (CST) Subject: [CMake] config-specific compiler definitions don't work properly In-Reply-To: References: <718a0b2e.1229a.14e9c21a2b5.Coremail.jiandingzhe@163.com> Message-ID: <5e4a0250.27096.14eb5802b3e.Coremail.jiandingzhe@163.com> Hi: It solved the compiler definitions. However, when I come to work with library, it came with further errors. In my project, we have an extra configuration named GraphicDebug. I want to have my project to use different library files which are compiled using different options. Firstly I tried this: add_library(foo_lib_use STATIC IMPORTED) set_property(TARGET foo_lib_use PROPERTY IMPORTED_LOCATION_GRAPHICDEBUG libfoo_gdbg.a ) It failed to set foo_lib_use: Demo/Demo: juze_lib_use-NOTFOUND I guessed the XXX_ don't work for customized configs, then I tried $<$<>> way: add_library(foo_lib_use STATIC IMPORTED) set_property(TARGET foo_lib_use PROPERTY IMPORTED_LOCATION $<$: libfoo_dbg.a> $<$: libfoo_gdbg.a> $<$: libfoo_rel.a> $<$: libfoo_reldbg.a> ) However, the foo_lib_use is not properly set according to configuration, it was instead set to the whole string with all $<$<>> stuffs. This is the line in generated build.make: Demo/Demo: $<$:;/home/yangxi/software/JUZE/lib/libjuce_dbg.a>;$<$:;/home/yangxi/software/JUZE/lib/libjuce_gdbg.a>;$<$:;/home/yangxi/software/JUZE/lib/libjuce_rel.a>;$<$:/home/yangxi/software/JUZE/lib/libjuce_reldbg.a> So, how can I properly set the library according to configuration? Thanks! ? 2015-07-17 21:42:50?"Petr Kmoch" ??? Hi. Looking at the documentation ( http://www.cmake.org/cmake/help/v3.3/manual/cmake-properties.7.html#properties-on-directories , http://www.cmake.org/cmake/help/v3.3/manual/cmake-properties.7.html#properties-on-targets ), you will find that neither the directory property nor the target property COMPILE_DEFINITIONS has per-configuration variants. They do support generator expressions, however, so you could use these instead: set_property(DIRECTORY PROPERTY COMPILE_DEFINITIONS $<$:FOO> $<$:BAR>) Petr On Fri, Jul 17, 2015 at 3:08 PM, Xi Yang wrote: Hi everyone! I'm trying to use config-specific definitions, but it seems doesn't work in VS2013. This is the CMakeLists.txt: cmake_minimum_required(VERSION 3.0) set_property(DIRECTORY PROPERTY COMPILE_DEFINITIONS_DEBUG FOO ) set_property(DIRECTORY PROPERTY COMPILE_DEFINITIONS_RELEASE BAR ) add_executable(main main.cpp) set_target_properties(main PROPERTIES COMPILE_DEFINITIONS_DEBUG FOO COMPILE_DEFINITIONS_RELEASE BAR ) Both target property and directory property are tried. And this is the source code main.cpp: #ifdef FOO #error got foo #endif #ifdef BAR #error got bar #endif int main(int argc, char** argv) { return 0; } If the definitions are sent to compilers, it should die with foo on Debug config, and die with bar on Release config. However, it finished compilation on both Debug and Release. I also have a look at the command line parameters of the Debug and Release config, it don't have "/D FOO" and "/D BAR". Thanks for a lot! -- 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 cedric.doucet at inria.fr Wed Jul 22 08:24:14 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Wed, 22 Jul 2015 14:24:14 +0200 (CEST) Subject: [CMake] Linking error after having found a package In-Reply-To: <1667315503.5144592.1437567310504.JavaMail.zimbra@inria.fr> Message-ID: <369969597.5147590.1437567854848.JavaMail.zimbra@inria.fr> Hello, I try to use the find_package function to find BLAS and LAPACK libraries which are required in my code. To do that, I do the following: ====================== FIND_PACKAGE(BLAS) FIND_PACKAGE(LAPACK) # I should test with BLAS_FOUND and LAPACK_FOUND here but that's not the problem LIST(GET BLAS_LIBRARIES 0 BLAS_LIB) LIST(GET LAPACK_LIBRARIES 0 LAPACK_LIB) TARGET_LINK_LIBRARY(myexe ${LAPACK_LIB}$ ${BLAS_LIB}$) ======================= I have manually checked that BLAS and LAPACK are actually found. As explained in FindBLAS.cmake and Find.LAPACK.cmake, BLAS_LIBRARIES and LAPACK_LIBRARIES are lists containing paths to these libraries. I get the first entry in each of these lists and try to link with these entries (/usr/lib/libf77blas.so, /usr/lib/liblapack.so). But I obtain the following error message: ================================================== g++: error: /usr/lib/liblapack.so$: No such file or directory g++: error: /usr/lib/libf77blas.so$: No such file or directory ================================================== But these files exist in my computer. Do you know where the problem come from? Cheers, C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Wed Jul 22 08:31:22 2015 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 22 Jul 2015 14:31:22 +0200 Subject: [CMake] Linking error after having found a package In-Reply-To: <369969597.5147590.1437567854848.JavaMail.zimbra@inria.fr> References: <1667315503.5144592.1437567310504.JavaMail.zimbra@inria.fr> <369969597.5147590.1437567854848.JavaMail.zimbra@inria.fr> Message-ID: 2015-07-22 14:24 GMT+02:00 Cedric Doucet : > > Hello, > > I try to use the find_package function to find BLAS and LAPACK libraries > which are required in my code. > > To do that, I do the following: > > ====================== > FIND_PACKAGE(BLAS) > FIND_PACKAGE(LAPACK) > > # I should test with BLAS_FOUND and LAPACK_FOUND here but that's not the > problem > LIST(GET BLAS_LIBRARIES 0 BLAS_LIB) > LIST(GET LAPACK_LIBRARIES 0 LAPACK_LIB) > > TARGET_LINK_LIBRARY(myexe ${LAPACK_LIB}$ ${BLAS_LIB}$) > You have extraneous '$' at the end of your variables reference ${LAPACK_LIB}$ should be ${LAPACK_LIB} > ======================= > > I have manually checked that BLAS and LAPACK are actually found. > As explained in FindBLAS.cmake and Find.LAPACK.cmake, BLAS_LIBRARIES and > LAPACK_LIBRARIES are lists containing paths to these libraries. > I get the first entry in each of these lists and try to link with these > entries (/usr/lib/libf77blas.so, /usr/lib/liblapack.so). > But I obtain the following error message: > > ================================================== > > g++: error: /usr/lib/liblapack.so$: No such file or directory > g++: error: /usr/lib/libf77blas.so$: No such file or directory > > ================================================== > so g++ is indeed right, look at the dollar sign at the end of .so files. > > But these files exist in my computer. > > > Do you know where the problem come from? > > > Cheers, > > > C?dric > > -- > > 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 > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.doucet at inria.fr Wed Jul 22 08:39:28 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Wed, 22 Jul 2015 14:39:28 +0200 (CEST) Subject: [CMake] Linking error after having found a package In-Reply-To: References: <1667315503.5144592.1437567310504.JavaMail.zimbra@inria.fr> <369969597.5147590.1437567854848.JavaMail.zimbra@inria.fr> Message-ID: <1467551351.5155161.1437568768371.JavaMail.zimbra@inria.fr> I'm afraid you're right. :-/ It works fine now. Thank you very much Eric! ----- Mail original ----- > De: "Eric Noulard" > ?: "Cedric Doucet" > Cc: cmake at cmake.org > Envoy?: Mercredi 22 Juillet 2015 14:31:22 > Objet: Re: [CMake] Linking error after having found a package > 2015-07-22 14:24 GMT+02:00 Cedric Doucet < cedric.doucet at inria.fr > : > > Hello, > > > I try to use the find_package function to find BLAS and LAPACK libraries > > which are required in my code. > > > To do that, I do the following: > > > ====================== > > > FIND_PACKAGE(BLAS) > > > FIND_PACKAGE(LAPACK) > > > # I should test with BLAS_FOUND and LAPACK_FOUND here but that's not the > > problem > > > LIST(GET BLAS_LIBRARIES 0 BLAS_LIB) > > > LIST(GET LAPACK_LIBRARIES 0 LAPACK_LIB) > > > TARGET_LINK_LIBRARY(myexe ${LAPACK_LIB}$ ${BLAS_LIB}$) > > You have extraneous '$' at the end of your variables reference > ${LAPACK_LIB}$ > should be > ${LAPACK_LIB} > > ======================= > > > I have manually checked that BLAS and LAPACK are actually found. > > > As explained in FindBLAS.cmake and Find.LAPACK.cmake, BLAS_LIBRARIES and > > LAPACK_LIBRARIES are lists containing paths to these libraries. > > > I get the first entry in each of these lists and try to link with these > > entries (/usr/lib/libf77blas.so, /usr/lib/liblapack.so). > > > But I obtain the following error message: > > > ================================================== > > > g++: error: /usr/lib/liblapack.so$: No such file or directory > > > g++: error: /usr/lib/libf77blas.so$: No such file or directory > > > ================================================== > > so g++ is indeed right, look at the dollar sign at the end of .so files. > > But these files exist in my computer. > > > Do you know where the problem come from? > > > Cheers, > > > C?dric > > > -- > > > 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 > > -- > Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From biddisco at cscs.ch Wed Jul 22 08:43:46 2015 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Wed, 22 Jul 2015 12:43:46 +0000 Subject: [CMake] find_package and lib/cmake/Foo In-Reply-To: References: <50320452A334BD42A5EC72BAD21450993C6F7CD9@MBX210.d.ethz.ch> <50320452A334BD42A5EC72BAD21450993C6F7D84@MBX210.d.ethz.ch> Message-ID: <50320452A334BD42A5EC72BAD21450993C6F8C6A@MBX210.d.ethz.ch> Robert > Have you tried setting CMAKE_PREFIX_PATH < That seems to work. I will use it from now on. Thanks JB From byrn at hdfgroup.org Wed Jul 22 10:14:19 2015 From: byrn at hdfgroup.org (Allen Byrne) Date: Wed, 22 Jul 2015 09:14:19 -0500 Subject: [CMake] Fortran build dependency on Windows In-Reply-To: <55AEA8E3.30206@kitware.com> References: <10512773.0BPFRloMbh@byrn.ad.hdfgroup.org> <55AE7C2C.1040602@kitware.com> <55AEA8E3.30206@kitware.com> Message-ID: <8096869.NLcxZ7SRjH@byrn.ad.hdfgroup.org> Consider this issue closed - all Nightly tests succeeded. Thank You very much! Allen On Tuesday, July 21, 2015 04:17:39 PM Brad King wrote: > On 07/21/2015 01:06 PM, Brad King wrote: > > It looks like OBJECT_DEPENDS is not fully implemented for VS >= 10. > > I'll look at fixing that. > > It turns out that is because .vcxproj files do not support it. > The ClCompile task is documented here: > > https://msdn.microsoft.com/en-us/library/ee862477.aspx > > and it does not support an AdditionalInputs field. The documentation > of OBJECT_DEPENDS will have to be updated accordingly. > > > Meanwhile you can work around the problem by moving generation of > > the source file to a custom target and then use add_dependencies to > > make sure that is built before the target that compiles the source. > > Please let me know if this works for you or if you find another > workaround. > > Thanks, > -Brad From brad.king at kitware.com Wed Jul 22 11:14:37 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 22 Jul 2015 11:14:37 -0400 Subject: [CMake] CTest threshold exceeds 1024 bytes In-Reply-To: <015401d0c402$ea609040$bf21b0c0$@gmx.at> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> <015401d0c402$ea609040$bf21b0c0$@gmx.at> Message-ID: <55AFB35D.4000004@kitware.com> On 07/21/2015 06:16 PM, Roman W?ger wrote: > I've attached a patch which learns CTest to handle it. > I hope this patch could be merged. Good start. Please also update Help/manual/ctest.1.rst with documentation for the new options. Also please extend the test suite, likely in Tests/RunCMake/CTestCommandLine, to cover the options. See Tests/RunCMake/README.rst for information about how the existing test works. You could perhaps add a case that uses a -check.cmake script to verify the length of the output in a Test.xml file after running "ctest -M Experimental -T Test" plus the new options. Thanks, -Brad From digitalriptide at gmail.com Wed Jul 22 14:22:45 2015 From: digitalriptide at gmail.com (digitalriptide) Date: Wed, 22 Jul 2015 11:22:45 -0700 Subject: [CMake] Changes to CMAKE_CXX_FLAGS_RELEASE not reflected in GUI Message-ID: Dear CMake Community, I would like to add an extra flag to CMAKE_CXX_FLAGS_RELEASE (-xHost for Intel compilers), so in my CMakeLists.txt I add: set( CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -xHost" ) If I then run VERBOSE=1 make, I observe that the xHost flag is passed to the compiler. If I view the GUI, however, (ccmake ..), and switch the view to advanced, the flags are still listed as the default (-O3 -DNDEBUG). Is this the intended behavior? Is there a way to specify additional release build flags in CMakeLists.txt and have them reflected in the GUI? Thank you for your recommendations! From anporumb at microsoft.com Wed Jul 22 18:04:06 2015 From: anporumb at microsoft.com (Andrei Porumb) Date: Wed, 22 Jul 2015 22:04:06 +0000 Subject: [CMake] Visual Studio solution folders with 1 item in them Message-ID: Hello CMake, Thank you for everything so far! I am migrating some cross platform projects to CMake. Naturally our devs (myself included) like things to look "in a certain way". And if "certain way" can be produced by CMake then adoption is smoothened. That being said, this is the issue at hand. How can I instruct CMake to produce some harmless Visual Studio solution folders having some non-target items in them? (I know how to insert targets under Visual Studio solution folders, but I need simple files). Like in the picture below. Notice that "Specs" solution folder contains 3 items, a text file, a bitmap and a sequenceDiagram, none of which are CMake targets. [cid:image001.png at 01D0C48F.A69D52C0] Any help is greatly appreciated. Best Regards, Andrei Porumb "a skhizein equals to 1 software rename/dev cycle" -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 25768 bytes Desc: image001.png URL: From d3ck0r at gmail.com Wed Jul 22 22:13:28 2015 From: d3ck0r at gmail.com (J Decker) Date: Wed, 22 Jul 2015 19:13:28 -0700 Subject: [CMake] Visual Studio solution folders with 1 item in them In-Reply-To: References: Message-ID: globally set set_property(GLOBAL PROPERTY USE_FOLDERS On) SET_TARGET_PROPERTIES( PROPERTIES FOLDER "folder name" ) On Wed, Jul 22, 2015 at 3:04 PM, Andrei Porumb wrote: > Hello CMake, > > > > Thank you for everything so far! > > > > I am migrating some cross platform projects to CMake. > Naturally our devs (myself included) like things to look "in a certain > way". And if "certain way" can be produced by CMake then adoption is > smoothened. > > > > That being said, this is the issue at hand. How can I > instruct CMake to produce some harmless Visual Studio solution folders > having some non-target items in them? (I know how to insert targets under > Visual Studio solution folders, but I need simple files). Like in the > picture below. Notice that "Specs" solution folder contains 3 items, a text > file, a bitmap and a sequenceDiagram, none of which are CMake targets. > > > > > > Any help is greatly appreciated. > > > > Best Regards, > > Andrei Porumb > > > > "a skhizein equals to 1 software rename/dev cycle" > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 25768 bytes Desc: not available URL: From anporumb at microsoft.com Wed Jul 22 23:27:14 2015 From: anporumb at microsoft.com (Andrei Porumb) Date: Thu, 23 Jul 2015 03:27:14 +0000 Subject: [CMake] Visual Studio solution folders with 1 item in them In-Reply-To: References: Message-ID: What you are suggesting will add some previously build targets to the solution inside a solution folder. What I want is to simply have a file inside a solution folder. Best Regards, Andrei Porumb "a skhizein equals to 1 software rename/dev cycle" From: J Decker [mailto:d3ck0r at gmail.com] Sent: Wednesday, July 22, 2015 7:13 PM To: Andrei Porumb Cc: cmake at cmake.org Subject: Re: [CMake] Visual Studio solution folders with 1 item in them globally set set_property(GLOBAL PROPERTY USE_FOLDERS On) SET_TARGET_PROPERTIES( PROPERTIES FOLDER "folder name" ) On Wed, Jul 22, 2015 at 3:04 PM, Andrei Porumb > wrote: Hello CMake, Thank you for everything so far! I am migrating some cross platform projects to CMake. Naturally our devs (myself included) like things to look "in a certain way". And if "certain way" can be produced by CMake then adoption is smoothened. That being said, this is the issue at hand. How can I instruct CMake to produce some harmless Visual Studio solution folders having some non-target items in them? (I know how to insert targets under Visual Studio solution folders, but I need simple files). Like in the picture below. Notice that "Specs" solution folder contains 3 items, a text file, a bitmap and a sequenceDiagram, none of which are CMake targets. [cid:image001.png at 01D0C4BC.639FFEF0] Any help is greatly appreciated. Best Regards, Andrei Porumb "a skhizein equals to 1 software rename/dev cycle" -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 25768 bytes Desc: image001.png URL: From jsvanbethlehem at gmail.com Thu Jul 23 03:01:02 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Thu, 23 Jul 2015 09:01:02 +0200 Subject: [CMake] Rerun CMake partially in Visual Studio Message-ID: Dear users, CMake has a very nice integration with Visual Studio. One problem I often encounter with reasonably large solutions is that one I change only one CMakeLists.txt file, the full solution gets regenerated. Would it possible somehow to *only* regenerate the project(s) that are affected by the CMakeLists.txt file I changed? Sincerely, Jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Thu Jul 23 03:23:22 2015 From: roman.wueger at gmx.at (=?UTF-8?Q?=22Roman_W=C3=BCger=22?=) Date: Thu, 23 Jul 2015 09:23:22 +0200 Subject: [CMake] CTest threshold exceeds 1024 bytes In-Reply-To: <55AFB35D.4000004@kitware.com> References: <26A7A5F1-8B9C-40A1-85B0-40AD29A0FF54@gmx.at> <55AE4EC3.8050607@kitware.com> <015401d0c402$ea609040$bf21b0c0$@gmx.at>, <55AFB35D.4000004@kitware.com> Message-ID: Hi Brad, i've updated the patch with the missing things, but I don't know how to use the -check.cmake scripts to check the length of the output. Maybe you could have a look at it. Best regards Roman Am 22.07.15 um 17:14 schrieb Brad King > On 07/21/2015 06:16 PM, Roman W?ger wrote: > > > I've attached a patch which learns CTest to handle it. > > > I hope this patch could be merged. > > > > Good start. Please also update Help/manual/ctest.1.rst with > > documentation for the new options. Also please extend the test > > suite, likely in Tests/RunCMake/CTestCommandLine, to cover the > > options. See Tests/RunCMake/README.rst for information about > > how the existing test works. You could perhaps add a case that > > uses a -check.cmake script to verify the length of the output > > in a Test.xml file after running "ctest -M Experimental -T Test" > > plus the new options. > > > > Thanks, > > -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ctest-learned-to-limit-the-output-of-passed-and-fail.patch Type: application/octet-stream Size: 8366 bytes Desc: not available URL: From chuck.atkins at kitware.com Thu Jul 23 08:22:04 2015 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Thu, 23 Jul 2015 08:22:04 -0400 Subject: [CMake] Changes to CMAKE_CXX_FLAGS_RELEASE not reflected in GUI In-Reply-To: References: Message-ID: > Is this the intended behavior? Yes. The GUI is essentially an editor for the CMake cache. These variables are persistent with global scope. As such, only the cache values are reflected in the GUI. When you set the CMAKE_CXX_FLAGS_RELEASE with this form of the set command, you are changing it's value in the current scope, but not in the cache, hence no updated value in the GUI. > Is there a way to specify additional > release build flags in CMakeLists.txt and have them reflected in the > GUI? > You can update the cache entry with the alternate signature for set: set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -xHost" CACHE STRING "Flags used by the compiler during release builds." FORCE) The "FORCE" option is necessary to change an existing cache entry. See details for setting cache values here: http://www.cmake.org/cmake/help/v3.3/command/set.html Thank you for your recommendations! > You're welcome :-) - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Thu Jul 23 08:36:35 2015 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Thu, 23 Jul 2015 08:36:35 -0400 Subject: [CMake] Linking error after having found a package In-Reply-To: <369969597.5147590.1437567854848.JavaMail.zimbra@inria.fr> References: <1667315503.5144592.1437567310504.JavaMail.zimbra@inria.fr> <369969597.5147590.1437567854848.JavaMail.zimbra@inria.fr> Message-ID: Hi Cedric, FIND_PACKAGE(BLAS) > FIND_PACKAGE(LAPACK) > > # I should test with BLAS_FOUND and LAPACK_FOUND here but that's not the > problem > If they're actually required then you can skip the additional check by calling: FIND_PACKAGE(BLAS REQUIRED) FIND_PACKAGE(LAPACK REQUIRED) This will cause the configure step to fail if not found LIST(GET BLAS_LIBRARIES 0 BLAS_LIB) > LIST(GET LAPACK_LIBRARIES 0 LAPACK_LIB) > ... > As explained in FindBLAS.cmake and Find.LAPACK.cmake, BLAS_LIBRARIES and > LAPACK_LIBRARIES are lists containing paths to these libraries. > I get the first entry in each of these lists and try to link with these > entries (/usr/lib/libf77blas.so, /usr/lib/liblapack.so). > You really should be using the _LIBRARIES variables instead it contains the link dependencies as well. For shared libraries, this is less of an issue since the dependencies will transitively propogate accordingly, but if you want to link it statically, then you'll need those extra libraries. Basically, the FOO_LIBRARIES variable should be used as is, if possible, for FIND_PACKAGE(FOO) TARGET_LINK_LIBRARY(myexe ${LAPACK_LIB}$ ${BLAS_LIB}$) > As Eric already pointed out, the extra trailing "$" needs to go - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Jul 23 08:45:34 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 23 Jul 2015 08:45:34 -0400 Subject: [CMake] Rerun CMake partially in Visual Studio In-Reply-To: References: Message-ID: Nope. CMake has no way of knowing whether you have logic in the lower level CMakeLists file which affects later included projects, or which might even possibly affect global (top level project) CMakeCache settings. Without adding facilities to track such interconnections, the entire tree from the top level down must be re-processed to figure out what to generate. HTH, David C. On Thu, Jul 23, 2015 at 3:01 AM, Jakob van Bethlehem wrote: > Dear users, > > CMake has a very nice integration with Visual Studio. One problem I often > encounter with reasonably large solutions is that one I change only one > CMakeLists.txt file, the full solution gets regenerated. Would it possible > somehow to *only* regenerate the project(s) that are affected by the > CMakeLists.txt file I changed? > > Sincerely, > Jakob > > -- > > 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 nilsgladitz at gmail.com Thu Jul 23 09:00:04 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 23 Jul 2015 15:00:04 +0200 Subject: [CMake] Changes to CMAKE_CXX_FLAGS_RELEASE not reflected in GUI In-Reply-To: References: Message-ID: <55B0E554.7040902@gmail.com> On 07/23/2015 02:22 PM, Chuck Atkins wrote: > You can update the cache entry with the alternate signature for set: > > set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -xHost" CACHE > STRING "Flags used by the compiler during release builds." FORCE) This would keep appending " -xHOST" to the variable every time cmake is invoked which might not be desirable either. Nils From DLRdave at aol.com Thu Jul 23 09:05:21 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 23 Jul 2015 09:05:21 -0400 Subject: [CMake] Changes to CMAKE_CXX_FLAGS_RELEASE not reflected in GUI In-Reply-To: References: Message-ID: However, be aware of two things if you do use FORCE: If CMAKE_CXX_FLAGS_RELEASE already contains "-xHost" you will be appending it *again* each time CMake is run in a given build tree... So you may want some "if(NOT CMAKE_CXX_FLAGS_RELEASE MATCHES "-xHost")" logic in there as well. Also, using FORCE unconditionally essentially eliminates the possibility of having an end user modify that cache value in the cmake-gui, since you'll be overwriting it with your value. Consider making it INTERNAL rather than having it appear in the GUI if you really need to control its value from CMakeLists rather than allowing end users to edit it. HTH, David C. On Thu, Jul 23, 2015 at 8:22 AM, Chuck Atkins wrote: >> Is this the intended behavior? > > > Yes. The GUI is essentially an editor for the CMake cache. These variables > are persistent with global scope. As such, only the cache values are > reflected in the GUI. When you set the CMAKE_CXX_FLAGS_RELEASE with this > form of the set command, you are changing it's value in the current scope, > but not in the cache, hence no updated value in the GUI. > > >> >> Is there a way to specify additional >> release build flags in CMakeLists.txt and have them reflected in the >> GUI? > > > You can update the cache entry with the alternate signature for set: > > set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -xHost" CACHE STRING > "Flags used by the compiler during release builds." FORCE) > > The "FORCE" option is necessary to change an existing cache entry. See > details for setting cache values here: > http://www.cmake.org/cmake/help/v3.3/command/set.html > > >> Thank you for your recommendations! > > > You're welcome :-) > > - Chuck > > > -- > > 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 parag at ionicsecurity.com Thu Jul 23 10:28:07 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Thu, 23 Jul 2015 14:28:07 +0000 Subject: [CMake] Visual Studio solution folders with 1 item in them In-Reply-To: References: Message-ID: <09A0AA14-083D-4258-A1E7-B509EB0BC228@ionicsecurity.com> Couldn?t you use the source_group() command to do this? That is how I arbitrarily group my source files into folders within Visual Studio. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: Andrei Porumb > Date: Wednesday, July 22, 2015 at 11:27 PM To: J Decker > Cc: "cmake at cmake.org" > Subject: Re: [CMake] Visual Studio solution folders with 1 item in them What you are suggesting will add some previously build targets to the solution inside a solution folder. What I want is to simply have a file inside a solution folder. Best Regards, Andrei Porumb "a skhizein equals to 1 software rename/dev cycle" From: J Decker [mailto:d3ck0r at gmail.com] Sent: Wednesday, July 22, 2015 7:13 PM To: Andrei Porumb > Cc: cmake at cmake.org Subject: Re: [CMake] Visual Studio solution folders with 1 item in them globally set set_property(GLOBAL PROPERTY USE_FOLDERS On) SET_TARGET_PROPERTIES( PROPERTIES FOLDER "folder name" ) On Wed, Jul 22, 2015 at 3:04 PM, Andrei Porumb > wrote: Hello CMake, Thank you for everything so far! I am migrating some cross platform projects to CMake. Naturally our devs (myself included) like things to look "in a certain way". And if "certain way" can be produced by CMake then adoption is smoothened. That being said, this is the issue at hand. How can I instruct CMake to produce some harmless Visual Studio solution folders having some non-target items in them? (I know how to insert targets under Visual Studio solution folders, but I need simple files). Like in the picture below. Notice that "Specs" solution folder contains 3 items, a text file, a bitmap and a sequenceDiagram, none of which are CMake targets. [cid:image001.png at 01D0C4BC.639FFEF0] Any help is greatly appreciated. Best Regards, Andrei Porumb "a skhizein equals to 1 software rename/dev cycle" -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 25768 bytes Desc: image001.png URL: From bill.hoffman at kitware.com Thu Jul 23 10:38:20 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 23 Jul 2015 10:38:20 -0400 Subject: [CMake] Rerun CMake partially in Visual Studio In-Reply-To: References: Message-ID: <55B0FC5C.8060307@kitware.com> On 7/23/2015 8:45 AM, David Cole via CMake wrote: > Nope. > > CMake has no way of knowing whether you have logic in the lower level > CMakeLists file which affects later included projects, or which might > even possibly affect global (top level project) CMakeCache settings. > Without adding facilities to track such interconnections, the entire > tree from the top level down must be re-processed to figure out what > to generate. That said, there is some work going on that might actually do this in the future. Stephen Kelley is working on being able to save state and tell which parts have been touched. This would be used for editors but would be useful for this type of thing as well. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoffman at kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 From dumont.guillaume at gmail.com Thu Jul 23 11:08:36 2015 From: dumont.guillaume at gmail.com (Guillaume Dumont) Date: Thu, 23 Jul 2015 11:08:36 -0400 Subject: [CMake] CMakeFindDependencyMacro and components Message-ID: Hi, I have a projet that depends on some Boost COMPONENTS I would like to use the following code the project-config.cmake file generate by CMake using code like: include(CMakeFindDependencyMacro) find_dependency(Boost COMPONENTS date_time filesystem system) Looking at the CMakeFindDependencyMacro code the COMPONENTS argument does not seem to be supported. Is there a workaround for this situation? -- Guillaume Dumont ========================= dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From anporumb at microsoft.com Thu Jul 23 11:24:05 2015 From: anporumb at microsoft.com (Andrei Porumb) Date: Thu, 23 Jul 2015 15:24:05 +0000 Subject: [CMake] Visual Studio solution folders with 1 item in them In-Reply-To: <09A0AA14-083D-4258-A1E7-B509EB0BC228@ionicsecurity.com> References: <09A0AA14-083D-4258-A1E7-B509EB0BC228@ionicsecurity.com> Message-ID: Hello Parag, I am very sorry to say that your suggestion achieves something different (similar, but different). SOURCE_GROUP creates a "project filter" (that's an entity under a project). A "project filter" is not a "solution folder" (yeah, they look very similar). Picture included with a solution folder and a project filter. What I want is to place some random files under the solution folder. These files are not CMake targets. [cid:image002.png at 01D0C520.EF1E4C70] Best Regards, Andrei Porumb "a skhizein equals to 1 software rename/dev cycle" From: Parag Chandra [mailto:parag at ionicsecurity.com] Sent: Thursday, July 23, 2015 7:28 AM To: Andrei Porumb ; J Decker Cc: cmake at cmake.org Subject: Re: [CMake] Visual Studio solution folders with 1 item in them Couldn?t you use the source_group() command to do this? That is how I arbitrarily group my source files into folders within Visual Studio. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [Image removed by sender.] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: Andrei Porumb > Date: Wednesday, July 22, 2015 at 11:27 PM To: J Decker > Cc: "cmake at cmake.org" > Subject: Re: [CMake] Visual Studio solution folders with 1 item in them What you are suggesting will add some previously build targets to the solution inside a solution folder. What I want is to simply have a file inside a solution folder. Best Regards, Andrei Porumb "a skhizein equals to 1 software rename/dev cycle" From: J Decker [mailto:d3ck0r at gmail.com] Sent: Wednesday, July 22, 2015 7:13 PM To: Andrei Porumb > Cc: cmake at cmake.org Subject: Re: [CMake] Visual Studio solution folders with 1 item in them globally set set_property(GLOBAL PROPERTY USE_FOLDERS On) SET_TARGET_PROPERTIES( PROPERTIES FOLDER "folder name" ) On Wed, Jul 22, 2015 at 3:04 PM, Andrei Porumb > wrote: Hello CMake, Thank you for everything so far! I am migrating some cross platform projects to CMake. Naturally our devs (myself included) like things to look "in a certain way". And if "certain way" can be produced by CMake then adoption is smoothened. That being said, this is the issue at hand. How can I instruct CMake to produce some harmless Visual Studio solution folders having some non-target items in them? (I know how to insert targets under Visual Studio solution folders, but I need simple files). Like in the picture below. Notice that "Specs" solution folder contains 3 items, a text file, a bitmap and a sequenceDiagram, none of which are CMake targets. [cid:image003.png at 01D0C520.EF1E4C70] Any help is greatly appreciated. Best Regards, Andrei Porumb "a skhizein equals to 1 software rename/dev cycle" -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: ~WRD000.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 24548 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 25768 bytes Desc: image003.png URL: From daniel at kogitoapp.com Thu Jul 23 11:24:53 2015 From: daniel at kogitoapp.com (Daniel S. Reichenbach) Date: Thu, 23 Jul 2015 17:24:53 +0200 Subject: [CMake] CMakeFindDependencyMacro and components In-Reply-To: References: Message-ID: <55B10745.1080505@kogitoapp.com> Hi, > find_dependency(Boost COMPONENTS date_time filesystem system) > > Looking at the CMakeFindDependencyMacro code the COMPONENTS argument > does not seem to be supported. > > Is there a workaround for this situation? What about using e.g. set(BOOST_ROOT $ENV{BOOST_ROOT}) find_package(Boost 1.54 REQUIRED COMPONENTS filesystem program_options regex system thread) I'm using this in a few projects and it reliably detects Boost and the components on Mac OS X, Linux and Windows. WkR, Daniel -- [kogito](http://kogitoapp.com) - nerds available for awesome projects kogito Anwendungsentwicklung brainz at kogitoapp.com c/o Daniel S. Reichenbach phone: +49 221 27096773 Limburger Stra?e 19 mobile: +49 160 96311159 50672 K?ln, Germany From dumont.guillaume at gmail.com Thu Jul 23 11:39:54 2015 From: dumont.guillaume at gmail.com (Guillaume Dumont) Date: Thu, 23 Jul 2015 11:39:54 -0400 Subject: [CMake] CMakeFindDependencyMacro and components In-Reply-To: <55B10745.1080505@kogitoapp.com> References: <55B10745.1080505@kogitoapp.com> Message-ID: According to documentation: http://www.cmake.org/cmake/help/v3.2/module/CMakeFindDependencyMacro.html find_dependency() wraps a find_package() call for a package dependency. It is designed to be used in a Config.cmake file, and it forwards the correct parameters for EXACT, QUIET and REQUIRED which were passed to the original find_package() call. It also sets an informative diagnostic message if the dependency could not be found. But there is no mention of COMPONENTS and other find_package arguments so I guess I will have to resort to using find_package or a custom CMakeFindDependencyMacro. Guillaume On Thu, Jul 23, 2015 at 11:24 AM, Daniel S. Reichenbach < daniel at kogitoapp.com> wrote: > Hi, > > find_dependency(Boost COMPONENTS date_time filesystem system) >> >> Looking at the CMakeFindDependencyMacro code the COMPONENTS argument >> does not seem to be supported. >> >> Is there a workaround for this situation? >> > What about using e.g. > > set(BOOST_ROOT $ENV{BOOST_ROOT}) > find_package(Boost 1.54 REQUIRED COMPONENTS filesystem program_options > regex system thread) > > I'm using this in a few projects and it reliably detects Boost and the > components on Mac OS X, Linux and Windows. > > WkR, > Daniel > -- > [kogito](http://kogitoapp.com) - nerds available for awesome projects > > kogito Anwendungsentwicklung brainz at kogitoapp.com > c/o Daniel S. Reichenbach phone: +49 221 27096773 > Limburger Stra?e 19 mobile: +49 160 96311159 > 50672 K?ln, Germany > -- > > 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 DLRdave at aol.com Thu Jul 23 12:45:41 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 23 Jul 2015 12:45:41 -0400 Subject: [CMake] Visual Studio solution folders with 1 item in them In-Reply-To: References: <09A0AA14-083D-4258-A1E7-B509EB0BC228@ionicsecurity.com> Message-ID: CMake only puts projects (libraries, executables, custom targets) inside of solution folders. There's currently no way to add an individual file in them directly. D On Thu, Jul 23, 2015 at 11:24 AM, Andrei Porumb wrote: > Hello Parag, > > > > I am very sorry to say that your suggestion achieves > something different (similar, but different). SOURCE_GROUP creates a > "project filter" (that's an entity under a project). A "project filter" is > not a "solution folder" (yeah, they look very similar). Picture included > with a solution folder and a project filter. > > > > What I want is to place some random files under the > solution folder. These files are not CMake targets. > > > > > > Best Regards, > > Andrei Porumb > > > > "a skhizein equals to 1 software rename/dev cycle" > > > > *From:* Parag Chandra [mailto:parag at ionicsecurity.com] > *Sent:* Thursday, July 23, 2015 7:28 AM > *To:* Andrei Porumb ; J Decker > *Cc:* cmake at cmake.org > *Subject:* Re: [CMake] Visual Studio solution folders with 1 item in them > > > > Couldn?t you use the source_group() command to do this? That is how I > arbitrarily group my source files into folders within Visual Studio. > > > > > *Parag Chandra* > Senior Software Engineer, Mobile Team > Mobile: +1.919.824.1410 > > [image: Image removed by sender.] > > Ionic Security Inc. > 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 > > > > *From: *Andrei Porumb > *Date: *Wednesday, July 22, 2015 at 11:27 PM > *To: *J Decker > *Cc: *"cmake at cmake.org" > *Subject: *Re: [CMake] Visual Studio solution folders with 1 item in them > > > > What you are suggesting will add some previously build targets to the > solution inside a solution folder. What I want is to simply have a file > inside a solution folder. > > > > Best Regards, > > Andrei Porumb > > > > "a skhizein equals to 1 software rename/dev cycle" > > > > *From:* J Decker [mailto:d3ck0r at gmail.com ] > *Sent:* Wednesday, July 22, 2015 7:13 PM > *To:* Andrei Porumb > *Cc:* cmake at cmake.org > *Subject:* Re: [CMake] Visual Studio solution folders with 1 item in them > > > > globally set > > > > set_property(GLOBAL PROPERTY USE_FOLDERS On) > > > > > > SET_TARGET_PROPERTIES( PROPERTIES > > FOLDER "folder name" > > ) > > > > > > > > > > On Wed, Jul 22, 2015 at 3:04 PM, Andrei Porumb > wrote: > > Hello CMake, > > > > Thank you for everything so far! > > > > I am migrating some cross platform projects to CMake. > Naturally our devs (myself included) like things to look "in a certain > way". And if "certain way" can be produced by CMake then adoption is > smoothened. > > > > That being said, this is the issue at hand. How can I > instruct CMake to produce some harmless Visual Studio solution folders > having some non-target items in them? (I know how to insert targets under > Visual Studio solution folders, but I need simple files). Like in the > picture below. Notice that "Specs" solution folder contains 3 items, a text > file, a bitmap and a sequenceDiagram, none of which are CMake targets. > > > > > > Any help is greatly appreciated. > > > > Best Regards, > > Andrei Porumb > > > > "a skhizein equals to 1 software rename/dev cycle" > > > > > -- > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 24548 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 25768 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: not available URL: From ruslan_baratov at yahoo.com Thu Jul 23 15:03:15 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 23 Jul 2015 22:03:15 +0300 Subject: [CMake] CMakeFindDependencyMacro and components In-Reply-To: References: <55B10745.1080505@kogitoapp.com> Message-ID: <55B13A73.2020309@yahoo.com> On 23-Jul-15 18:08, Guillaume Dumont wrote: > include(CMakeFindDependencyMacro) > > find_dependency(Boost COMPONENTS date_time filesystem system) Note that by default Boost_LIBRARIES is a list of full paths to the components, so find_dependency not needed since library will be hardcoded into *Targets.cmake On 23-Jul-15 18:39, Guillaume Dumont wrote: > ... or a custom CMakeFindDependencyMacro. I guess you can send a patch in this case From robert.maynard at kitware.com Thu Jul 23 16:48:47 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 23 Jul 2015 16:48:47 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.3.0 Released Message-ID: I am proud to announce that CMake 3.3.0 is now available for download at: http://www.cmake.org/download/ Documentation is available at: http://www.cmake.org/cmake/help/v3.3 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.3/release/3.3.html Some of the more significant features of CMake 3.3 are: * The "if()" command learned a new "IN_LIST" operator that evaluates to true if a given element is contained in a named list. * The "add_dependencies()" command learned to allow dependencies to be added to *interface libraries*. Dependencies added to an interface library are followed transitively in its place since the target itself does not build. * The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable. * The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN" target properties now affect compilation in sources of all target types. See policy "CMP0063". * A "_INCLUDE_WHAT_YOU_USE" target property and supporting "CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell the *Makefile Generators* and the "Ninja" generator to run "include- what-you-use" along with the compiler for "C" and "CXX" languages. Deprecated and Removed Features: * The "ctest_build()" and "build_command()" commands no longer tell "make" tools to ignore errors with the "-i" option. Previously this was done for *Makefile Generators* but not others. See policy "CMP0061". * The "Visual Studio 7" generator (.NET 2002) is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 6" generator is now deprecated and will be removed in a future version of CMake. * The "add_definitions()" command no longer causes a "DEFINITIONS" directory property to be populated. See policy "CMP0059". CMake 3.3 Release Notes *********************** Changes made since CMake 3.2 include the following. New Features ============ Generators ---------- * The *Makefile Generators* now add ".DELETE_ON_ERROR" to the makefiles that contain the actual build rules for files on disk. This tells GNU make to remove rule outputs when their recipe modifies an output but fails. * The *Visual Studio Generators* learned to support ".xaml" source files and automatically associate them with corresponding ".h" and ".cpp" sources. * A new experimental "Green Hills MULTI" generator was added on Windows. Green Hills MULTI is an IDE for embedded real-time systems. Commands -------- * The "add_dependencies()" command learned to allow dependencies to be added to *interface libraries*. Dependencies added to an interface library are followed transitively in its place since the target itself does not build. * The "execute_process()" command learned to support specifying the same file for "OUTPUT_FILE" and "ERROR_FILE". * The "file(GLOB)" and "file(GLOB_RECURSE)" commands learned a new "LIST_DIRECTORIES " option to specify whether the glob result should include directories. * The "find_library()", "find_path()", and "find_file()" commands now search in installation prefixes derived from the "PATH" environment variable. * The "if()" command learned a new "IN_LIST" operator that evaluates to true if a given element is contained in a named list. * The "install(EXPORT)" and "export()" commands learned to export targets that populate the "INTERFACE_SOURCES" target property. * The "install(TARGETS)" command learned to support generator expressions in the "DESTINATION" value. Variables --------- * The version of some Fortran compilers is now detected and stored in the "CMAKE_Fortran_COMPILER_VERSION" variable. * The *Visual Studio Generators* learned a new "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" option to put the "INSTALL" target in the default build of a solution (".sln") file. Properties ---------- * A "CROSSCOMPILING_EMULATOR" target property and supporting "CMAKE_CROSSCOMPILING_EMULATOR" variable were introduced to allow target platform binaries to run on the host during cross compiling. * A "_INCLUDE_WHAT_YOU_USE" target property and supporting "CMAKE__INCLUDE_WHAT_YOU_USE" variable were introduced to tell the *Makefile Generators* and the "Ninja" generator to run "include- what-you-use" along with the compiler for "C" and "CXX" languages. * The "_VISIBILITY_PRESET" and "VISIBILITY_INLINES_HIDDEN" target properties now affect compilation in sources of all target types. See policy "CMP0063". * The "XCODE_ATTRIBUTE_" target property learned to support generator expressions. Modules ------- * The "CheckFortranCompilerFlag" module was introduced to check "Fortran" compiler flags, much like the "CheckCCompilerFlag" module already does for "C". * The "ExternalData" module learned a new "ExternalData_NO_SYMLINKS" option to disable use of symbolic links to populate the real data files and use copies instead. * The "ExternalData" module learned a new "RECURSE:" option in "DATA{}" references specifying directories. This allows an entire directory tree of associated files to be matched. * The "ExternalData" module learned a new URL template placeholder "%(algo:)" to allow custom mapping from algorithm name to URL component through configuration of new "ExternalData_URL_ALGO__" variables. This allows more flexibility in remote URLs. * The "ExternalProject" module learned to replace tokens like "" in the "BYPRODUCTS" of each step. * The "ExternalProject" module APIs learned to support "generator expressions" when using "LOG_*" options and in CMake initial cache options. * The "FindBoost" module now tracks the directories containing libraries separately for RELEASE and DEBUG configurations. * The "FindCUDA" module now defaults to using the static CUDA runtime library if it is available. A new "CUDA_USE_STATIC_CUDA_RUNTIME" option is offered to control this behavior. * The "FindMatlab" module was completely rewritten. It learned about versions and components and to find Matlab in a more precise and multiplatform way. The module now offers APIs to create mex extensions, documentation, and unit tests. * The "FindPackageHandleStandardArgs" module "FIND_PACKAGE_HANDLE_STANDARD_ARGS" function now always populates both the "_FOUND" and "_FOUND" variables (the latter for backwards compatibility). The "FOUND_VAR" option is now ignored except to enforce its allowed values. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_SYSTEM_RUNTIME_COMPONENT" option to specify the installation component. Generator Expressions --------------------- * A new "COMPILE_LANGUAGE" generator expression was introduced to allow specification of compile options for target files based on the "LANGUAGE" of each source file. Due to limitations of the underlying native build tools, this feature has varying support across generators. See the "cmake-generator-expressions(7)" manual for details. CTest ----- * The "ctest(1)" tool learned a new "--repeat-until-fail " option to help find sporadic test failures. * The "CTestCoverageCollectGCOV" module learned to support the same "CTEST_CUSTOM_COVERAGE_EXCLUDE" option as the "ctest_coverage()" command. CPack ----- * The "cpack(1)" "IFW" generator and the "CPackIFW" module learned to support Qt Framework Installer 2.0 tools. * The "CPackDeb" module learned a new "CPACK_DEBIAN__PACKAGE_SHLIBDEPS" variable to specify per-component use of "dpkg-shlibdeps". * The "CPackDeb" module learned a new "CPACK_DEBIAN__PACKAGE_DEPENDS" option to specify per- component dependencies. * The "CPackRPM" module learned to package symbolic links more cleanly and now supports directory symlinks with recent "rpmbuild" versions. * The "CPackRPM" module learned a new "CPACK_RPM_ADDITIONAL_MAN_DIRS" variable to specify directories containing man pages for the brp- compress RPM macro. * The "CPackRPM" module learned a new "CPACK_RPM__PACKAGE_ARCHITECTURE" variable to specify a component-specific package architecture. * The CPack WIX generator learned the new "CPACK_START_MENU_SHORTCUTS", "CPACK_DESKTOP_SHORTCUTS" and "CPACK_STARTUP_SHORTCUTS" installed file properties which can be used to install shorcuts in the Start Menu, on the Desktop and in the Startup Folder respectively. Other ----- * The "Compile Features" functionality is now aware of features supported by GNU compilers on Windows, versions 4.4 through 5.0. * The "cmake(1)" "-E tar" command learned a new "--format" option to specify the archive format to be written. * On OS X, CMake learned to create XCTest bundles to test Frameworks and App Bundles within Xcode. The "FindXCTest" module provides convenience functions to handle "XCTEST" bundles. Deprecated and Removed Features =============================== * On OS X the "cmake-gui(1)" no longer has the "Install For Command Line Use" menu item. Instead there is a "How to Install For Command Line Use" menu item that shows an informational dialog box explaining how to make the command line tools available. For example: /Applications/CMake.app/Contents/bin/cmake-gui --install * The "ctest_build()" and "build_command()" commands no longer tell "make" tools to ignore errors with the "-i" option. Previously this was done for *Makefile Generators* but not others. See policy "CMP0061". * The "Visual Studio 10 2010" generator no longer checks for running VS IDEs with the project open or asks them to reload. This was originally done for VS 10 because it had been done for VS 7 through 9 to avoid prompting for every project in a solution. Since VS >= 10 allow the whole solution to reload at once they do not need CMake to help them. * The "Visual Studio 7" generator (.NET 2002) is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 6" generator is now deprecated and will be removed in a future version of CMake. * The "find_package()" command no longer considers project build trees recently configured in a "cmake-gui(1)". This was previously done only on Windows and is now never done. The "NO_CMAKE_BUILDS_PATH" option is now ignored if given and effectively always on. Projects may populate the *User Package Registry* to aid users building multiple dependent projects one after another. * When building with GNU tools on Windows (MinGW tools), the "find_library()" command will no longer consider ".dll" files to be linkable libraries. All dynamic link libraries are expected to provide separate ".dll.a" or ".lib" import libraries. * The "add_definitions()" command no longer causes a "DEFINITIONS" directory property to be populated. See policy "CMP0059". * With Visual Studio 7, 8, and 9 generators the value of the "$(OutDir)" placeholder no longer evaluates to the configuration name. Projects should use "$(ConfigurationName)" for that instead. * Using the output of "export()" with the "install(FILES)" command is no longer allowed. See policy "CMP0062" for details. Other Changes ============= * The "Ninja" generator now requires that calls to the "add_custom_command()" and "add_custom_target()" commands use the "BYPRODUCTS" option to explicitly specify any files generated by the custom commands that are not listed as outputs (perhaps because their timestamps are allowed to be older than the inputs). See policy "CMP0058". * Build-time progress output of *Makefile Generators* has been improved. It no longer mixes progress and build rule messages during parallel builds. The link rule messages now have progress and are displayed as bold green instead of bold red (since red is often associated with an error message). * The "CMAKE_CFG_INTDIR" variable value for Visual Studio 7, 8, and 9 is now "$(ConfigurationName)" instead of "$(OutDir)". This should have no effect on the intended use cases of the variable. * Linking to library files by a full path in an implicit linker search directory (e.g. "/usr/lib/libfoo.a") no longer asks the linker to search for the library (e.g. "-lfoo") and now links by full path. See policy "CMP0060". ------------------------------------------------------------------- Changes made since CMake 3.3.0-rc4: Brad King (3): Features: Update MSVC features for VS 2015 RTM OS X: Use -iframework with AppleClang only on version >= 4.2 CMake 3.3.0 ------------------------------------------------------------------- From mohammedrashadkm at gmail.com Thu Jul 23 17:56:56 2015 From: mohammedrashadkm at gmail.com (Rashad M) Date: Thu, 23 Jul 2015 23:56:56 +0200 Subject: [CMake] fixup_bundle on linux Message-ID: Hi all, Does fixup_bundle() from BundleUtiltites works on linux in a similar fashion as in OSX. Currently calling fixup_bundle on a .app folder with some search dirs and libs it will scan the dependencies and produce a portable package. Is that possible in linux? I mean to generate distribution independent binaries. There is the whole stuff with RPATH which is helpful. But I dont know how fixup_bundle works on linux platform. Can anyone explain this ? -- Regards, Rashad -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Fri Jul 24 03:01:59 2015 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Fri, 24 Jul 2015 07:01:59 +0000 Subject: [CMake] =?utf-8?q?Rerun_CMake_partially_in_Visual_Studio?= In-Reply-To: <55B0FC5C.8060307@kitware.com> References: , <55B0FC5C.8060307@kitware.com> Message-ID: May I ask what you mean by ?editors?? Do you mean GUI editors to managing CMake projects? M?t? Felad?: Bill Hoffman Elk?ldve: ?cs?t?rt?k?, ?2015?. ?j?lius? ?23?. ?16?:?38 C?mzett: cmake at cmake.org On 7/23/2015 8:45 AM, David Cole via CMake wrote: > Nope. > > CMake has no way of knowing whether you have logic in the lower level > CMakeLists file which affects later included projects, or which might > even possibly affect global (top level project) CMakeCache settings. > Without adding facilities to track such interconnections, the entire > tree from the top level down must be re-processed to figure out what > to generate. That said, there is some work going on that might actually do this in the future. Stephen Kelley is working on being able to save state and tell which parts have been touched. This would be used for editors but would be useful for this type of thing as well. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoffman at kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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 kretz at kde.org Fri Jul 24 04:23:48 2015 From: kretz at kde.org (Matthias Kretz) Date: Fri, 24 Jul 2015 10:23:48 +0200 Subject: [CMake] using ctest launchers leads to empty warning/error messages on the dashboard Message-ID: <1721857.RCE4EdRJxR@drazi> Hi, using set(ENV{CTEST_USE_LAUNCHERS_DEFAULT} "ON") I don't get any output on the CDash dashboard anymore. AFAICT the Build directory in Testing/tag/ is removed but never recreated. I.e. if I call CTEST_LAUNCH_LOGS=./not-existing-directory make the launcher output is not stored to disk. With CTEST_LAUNCH_LOGS=./ make I get launch-* and warning-* files in the cwd. Is this a bug in ctest or am I doing something wrong? I was testing with cmake version 3.3.0-rc3. Cheers, Matthias -- ?????????????????????????????????????????????????????????????????????????????? Matthias Kretz SIMD easy and portable: https://github.com/VcDevel/Vc ?????????????????????????????????????????????????????????????????????????????? From kretz at kde.org Fri Jul 24 05:28:13 2015 From: kretz at kde.org (Matthias Kretz) Date: Fri, 24 Jul 2015 11:28:13 +0200 Subject: [CMake] using ctest launchers leads to empty warning/error messages on the dashboard In-Reply-To: <1721857.RCE4EdRJxR@drazi> References: <1721857.RCE4EdRJxR@drazi> Message-ID: <3292089.JALHGOf2On@drazi> On Friday 24 July 2015 10:23:48 Matthias Kretz wrote: > set(ENV{CTEST_USE_LAUNCHERS_DEFAULT} "ON") > > I don't get any output on the CDash dashboard anymore. AFAICT the Build > directory in Testing/tag/ is removed but never recreated. With the following patch I get output back to the dashboard: --- a/Source/CTest/cmCTestLaunch.cxx +++ b/Source/CTest/cmCTestLaunch.cxx @@ -207,6 +207,7 @@ void cmCTestLaunch::ComputeFileNames() this->LogDir = d; cmSystemTools::ConvertToUnixSlashes(this->LogDir); this->LogDir += "/"; + cmSystemTools::MakeDirectory(this->LogDir); // We hash the input command working dir and command line to obtain // a repeatable and (probably) unique name for log files. But the dashboard still shows the conflated output of the parallel build instead of the correct context per source/object file. Cheers, Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From kretz at kde.org Fri Jul 24 05:37:15 2015 From: kretz at kde.org (Matthias Kretz) Date: Fri, 24 Jul 2015 11:37:15 +0200 Subject: [CMake] using ctest launchers leads to empty warning/error messages on the dashboard In-Reply-To: <3292089.JALHGOf2On@drazi> References: <1721857.RCE4EdRJxR@drazi> <3292089.JALHGOf2On@drazi> Message-ID: <2468179.pl8xP86s9I@drazi> OK, this patch is bogus. Because cmCTestBuildHandler::LaunchHelper::LaunchHelper should call MakeDirectory already if this->Handler->UseCTestLaunch is true. Makes my test results even more strange then. On Friday 24 July 2015 11:28:13 Matthias Kretz wrote: > On Friday 24 July 2015 10:23:48 Matthias Kretz wrote: > > set(ENV{CTEST_USE_LAUNCHERS_DEFAULT} "ON") > > > > I don't get any output on the CDash dashboard anymore. AFAICT the Build > > directory in Testing/tag/ is removed but never recreated. > > With the following patch I get output back to the dashboard: > --- a/Source/CTest/cmCTestLaunch.cxx > +++ b/Source/CTest/cmCTestLaunch.cxx > @@ -207,6 +207,7 @@ void cmCTestLaunch::ComputeFileNames() > this->LogDir = d; > cmSystemTools::ConvertToUnixSlashes(this->LogDir); > this->LogDir += "/"; > + cmSystemTools::MakeDirectory(this->LogDir); > > // We hash the input command working dir and command line to obtain > // a repeatable and (probably) unique name for log files. > > But the dashboard still shows the conflated output of the parallel build > instead of the correct context per source/object file. > > Cheers, > Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From kretz at kde.org Fri Jul 24 05:58:28 2015 From: kretz at kde.org (Matthias Kretz) Date: Fri, 24 Jul 2015 11:58:28 +0200 Subject: [CMake] using ctest launchers leads to empty warning/error messages on the dashboard In-Reply-To: <1721857.RCE4EdRJxR@drazi> References: <1721857.RCE4EdRJxR@drazi> Message-ID: <2574060.ICSdPpA8XF@drazi> On Friday 24 July 2015 10:23:48 Matthias Kretz wrote: > set(ENV{CTEST_USE_LAUNCHERS_DEFAULT} "ON") > > I don't get any output on the CDash dashboard anymore. AFAICT the Build > directory in Testing/tag/ is removed but never recreated. I.e. if I call Maybe the better lead: I made the UseLaunchers setting behave just as BuildDirectory, in terms of requiring its presence. And I get: Cannot find UseLaunchers key in the DartConfiguration.tcl But OTOH: grep Launch DartConfiguration.tcl UseLaunchers: ON Cheers, Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From nilsgladitz at gmail.com Fri Jul 24 08:41:10 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 24 Jul 2015 14:41:10 +0200 Subject: [CMake] using ctest launchers leads to empty warning/error messages on the dashboard In-Reply-To: <1721857.RCE4EdRJxR@drazi> References: <1721857.RCE4EdRJxR@drazi> Message-ID: <55B23266.3010007@gmail.com> On 07/24/2015 10:23 AM, Matthias Kretz wrote: > set(ENV{CTEST_USE_LAUNCHERS_DEFAULT} "ON") Is that in your ctest -S script? Do you also have set(CTEST_USE_LAUNCHERS ON) in the same script? Nils From rcdailey.lists at gmail.com Fri Jul 24 10:56:55 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 24 Jul 2015 09:56:55 -0500 Subject: [CMake] Is add_definitions() still recommended? Message-ID: Starting with CMake 3.1, and going forward, is add_definitions() still recommended if you have preprocessor definitions you want included in all projects? The evolution of CMake appears to discourage setting global state in favor of relying more on target properties (for includes, definitions, and more). This usually requires me to create a wrapper function I use in all CMake scripts to generate targets, so it will handle setup common to all projects. Sometimes it's just easier to set global state. What's the desired design and structure intended going forward? From sebasvarma at gmail.com Fri Jul 24 13:12:43 2015 From: sebasvarma at gmail.com (michelle lopez) Date: Fri, 24 Jul 2015 12:12:43 -0500 Subject: [CMake] Running a program post-build Message-ID: Hello. This is my first time using cmake. How do I get a program that is built to run in cmake? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Fri Jul 24 15:02:21 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri, 24 Jul 2015 15:02:21 -0400 Subject: [CMake] Rerun CMake partially in Visual Studio In-Reply-To: <20150724070833.81E1EB0D02@public.kitware.com> References: <55B0FC5C.8060307@kitware.com> <20150724070833.81E1EB0D02@public.kitware.com> Message-ID: <55B28BBD.2040208@kitware.com> On 7/24/2015 3:01 AM, Nagy-Egri M?t? Ferenc via CMake wrote: > May I ask what you mean by ?editors?? Do you mean GUI editors to > managing CMake projects? > > M?t? > Yes, things like QtCreator. Or future IDEs that might use CMake as a build system. -Bill From diltsman at gmail.com Fri Jul 24 18:02:28 2015 From: diltsman at gmail.com (Daniel Dilts) Date: Fri, 24 Jul 2015 15:02:28 -0700 Subject: [CMake] Getting Location of This File Message-ID: I have a set of CMake commands that I want to place in a single file and have other projects use it. The commands in the file must affect the scope that references it, so the declared functions, include_directories, etc. must affect things in the scope that includes it. I attempted to place these things in a file and use include(filename.cmake) to add the file. This appears to work until the file with the include() is in a different location. I need the include_directories to be relative to the location of filename.cmake, not the CMakeLists.txt that included it. Is there any way to accomplish this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Jul 24 22:40:07 2015 From: d3ck0r at gmail.com (J Decker) Date: Fri, 24 Jul 2015 19:40:07 -0700 Subject: [CMake] Getting Location of This File In-Reply-To: References: Message-ID: ${CMAKE_SOURCE_DIR} - path of the root cmake file called ${CMAKE_CURRENT_SOURCE_DIR} - path of the current cmakelists On Fri, Jul 24, 2015 at 3:02 PM, Daniel Dilts wrote: > I have a set of CMake commands that I want to place in a single file and > have other projects use it. The commands in the file must affect the scope > that references it, so the declared functions, include_directories, etc. > must affect things in the scope that includes it. > > I attempted to place these things in a file and use > include(filename.cmake) to add the file. This appears to work until the > file with the include() is in a different location. > > I need the include_directories to be relative to the location of > filename.cmake, not the CMakeLists.txt that included it. > > Is there any way to accomplish this? > > -- > > 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 irwin at beluga.phys.uvic.ca Fri Jul 24 22:25:21 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 24 Jul 2015 19:25:21 -0700 (PDT) Subject: [CMake] Using cmake on the MSYS2 platform(s) Message-ID: Recently, I have found two useful resources () and ) giving advice on how to use cmake with MSYS2 and its collection of packages compiled with either the the mingw-w64-i686 or mingw-w64-x86_64 toolchains. (For further background on MSYS2, its tool chains, and it's pacman package repositories see .) The cmake advice from the openwalnut and allegro sites is essentially consistent except for one issue which is what generator to use? The openwalnut site recommends "Unix Makefiles" to build openwalnut while the allegro site recommends "MSYS Makefiles" to build allegro. Although I am sure those two generators work for their own peculiar build needs on the MSYS2 platforms is there a general recommendation that anyone here has for the recommended generator to use for the MSYS2 platforms? Note this question and the openwalnut and allegro comments are concerned with the case where you are using MSYS2 build tools (e.g., make, pkg-config, grep, sed, gzip, and tar) and not the case where you are building using either of the mingw-w64-i686 or mingw-w64-x86_64 toolchains without the MSYS2 build tools. Also note that although the MSYS2 project is a similar concept to classical MSYS (which is an ancient spin-off from Cygwin), the details can be quite different because MSYS2 is a modern spin-off from Cygwin. Therefore, recommending a MinGW/MSYS solution e.g., "MSYS Makefiles" for the MSYS2 case may or may not be more appropriate than recommending a Cygwin solution, e.g., "Unix Makefiles" for the MSYS2 case. So what I need here is a recommendation based on actual experience with MSYS2 and not MSYS. 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 diltsman at gmail.com Sat Jul 25 00:30:29 2015 From: diltsman at gmail.com (Daniel Dilts) Date: Fri, 24 Jul 2015 21:30:29 -0700 Subject: [CMake] Getting Location of This File In-Reply-To: References: Message-ID: Yes, ${CMAKE_CURRENT_SOURCE_DIR} has the path to the CMakeLists.txt file that has the include() command. Is there a variable with the path of the file referenced by the include() command? On Fri, Jul 24, 2015 at 7:40 PM, J Decker wrote: > ${CMAKE_SOURCE_DIR} - path of the root cmake file called > ${CMAKE_CURRENT_SOURCE_DIR} - path of the current cmakelists > > On Fri, Jul 24, 2015 at 3:02 PM, Daniel Dilts wrote: > >> I have a set of CMake commands that I want to place in a single file and >> have other projects use it. The commands in the file must affect the scope >> that references it, so the declared functions, include_directories, etc. >> must affect things in the scope that includes it. >> >> I attempted to place these things in a file and use >> include(filename.cmake) to add the file. This appears to work until the >> file with the include() is in a different location. >> >> I need the include_directories to be relative to the location of >> filename.cmake, not the CMakeLists.txt that included it. >> >> Is there any way to accomplish this? >> >> -- >> >> 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 d3ck0r at gmail.com Sat Jul 25 00:45:48 2015 From: d3ck0r at gmail.com (J Decker) Date: Fri, 24 Jul 2015 21:45:48 -0700 Subject: [CMake] Getting Location of This File In-Reply-To: References: Message-ID: On Fri, Jul 24, 2015 at 9:30 PM, Daniel Dilts wrote: > Yes, ${CMAKE_CURRENT_SOURCE_DIR} has the path to the CMakeLists.txt file > that has the include() command. Is there a variable with the path of the > file referenced by the include() command? > Could define such a variable before the include... then the included file could reference that variable? > > On Fri, Jul 24, 2015 at 7:40 PM, J Decker wrote: > >> ${CMAKE_SOURCE_DIR} - path of the root cmake file called >> ${CMAKE_CURRENT_SOURCE_DIR} - path of the current cmakelists >> >> On Fri, Jul 24, 2015 at 3:02 PM, Daniel Dilts wrote: >> >>> I have a set of CMake commands that I want to place in a single file and >>> have other projects use it. The commands in the file must affect the scope >>> that references it, so the declared functions, include_directories, etc. >>> must affect things in the scope that includes it. >>> >>> I attempted to place these things in a file and use >>> include(filename.cmake) to add the file. This appears to work until the >>> file with the include() is in a different location. >>> >>> I need the include_directories to be relative to the location of >>> filename.cmake, not the CMakeLists.txt that included it. >>> >>> Is there any way to accomplish this? >>> >>> -- >>> >>> 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 audiofanatic at gmail.com Sat Jul 25 03:20:47 2015 From: audiofanatic at gmail.com (Craig Scott) Date: Sat, 25 Jul 2015 17:20:47 +1000 Subject: [CMake] Building gtest with ExternalProject at configure time Message-ID: Hi all. I was surprised recently to find little in the way of a simple method to build gtest as part of a CMake project without having to either (a) add the gtest source to my own project or (b) use ExternalProject and then have to manually create import libraries for tests to link against. Since neither option was particularly appealing, I found a way to combine the best of both approaches without the downsides subsequently wrote a blog article showing how to do it. The general gist of it is to use ExternalProject to download at configure time and then add the gtest source to your project using add_subdirectory(). This means gtest builds with the same compiler and settings as the rest of your project, but it does not require adding the gtest source to your project tree. The gtest and gtest_main CMake targets are automatically available in your project without having to define any import libraries manually. The method I used was relatively straightforward, I create a sub-project in the main project's build area and build it as part of the main CMake step. All the sub-project does is use ExternalProject to download the gtest source to a defined location, so the main project then has the source already in place and can therefore use add_subdirectory() to bring gtest into your main project. It turns out that it was also easy to make the approach generic so it could be applied to any external CMake-based project. The blog article with all the details can be found here: http://crascit.com/2015/07/25/cmake-gtest/ What struck me after investigating and implementing this was how useful it might be if ExternalProject had an option which made it run (at least some steps) at configure time (i.e. when CMake is run) rather than at build time. My approach seems to suggest it may not be all that hard, but the ExternalProject implementation is more involved than I wanted to pick apart. If anyone wants to explore it, my blog article probably shows you enough of a clue to how it might be possible to do it. -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dseaward925 at gmail.com Sat Jul 25 03:52:43 2015 From: dseaward925 at gmail.com (David Seaward) Date: Sat, 25 Jul 2015 09:52:43 +0200 Subject: [CMake] Why would CMake add dependencies to libgomp? Message-ID: Hi, I am generating Code::Blocks project files using CMake GUI. When I do this dependencies to GOMP/libgomp are added to the project makefiles. If I remove them manually, then make the project, they are added again (and the build fails because they are there and I don't have libgomp). Is there any reason why CMake would be inserting these dependencies to GOMP? Given that they are being added, is there any way to suppress/inhibit them? Perhaps by setting a value via the CMake GUI interface? (A full explanation of my build attempt is given here http://stackoverflow.com/questions/31614268 , but I was wondering if there was a CMake-specific cause or workaround.) Many thanks, David From nilsgladitz at gmail.com Sat Jul 25 04:08:57 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sat, 25 Jul 2015 10:08:57 +0200 Subject: [CMake] Why would CMake add dependencies to libgomp? In-Reply-To: References: Message-ID: <55B34419.3000102@gmail.com> On 25.07.2015 09:52, David Seaward wrote: > Hi, > > I am generating Code::Blocks project files using CMake GUI. When I do > this dependencies to GOMP/libgomp are added to the project makefiles. > If I remove them manually, then make the project, they are added again > (and the build fails because they are there and I don't have libgomp). > From the looks of it libpointmatcher links to the libraries in ${libnabo_LIBRARIES}: https://github.com/ethz-asl/libpointmatcher/blob/master/CMakeLists.txt#L137 And libnabo_LIBRARIES contains "gomp" when using gcc: https://github.com/ethz-asl/libnabo/blob/master/libnaboConfig.cmake.in#L11 Nils From foss at grueninger.de Sat Jul 25 04:04:16 2015 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Sat, 25 Jul 2015 10:04:16 +0200 Subject: [CMake] Tests 115, 116, 117 and, 118 fail Message-ID: <55B34300.9070403@grueninger.de> Dear CMake, I am trying to create a CMake 3.3.0 RPM for openSuse using their Open Build Service. It compiles but the tests 115, 116, 117 and, 118 fail. The RPM build causes the error but I don't get what I should change. I attached the output. Bye Christoph -- I'm OK. The world's all wrong. -- Harry Weese -------------- next part -------------- [ 512s] 123/386 Test #115: CPackComponentsForAll-RPM-default ................***Failed 2.16 sec [ 512s] Generate graphviz: /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/CPackComponentsForAll.dot [ 512s] Writing /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/CPackComponentsForAll.dot.mylib... [ 512s] Writing /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/CPackComponentsForAll.dot.mylibapp... [ 512s] Writing /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/CPackComponentsForAll.dot.mylibapp2... [ 512s] Writing /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/CPackComponentsForAll.dot.mylib.dependers... [ 512s] Writing /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/CPackComponentsForAll.dot.mylibapp.dependers... [ 512s] Writing /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/CPackComponentsForAll.dot.mylibapp2.dependers... [ 512s] Writing /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/CPackComponentsForAll.dot... [ 512s] Internal cmake changing into directory: /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default [ 512s] ======== CMake output ====== [ 512s] The C compiler identification is GNU 5.1.1 [ 512s] The CXX compiler identification is GNU 5.1.1 [ 512s] Check for working C compiler: /usr/bin/cc [ 512s] Configuring [ 512s] Check for working C compiler: /usr/bin/cc -- works [ 512s] Detecting C compiler ABI info [ 512s] Configuring [ 512s] Detecting C compiler ABI info - done [ 512s] Detecting C compile features [ 512s] Configuring [ 512s] Configuring [ 512s] Configuring [ 512s] Detecting C compile features - done [ 512s] Check for working CXX compiler: /usr/bin/c++ [ 512s] Configuring [ 512s] Check for working CXX compiler: /usr/bin/c++ -- works [ 512s] Detecting CXX compiler ABI info [ 512s] Configuring [ 512s] Detecting CXX compiler ABI info - done [ 512s] Detecting CXX compile features [ 512s] Configuring [ 512s] Configuring [ 512s] Configuring [ 512s] Detecting CXX compile features - done [ 512s] Configuring [ 512s] Configuring done [ 512s] Generating [ 512s] Generating done [ 512s] Build files have been written to: /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default [ 512s] ======== End CMake output ====== [ 512s] Change Dir: /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default [ 512s] [ 512s] Run Clean Command:"/usr/bin/gmake" "clean" [ 512s] [ 512s] Run Build Command:"/usr/bin/gmake" [ 512s] Scanning dependencies of target mylib [ 512s] [ 16%] Building CXX object CMakeFiles/mylib.dir/mylib.cpp.o [ 512s] [ 33%] Linking CXX static library libmylib.a [ 512s] [ 33%] Built target mylib [ 512s] Scanning dependencies of target mylibapp [ 512s] [ 50%] Building CXX object CMakeFiles/mylibapp.dir/mylibapp.cpp.o [ 512s] [ 66%] Linking CXX executable mylibapp [ 512s] [ 66%] Built target mylibapp [ 512s] Scanning dependencies of target mylibapp2 [ 512s] [ 83%] Building CXX object CMakeFiles/mylibapp2.dir/mylibapp.cpp.o [ 512s] [100%] Linking CXX executable mylibapp2 [ 512s] [100%] Built target mylibapp2 [ 512s] Running test command: "/home/abuild/rpmbuild/BUILD/cmake-3.3.0/bin/cmake" "-DCPackComponentsForAll_BINARY_DIR:PATH=/home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default" "-DCPackGen=RPM" "-DCPackComponentWay=default" "-P" "/home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/RunCPackVerifyResult.cmake" [ 512s] Test command failed: /home/abuild/rpmbuild/BUILD/cmake-3.3.0/bin/cmake [ 512s] -- ============================================================================= [ 512s] -- CTEST_FULL_OUTPUT (Avoid ctest truncation of output) [ 512s] -- [ 512s] CMAKE_CPACK_COMMAND = /home/abuild/rpmbuild/BUILD/cmake-3.3.0/bin/cpack [ 512s] config_args = -C;NoConfig [ 512s] config_verbose = -D;CPACK_RPM_PACKAGE_DEBUG=1 [ 512s] CMake Error at /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/RunCPackVerifyResult.cmake:105 (message): [ 512s] error: CPack execution went wrong!, CPack_output=CPack: Create package [ 512s] using RPM [ 512s] [ 512s] CPack: Install projects [ 512s] [ 512s] CPack: - Run preinstall target for: CPackComponentsForAll [ 512s] [ 512s] CPack: - Install project: CPackComponentsForAll [ 512s] [ 512s] CPack: Create package [ 512s] [ 512s] , CPack_error=CPackRPM:Debug: rpmbuild version is <4.12.0.1> [ 512s] [ 512s] CPackRPM:Debug: LSB_RELEASE = lsb_release not installed/found! [ 512s] [ 512s] CPackRPM:Debug: Trying to build a relocatable package [ 512s] [ 512s] CPackRPM:Debug: removing '/usr' from relocation paths [ 512s] [ 512s] CPackRPM:Debug: processing URL [ 512s] [ 512s] CPackRPM:Debug: processing REQUIRES [ 512s] [ 512s] CPackRPM:Debug: processing SUGGESTS [ 512s] [ 512s] CPackRPM:Debug: processing PROVIDES [ 512s] [ 512s] CPackRPM:Debug: processing OBSOLETES [ 512s] [ 512s] CPackRPM:Debug: processing PREFIX [ 512s] [ 512s] CPackRPM:Debug: using CPACK_RPM_PACKAGE_PREFIX [ 512s] [ 512s] CPackRPM:Debug: User defined Prefix: [ 512s] [ 512s] /usr [ 512s] [ 512s] CPackRPM:Debug: processing CONFLICTS [ 512s] [ 512s] CPackRPM:Debug: processing AUTOPROV [ 512s] [ 512s] CPackRPM:Debug: processing AUTOREQ [ 512s] [ 512s] CPackRPM:Debug: processing AUTOREQPROV [ 512s] [ 512s] CPackRPM:Debug: processing REQUIRES_PRE [ 512s] [ 512s] CPackRPM:Debug: processing REQUIRES_POST [ 512s] [ 512s] CPackRPM:Debug: processing REQUIRES_PREUN [ 512s] [ 512s] CPackRPM:Debug: processing REQUIRES_POSTUN [ 512s] [ 512s] CPackRPM:Debug: Initial list of path to OMIT in RPM: [ 512s] [ 512s] CPackRPM:Debug: CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST= [ 512s] /etc;/etc/init.d;/usr;/usr/share;/usr/share/doc;/usr/bin;/usr/lib;/usr/lib64;/usr/include [ 512s] [ 512s] [ 512s] CPackRPM:Debug: Final list of path to OMIT in RPM: [ 512s] /etc;/etc/init.d;/usr;/usr/share;/usr/share/doc;/usr/bin;/usr/lib;/usr/lib64;/usr/include [ 512s] [ 512s] [ 512s] CPackRPM:Debug: CPACK_TOPLEVEL_DIRECTORY = [ 512s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/_CPack_Packages/Linux/RPM [ 512s] [ 512s] [ 512s] CPackRPM:Debug: CPACK_TOPLEVEL_TAG = Linux [ 512s] [ 512s] CPackRPM:Debug: CPACK_TEMPORARY_DIRECTORY = [ 512s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/_CPack_Packages/Linux/RPM/MyLib-1.0.2-Linux [ 512s] [ 512s] [ 512s] CPackRPM:Debug: CPACK_OUTPUT_FILE_NAME = MyLib-1.0.2-Linux.rpm [ 512s] [ 512s] CPackRPM:Debug: CPACK_OUTPUT_FILE_PATH = [ 512s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/MyLib-1.0.2-Linux.rpm [ 512s] [ 512s] [ 512s] CPackRPM:Debug: CPACK_PACKAGE_FILE_NAME = MyLib-1.0.2-Linux [ 512s] [ 512s] CPackRPM:Debug: CPACK_RPM_BINARY_SPECFILE = [ 512s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/_CPack_Packages/Linux/RPM/SPECS/mylib.spec [ 512s] [ 512s] [ 512s] CPackRPM:Debug: CPACK_PACKAGE_INSTALL_DIRECTORY = CPack Component Example [ 512s] [ 512s] CPackRPM:Debug: CPACK_TEMPORARY_PACKAGE_FILE_NAME = [ 512s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/_CPack_Packages/Linux/RPM/MyLib-1.0.2-Linux.rpm [ 512s] [ 512s] [ 512s] CPackRPM: Will use GENERATED spec file: [ 512s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/_CPack_Packages/Linux/RPM/SPECS/mylib.spec [ 512s] [ 512s] [ 512s] CPackRPM:Debug: You may consult rpmbuild logs in: [ 512s] [ 512s] CPackRPM:Debug: - [ 512s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/_CPack_Packages/Linux/RPM/rpmbuild.err [ 512s] [ 512s] [ 512s] CPackRPM:Debug: *** + umask 022 [ 512s] [ 512s] + cd [ 512s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/_CPack_Packages/Linux/RPM/BUILD [ 512s] [ 512s] [ 512s] + mv [ 512s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/_CPack_Packages/Linux/RPM/MyLib-1.0.2-Linux [ 512s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/_CPack_Packages/Linux/RPM/tmpBBroot [ 512s] [ 512s] [ 512s] + exit 0 [ 512s] [ 512s] + umask 022 [ 512s] [ 512s] + cd [ 512s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/_CPack_Packages/Linux/RPM/BUILD [ 512s] [ 512s] [ 512s] + '[' -e [ 512s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/_CPack_Packages/Linux/RPM/MyLib-1.0.2-Linux [ 512s] ']' [ 512s] [ 512s] + mv [ 512s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/_CPack_Packages/Linux/RPM/tmpBBroot [ 513s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/_CPack_Packages/Linux/RPM/MyLib-1.0.2-Linux [ 513s] [ 513s] [ 513s] + /usr/lib/rpm/brp-compress [ 513s] [ 513s] + /usr/lib/rpm/brp-suse [ 513s] [ 513s] error: Bad exit status from /var/tmp/rpm-tmp.kuAXCf (%install) [ 513s] [ 513s] Bad exit status from /var/tmp/rpm-tmp.kuAXCf (%install) [ 513s] *** [ 513s] [ 513s] CPackRPM:Debug: - [ 513s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/_CPack_Packages/Linux/RPM/rpmbuild.out [ 513s] [ 513s] [ 513s] CPackRPM:Debug: *** Building target platforms: x86_64 [ 513s] [ 513s] Building for target x86_64 [ 513s] [ 513s] Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.KlszZP [ 513s] [ 513s] Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.kuAXCf [ 513s] [ 513s] calling /usr/lib/rpm/brp-suse.d/brp-05-permissions [ 513s] [ 513s] setting / to root:root 0755. (wrong owner/group abuild:abuild) [ 513s] [ 513s] setting /usr/ to root:root 0755. (wrong owner/group abuild:abuild) [ 513s] [ 513s] calling /usr/lib/rpm/brp-suse.d/brp-15-strip-debug [ 513s] [ 513s] calling /usr/lib/rpm/brp-suse.d/brp-25-symlink [ 513s] [ 513s] INFO: relinking [ 513s] /usr/non_relocatable/depth_two/symlink_from_non_relocatable_path -> [ 513s] ../../lib64/inside_relocatable_two/depth_two (was [ 513s] .././../lib64/inside_relocatable_two/depth_two) [ 513s] [ 513s] INFO: relinking /usr/lib64/inside_relocatable_one/symlink_subdir_path -> [ 513s] depth_two/depth_three (was [ 513s] ../../lib64/inside_relocatable_one/depth_two/depth_three) [ 513s] [ 513s] INFO: relinking [ 513s] /usr/lib64/inside_relocatable_one/depth_two/symlink_samedir_path_current_dir [ 513s] -> depth_three (was ./depth_three) [ 513s] [ 513s] INFO: relinking [ 513s] /usr/lib64/inside_relocatable_one/depth_two/depth_three/symlink_parentdir_path [ 513s] -> ../depth_two (was [ 513s] .././../../../lib64/inside_relocatable_one/./depth_two) [ 513s] [ 513s] ERROR: link target doesn't exist (neither in build root nor in installed [ 513s] system): [ 513s] [ 513s] /usr/lib64/inside_relocatable_one/depth_two/symlink_outside_package -> /usr/lib64/inside_relocatable_one/depth_two/outside_package [ 513s] [ 513s] Add the package providing the target to neededforbuild and Requires [ 513s] [ 513s] INFO: relinking [ 513s] /usr/lib64/inside_relocatable_one/depth_two/symlink_outside_package -> [ 513s] outside_package (was ./outside_package) [ 513s] [ 513s] INFO: relinking [ 513s] /usr/lib64/inside_relocatable_one/depth_two/symlink_samedir_path_longer -> [ 513s] depth_three (was [ 513s] ../../../lib64/.././lib64/inside_relocatable_one/./depth_two/depth_three) [ 513s] [ 513s] INFO: relinking [ 513s] /usr/lib64/inside_relocatable_two/depth_two/symlink_to_non_relocatable_path [ 513s] -> ../../../non_relocatable/depth_two (was [ 513s] .././../../non_relocatable/./depth_two) [ 513s] [ 513s] INFO: relinking [ 513s] /usr/lib64/inside_relocatable_two/depth_two/symlink_other_relocatable_path [ 513s] -> ../../../other_relocatable/depth_two (was [ 513s] .././.././../other_relocatable/./depth_two) [ 513s] [ 513s] [ 513s] [ 513s] [ 513s] [ 513s] RPM build errors: [ 513s] [ 513s] *** [ 513s] [ 513s] CPack Error: Problem copying the package: [ 513s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/_CPack_Packages/Linux/RPM/MyLib-1.0.2-Linux.rpm [ 513s] to [ 513s] /home/abuild/rpmbuild/BUILD/cmake-3.3.0/Tests/CPackComponentsForAll/buildRPM-default/MyLib-1.0.2-Linux.rpm [ 513s] [ 513s] [ 513s] CPack Error: Error when generating package: MyLib [ 513s] [ 513s] From micha.hergarden at gmail.com Sat Jul 25 04:35:25 2015 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Sat, 25 Jul 2015 10:35:25 +0200 Subject: [CMake] Running a program post-build In-Reply-To: References: Message-ID: <55B34A4D.4080100@gmail.com> On 07/24/2015 07:12 PM, michelle lopez wrote: > Hello. This is my first time using cmake. How do I get a program > that is built to run in cmake? > > Hello Michelle, Could you elaborate on that? If you want one of the targets being built to run as part of the whole project build, you can use the 'add_custom_target()' command to add another target that will run your program. regards, Micha -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From ruslan_baratov at yahoo.com Sat Jul 25 08:01:45 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sat, 25 Jul 2015 15:01:45 +0300 Subject: [CMake] Building gtest with ExternalProject at configure time In-Reply-To: References: Message-ID: <55B37AA9.1000401@yahoo.com> On 25-Jul-15 10:20, Craig Scott wrote: > Hi all. I was surprised recently to find little in the way of a simple > method to build gtest as part of a CMake project without having to > either (a) add the gtest source to my own project or (b) use > ExternalProject and then have to manually create import libraries for > tests to link against. Since neither option was particularly > appealing, I found a way to combine the best of both approaches > without the downsides subsequently wrote a blog article showing how to > do it. The general gist of it is to use ExternalProject to download at > configure time and then add the gtest source to your project using > add_subdirectory(). This means gtest builds with the same compiler and > settings as the rest of your project, but it does not require adding > the gtest source to your project tree. The gtest and gtest_main CMake > targets are automatically available in your project without having to > define any import libraries manually. > > The method I used was relatively straightforward, I create a > sub-project in the main project's build area and build it as part of > the main CMake step. All the sub-project does is use ExternalProject > to download the gtest source to a defined location, so the main > project then has the source already in place and can therefore use > add_subdirectory() to bring gtest into your main project. It turns out > that it was also easy to make the approach generic so it could be > applied to any external CMake-based project. The blog article with all > the details can be found here: > > http://crascit.com/2015/07/25/cmake-gtest/ > > What struck me after investigating and implementing this was how > useful it might be if ExternalProject had an option which made it run > (at least some steps) at configure time (i.e. when CMake is run) > rather than at build time. My approach seems to suggest it may not be > all that hard, but the ExternalProject implementation is more involved > than I wanted to pick apart. If anyone wants to explore it, my blog > article probably shows you enough of a clue to how it might be > possible to do it. > > -- > Craig Scott > Melbourne, Australia > http://crascit.com > > Hi, I've leaved a small comment in your blog but don't see it :) So I reply here. In short find_package is much more convenient option than add_subdirectory so it's still better to run install (I know that this particular GTest project doesn't have install by default). Also there are a lot of other stuff you need to solve to generalize this approach. For instance version of GTest saved in gtest-CMakeLists.txt of local project, assume: A use GTest 1.0, B use GTest 2.0, C use A and B - what version of GTest we should use? If you're interested here is a package manager I'm working on: https://github.com/ruslo/hunter. GTest package: https://github.com/ruslo/hunter/wiki/pkg.gtest Cheers, Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Sat Jul 25 08:07:56 2015 From: DLRdave at aol.com (David Cole) Date: Sat, 25 Jul 2015 08:07:56 -0400 Subject: [CMake] Getting Location of This File In-Reply-To: References: Message-ID: I think http://www.cmake.org/cmake/help/v3.3/variable/CMAKE_CURRENT_LIST_FILE.html is exactly what you're asking for, and will work in most contexts you're thinking of. (Configuring from a top level or sub-directory CMakeLists file, in an included file, running a CMake -P script file...) The only thing I'd say you should watch out for is using it inside a function you define. I think it evaluates to the location where the function is being called from, so in that case, it would NOT be the file it's defined in (necessarily)... I could be wrong on this point, though, so you should double check experimentally. Or by analyzing the CMake source. HTH, David C. On Saturday, July 25, 2015, J Decker wrote: > > > On Fri, Jul 24, 2015 at 9:30 PM, Daniel Dilts > wrote: > >> Yes, ${CMAKE_CURRENT_SOURCE_DIR} has the path to the CMakeLists.txt file >> that has the include() command. Is there a variable with the path of the >> file referenced by the include() command? >> > Could define such a variable before the include... then the included file > could reference that variable? > >> >> On Fri, Jul 24, 2015 at 7:40 PM, J Decker > > wrote: >> >>> ${CMAKE_SOURCE_DIR} - path of the root cmake file called >>> ${CMAKE_CURRENT_SOURCE_DIR} - path of the current cmakelists >>> >>> On Fri, Jul 24, 2015 at 3:02 PM, Daniel Dilts >> > wrote: >>> >>>> I have a set of CMake commands that I want to place in a single file >>>> and have other projects use it. The commands in the file must affect the >>>> scope that references it, so the declared functions, include_directories, >>>> etc. must affect things in the scope that includes it. >>>> >>>> I attempted to place these things in a file and use >>>> include(filename.cmake) to add the file. This appears to work until the >>>> file with the include() is in a different location. >>>> >>>> I need the include_directories to be relative to the location of >>>> filename.cmake, not the CMakeLists.txt that included it. >>>> >>>> Is there any way to accomplish this? >>>> >>>> -- >>>> >>>> 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 DLRdave at aol.com Sat Jul 25 08:14:47 2015 From: DLRdave at aol.com (David Cole) Date: Sat, 25 Jul 2015 08:14:47 -0400 Subject: [CMake] Building gtest with ExternalProject at configure time In-Reply-To: References: Message-ID: Interesting idea. I can say for sure one of the reasons we didn't take this approach when we first built ExternalProject was to avoid spending significant time on ANYTHING during the CMake configure of the main project. Deferring everything time-consuming to build time, after the configure step, was always top of mind... Having said that, though, the line of division between an internal project (add_subdirectory) and external projects has always been a source of confusion for people coming into it fresh. So a blended approach like what you propose here could be quite useful. I wonder if we should add an entirely separate module for such a thing...? Perhaps called ImportedProject or something similar. I think adding to ExternalProject for this would be the wrong approach because it's not really "external" anymore once you start using add_subdirectory. I'm happy to go along with the consensus, though, if most others think differently that this. Thanks for your work on this idea! David C. On Saturday, July 25, 2015, Craig Scott wrote: > Hi all. I was surprised recently to find little in the way of a simple > method to build gtest as part of a CMake project without having to either > (a) add the gtest source to my own project or (b) use ExternalProject and > then have to manually create import libraries for tests to link against. > Since neither option was particularly appealing, I found a way to combine > the best of both approaches without the downsides subsequently wrote a blog > article showing how to do it. The general gist of it is to use > ExternalProject to download at configure time and then add the gtest source > to your project using add_subdirectory(). This means gtest builds with the > same compiler and settings as the rest of your project, but it does not > require adding the gtest source to your project tree. The gtest and > gtest_main CMake targets are automatically available in your project > without having to define any import libraries manually. > > The method I used was relatively straightforward, I create a sub-project > in the main project's build area and build it as part of the main CMake > step. All the sub-project does is use ExternalProject to download the gtest > source to a defined location, so the main project then has the source > already in place and can therefore use add_subdirectory() to bring gtest > into your main project. It turns out that it was also easy to make the > approach generic so it could be applied to any external CMake-based > project. The blog article with all the details can be found here: > > http://crascit.com/2015/07/25/cmake-gtest/ > > What struck me after investigating and implementing this was how useful it > might be if ExternalProject had an option which made it run (at least some > steps) at configure time (i.e. when CMake is run) rather than at build > time. My approach seems to suggest it may not be all that hard, but the > ExternalProject implementation is more involved than I wanted to pick > apart. If anyone wants to explore it, my blog article probably shows you > enough of a clue to how it might be possible to do it. > > -- > Craig Scott > Melbourne, Australia > http://crascit.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsvanbethlehem at gmail.com Sat Jul 25 14:43:18 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Sat, 25 Jul 2015 20:43:18 +0200 Subject: [CMake] Rerun CMake partially in Visual Studio In-Reply-To: <55B28BBD.2040208@kitware.com> References: <55B0FC5C.8060307@kitware.com> <20150724070833.81E1EB0D02@public.kitware.com> <55B28BBD.2040208@kitware.com> Message-ID: <01B2C021-4FD1-4D18-B191-E111FE8C6802@gmail.com> >> > Yes, things like QtCreator. Or future IDEs that might use CMake as a build system. > FYI: CLion by Jetbrains is the first IDE I know of that fully integrates CMake natively. If that IDE is as good as their Python IDE I worked with in the past, I may yet spend some bucks on it :) Sincerely, Jakob From digitalriptide at gmail.com Sat Jul 25 14:47:38 2015 From: digitalriptide at gmail.com (digitalriptide) Date: Sat, 25 Jul 2015 11:47:38 -0700 Subject: [CMake] Fortran and Ninja Support? Message-ID: Dear CMake Community, I recently tried to use the Ninja generator with a project that has Fortran source files, but CMake returned an error stating that Ninja and Fortran are not yet compatible with CMake. Is this feature planned for the future? Thank you kindly! From roman.wueger at gmx.at Mon Jul 27 01:34:34 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Mon, 27 Jul 2015 07:34:34 +0200 Subject: [CMake] check_cxx_source_compiles and include directories Message-ID: <419A5EC7-E63B-4691-9643-07A34EB376C1@gmx.at> Hello, I've a small code example to test if the header file exists (with check_cxx_source_compiles), which sets my variable successfully to TRUE. When I compile the real code then I got an error message saying 'mutex' file not found. I checked the compile flags for both situations and these are equal. So I thought that the include directories could be the problem. Any hints? Best Regards Roman From florian.reinhard at googlemail.com Mon Jul 27 06:37:39 2015 From: florian.reinhard at googlemail.com (Florian Reinhard) Date: Mon, 27 Jul 2015 12:37:39 +0200 Subject: [CMake] TI-C CMAKE_C_LINK_EXECUTABLE order In-Reply-To: <3960370AB9E94C4F99461A0A6C2C3BA00290B23450@blitzpost2.europe.pc.cognex.com> References: <3960370AB9E94C4F99461A0A6C2C3BA00290B23450@blitzpost2.europe.pc.cognex.com> Message-ID: Hi Falk, the TI Docs contains the following line: cl6x --run_linker {--rom_model | --ram_model} filenames [options] [--output_file= name.out] --library= library [lnk.cmd] therefore i'd suggest the following changes: set(CMAKE_C_LINK_EXECUTABLE " --run_linker --map_file=.map --output_file= ") set(CMAKE_ASM_LINK_EXECUTABLE " --run_linker --map_file=.map --output_file= ") set(CMAKE_CXX_LINK_EXECUTABLE " --run_linker --map_file=.map --output_file= ") I'm using it on a c++ project, linker language is c, the c/c++ line above works for me. I didn't test ASM, but i guess that's straight forward. Maybe Alex Neundorf can do this change . Regards, Florian 2015-05-28 8:15 GMT+02:00 Tristram, Falk : > Hi all, > > > > before creating a bug report about this problem, I first want to get > feedback here. > > I have created a CMake build system for a whole bunch of embedded targets > all working fine. > > > > Now I ran into a strange problem related to the tms470_5.0.1. > > Some of the symbols are just dropped by linker (optimized out). > > I pinned down the problem to the ?TI-C.cmake?. > > > > set(CMAKE_C_LINK_EXECUTABLE " --run_linker > --output_file= --map_file=.map > ") > > > > is the last entry. > > In my case OBJECTS just consists out of one file ?main.c.obj?. > > > > Changing the order just works fine, as follows: > > set(CMAKE_C_LINK_EXECUTABLE " --run_linker > --output_file= --map_file=.map > ") > > > > Now here is my question: > > Is there any specific reason why comes as last parameter? > > Could you change the order for future versions? > > > > Note: I am still checking/testing the impact of the changed order to our > other TI-C build systems. > > > > Best regards, > > Falk > > -- > > 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 apaku at gmx.de Mon Jul 27 08:25:41 2015 From: apaku at gmx.de (Andreas Pakulat) Date: Mon, 27 Jul 2015 14:25:41 +0200 Subject: [CMake] Packaging debug symbol files on Windows Message-ID: Hi, I'm trying to generate a zip file (on Windows) for a shared library including the generated debug symbols in pdb files with CPack. Unfortunately CPack does not seem to pick up the pdb files all by itself and after cross-reading the cpack docs in the cmake wiki I didn't see any switch to enable such behavior. Did somebody already do this and if so how? Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Jul 27 09:12:07 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 27 Jul 2015 15:12:07 +0200 Subject: [CMake] Packaging debug symbol files on Windows In-Reply-To: References: Message-ID: <55B62E27.5000904@gmail.com> On 07/27/2015 02:25 PM, Andreas Pakulat wrote: > Hi, > > I'm trying to generate a zip file (on Windows) for a shared library > including the generated debug symbols in pdb files with CPack. > Unfortunately CPack does not seem to pick up the pdb files all by itself > and after cross-reading the cpack docs in the cmake wiki I didn't see > any switch to enable such behavior. > > Did somebody already do this and if so how? What gets installed is decided by install() commands in your project rather than by CPack. You can use the $ [1] generator expression to install pdb files. e.g. install(FILES $ DESTINATION bin) Nils [1] http://www.cmake.org/cmake/help/v3.3/manual/cmake-generator-expressions.7.html From apaku at gmx.de Mon Jul 27 09:46:37 2015 From: apaku at gmx.de (Andreas Pakulat) Date: Mon, 27 Jul 2015 15:46:37 +0200 Subject: [CMake] Packaging debug symbol files on Windows In-Reply-To: <55B62E27.5000904@gmail.com> References: <55B62E27.5000904@gmail.com> Message-ID: Hi Nils, On Mon, Jul 27, 2015 at 3:12 PM, Nils Gladitz wrote: > On 07/27/2015 02:25 PM, Andreas Pakulat wrote: > >> Hi, >> >> I'm trying to generate a zip file (on Windows) for a shared library >> including the generated debug symbols in pdb files with CPack. >> Unfortunately CPack does not seem to pick up the pdb files all by itself >> and after cross-reading the cpack docs in the cmake wiki I didn't see >> any switch to enable such behavior. >> >> Did somebody already do this and if so how? >> > > What gets installed is decided by install() commands in your project > rather than by CPack. > > You can use the $ [1] generator expression to install > pdb files. > > e.g. install(FILES $ DESTINATION bin) > Ah, interesting. I would've thought that an install() would automatically include the pdb files, after all those are usually useful after the build process and the builddir is often gone once a library is being used. I've meanwhile also noticed that the default compiler flags that CMake uses include the debug information in the dll itself (dll size is doubled), so for now don't even have to have the separate pdb files packaged anymore (in this case the pdb info is small enough to just keep in the dll). Thanks for the pointer. Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Jul 27 09:58:11 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 27 Jul 2015 15:58:11 +0200 Subject: [CMake] Packaging debug symbol files on Windows In-Reply-To: References: <55B62E27.5000904@gmail.com> Message-ID: <55B638F3.7070608@gmail.com> On 07/27/2015 03:46 PM, Andreas Pakulat wrote: > I've meanwhile also noticed that the default compiler flags that CMake > uses include the debug information in the dll itself (dll size is > doubled), so for now don't even have to have the separate pdb files > packaged anymore (in this case the pdb info is small enough to just keep > in the dll). I am not entirely sure what you mean but CMake's default flags for the Visual Studio compiler when building "Debug" or "RelWithDebInfo" use /Zi (debug information in external pdb) rather than /Z7 (embedded debug information; no pdb is generated). Maybe your project replaces the default flags? Nils From apaku at gmx.de Mon Jul 27 12:13:16 2015 From: apaku at gmx.de (Andreas Pakulat) Date: Mon, 27 Jul 2015 18:13:16 +0200 Subject: [CMake] Packaging debug symbol files on Windows In-Reply-To: <55B638F3.7070608@gmail.com> References: <55B62E27.5000904@gmail.com> <55B638F3.7070608@gmail.com> Message-ID: Hi Nils, On Mon, Jul 27, 2015 at 3:58 PM, Nils Gladitz wrote: > On 07/27/2015 03:46 PM, Andreas Pakulat wrote: > >> I've meanwhile also noticed that the default compiler flags that CMake >> uses include the debug information in the dll itself (dll size is >> doubled), so for now don't even have to have the separate pdb files >> packaged anymore (in this case the pdb info is small enough to just keep >> in the dll). >> > > I am not entirely sure what you mean but CMake's default flags for the > Visual Studio compiler when building "Debug" or "RelWithDebInfo" use /Zi > (debug information in external pdb) rather than /Z7 (embedded debug > information; no pdb is generated). > > Maybe your project replaces the default flags? No Z7 or Zi anywhere in the CMake files and the generated makefiles include /Zi. So I don't know why the dll's would be bigger and generate proper backtrace information when analyzing a dump file but so it is and thats fine with me for now. Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From sepp2788 at gmail.com Mon Jul 27 13:57:04 2015 From: sepp2788 at gmail.com (Sepp Wolf) Date: Mon, 27 Jul 2015 19:57:04 +0200 Subject: [CMake] Cross compiling & conflicting declarations Message-ID: Hello, I'm using CMake 3.2.2 on Solaris 10 x86. I've built a toolchain to cross compile for SPARC, which is working fine for software with GNU autotools. But now I'm trying to compile Synergy, which is based on CMake, and I have lots of troubles with double declarations: [sepp at synergy /home/sepp/synergy]% gmake [ 0%] Building CXX object src/lib/arch/CMakeFiles/arch.dir/Arch.cpp.o In file included from /opt/cc_sparc/sysroot/usr/include/stdlib.h:17:0, from /home/sepp/synergy/src/lib/arch/../common/common.h:146, from /home/sepp/synergy/src/lib/arch/../arch/Arch.h:38, from /home/sepp/synergy/src/lib/arch/Arch.cpp:19: /opt/cc_sparc/sysroot/usr/include/iso/stdlib_iso.h:118:38: error: conflicting declaration of 'void* std::bsearch(const void*, const void*, std::size_t, std::size_t, int (*)(const void*, const void*))' with 'C++' linkage int (*)(const void *, const void *)); ^ /opt/cc_sparc/sysroot/usr/include/iso/stdlib_iso.h:113:14: note: previous declaration with 'C' linkage extern void *bsearch(const void *, const void *, size_t, size_t, ^ In file included from /opt/cc_sparc/sysroot/usr/include/iso/stdlib_iso.h:30:0, from /opt/cc_sparc/sysroot/usr/include/stdlib.h:17, from /home/sepp/synergy/src/lib/arch/../common/common.h:146, from /home/sepp/synergy/src/lib/arch/../arch/Arch.h:38, from /home/sepp/synergy/src/lib/arch/Arch.cpp:19: /opt/cc_sparc/sysroot/usr/include/iso/stdlib_iso.h:131:61: error: conflicting declaration 'const char* restrict' extern size_t mbstowcs(wchar_t *_RESTRICT_KYWD, const char *_RESTRICT_KYWD, ^ /opt/cc_sparc/sysroot/usr/include/iso/stdlib_iso.h:131:33: note: previous declaration as 'wchar_t* restrict' extern size_t mbstowcs(wchar_t *_RESTRICT_KYWD, const char *_RESTRICT_KYWD, ^ /opt/cc_sparc/sysroot/usr/include/iso/stdlib_iso.h:133:56: error: conflicting declaration 'const char* restrict' extern int mbtowc(wchar_t *_RESTRICT_KYWD, const char *_RESTRICT_KYWD, size_t); ^ /opt/cc_sparc/sysroot/usr/include/iso/stdlib_iso.h:133:28: note: previous declaration as 'wchar_t* restrict' extern int mbtowc(wchar_t *_RESTRICT_KYWD, const char *_RESTRICT_KYWD, size_t); [snip] My CMake Toolchain-file looks like this: # this one is important SET(CMAKE_SYSTEM_NAME SunOS) #this one not so much SET(CMAKE_SYSTEM_VERSION 1) # specify the cross compiler SET(CMAKE_C_COMPILER /opt/cc_sparc/bin/sparc-sun-solaris2.10-gcc) SET(CMAKE_CXX_COMPILER /opt/cc_sparc/bin/sparc-sun-solaris2.10-g++) SET(CMAKE_C_FLAGS "--sysroot=/opt/cc_sparc/sysroot") SET(CMAKE_CXX_FLAGS "--sysroot=/opt/cc_sparc/sysroot") SET(CURL_LIBRARY /opt/cc_sparc/sysroot/lib) SET(CURL_INCLUDE_DIR /opt/cc_sparc/sysroot/include) SET(CMAKE_SYSROOT_PATH /opt/cc_sparc/sysroot) # where is the target environment SET(CMAKE_FIND_ROOT_PATH "${CMAKE_SYSROOT_PATH}/usr/lib") # Don't search for programs in the host environment SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) # Search for the libraries and headers in the target environment SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) include_directories(SYSTEM /home/sepp/synergy/src/lib/common) include_directories(SYSTEM /opt/cc_sparc/sysroot/usr/include) include_directories(SYSTEM /opt/cc_sparc/sysroot/usr/include/c++/3.4.3) include_directories(SYSTEM /opt/cc_sparc/sysroot/usr/include/c++/3.4.3/sparc-sun-solaris2.10) --- When I compile the same code for Solaris 10 x86 without this toolchain and alternate sysroot, everything works fine. Can someone tell me what I'm doing wrong? Thanks From roman.wueger at gmx.at Mon Jul 27 15:26:18 2015 From: roman.wueger at gmx.at (=?iso-8859-1?Q?Roman_W=FCger?=) Date: Mon, 27 Jul 2015 21:26:18 +0200 Subject: [CMake] [cmake-developers] check_cxx_source_compiles and include directories In-Reply-To: <419A5EC7-E63B-4691-9643-07A34EB376C1@gmx.at> References: <419A5EC7-E63B-4691-9643-07A34EB376C1@gmx.at> Message-ID: <050101d0c8a2$1df05050$59d0f0f0$@gmx.at> So, here is the piece of code which works Main CMakeLists.txt: project(MyProject) list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake) if (APPLE) set(CMAKE_CXX_EXTENSIONS OFF) # Use -std=c++11 instead of -std=gnu++11 endif() set(CMAKE_CXX_STANDARD 11) include(CheckCXXCompilerFlag) # Required for check_cxx_source_cmopiles check_cxx_compiler_flag("-std=c++11" CXX11_FLAG) if (CXX11_FLAG) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") endif() include(CheckMyCXX11Features.cmake) . . . add_subdirectory(SubProj1) add_subdirectory(SubProj2) . . . CheckMyCXX11Features.cmake: include(CheckCXXSourceCompiles) # C++11 Unique Lock and Mutex set(CMAKE_REQUIRED_FLAGS "${CMAKE_CXX_FLAGS}") check_cxx_source_compiles( "#include // std::mutex, std::unique_lock std::mutex mtx; // mutex for critical section void print_block (int n, char c) { // critical section (exclusive access to std::cout signaled by lifetime of lck): std::unique_lock lck (mtx); for (int i=0; i, but check_cxx_source_compiles succeeds. Did I miss configure something here? Best Regards Roman > -----Urspr?ngliche Nachricht----- > Von: cmake-developers [mailto:cmake-developers-bounces at cmake.org] Im > Auftrag von Roman W?ger > Gesendet: Montag, 27. Juli 2015 07:35 > An: CMake MailingList ; CMake Developer MailingList > > Betreff: [cmake-developers] check_cxx_source_compiles and include > directories > > Hello, > > I've a small code example to test if the header file exists (with > check_cxx_source_compiles), which sets my variable successfully to TRUE. > > When I compile the real code then I got an error message saying 'mutex' file > not found. > > I checked the compile flags for both situations and these are equal. So I > thought that the include directories could be the problem. > > Any hints? > > Best Regards > Roman > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From digitalriptide at gmail.com Mon Jul 27 17:13:03 2015 From: digitalriptide at gmail.com (digitalriptide) Date: Mon, 27 Jul 2015 14:13:03 -0700 Subject: [CMake] FindPythonInterp.cmake and FindPythonLibs.cmake Modules Find Different Pythons Message-ID: When I execute FindPythonLibs.cmake and FindPythonInterp.cmake on the same system, they locate different Python installations. I am running OS X with cmake 3.2.3. FindPythonLibs picks up the system-provided python installation, while FindPythonInterp picks up the version of Python I installed through MacPorts. Is this the intended behavior? Is there a way to fix this? I don't really care which version the modules pick up, but it would be nice if they were internally consistent, as the version mis-match is leading to subtle bugs. I can hardcode the paths to the desired libraries with PYTHON_EXECUTABLE and PYTHON_LIBRARY, but that isn't very portable... Thank you kindly for your advices! From d3ck0r at gmail.com Mon Jul 27 19:57:15 2015 From: d3ck0r at gmail.com (J Decker) Date: Mon, 27 Jul 2015 16:57:15 -0700 Subject: [CMake] Packaging debug symbol files on Windows In-Reply-To: References: <55B62E27.5000904@gmail.com> <55B638F3.7070608@gmail.com> Message-ID: Debug also adds padding between functions and stack checking which can significantly add to code size for smaller libraries... or libraries with lots of tiny functions. On Mon, Jul 27, 2015 at 9:13 AM, Andreas Pakulat wrote: > Hi Nils, > > On Mon, Jul 27, 2015 at 3:58 PM, Nils Gladitz > wrote: > >> On 07/27/2015 03:46 PM, Andreas Pakulat wrote: >> >>> I've meanwhile also noticed that the default compiler flags that CMake >>> uses include the debug information in the dll itself (dll size is >>> doubled), so for now don't even have to have the separate pdb files >>> packaged anymore (in this case the pdb info is small enough to just keep >>> in the dll). >>> >> >> I am not entirely sure what you mean but CMake's default flags for the >> Visual Studio compiler when building "Debug" or "RelWithDebInfo" use /Zi >> (debug information in external pdb) rather than /Z7 (embedded debug >> information; no pdb is generated). >> >> Maybe your project replaces the default flags? > > > No Z7 or Zi anywhere in the CMake files and the generated makefiles > include /Zi. So I don't know why the dll's would be bigger and generate > proper backtrace information when analyzing a dump file but so it is and > thats fine with me for now. > > Andreas > > -- > > 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 jens.auer at cgi.com Tue Jul 28 04:39:17 2015 From: jens.auer at cgi.com (Auer, Jens) Date: Tue, 28 Jul 2015 08:39:17 +0000 Subject: [CMake] CMake finds wrong ar/ranlib/nm Message-ID: Hi, I am trying to use another compiler than the default one installed on my system. I have to do this because I want to use a newer gcc than the one on centos 7,so I installed RedHat Developer Toolset 3 with gcc 4.9. When I call cmake with scl enable devtoolset-3 "cmake ../src" in my build directory, it generates makefiles which use the new compiler and linker, but still uses the default /usr/bin/ar etc. This is problematic because I enable whole-program-optimization in release mode, and this needs to use the ar provided with gcc 4.9 to handle the link-time optimization object files. I have tried various things to force cmake to use a specific ar, but none of these worked: - Manually set CMAKE_AR in the CMakeLists.txt - Change CMAKE_AR in the cache - Write my own toolchain file With the toolchain file, cmake creates Makefiles but puts an empty ar command in the lib "link" command, and building thus fails with an error. Am I missing something? Best wishes, Jens Auer -- Dr. Jens Auer | CGI | Software Engineer CGI Deutschland Ltd. & Co. KG Rheinstra?e 95 | 64295 Darmstadt | Germany T: +49 6151 36860 154 jens.auer at cgi.com Unsere Pflichtangaben gem?? ? 35a GmbHG / ?? 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben. CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at classdesign.com Tue Jul 28 08:59:25 2015 From: bill at classdesign.com (Bill Somerville) Date: Tue, 28 Jul 2015 13:59:25 +0100 Subject: [CMake] BundleUtilities not working Message-ID: <55B77CAD.8050506@classdesign.com> Hi, I am suffering issues with BundleUtilities fixup_bundle() when used on Windows with MinGW. The issue is because the underlying GetPrerequisites module uses the MS dumpbin.exe utility to find dependent libraries of executables. This is a problem because it crashes on many libraries and executables from later MinGW tools, for example the GNU Fortran library libgfortran-3.dll. I believe the crash is due to the DLL having no symbols. The problem is exacerbated by GetPrequisites having very little error checking so it silently fails and doesn't install the dependent libraries. GetPrerequisites can use objdump if dumpbin is not available but this has another issue. The output from 'objdump -p ' can be very long, over 10000+ lines for a large Qt library for example, and this causes GetPrerequsites to run exceedingly slowly as it uses execute_process() to capture the output into a CMake variable then parses it with string(REGEX REPLACE ...) and a loop doing an if(... MATCHES ) on every line. So I have a choice of broken or too slow for practical use :( Is BundleUtilities.cmake and GetPrerequisites.cmake maintained, if so who by? I can suggest a few improvements, the main one being to filter the command output used to get prerequisites in a pipeline (execute_command() with multiple commands using grep) and better error checking. Also perhaps dumpbin should only be used if objdump is not available. Regards Bill Somerville. From brad.king at kitware.com Tue Jul 28 10:55:16 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 28 Jul 2015 10:55:16 -0400 Subject: [CMake] [cmake-developers] check_cxx_source_compiles and include directories In-Reply-To: <050101d0c8a2$1df05050$59d0f0f0$@gmx.at> References: <419A5EC7-E63B-4691-9643-07A34EB376C1@gmx.at> <050101d0c8a2$1df05050$59d0f0f0$@gmx.at> Message-ID: <55B797D4.7000605@kitware.com> On 07/27/2015 03:26 PM, Roman W?ger wrote: > SubProj1 and SubProj2 does not find , but > check_cxx_source_compiles succeeds. > > Did I miss configure something here? The posted example works for me on Linux with g++ 4.9.3. The check succeeds and an executable I create in SubProj1 can #include . I have "/usr/include/c++/4.9.3/mutex" right next to all the other C++ headers. -Brad From bill.hoffman at kitware.com Tue Jul 28 11:03:01 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 28 Jul 2015 11:03:01 -0400 Subject: [CMake] BundleUtilities not working In-Reply-To: <55B77CAD.8050506@classdesign.com> References: <55B77CAD.8050506@classdesign.com> Message-ID: <55B799A5.6000701@kitware.com> On 7/28/2015 8:59 AM, Bill Somerville wrote: > Hi, > > I am suffering issues with BundleUtilities fixup_bundle() when used on > Windows with MinGW. The issue is because the underlying GetPrerequisites > module uses the MS dumpbin.exe utility to find dependent libraries of > executables. This is a problem because it crashes on many libraries and > executables from later MinGW tools, for example the GNU Fortran library > libgfortran-3.dll. I believe the crash is due to the DLL having no symbols. > > The problem is exacerbated by GetPrequisites having very little error > checking so it silently fails and doesn't install the dependent libraries. > > GetPrerequisites can use objdump if dumpbin is not available but this > has another issue. The output from 'objdump -p ' can be very > long, over 10000+ lines for a large Qt library for example, and this > causes GetPrerequsites to run exceedingly slowly as it uses > execute_process() to capture the output into a CMake variable then > parses it with string(REGEX REPLACE ...) and a loop doing an if(... > MATCHES ) on every line. > > So I have a choice of broken or too slow for practical use :( > > Is BundleUtilities.cmake and GetPrerequisites.cmake maintained, if so > who by? I can suggest a few improvements, the main one being to filter > the command output used to get prerequisites in a pipeline > (execute_command() with multiple commands using grep) and better error > checking. Also perhaps dumpbin should only be used if objdump is not > available. It is not supported by anyone in particular. However, it is a supported and well used part of CMake. I would suggest that you create a patch, and work on the cmake-developers mailing list: http://www.cmake.org/gitweb?p=cmake.git;a=blob_plain;f=CONTRIBUTING.rst;hb=master Looking at the code, it seems that objdump is intended for MinGW. I wonder if there is a less verbose mode that can get the same information. OR, it seems that MinGW has ldd (at least mine does). What happens if you use the ldd mode? I would suggest that you try some stuff and see what actually works with your system and then report back to the cmake-developers list with either a complete patch or an approach that works and I can help you get it into CMake. Thanks for the contribution. -Bill From bill.hoffman at kitware.com Tue Jul 28 11:05:00 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 28 Jul 2015 11:05:00 -0400 Subject: [CMake] CMake finds wrong ar/ranlib/nm In-Reply-To: References: Message-ID: <55B79A1C.9080400@kitware.com> On 7/28/2015 4:39 AM, Auer, Jens wrote: > Hi, > > I am trying to use another compiler than the default one installed on my > system. I have to do this because I want to use a newer gcc than the one > on centos 7,so I installed RedHat Developer Toolset 3 with gcc 4.9. When > I call cmake with > > sclenable devtoolset-3 ?cmake ../src? in my build directory, it > generates makefiles which use the new compiler and linker, but still > uses the default /usr/bin/ar etc. This is problematic because I enable > whole-program-optimization in release mode, and this needs to use the ar > provided with gcc 4.9 to handle the link-time optimization object files. > > I have tried various things to force cmake to use a specific ar, but > none of these worked: > > -Manually set CMAKE_AR in the CMakeLists.txt > > -Change CMAKE_AR in the cache > > -Write my own toolchain file > > With the toolchain file, cmake creates Makefiles but puts an empty ar > command in the lib ?link? command, and building thus fails with an error. > > Am I missing something? > This is an environment thing. Make sure the command line you are using is setup to find the other tools first in your PATH and it should work. CMake assumes the environment is setup to work with the compiler you want to use. -Bill From bill at classdesign.com Tue Jul 28 11:32:40 2015 From: bill at classdesign.com (Bill Somerville) Date: Tue, 28 Jul 2015 16:32:40 +0100 Subject: [CMake] BundleUtilities not working In-Reply-To: <55B799A5.6000701@kitware.com> References: <55B77CAD.8050506@classdesign.com> <55B799A5.6000701@kitware.com> Message-ID: <55B7A098.7060006@classdesign.com> On 28/07/2015 16:03, Bill Hoffman wrote: Hi Bill, > On 7/28/2015 8:59 AM, Bill Somerville wrote: >> Hi, >> >> I am suffering issues with BundleUtilities fixup_bundle() when used on >> Windows with MinGW. The issue is because the underlying GetPrerequisites >> module uses the MS dumpbin.exe utility to find dependent libraries of >> executables. This is a problem because it crashes on many libraries and >> executables from later MinGW tools, for example the GNU Fortran library >> libgfortran-3.dll. I believe the crash is due to the DLL having no >> symbols. >> >> The problem is exacerbated by GetPrequisites having very little error >> checking so it silently fails and doesn't install the dependent >> libraries. >> >> GetPrerequisites can use objdump if dumpbin is not available but this >> has another issue. The output from 'objdump -p ' can be very >> long, over 10000+ lines for a large Qt library for example, and this >> causes GetPrerequsites to run exceedingly slowly as it uses >> execute_process() to capture the output into a CMake variable then >> parses it with string(REGEX REPLACE ...) and a loop doing an if(... >> MATCHES ) on every line. >> >> So I have a choice of broken or too slow for practical use :( >> >> Is BundleUtilities.cmake and GetPrerequisites.cmake maintained, if so >> who by? I can suggest a few improvements, the main one being to filter >> the command output used to get prerequisites in a pipeline >> (execute_command() with multiple commands using grep) and better error >> checking. Also perhaps dumpbin should only be used if objdump is not >> available. > Thanks for replying. > It is not supported by anyone in particular. However, it is a > supported and well used part of CMake. I would suggest that you > create a patch, and work on the cmake-developers mailing list: > http://www.cmake.org/gitweb?p=cmake.git;a=blob_plain;f=CONTRIBUTING.rst;hb=master > OK, I will see what I can come up with. > > Looking at the code, it seems that objdump is intended for MinGW. I > wonder if there is a less verbose mode that can get the same > information. OR, it seems that MinGW has ldd (at least mine does). > What happens if you use the ldd mode? It uses dumpbin.exe in preference to objdump if it can find it and it even has hard coded paths to find it even if it is not on the PATH. Back at MinGW 4.8 dumpbin works OK but somewhere between there and MinGW 4.9.2 the compiler support DLLs have changed and cause dumpbin to barf. I have checked for objdump command options to reduce the output but there don't appear to be any that help. TBH running from the command line as, for example: $ objdump -p | grep 'DLL Name:' runs in a fraction of a second compared with up to 10 minutes on an i7 CPU for the GetPrerequisites version that messes around with the output in a CMake variable. AFAIK ldd is an ELF format tool and there is no COFF equivalent for native Windows PE binaries. > > I would suggest that you try some stuff and see what actually works > with your system and then report back to the cmake-developers list > with either a complete patch or an approach that works and I can help > you get it into CMake. Thanks for the contribution. I thought that was what I had done. OK I will see if I can brew up a patch but it will be a big change as I see several more issues in GetPrerequisites and I am not a CMake expert. > > -Bill > Regards Bill Somerville. From roman.wueger at gmx.at Tue Jul 28 12:23:12 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 28 Jul 2015 18:23:12 +0200 Subject: [CMake] [cmake-developers] check_cxx_source_compiles and include directories In-Reply-To: <55B797D4.7000605@kitware.com> References: <419A5EC7-E63B-4691-9643-07A34EB376C1@gmx.at> <050101d0c8a2$1df05050$59d0f0f0$@gmx.at> <55B797D4.7000605@kitware.com> Message-ID: <8A118920-48E3-4263-B7FB-2992F0A0A467@gmx.at> Hi Brad, thanks for your investigation. I've tried it on Mac OS 10.10.4 with clang 6.1.0.6020053 from XCode 6 using "Unix Makefiles" as the generator. Best Regards Roman > Am 28.07.2015 um 16:55 schrieb Brad King : > >> On 07/27/2015 03:26 PM, Roman W?ger wrote: >> SubProj1 and SubProj2 does not find , but >> check_cxx_source_compiles succeeds. >> >> Did I miss configure something here? > > The posted example works for me on Linux with g++ 4.9.3. > The check succeeds and an executable I create in SubProj1 > can #include . I have "/usr/include/c++/4.9.3/mutex" > right next to all the other C++ headers. > > -Brad > From brad.king at kitware.com Tue Jul 28 12:47:05 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 28 Jul 2015 12:47:05 -0400 Subject: [CMake] BundleUtilities not working In-Reply-To: <55B7A098.7060006@classdesign.com> References: <55B77CAD.8050506@classdesign.com> <55B799A5.6000701@kitware.com> <55B7A098.7060006@classdesign.com> Message-ID: <55B7B209.5030407@kitware.com> On 07/28/2015 11:32 AM, Bill Somerville wrote: > I have checked for objdump command options to reduce the output but > there don't appear to be any that help. TBH running from the command > line as, for example: > > $ objdump -p | grep 'DLL Name:' > > runs in a fraction of a second compared with up to 10 minutes on an i7 > CPU for the GetPrerequisites version that messes around with the output > in a CMake variable. FYI, execute_process supports multiple COMMAND options and will construct a pipeline threading each command's stdout to the next command's stdin. Therefore you should be able to do piping like the above if you know a grep is available. Otherwise you could also consider using OUTPUT_FILE to put the output in a temporary file and then use file(STRINGS) to load a subset of it into memory. -Brad From brad.king at kitware.com Tue Jul 28 12:50:05 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 28 Jul 2015 12:50:05 -0400 Subject: [CMake] [cmake-developers] check_cxx_source_compiles and include directories In-Reply-To: <8A118920-48E3-4263-B7FB-2992F0A0A467@gmx.at> References: <419A5EC7-E63B-4691-9643-07A34EB376C1@gmx.at> <050101d0c8a2$1df05050$59d0f0f0$@gmx.at> <55B797D4.7000605@kitware.com> <8A118920-48E3-4263-B7FB-2992F0A0A467@gmx.at> Message-ID: <55B7B2BD.8090109@kitware.com> On 07/28/2015 12:23 PM, Roman W?ger wrote: > I've tried it on Mac OS 10.10.4 with clang 6.1.0.6020053 from > XCode 6 using "Unix Makefiles" as the generator. Is that using the Xcode Command Line Tools or the /usr/bin/c++ stub that uses the /Applications/Xcode.app/.../bin/clang++ compiler underneath? Is CMAKE_OSX_SYSROOT set? Does -isysroot appear on the compilation command line? Thanks, -Brad From bill at classdesign.com Tue Jul 28 12:51:48 2015 From: bill at classdesign.com (Bill Somerville) Date: Tue, 28 Jul 2015 17:51:48 +0100 Subject: [CMake] BundleUtilities not working In-Reply-To: <55B7B209.5030407@kitware.com> References: <55B77CAD.8050506@classdesign.com> <55B799A5.6000701@kitware.com> <55B7A098.7060006@classdesign.com> <55B7B209.5030407@kitware.com> Message-ID: <55B7B324.7060800@classdesign.com> On 28/07/2015 17:47, Brad King wrote: Hi Brad, > On 07/28/2015 11:32 AM, Bill Somerville wrote: >> I have checked for objdump command options to reduce the output but >> there don't appear to be any that help. TBH running from the command >> line as, for example: >> >> $ objdump -p | grep 'DLL Name:' >> >> runs in a fraction of a second compared with up to 10 minutes on an i7 >> CPU for the GetPrerequisites version that messes around with the output >> in a CMake variable. > FYI, execute_process supports multiple COMMAND options and will construct > a pipeline threading each command's stdout to the next command's stdin. > Therefore you should be able to do piping like the above if you know a > grep is available. Otherwise you could also consider using OUTPUT_FILE > to put the output in a temporary file and then use file(STRINGS) to load > a subset of it into memory. OK, on the execute_process() pipeline, I have tried that and it works well. Not quite as fast as the shell equivalent but easily fast enough for this. The possible lack of grep is a potential issue so your read back from file suggestion is interesting, is there a recognized place to write temporary files like this? > > -Brad > 73 Bill Somerville. From brad.king at kitware.com Tue Jul 28 13:04:55 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 28 Jul 2015 13:04:55 -0400 Subject: [CMake] BundleUtilities not working In-Reply-To: <55B7B324.7060800@classdesign.com> References: <55B77CAD.8050506@classdesign.com> <55B799A5.6000701@kitware.com> <55B7A098.7060006@classdesign.com> <55B7B209.5030407@kitware.com> <55B7B324.7060800@classdesign.com> Message-ID: <55B7B637.7050307@kitware.com> On 07/28/2015 12:51 PM, Bill Somerville wrote: > The possible lack of grep is a potential issue so your read > back from file suggestion is interesting, is there a recognized place to > write temporary files like this? IIRC the code in question runs during "cmake -P cmake_install.cmake" scripts so CMAKE_CURRENT_BINARY_DIR may be a reasonable choice. If for any reason you need to randomize the file name then you could use string(RANDOM). Since this is specific to Windows perhaps $ENV{TEMP} will be useful, though I don't recall off the top of my head whether applications are supposed to read that directly. Certainly a randomized file name would be needed if a shared temp dir were used. -Brad From roman.wueger at gmx.at Tue Jul 28 15:38:36 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 28 Jul 2015 21:38:36 +0200 Subject: [CMake] [cmake-developers] check_cxx_source_compiles and include directories In-Reply-To: <55B7B2BD.8090109@kitware.com> References: <419A5EC7-E63B-4691-9643-07A34EB376C1@gmx.at> <050101d0c8a2$1df05050$59d0f0f0$@gmx.at> <55B797D4.7000605@kitware.com> <8A118920-48E3-4263-B7FB-2992F0A0A467@gmx.at> <55B7B2BD.8090109@kitware.com> Message-ID: <00fd01d0c96d$00e59ad0$02b0d070$@gmx.at> Thanks Brad yes, and that's the point. I've found my mistake, I had set the CMAKE_OSX_DEPLOYMENT_TARGET and CMAKE_OSX_SYSROOT between the check_cxx_source_compiles() calls and the add_subdirectory() calls. I moved the CMAKE_OSX_DEPLOYMENT_TARGET and CMAKE_OSX_SYSROOT initialization on top of the check_cxx_source_compiles() calls and everthing is working as expected. So, in my situation the order is: 1.) CMAKE_OSX_DEPLOYMENT_TARGET and CMAKE_OSX_SYSROOT 2.) check_cxx_source_compiles() and other platform checks 3.) add_subdirectory() and other stuff Best Regards Roman > -----Urspr?ngliche Nachricht----- > Von: Brad King [mailto:brad.king at kitware.com] > Gesendet: Dienstag, 28. Juli 2015 18:50 > An: Roman W?ger > Cc: CMake MailingList ; CMake Developer MailingList > > Betreff: Re: [cmake-developers] check_cxx_source_compiles and include > directories > > On 07/28/2015 12:23 PM, Roman W?ger wrote: > > I've tried it on Mac OS 10.10.4 with clang 6.1.0.6020053 from XCode 6 > > using "Unix Makefiles" as the generator. > > Is that using the Xcode Command Line Tools or the /usr/bin/c++ stub that > uses the /Applications/Xcode.app/.../bin/clang++ compiler underneath? > Is CMAKE_OSX_SYSROOT set? Does -isysroot appear on the compilation > command line? > > Thanks, > -Brad From nils.guillermin at gmail.com Tue Jul 28 21:46:26 2015 From: nils.guillermin at gmail.com (Nils Guillermin) Date: Tue, 28 Jul 2015 21:46:26 -0400 Subject: [CMake] CMake inconsistent with python libraries Message-ID: Hello everyone, My first time posting to this mailing list so forgive me if I'm off base. I first wanted to make sure this was a new problem before I posted a bug report, as the cmake website asks. I was trying to install gr-air-modes ( https://github.com/bistromath/gr-air-modes/) and I ran into an issue where CMake straight up says two things at once and the eventual result is a fatal Python error due to mismatched libraries. First, the cmake command I use is a plain `cmake ../`. The relevant part of the build output is -- Found PythonLibs: /usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib (found version "2.7.6") -- Found PythonLibs: /usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib (found suitable version "2.7.6", minimum required is "2") As far as I understand, it found python 2.7.10 files, but for some reason is calling them version 2.7.6. I'd expect it to say "found suitable version '2.7.10'" but perhaps I'm wrong. After this it builds fine, but when run immediately crashes with a Fatal Python Error, and the Error Reporter that comes up makes it clear that its a problem of mismatched libraries. I can post that if anyone needs. Am I wrong in what I'm expecting? Should I open a proper bug report? Thanks, Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Tue Jul 28 23:17:49 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Wed, 29 Jul 2015 03:17:49 +0000 (UTC) Subject: [CMake] CMake inconsistent with python libraries References: Message-ID: Nils Guillermin writes: > > Hello everyone, > My first time posting to this mailing list so forgive me if I'm off base. I first wanted to make sure this was a new problem before I posted a bug report, as the cmake website asks. Welcome to the lists! >I was trying to install gr-air-modes (https://github.com/bistromath/gr-air- modes/) and I ran into an issue where CMake straight up says two things at once and the eventual result is a fatal Python error due to mismatched libraries. > > First, the cmake command I use is a plain `cmake ../`. > > The relevant part of the build output is-- Found PythonLibs: /usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/l ib/libpython2.7.dylib (found version "2.7.6") -- Found PythonLibs: /usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/l ib/libpython2.7.dylib (found suitable version "2.7.6", minimum required is "2") > > As far as I understand, it found python 2.7.10 files, but for some reason is calling them version 2.7.6. I'd expect it to say "found suitable version '2.7.10'" but perhaps I'm wrong. > After this it builds fine, but when run immediately crashes with a Fatal Python Error, and the Error Reporter that comes up makes it clear that its a problem of mismatched libraries. I can post that if anyone needs. There are some known issues with Homebrew: http://www.cmake.org/Bug/view.php?id=14809 But it would be worthwhile trying CMake Git master: http://www.cmake.org/Wiki/CMake/Git Hope this helps, Matt From irwin at beluga.phys.uvic.ca Tue Jul 28 23:25:48 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 28 Jul 2015 20:25:48 -0700 (PDT) Subject: [CMake] CMake inconsistent with python libraries In-Reply-To: References: Message-ID: On 2015-07-28 21:46-0400 Nils Guillermin wrote: > Hello everyone, > > My first time posting to this mailing list so forgive me if I'm off base. I > first wanted to make sure this was a new problem before I posted a bug > report, as the cmake website asks. I was trying to install gr-air-modes ( > https://github.com/bistromath/gr-air-modes/) and I ran into an issue where > CMake straight up says two things at once and the eventual result is a > fatal Python error due to mismatched libraries. > > First, the cmake command I use is a plain `cmake ../`. > > The relevant part of the build output is > > -- Found PythonLibs: > /usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib > (found version "2.7.6") > -- Found PythonLibs: > /usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib > (found suitable version "2.7.6", minimum required is "2") > > As far as I understand, it found python 2.7.10 files, but for some reason > is calling them version 2.7.6. I'd expect it to say "found suitable version > '2.7.10'" but perhaps I'm wrong. > > After this it builds fine, but when run immediately crashes with a Fatal > Python Error, and the Error Reporter that comes up makes it clear that its > a problem of mismatched libraries. I can post that if anyone needs. > > Am I wrong in what I'm expecting? Should I open a proper bug report? Just to add some more information to your report in case my comments below don't help you find the answer, what are the results of python --version for the same PATH setup you had when running the cmake command? If that result is 2.7.6, that explains the above incompatibility, and you will have to install instead a package that contains a python interpreter that is consistent with the python libraries version you have installed or vice versa. If instead, the problem is multiple versions of the python interpreter, then your software distribution may have some method of singling out which python interpreter alternative is the one that you want to correspond exactly to the "python" used in the above command. (For example, the Debian distribution of Linux has the update-alternatives command to handle this issue, and I presume most other Linux distributions have something similar.) Also, look at the Python_ADDITIONAL_VERSIONS CMake variable. (I have no experience with that, but from what the CMake documentation says, that is a way to select a particular version of the interpreter and the libraries, which presumably can be used to look only for consistent versions.) HTH. 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 csiga.biga at aol.com Wed Jul 29 03:49:07 2015 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Wed, 29 Jul 2015 07:49:07 +0000 Subject: [CMake] =?utf-8?q?CMake_IR?= Message-ID: Dear CMake devs/users, I wanted to ask your opinion on something that has been troubling me since? well, ever since I started using CMake. I have not found a single person alive who would have said: ?The script language of CMake is nice, intuitive and productive. Authoring scripts is easy, and writing custom macros is not difficult either.? There are gazillions of scripting languages one could have chosen for CMake (Python, Perl, Ruby, Powershell, Bash, etc.) that would allow developers to reuse existing skills, or learn one that is useful elsewhere, not just in terms of CMake. These languages have a lot of thought put into them. They are superior to CMake?s own in just about every regard. I came up with an idea presented here: http://1drv.ms/1MsufbF Enhancements such a change could bring about: The big selling point would be the ability to introduce arbitrary front-ends to CMake, not just CMakelists.txt. Every developer could choose an input language that suits their project/needs/skills. (It would also ease the custom implementations of cmake.exe itself in any language, but that is just a side-effect.) It would modularize the internals of CMake in a cleaner fashion Facilitate the introduction of new languages understood by CMake (such as work put into C# and Swift currently) Would allow for configure-time validating of compiler-specific options Use deferred makefile generation by default (making the implementation of tools like Cotire for precompiled headers trivial to implement, as well NMake batch mode, or detecting multiple/cyclic linkage, by making use of global information about the build process) Many features could automatically be reused by all generators. (Imagine Swift, and Fortran libraries being compiled as NuGet packages and publishing them without any hassle on user side, or having to implement anything in the XCode generator.) SIGNIFICANTLY increase interoperability with other tools. Implementing GUI front-ends (such as in CLion, or Visual Studio (work in progress)) are orders of magnitude simpler by generating a stateless IR, as opposed to generating a stateful script. While it is a refactor of the entire toolchain, it is something that could be done incrementally, with the existing parts functioning normally. I believe CMake is an invaluable tool, but it could do far better. 0/10 CMake users I?ve met say they are ?happy? CMake users. The learning curve is steep, and the skills gained are not reusable. CMake could gain even greater momentum (not by ditching, but) by offering alternate input languages with entities (classes, functions, macros, etc.) that feel natural in the given context. Initial feedback in my vicinity was favorable, even those with zealous CMake opposition aggreed this were something awesome to pull off (though they expressed their disbelief in Kitware and the community approving such a radical change). This mail along with the document only intends to get the ball rolling and hopefully manifest in something similar, starting with CMake 4.0 perhaps. Eagerly await the rolling ball. With all due respect, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwan.work at gmail.com Wed Jul 29 05:01:17 2015 From: rwan.work at gmail.com (Raymond Wan) Date: Wed, 29 Jul 2015 17:01:17 +0800 Subject: [CMake] CMake IR In-Reply-To: <20150729084010.94CFEAD02D@public.kitware.com> References: <20150729084010.94CFEAD02D@public.kitware.com> Message-ID: Hi M?t?, On Wed, Jul 29, 2015 at 3:49 PM, Nagy-Egri M?t? Ferenc wrote: > I wanted to ask your opinion on something that has been troubling me since? > well, ever since I started using CMake. I have not found a single person > alive who would have said: > > ?The script language of CMake is nice, intuitive and productive. Authoring > scripts is easy, and writing custom macros is not difficult either.? I'm not much of an expert wih CMake but when someone says "I have not found a single person alive...", I would usually counter by asking how many people you've asked? :-) > Initial feedback in my vicinity was favorable, even those with zealous CMake > opposition aggreed this were something awesome to pull off (though they > expressed their disbelief in Kitware and the community approving such a > radical change). This mail along with the document only intends to get the > ball rolling and hopefully manifest in something similar, starting with > CMake 4.0 perhaps. I for one am quite happy with CMake. We can point fingers at technology (i.e., which programming language is better or worse), but in the end, it's really the community support (IMHO). And if I'm stuck with CMake, I can usually find answers to most of my problems on this e-mail list or by searching Google. If you want to refactor CMake along these lines: > There are gazillions of scripting languages one could have chosen for > CMake (Python, Perl, Ruby, Powershell, Bash, etc.) I have a question for you. Why introduce them as CMake 4.0? Why not start a new project from scratch and give it a new name. Why "take over" the name of an already working tool? I mean, it's like complaining about Perl (apologies to Perl lovers...just an example!) and wanting to rewrite it from scratch. Up to a point, it is better to come up with new name...if you think you can do it better. I honestly don't think CMake is broken. Perhaps it's because I came from Makefiles and then Autotools -- the latter was a nightmare! Perhaps one possible improvement to CMake might be to improve the documentation a bit so that maybe there's more information on how to *write* modules (as opposed to using modules). Ray From csiga.biga at aol.com Wed Jul 29 06:02:52 2015 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Wed, 29 Jul 2015 10:02:52 +0000 Subject: [CMake] =?utf-8?q?CMake_IR?= In-Reply-To: References: <20150729084010.94CFEAD02D@public.kitware.com>, Message-ID: How many people have I asked? We are a group of 5, and have several fellows who have drifted off to companies each with their respective dev teams of 5-15 people. General tendency is that everywhere, there is 1 CMake guru, the rest would be better off not touching the scripts, because they do more harm than good. I can believe that someone coming from the autotools or GNU Make find CMake to be a salvation. But someone being used to Visual Studio?s Solution Explorer (and things generally working out-of-the-box) finds hand authoring scripts in a unique language that?s been documented only 2 months ago? Don?t get me wrong, I am an admin and spend a considerable amount of time scripting in various languages. It?s not the fact that I have to touch scripts. It?s the fact that doing so is a pain. The reason I suggested this as a CMake 4.0 feature is because I am the 11th person out of 10 who actually ?likes? CMake a bit and cares for it. I?d rather empower a tool I use on a daily basis than spawn an alternative and spend half my life trying to winning the world over. As is the case with operating systems, they have accumulated so much code, there is no point in trying to write a new one, rather than fixing the ones that exist. Every respectable cross-platform project uses CMake and I have no intention of going against that. I?ve neither the resources (time mostly) to do that, neither do I like the fact of spawning ?yet another build system? when nothing prevents from enhancing one that is almost perfect. With enough feedback like yours, I might just brew something similar in a few years time (on the expense of my free time). I could do something just like the author of Invoke-Build did and brew something that only I in the entire world would use, even though that in some sense Invoke-Build is far better than GNU Make or NMake in its foundations (being a processor of inter-dependent jobs, and nothing else). I understand your concern with people trying to hijack a community project and alter it to their personal ideals. However the fact that there are people fighting a war for CMake-izing Boost 2.0, and the fact that Boost 1.x failed two attempts at doing so is because the Boost developers were reluctant to pick up CMake as a build system, even though it is superior to Boost Build in every aspect. That too, is a build system used only in Boost, and nowhere else in the world. (I even had an email discussion with the authors of such an attempt. He handed all the working scripts to the devs, all they should?ve do was type cmake.exe ../src, but they did not.) One of the reasons these attempts failed was because of the Boost dev?s love for their ?own child? (Boost Build). The other is that CMake is unfriendly for devs. It is better than many others, but worse than many others. When it works, it?s great. But getting it to work is not always as easy as one might like. I had an idea I felt would benefit the community (the CMake community that is), I thought I?d share it as an idea. ps.: I also had an email encounter with the dev of Invoke-Build about cooking up an Invoke-Build back-end to CMake. He had no idea CMake exists, but because he needed a scriptable (from Powershell that is) build system, he cooked up one of his own. If CMake had a PS front-end, maybe a whole bunch of people pick it up who don?t even know it exists because they live outside the cross-platform world. Felad?: Raymond Wan Elk?ldve: ?szerda?, ?2015?. ?j?lius? ?29?. ?11?:?01 C?mzett: Nagy-Egri M?t? Ferenc M?solat: cmake at cmake.org Hi M?t?, On Wed, Jul 29, 2015 at 3:49 PM, Nagy-Egri M?t? Ferenc wrote: > I wanted to ask your opinion on something that has been troubling me since? > well, ever since I started using CMake. I have not found a single person > alive who would have said: > > ?The script language of CMake is nice, intuitive and productive. Authoring > scripts is easy, and writing custom macros is not difficult either.? I'm not much of an expert wih CMake but when someone says "I have not found a single person alive...", I would usually counter by asking how many people you've asked? :-) > Initial feedback in my vicinity was favorable, even those with zealous CMake > opposition aggreed this were something awesome to pull off (though they > expressed their disbelief in Kitware and the community approving such a > radical change). This mail along with the document only intends to get the > ball rolling and hopefully manifest in something similar, starting with > CMake 4.0 perhaps. I for one am quite happy with CMake. We can point fingers at technology (i.e., which programming language is better or worse), but in the end, it's really the community support (IMHO). And if I'm stuck with CMake, I can usually find answers to most of my problems on this e-mail list or by searching Google. If you want to refactor CMake along these lines: > There are gazillions of scripting languages one could have chosen for > CMake (Python, Perl, Ruby, Powershell, Bash, etc.) I have a question for you. Why introduce them as CMake 4.0? Why not start a new project from scratch and give it a new name. Why "take over" the name of an already working tool? I mean, it's like complaining about Perl (apologies to Perl lovers...just an example!) and wanting to rewrite it from scratch. Up to a point, it is better to come up with new name...if you think you can do it better. I honestly don't think CMake is broken. Perhaps it's because I came from Makefiles and then Autotools -- the latter was a nightmare! Perhaps one possible improvement to CMake might be to improve the documentation a bit so that maybe there's more information on how to *write* modules (as opposed to using modules). Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.despres at gmail.com Wed Jul 29 07:43:39 2015 From: nicolas.despres at gmail.com (=?UTF-8?Q?Nicolas_Despr=C3=A8s?=) Date: Wed, 29 Jul 2015 13:43:39 +0200 Subject: [CMake] CMake IR In-Reply-To: <20150729084010.94CFEAD02D@public.kitware.com> References: <20150729084010.94CFEAD02D@public.kitware.com> Message-ID: Hi M?t?, One way of doing would be to write a tool using whatever language you like, reading an input script written in whatever language you like, that generates cmake code. In such case, the modification to cmake would be smaller but not that simple. You can see this thread from the archive for further details: http://www.cmake.org/pipermail/cmake-developers/2014-May/010450.html Cheers, Nico On Wed, Jul 29, 2015 at 9:49 AM, Nagy-Egri M?t? Ferenc wrote: > Dear CMake devs/users, > > I wanted to ask your opinion on something that has been troubling me > since? well, ever since I started using CMake. I have not found a single > person alive who would have said: > > ?The script language of CMake is nice, intuitive and productive. Authoring > scripts is easy, and writing custom macros is not difficult either.? > > There are gazillions of scripting languages one could have chosen for > CMake (Python, Perl, Ruby, Powershell, Bash, etc.) that would allow > developers to reuse existing skills, or learn one that is useful elsewhere, > not just in terms of CMake. These languages have a lot of thought put into > them. They are superior to CMake?s own in just about every regard. > > I came up with an idea presented here: *http://1drv.ms/1MsufbF* > > > Enhancements such a change could bring about: > > - The big selling point would be the ability to introduce arbitrary > front-ends to CMake, not just CMakelists.txt. Every developer could choose > an input language that suits their project/needs/skills. > - (It would also ease the custom implementations of cmake.exe itself > in any language, but that is just a side-effect.) > - It would modularize the internals of CMake in a cleaner fashion > - Facilitate the introduction of new languages understood by CMake > (such as work put into C# and Swift currently) > - Would allow for configure-time validating of compiler-specific > options > - Use deferred makefile generation by default (making the > implementation of tools like Cotire > for precompiled headers trivial to implement, as well NMake batch mode, > or detecting multiple/cyclic linkage, by making use of global information > about the build process) > - Many features could automatically be reused by all generators. > (Imagine Swift, and Fortran libraries being compiled as NuGet packages and > publishing them without any hassle on user side, or having to implement > anything in the XCode generator.) > - SIGNIFICANTLY increase interoperability with other tools. > Implementing GUI front-ends (such as in CLion, or Visual Studio (work in > progress)) are orders of magnitude simpler by generating a stateless IR, as > opposed to generating a stateful script. > > > While it is a refactor of the entire toolchain, it is something that could > be done incrementally, with the existing parts functioning normally. > > I believe CMake is an invaluable tool, but it could do far better. 0/10 > CMake users I?ve met say they are ?happy? CMake users. The learning curve > is steep, and the skills gained are not reusable. CMake could gain even > greater momentum (not by ditching, but) by offering alternate input > languages with entities (classes, functions, macros, etc.) that feel > natural in the given context. > > Initial feedback in my vicinity was favorable, even those with zealous > CMake opposition aggreed this were something awesome to pull off (though > they expressed their disbelief in Kitware and the community approving such > a radical change). This mail along with the document only intends to get > the ball rolling and hopefully manifest in something similar, starting with > CMake 4.0 perhaps. > > Eagerly await the rolling ball. > > With all due respect, > M?t? > > -- > > 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 > -- Nicolas Despr?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From Barthelemy.Von.Haller at cern.ch Wed Jul 29 08:20:54 2015 From: Barthelemy.Von.Haller at cern.ch (Barthelemy Von Haller) Date: Wed, 29 Jul 2015 12:20:54 +0000 Subject: [CMake] [CPack]Call "make package" on subprojects from the top directory Message-ID: <9511D70A3F79B342A045E67C062DD28FDEDF01D7@CERNXCHG43.cern.ch> Hello, I have a projects looking like this : Repo . ??? CMakeLists.txt ??? ProjA ? ??? cmake ? ? ??? CPackConfig.cmake ? ??? CMakeLists.txt ? ??? doc ? ??? include ? ??? src ? ??? test ??? ProjB ? ??? cmake ? ? ??? CPackConfig.cmake ? ??? CMakeLists.txt ? ??? doc ? ??? include ? ??? src ? ??? test ??? More projects... Each project (ProjA, ProjB, ...) is buildable on its own. It can be tested, installed and packaged alone. I want to be able to do the same from the top directory as well. In this case, it would apply the target to all subprojects. It works fine for "make", "make test", "make install" but not for "make package". With the latter, only the last project is packaged not the others. Is there a clean way to call CPack from the top directory ? Thank you, Barthelemy -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Wed Jul 29 08:58:18 2015 From: matt.mccormick at kitware.com (Matt McCormick) Date: Wed, 29 Jul 2015 08:58:18 -0400 Subject: [CMake] CMake IR In-Reply-To: <20150729084010.94CFEAD02D@public.kitware.com> References: <20150729084010.94CFEAD02D@public.kitware.com> Message-ID: Hi M?t?, There is some on-going work along the lines of separating out state. See this thread for more information: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658 You may want to have further discussions on the cmake-developers list. Cheers, Matt On Wed, Jul 29, 2015 at 3:49 AM, Nagy-Egri M?t? Ferenc wrote: > Dear CMake devs/users, > > I wanted to ask your opinion on something that has been troubling me since? > well, ever since I started using CMake. I have not found a single person > alive who would have said: > > ?The script language of CMake is nice, intuitive and productive. Authoring > scripts is easy, and writing custom macros is not difficult either.? > > There are gazillions of scripting languages one could have chosen for CMake > (Python, Perl, Ruby, Powershell, Bash, etc.) that would allow developers to > reuse existing skills, or learn one that is useful elsewhere, not just in > terms of CMake. These languages have a lot of thought put into them. They > are superior to CMake?s own in just about every regard. > > I came up with an idea presented here: http://1drv.ms/1MsufbF > > Enhancements such a change could bring about: > > The big selling point would be the ability to introduce arbitrary front-ends > to CMake, not just CMakelists.txt. Every developer could choose an input > language that suits their project/needs/skills. > (It would also ease the custom implementations of cmake.exe itself in any > language, but that is just a side-effect.) > It would modularize the internals of CMake in a cleaner fashion > Facilitate the introduction of new languages understood by CMake (such as > work put into C# and Swift currently) > Would allow for configure-time validating of compiler-specific options > Use deferred makefile generation by default (making the implementation of > tools like Cotire for precompiled headers trivial to implement, as well > NMake batch mode, or detecting multiple/cyclic linkage, by making use of > global information about the build process) > Many features could automatically be reused by all generators. (Imagine > Swift, and Fortran libraries being compiled as NuGet packages and publishing > them without any hassle on user side, or having to implement anything in the > XCode generator.) > SIGNIFICANTLY increase interoperability with other tools. Implementing GUI > front-ends (such as in CLion, or Visual Studio (work in progress)) are > orders of magnitude simpler by generating a stateless IR, as opposed to > generating a stateful script. > > > While it is a refactor of the entire toolchain, it is something that could > be done incrementally, with the existing parts functioning normally. > > I believe CMake is an invaluable tool, but it could do far better. 0/10 > CMake users I?ve met say they are ?happy? CMake users. The learning curve is > steep, and the skills gained are not reusable. CMake could gain even greater > momentum (not by ditching, but) by offering alternate input languages with > entities (classes, functions, macros, etc.) that feel natural in the given > context. > > Initial feedback in my vicinity was favorable, even those with zealous CMake > opposition aggreed this were something awesome to pull off (though they > expressed their disbelief in Kitware and the community approving such a > radical change). This mail along with the document only intends to get the > ball rolling and hopefully manifest in something similar, starting with > CMake 4.0 perhaps. > > Eagerly await the rolling ball. > > With all due respect, > M?t? > > -- > > 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 csiga.biga at aol.com Wed Jul 29 08:51:57 2015 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Wed, 29 Jul 2015 12:51:57 +0000 Subject: [CMake] =?utf-8?q?CMake_IR?= In-Reply-To: References: <20150729084010.94CFEAD02D@public.kitware.com>, Message-ID: Hi Nico, thank you for the idea. That idea occured to me too, trying to generate the CMakelists.txt script from the desired front-end. Having taken a deep dive into XML schemas, hardcore people even criticise W3C XML Schemas for not having a mathematical foundation which make it difficult to reason about backward compatibility of change to the schema. Using the CMake script, a stateful, imperative script language as an intermediate introduces even more threats, than using a not so well defined, but at least stateless datastructure like XML. Seeing that people want this idea as a seperate project more than a part of CMake, I thought of: defining the XML Schema of building a C++ application defining the XML Schema of a particluar compiler toolchain write a front-end in a script language of choice write a generator for a back-end of choice provide a prototype of a CMakelists.txt >> XML front-end as a proof-of-concept That way CMakelists.txt files could be used in a completeley alternate toolchain. Felad?: Nicolas Despr?s Elk?ldve: ?szerda?, ?2015?. ?j?lius? ?29?. ?13?:?43 C?mzett: Nagy-Egri M?t? Ferenc M?solat: cmake at cmake.org Hi M?t?, One way of doing would be to write a tool using whatever language you like, reading an input script written in whatever language you like, that generates cmake code. In such case, the modification to cmake would be smaller but not that simple. You can see this thread from the archive for further details: http://www.cmake.org/pipermail/cmake-developers/2014-May/010450.html Cheers, Nico On Wed, Jul 29, 2015 at 9:49 AM, Nagy-Egri M?t? Ferenc wrote: Dear CMake devs/users, I wanted to ask your opinion on something that has been troubling me since? well, ever since I started using CMake. I have not found a single person alive who would have said: ?The script language of CMake is nice, intuitive and productive. Authoring scripts is easy, and writing custom macros is not difficult either.? There are gazillions of scripting languages one could have chosen for CMake (Python, Perl, Ruby, Powershell, Bash, etc.) that would allow developers to reuse existing skills, or learn one that is useful elsewhere, not just in terms of CMake. These languages have a lot of thought put into them. They are superior to CMake?s own in just about every regard. I came up with an idea presented here: http://1drv.ms/1MsufbF Enhancements such a change could bring about: The big selling point would be the ability to introduce arbitrary front-ends to CMake, not just CMakelists.txt. Every developer could choose an input language that suits their project/needs/skills. (It would also ease the custom implementations of cmake.exe itself in any language, but that is just a side-effect.) It would modularize the internals of CMake in a cleaner fashion Facilitate the introduction of new languages understood by CMake (such as work put into C# and Swift currently) Would allow for configure-time validating of compiler-specific options Use deferred makefile generation by default (making the implementation of tools like Cotire for precompiled headers trivial to implement, as well NMake batch mode, or detecting multiple/cyclic linkage, by making use of global information about the build process) Many features could automatically be reused by all generators. (Imagine Swift, and Fortran libraries being compiled as NuGet packages and publishing them without any hassle on user side, or having to implement anything in the XCode generator.) SIGNIFICANTLY increase interoperability with other tools. Implementing GUI front-ends (such as in CLion, or Visual Studio (work in progress)) are orders of magnitude simpler by generating a stateless IR, as opposed to generating a stateful script. While it is a refactor of the entire toolchain, it is something that could be done incrementally, with the existing parts functioning normally. I believe CMake is an invaluable tool, but it could do far better. 0/10 CMake users I?ve met say they are ?happy? CMake users. The learning curve is steep, and the skills gained are not reusable. CMake could gain even greater momentum (not by ditching, but) by offering alternate input languages with entities (classes, functions, macros, etc.) that feel natural in the given context. Initial feedback in my vicinity was favorable, even those with zealous CMake opposition aggreed this were something awesome to pull off (though they expressed their disbelief in Kitware and the community approving such a radical change). This mail along with the document only intends to get the ball rolling and hopefully manifest in something similar, starting with CMake 4.0 perhaps. Eagerly await the rolling ball. With all due respect, M?t? -- 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 -- Nicolas Despr?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Wed Jul 29 09:11:48 2015 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Wed, 29 Jul 2015 13:11:48 +0000 Subject: [CMake] =?utf-8?q?CMake_IR?= In-Reply-To: References: <20150729084010.94CFEAD02D@public.kitware.com>, Message-ID: Hi Matt, I also posted this idea to the dev list at the same time, but it?s awaiting moderation due to the inserted links. The project you reference is very similar indeed. It facilitates the consuming of CMake for IDEs, but it does not help in integrating it. Unaffecting the internals of CMake (which end-users don?t really care about anyway) is both good and bad at the same time. IDEs consuming this stateless representation of a build help them being a back-end on their own right, but does not help interacting with the build. Introducing a new source file in the IDE still could only be done by altering the script files (by the IDE or the user). This kind of integration is what CLion is doing, but I?m not sure I would be happy with the kind of features they present here, namely that the IDE ?plays along? with someone who comments out critical parts of the generated script. The IDE should have a chance at interacting with CMake at a lower level, that is CMake understanding it?s own generated stuff you mentioned. But if it would understand it, why not use it internally? Felad?: Matt McCormick Elk?ldve: ?szerda?, ?2015?. ?j?lius? ?29?. ?14?:?58 C?mzett: Nagy-Egri M?t? Ferenc M?solat: cmake at cmake.org Hi M?t?, There is some on-going work along the lines of separating out state. See this thread for more information: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658 You may want to have further discussions on the cmake-developers list. Cheers, Matt On Wed, Jul 29, 2015 at 3:49 AM, Nagy-Egri M?t? Ferenc wrote: > Dear CMake devs/users, > > I wanted to ask your opinion on something that has been troubling me since? > well, ever since I started using CMake. I have not found a single person > alive who would have said: > > ?The script language of CMake is nice, intuitive and productive. Authoring > scripts is easy, and writing custom macros is not difficult either.? > > There are gazillions of scripting languages one could have chosen for CMake > (Python, Perl, Ruby, Powershell, Bash, etc.) that would allow developers to > reuse existing skills, or learn one that is useful elsewhere, not just in > terms of CMake. These languages have a lot of thought put into them. They > are superior to CMake?s own in just about every regard. > > I came up with an idea presented here: http://1drv.ms/1MsufbF > > Enhancements such a change could bring about: > > The big selling point would be the ability to introduce arbitrary front-ends > to CMake, not just CMakelists.txt. Every developer could choose an input > language that suits their project/needs/skills. > (It would also ease the custom implementations of cmake.exe itself in any > language, but that is just a side-effect.) > It would modularize the internals of CMake in a cleaner fashion > Facilitate the introduction of new languages understood by CMake (such as > work put into C# and Swift currently) > Would allow for configure-time validating of compiler-specific options > Use deferred makefile generation by default (making the implementation of > tools like Cotire for precompiled headers trivial to implement, as well > NMake batch mode, or detecting multiple/cyclic linkage, by making use of > global information about the build process) > Many features could automatically be reused by all generators. (Imagine > Swift, and Fortran libraries being compiled as NuGet packages and publishing > them without any hassle on user side, or having to implement anything in the > XCode generator.) > SIGNIFICANTLY increase interoperability with other tools. Implementing GUI > front-ends (such as in CLion, or Visual Studio (work in progress)) are > orders of magnitude simpler by generating a stateless IR, as opposed to > generating a stateful script. > > > While it is a refactor of the entire toolchain, it is something that could > be done incrementally, with the existing parts functioning normally. > > I believe CMake is an invaluable tool, but it could do far better. 0/10 > CMake users I?ve met say they are ?happy? CMake users. The learning curve is > steep, and the skills gained are not reusable. CMake could gain even greater > momentum (not by ditching, but) by offering alternate input languages with > entities (classes, functions, macros, etc.) that feel natural in the given > context. > > Initial feedback in my vicinity was favorable, even those with zealous CMake > opposition aggreed this were something awesome to pull off (though they > expressed their disbelief in Kitware and the community approving such a > radical change). This mail along with the document only intends to get the > ball rolling and hopefully manifest in something similar, starting with > CMake 4.0 perhaps. > > Eagerly await the rolling ball. > > With all due respect, > M?t? > > -- > > 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 DLRdave at aol.com Wed Jul 29 09:25:51 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 29 Jul 2015 09:25:51 -0400 Subject: [CMake] CMake IR In-Reply-To: <20150729112929.39747B0C74@public.kitware.com> References: <20150729084010.94CFEAD02D@public.kitware.com> <20150729112929.39747B0C74@public.kitware.com> Message-ID: This all seems like a very good idea, and also like it will take an enormous amount of time and effort. I'd like to help, but I have quite limited available time these days. Let us know if there are specific things you need help with in advancing towards an implementation of these ideas. David C. On Wed, Jul 29, 2015 at 6:02 AM, Nagy-Egri M?t? Ferenc wrote: > How many people have I asked? We are a group of 5, and have several fellows > who have drifted off to companies each with their respective dev teams of > 5-15 people. General tendency is that everywhere, there is 1 CMake guru, the > rest would be better off not touching the scripts, because they do more harm > than good. > > I can believe that someone coming from the autotools or GNU Make find CMake > to be a salvation. But someone being used to Visual Studio?s Solution > Explorer (and things generally working out-of-the-box) finds hand authoring > scripts in a unique language that?s been documented only 2 months ago? Don?t > get me wrong, I am an admin and spend a considerable amount of time > scripting in various languages. It?s not the fact that I have to touch > scripts. It?s the fact that doing so is a pain. > > The reason I suggested this as a CMake 4.0 feature is because I am the 11th > person out of 10 who actually ?likes? CMake a bit and cares for it. I?d > rather empower a tool I use on a daily basis than spawn an alternative and > spend half my life trying to winning the world over. As is the case with > operating systems, they have accumulated so much code, there is no point in > trying to write a new one, rather than fixing the ones that exist. Every > respectable cross-platform project uses CMake and I have no intention of > going against that. I?ve neither the resources (time mostly) to do that, > neither do I like the fact of spawning ?yet another build system? when > nothing prevents from enhancing one that is almost perfect. > > With enough feedback like yours, I might just brew something similar in a > few years time (on the expense of my free time). I could do something just > like the author of Invoke-Build did and brew something that only I in the > entire world would use, even though that in some sense Invoke-Build is far > better than GNU Make or NMake in its foundations (being a processor of > inter-dependent jobs, and nothing else). > > I understand your concern with people trying to hijack a community project > and alter it to their personal ideals. However the fact that there are > people fighting a war for CMake-izing Boost 2.0, and the fact that Boost 1.x > failed two attempts at doing so is because the Boost developers were > reluctant to pick up CMake as a build system, even though it is superior to > Boost Build in every aspect. That too, is a build system used only in Boost, > and nowhere else in the world. (I even had an email discussion with the > authors of such an attempt. He handed all the working scripts to the devs, > all they should?ve do was type cmake.exe ../src, but they did not.) One of > the reasons these attempts failed was because of the Boost dev?s love for > their ?own child? (Boost Build). The other is that CMake is unfriendly for > devs. It is better than many others, but worse than many others. When it > works, it?s great. But getting it to work is not always as easy as one might > like. > > I had an idea I felt would benefit the community (the CMake community that > is), I thought I?d share it as an idea. > > ps.: I also had an email encounter with the dev of Invoke-Build about > cooking up an Invoke-Build back-end to CMake. He had no idea CMake exists, > but because he needed a scriptable (from Powershell that is) build system, > he cooked up one of his own. If CMake had a PS front-end, maybe a whole > bunch of people pick it up who don?t even know it exists because they live > outside the cross-platform world. > > Felad?: Raymond Wan > Elk?ldve: ?szerda?, ?2015?. ?j?lius? ?29?. ?11?:?01 > C?mzett: Nagy-Egri M?t? Ferenc > M?solat: cmake at cmake.org > > Hi M?t?, > > > > On Wed, Jul 29, 2015 at 3:49 PM, Nagy-Egri M?t? Ferenc > wrote: >> I wanted to ask your opinion on something that has been troubling me >> since? >> well, ever since I started using CMake. I have not found a single person >> alive who would have said: >> >> ?The script language of CMake is nice, intuitive and productive. Authoring >> scripts is easy, and writing custom macros is not difficult either.? > > > I'm not much of an expert wih CMake but when someone says "I have not > found a single person alive...", I would usually counter by asking how > many people you've asked? :-) > > >> Initial feedback in my vicinity was favorable, even those with zealous >> CMake >> opposition aggreed this were something awesome to pull off (though they >> expressed their disbelief in Kitware and the community approving such a >> radical change). This mail along with the document only intends to get the >> ball rolling and hopefully manifest in something similar, starting with >> CMake 4.0 perhaps. > > > I for one am quite happy with CMake. We can point fingers at > technology (i.e., which programming language is better or worse), but > in the end, it's really the community support (IMHO). And if I'm > stuck with CMake, I can usually find answers to most of my problems on > this e-mail list or by searching Google. > > If you want to refactor CMake along these lines: > >> There are gazillions of scripting languages one could have chosen for >> CMake (Python, Perl, Ruby, Powershell, Bash, etc.) > > I have a question for you. Why introduce them as CMake 4.0? Why not > start a new project from scratch and give it a new name. Why "take > over" the name of an already working tool? I mean, it's like > complaining about Perl (apologies to Perl lovers...just an example!) > and wanting to rewrite it from scratch. Up to a point, it is better > to come up with new name...if you think you can do it better. > > I honestly don't think CMake is broken. Perhaps it's because I came > from Makefiles and then Autotools -- the latter was a nightmare! > Perhaps one possible improvement to CMake might be to improve the > documentation a bit so that maybe there's more information on how to > *write* modules (as opposed to using modules). > > 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 From DLRdave at aol.com Wed Jul 29 09:28:14 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 29 Jul 2015 09:28:14 -0400 Subject: [CMake] CMake IR In-Reply-To: <20150729131152.DB009AFAA4@public.kitware.com> References: <20150729084010.94CFEAD02D@public.kitware.com> <20150729131152.DB009AFAA4@public.kitware.com> Message-ID: And I wouldn't give up just yet on building support for this into CMake, if not building the entire thing into a future CMake. Perhaps there are valid objections, or perhaps people just need convincing. D On Wed, Jul 29, 2015 at 8:51 AM, Nagy-Egri M?t? Ferenc wrote: > Hi Nico, > > thank you for the idea. That idea occured to me too, trying to generate the > CMakelists.txt script from the desired front-end. Having taken a deep dive > into XML schemas, hardcore people even criticise W3C XML Schemas for not > having a mathematical foundation which make it difficult to reason about > backward compatibility of change to the schema. Using the CMake script, a > stateful, imperative script language as an intermediate introduces even more > threats, than using a not so well defined, but at least stateless > datastructure like XML. > > Seeing that people want this idea as a seperate project more than a part of > CMake, I thought of: > > defining the XML Schema of building a C++ application > defining the XML Schema of a particluar compiler toolchain > write a front-end in a script language of choice > write a generator for a back-end of choice > provide a prototype of a CMakelists.txt >> XML front-end as a > proof-of-concept > > > That way CMakelists.txt files could be used in a completeley alternate > toolchain. > > Felad?: Nicolas Despr?s > Elk?ldve: ?szerda?, ?2015?. ?j?lius? ?29?. ?13?:?43 > C?mzett: Nagy-Egri M?t? Ferenc > M?solat: cmake at cmake.org > > Hi M?t?, > > One way of doing would be to write a tool using whatever language you like, > reading an input script written in whatever language you like, that > generates cmake code. In such case, the modification to cmake would be > smaller but not that simple. > > You can see this thread from the archive for further details: > http://www.cmake.org/pipermail/cmake-developers/2014-May/010450.html > > Cheers, > Nico > > > On Wed, Jul 29, 2015 at 9:49 AM, Nagy-Egri M?t? Ferenc > wrote: >> >> Dear CMake devs/users, >> >> I wanted to ask your opinion on something that has been troubling me >> since? well, ever since I started using CMake. I have not found a single >> person alive who would have said: >> >> ?The script language of CMake is nice, intuitive and productive. Authoring >> scripts is easy, and writing custom macros is not difficult either.? >> >> There are gazillions of scripting languages one could have chosen for >> CMake (Python, Perl, Ruby, Powershell, Bash, etc.) that would allow >> developers to reuse existing skills, or learn one that is useful elsewhere, >> not just in terms of CMake. These languages have a lot of thought put into >> them. They are superior to CMake?s own in just about every regard. >> >> I came up with an idea presented here: http://1drv.ms/1MsufbF >> >> Enhancements such a change could bring about: >> >> The big selling point would be the ability to introduce arbitrary >> front-ends to CMake, not just CMakelists.txt. Every developer could choose >> an input language that suits their project/needs/skills. >> (It would also ease the custom implementations of cmake.exe itself in any >> language, but that is just a side-effect.) >> It would modularize the internals of CMake in a cleaner fashion >> Facilitate the introduction of new languages understood by CMake (such as >> work put into C# and Swift currently) >> Would allow for configure-time validating of compiler-specific options >> Use deferred makefile generation by default (making the implementation of >> tools like Cotire for precompiled headers trivial to implement, as well >> NMake batch mode, or detecting multiple/cyclic linkage, by making use of >> global information about the build process) >> Many features could automatically be reused by all generators. (Imagine >> Swift, and Fortran libraries being compiled as NuGet packages and publishing >> them without any hassle on user side, or having to implement anything in the >> XCode generator.) >> SIGNIFICANTLY increase interoperability with other tools. Implementing GUI >> front-ends (such as in CLion, or Visual Studio (work in progress)) are >> orders of magnitude simpler by generating a stateless IR, as opposed to >> generating a stateful script. >> >> >> While it is a refactor of the entire toolchain, it is something that could >> be done incrementally, with the existing parts functioning normally. >> >> I believe CMake is an invaluable tool, but it could do far better. 0/10 >> CMake users I?ve met say they are ?happy? CMake users. The learning curve is >> steep, and the skills gained are not reusable. CMake could gain even greater >> momentum (not by ditching, but) by offering alternate input languages with >> entities (classes, functions, macros, etc.) that feel natural in the given >> context. >> >> Initial feedback in my vicinity was favorable, even those with zealous >> CMake opposition aggreed this were something awesome to pull off (though >> they expressed their disbelief in Kitware and the community approving such a >> radical change). This mail along with the document only intends to get the >> ball rolling and hopefully manifest in something similar, starting with >> CMake 4.0 perhaps. >> >> Eagerly await the rolling ball. >> >> With all due respect, >> M?t? >> >> -- >> >> 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 > > > > > -- > Nicolas Despr?s > > -- > > 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 bill.hoffman at kitware.com Wed Jul 29 09:41:03 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 29 Jul 2015 09:41:03 -0400 Subject: [CMake] CMake IR In-Reply-To: <20150729132210.2B20FB0B69@public.kitware.com> References: <20150729084010.94CFEAD02D@public.kitware.com> <20150729132210.2B20FB0B69@public.kitware.com> Message-ID: <55B8D7EF.2040108@kitware.com> On 7/29/2015 9:11 AM, Nagy-Egri M?t? Ferenc via CMake wrote: > I also posted this idea to the dev list at the same time, but it?s > awaiting moderation due to the inserted links. > We really do not moderate the lists like that. If it is pending it is because you are not a member of the list. So, you should become a member: http://www.cmake.org/mailman/listinfo/cmake-developers Then repost. -Bill From nicolas.despres at gmail.com Wed Jul 29 09:51:16 2015 From: nicolas.despres at gmail.com (=?UTF-8?Q?Nicolas_Despr=C3=A8s?=) Date: Wed, 29 Jul 2015 15:51:16 +0200 Subject: [CMake] CMake IR In-Reply-To: <55b8d115.8815370a.249be.2ee9SMTPIN_ADDED_MISSING@mx.google.com> References: <20150729084010.94CFEAD02D@public.kitware.com> <55b8d115.8815370a.249be.2ee9SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Wed, Jul 29, 2015 at 2:51 PM, Nagy-Egri M?t? Ferenc wrote: > Hi Nico, > > thank you for the idea. That idea occured to me too, trying to generate > the CMakelists.txt script from the desired front-end. Having taken a deep > dive into XML schemas, hardcore people even criticise W3C XML Schemas for > not having a mathematical foundation which make it difficult to reason > about backward compatibility of change to the schema. Using the CMake > script, a stateful, imperative script language as an intermediate > introduces even more threats, than using a not so well defined, but at > least stateless datastructure like XML. > I disagree with that statement because I do not see any issue in generating stateful language. autoconf generates shell script. bison, flex, and many others generates C code. Compilers front-end generate IR which is nothing else than a unified assembly language. Compilers back-end generate assembly language for various CPU. Correct me if I am wrong but all those languages are stateful and all thoses generators have been working pretty well for decades. I think the true requirement is whether the language being generated is stable or not. The CMake script language is stable and a lot of effort is spent to keep backward compatibility via policies. [...] -- Nicolas Despr?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From domen.vrankar at gmail.com Wed Jul 29 10:07:41 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 29 Jul 2015 16:07:41 +0200 Subject: [CMake] Tests 115, 116, 117 and, 118 fail In-Reply-To: <55B34300.9070403@grueninger.de> References: <55B34300.9070403@grueninger.de> Message-ID: > I am trying to create a CMake 3.3.0 RPM for openSuse using their Open > Build Service. It compiles but the tests 115, 116, 117 and, 118 fail. > The RPM build causes the error but I don't get what I should change. I > attached the output. >From the attached output it would seem that something went wrong during symlink creation/packaging: ERROR: link target doesn't exist (neither in build root nor in installed [ 513s] system): [ 513s] [ 513s] /usr/lib64/inside_relocatable_one/depth_two/symlink_outside_package -> /usr/lib64/inside_relocatable_one/depth_two/outside_package Could you please check if this symlink gets created and if not why? This seems to be something specific to your environment as the tests run fine on nightly dashboard. Which OS are you using? Regards, Domen From domagoj.saric at littleendian.com Wed Jul 29 10:25:54 2015 From: domagoj.saric at littleendian.com (Domagoj Saric) Date: Wed, 29 Jul 2015 16:25:54 +0200 Subject: [CMake] CMake IR In-Reply-To: <20150729112928.D87D7B0C73@public.kitware.com> References: <20150729084010.94CFEAD02D@public.kitware.com> <20150729112928.D87D7B0C73@public.kitware.com> Message-ID: <55B8E272.9090207@littleendian.com> On 29.7.2015. 12:02, Nagy-Egri M?t? Ferenc via CMake wrote: > The reason I suggested this as a CMake 4.0 feature is because I am the 11th > person out of 10 who actually ?likes? CMake a bit and cares for it. I?d rather > empower a tool I use on a daily basis than spawn an alternative and spend half > my life trying to winning the world over. My 2 ranting cents: you perfectly summed my own thoughts on CMake. This love-hate relationship seems to be a recurring theme (where you 'adore' the idea behind CMake but 'abhore' the implementation of the idea) so 'there's got to be something to it' ":)" In addition to it feeling like working with (or fighting against) an ugly crossover between a C preprocessor and a shell script from 1979, an increasingly big source of frustration is its rigidness and limitation of 'only one toolset/compiler per project'. With platforms like Android (NDK) that require you to build for X different architectures with different toolsets/compilers, or IDEs like Xcode or Visual Studio that offer targeting so many different combinations of toolsets and targets (even Android and iOS in the latest version) >from a single project< having a build system that requires you to create a separate build directory for each and every one of those combinations (and then somehow connect them into a master build where a single CPack invocation will be able to gather and package the build results of all the sub-builds) feels like an ancient torture device. As for the proposal, wouldn't the first logical step in 'decoupling CMake from its legacy' be what Clang did with libclang, i.e extracting the 'core'/non-scripting part of CMake into a libcmake around which new interfaces/DSLs can written/created..? -- Domagoj Saric Software Architect www.LittleEndian.com From domen.vrankar at gmail.com Wed Jul 29 10:59:24 2015 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 29 Jul 2015 16:59:24 +0200 Subject: [CMake] Tests 115, 116, 117 and, 118 fail In-Reply-To: <1162181512.353894.1438180748539.JavaMail.open-xchange@omgreatgod.store> References: <55B34300.9070403@grueninger.de> <1162181512.353894.1438180748539.JavaMail.open-xchange@omgreatgod.store> Message-ID: > I am not sure how to check for the links or their targets. Probably the tests run > fine on my local openSuse installation. A single test can be run with: ctest -V -R "CPackComponentsForAll-RPM-default" This will create directory structure in: ./Tests/CPackComponentsForAll/buildRPM-default/ There you should search for symlink_outside_package that should be found once in the directory above and once in one of child directories of _CPack_Packages subdirectory. Check if symlinks exist and check where they point to with "ls -la ". Regards, Domen From nils.guillermin at gmail.com Wed Jul 29 21:02:45 2015 From: nils.guillermin at gmail.com (Nils Guillermin) Date: Wed, 29 Jul 2015 21:02:45 -0400 Subject: [CMake] CMake inconsistent with python libraries Message-ID: Hello Everyone, I posted earlier about having issues with CMake listing a certain library as being found and then calling it by the wrong name in the (found version "XXX", minimum X) part. This problem has now been solved by using the patched CMake from nikolausdemmel/devel/cmake (Using homebrew, the command is `brew install nikolausdemmel/devel/cmake`). The actual program I was building (bistromath's gr-air-modes) still doesn't work, but I'll have to investigate whether it is still a CMake issue. As well I just wanted to make people aware of nikolaus demmel's branch if they're having similar issues. Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens.auer at cgi.com Thu Jul 30 03:14:46 2015 From: jens.auer at cgi.com (Auer, Jens) Date: Thu, 30 Jul 2015 07:14:46 +0000 Subject: [CMake] Passing generator expressions in variables Message-ID: Hi, I am trying to dynamically assemble a list of generator expressions and use them in add_executable. The background is that I have some macros to add targets, e.g. add_my_library(TARGET liba SOURCES ...) # this class add_library(liba OBJECT ...) internally add_my_executable(TARGET a DEPENDS liba libb SOURCES ...) In add_my_executable, I create a list of $ strings for all d {liba, libb}. However, cmake complains that it cannot find the source file $. A simplified example of what I want to do is this: add_library(A OBJECT a.cpp) set(alib $ ) With cmake 3.2.2, the first add_executable fails, the second one works. Is there another way to do this? Best wishes, Jens -- Dr. Jens Auer | CGI | Software Engineer CGI Deutschland Ltd. & Co. KG Rheinstra?e 95 | 64295 Darmstadt | Germany T: +49 6151 36860 154 jens.auer at cgi.com Unsere Pflichtangaben gem?? ? 35a GmbHG / ?? 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben. CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens.auer at cgi.com Thu Jul 30 03:17:15 2015 From: jens.auer at cgi.com (Auer, Jens) Date: Thu, 30 Jul 2015 07:17:15 +0000 Subject: [CMake] CMake finds wrong ar/ranlib/nm In-Reply-To: <55B79A1C.9080400@kitware.com> References: <55B79A1C.9080400@kitware.com> Message-ID: Thanks a lot. Obviously, setting the environment when calling cmake is not enough. The command scl enable devtoolset-3 "cmake ../src" sets the path etc and runs the cmake command, but it seems that cmake opens a new subshell with default settings. I've added the settings to .bashrc and it now finds the correct ar/ranlib etc. Unfortunately, this uncovered a bug in binutils on my system (centos 7) which results in a segfault when using ar to create a static lib with link-time-optimizations enabled. As a workaround, I tried to convert the library targets to OBJECT libraries, which also makes sense because I use the libraries to structure my project only. They are not delivered. However, this resulted in another problem with generator expressions. I will post another question for that. Thanks, Jens -- Dr. Jens Auer | CGI | Software Engineer CGI Deutschland Ltd. & Co. KG Rheinstra?e 95 | 64295 Darmstadt | Germany T: +49 6151 36860 154 jens.auer at cgi.com Unsere Pflichtangaben gem?? ? 35a GmbHG / ?? 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben. CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail. -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Bill Hoffman Sent: 28 July 2015 17:05 To: cmake at cmake.org Subject: Re: [CMake] CMake finds wrong ar/ranlib/nm On 7/28/2015 4:39 AM, Auer, Jens wrote: > Hi, > > I am trying to use another compiler than the default one installed on > my system. I have to do this because I want to use a newer gcc than > the one on centos 7,so I installed RedHat Developer Toolset 3 with gcc > 4.9. When I call cmake with > > sclenable devtoolset-3 "cmake ../src" in my build directory, it > generates makefiles which use the new compiler and linker, but still > uses the default /usr/bin/ar etc. This is problematic because I enable > whole-program-optimization in release mode, and this needs to use the > ar provided with gcc 4.9 to handle the link-time optimization object files. > > I have tried various things to force cmake to use a specific ar, but > none of these worked: > > -Manually set CMAKE_AR in the CMakeLists.txt > > -Change CMAKE_AR in the cache > > -Write my own toolchain file > > With the toolchain file, cmake creates Makefiles but puts an empty ar > command in the lib "link" command, and building thus fails with an error. > > Am I missing something? > This is an environment thing. Make sure the command line you are using is setup to find the other tools first in your PATH and it should work. CMake assumes the environment is setup to work with the compiler you want to use. -Bill -- 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 csiga.biga at aol.com Thu Jul 30 07:51:54 2015 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Thu, 30 Jul 2015 11:51:54 +0000 Subject: [CMake] =?utf-8?q?CMake_IR?= In-Reply-To: <55B8E272.9090207@littleendian.com> References: <20150729084010.94CFEAD02D@public.kitware.com> <20150729112928.D87D7B0C73@public.kitware.com>, <55B8E272.9090207@littleendian.com> Message-ID: @Domagoj: ?In addition to it feeling like working with (or fighting against) an ugly crossover between a C preprocessor and a shell script from 1979, an increasingly big source of frustration is its rigidness and limitation of 'only one toolset/compiler per project'.? ? I couldn?t have put it any better myself. Indeed, I recently had the idea of writing a Windows Store XAML application to give a GUI frontend to TagLib, just as an excercise and give it a jump start in August on my vacation when I want to do something productive. I started collecting the dependencies and everything, and came across? CMake has Windows Store support, but how on Earth am I going to build x86/x64/ARM targets from one VS solution? I was reading the docs a while and said to mysef ?ah, f*ck it, no CMake has nothing to do here.? It is very annoying that CMake has these limitation at it?s very core that would take months and months to rule out. I can imagine Android being even more painful in this regard. CMake really could do a whole lot better in this. @Nicolas: Yes, these tools indeed have been working for the past few decades. Others also suggested why don?t I generate CMakelists.txt instead? The problem is that the current limitations of CMake all originate from the way the workflow is organized. Multi-configuration makefiles are trivial to implement if you do them by hand. All targets append the architecture after their name (app-x86, app-x64, lib-x86, etc.) and there were all-x86 and all-x64 targets, and there were the usual ?all? target that references all-x86, all-x64. In CMake the workflow is baked into selecting an architecture at the earliest points in the configuration process and stores it as a global variable (state!) which then shoots all multi-configuration generators in the knee. Yes, it is possible to remove this limitation from CMake, but it would take roughly a year. Holding onto this limitation alone just because it is historically the way how CMake has been designed immediately rules it out from ~75% of application development going on in the world in the future (mobile app devel), which is funny because building cross-platform mobile apps is the future, and this is just the market that could benefit of CMake the most. @Bill: I am a member, I just tried sending using the same mail using the ?secret CC? option. It seems it did not work. @David: Maybe some convincing and positive feedback can do the trick. I mostly live my life on Windows, so most technologies and tools relate to Windows, but all the HPC clusters I use are linux, hence the need for CMake. My initial research builded down to this: Learn from the ?competition? Identify the portable properties of building a C++ application (mostly from CMake) and define an XML Schema. Create the Schema of a chosen compiler Implementing everything in C++ Initially do not bother with a front-end. Using the Schema, Visual Studio can provide Intellisense based on the .xsd file. This is sufficient for dev pourposes. Using this open-source lib, getting a parser/deserializer and datastructure for use in C++ is as easy as 1-2-3. Use the aforementioned lib to get a datastructure and serializer using the MSBuild Schema. Almost done. Just wrap the Schemas of the IR into neat C++ classes. Tadaaa: C++ front-end. Wrap the C++ classes with C++/CX for use with Powershell. Tadaaa: Powershell front-end. Implement everything in PS (just for kicks) PS alread understands the [xml] type and can read/write and process it. Validation can be used from PSCX. Transform the data read into MSBuild?s own. (Somewhat blindly, because there are no neat classes available in the MSBuild Schema format) Amost done. Write PS5 classes around the Schema entities. Tadaaa: PS front-end. Future work: Make it better Implement other generators after the all too convenient, XML based MSBuild. Add Unit Test Schemas Add packaging Schemas (Nuget is again XML based with XSD Schema, trivial to implement) Enhance package support to be able to fetch dependencies from git and build (a la Cargo), have installation method similar to CMake packages, etc. If the entire build?s information is available as an iterable C++ tree-like datastructure, how hard can it be to implement generators like Ninja? (Not trivial, but not hard either.) If there is a clear Schema of valid options for a specific feature, so many things simplify. Again, imagine automatic fetching of dependencies from multiple repositories even. Nuget, GitHub, .deb, you name it! And I haven?t even mentioned things like remote builds and what not? all new features could be introduced as a seperate Schema with it?s respective options, and if the user references the schema in the IR, and the generator supports it, it is done. Imagine distributed builds similar to Incredibuild, but with CMake. Nothing is needed, but the user define a pool of machines, and execution falls back to the core custom_command feature and call ssh and scp (or anything else) from the CLI and get the job done. SOOO many things could be trivially done, and GNUMake, Ninja, XCode, and all generators gain the ability for free! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleigh at codelibre.net Thu Jul 30 08:45:23 2015 From: rleigh at codelibre.net (Roger Leigh) Date: Thu, 30 Jul 2015 13:45:23 +0100 Subject: [CMake] Making and using static and shared libraries on Windows with Visual Studio Message-ID: <55BA1C63.2070303@codelibre.net> Hi folks, This might not be a problem with CMake, it's probably due to my lack of familiarity with Windows either in CMakeLists.txt or in the code itself. I have a large C++ codebase which uses CMake to build on Linux/Unix/MacOS X. I'm currently porting it to use a superbuild infrastructure to build on Windows. The superbuild works fine, but I'm running into odd linking errors. I've tried to create a minimal testcase to demonstrate the problem. This is here: https://github.com/rleigh-dundee/dlltest (test-vs201n.bat will run cmake and the builds automatically) This creates a few libraries which contain classes using std::string or std::vector and then links them into test programs. It's really trivial, and works fine on non-Windows systems, but fails when linking static libs on Windows. With Windows, I see this: Shared Static VS2012 Fail Fail VS2013 Works Fail VS2015 Warns Fail VS2012 has problems parsing the code, which looks like a VS2012 bug needing workaround, and the VS2015 DLL warning looks like some change in the internal implementation details of string and vector. What's concerning me is that I'm getting link errors along the lines of: c.lib(c.obj) : error LNK2019: unresolved external symbol "public: static unsigned __int64 const std:: basic_string,class std::allocator >::npos (?npos@?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@2_KB) referenced in function "class std::basic_string,class std::allocator > * __cdecl std::_Uninit_copy,class std::allocator > const *,class std::basic_string,class std::allocator > *,class std::allocator< class std::basic_string,class std::allocator > > >(class std::basic_string,class std::allocator > const *,class std::basic_string,class std::allocator > const *,class std::basic_string,class std::allocator > *,struct std::_Wrap_alloc,class std::allocator > > > &,struct std::_Nonscalar_ptr_iterator_tag)" (??$_Uninit_copy at PEBV?$basic_string at DU?$char_traits @D at std@@V?$allocator at D@2@@std@@PEAV12 at V?$allocator at V?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@@2@@std@@YAPEAV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@0 at PEBV10@0PEAV10 at AEAU?$_Wrap_alloc at V?$allocator at V?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@@std@@@0 at U_Nonscalar_ptr_iterator_tag@0@@Z) [C:\Users\rleigh\libtest\2013s\testc.vcxproj] c.lib(c2.obj) : error LNK2001: unresolved external symbol "public: static unsigned __int64 const std::basic_string,class std::allocator >::npos" (?npos@?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@2_KB) [C:\Users\rleigh\libtest\2013s\testc.vcxproj] The odd thing: this only occurs for libraries "c" and "d" using std::vector while libraries "a" and "b" using std::string work just fine--I'm not sure what exactly is using npos unless it's part of the vector default construction of string. Could any CMake users with Windows expertise possibly suggest what I'm doing wrong or missing here, either in the CMake logic or in the code. I thought I had all the template instantiations right for DLL export, but thought static libraries would Just Work! Many thanks, Roger From bill.hoffman at kitware.com Thu Jul 30 09:26:31 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 30 Jul 2015 09:26:31 -0400 Subject: [CMake] CMake finds wrong ar/ranlib/nm In-Reply-To: References: <55B79A1C.9080400@kitware.com> Message-ID: <55BA2607.6080507@kitware.com> On 7/30/2015 3:17 AM, Auer, Jens wrote: > Thanks a lot. Obviously, setting the environment when calling cmake > is not enough. The command scl enable devtoolset-3 "cmake ../src" > sets the path etc and runs the cmake command, but it seems that cmake > opens a new subshell with default settings. I've added the settings > to .bashrc and it now finds the correct ar/ranlib etc. I don't believe it. CMake does not open a new shell, something else is going on. Sounds like you have other system problems to deal with. -Bill From rleigh at codelibre.net Thu Jul 30 09:39:39 2015 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Thu, 30 Jul 2015 14:39:39 +0100 (BST) Subject: [CMake] Making and using static and shared libraries on Windows with Visual Studio In-Reply-To: <55BA1C63.2070303@codelibre.net> References: <55BA1C63.2070303@codelibre.net> Message-ID: It turns out this was my fault: removing the instantiation/export of std::char_traits was sufficient to correct the linker errors. Sorry for the noise, Roger From dumont.guillaume at gmail.com Thu Jul 30 09:43:50 2015 From: dumont.guillaume at gmail.com (Guillaume Dumont) Date: Thu, 30 Jul 2015 09:43:50 -0400 Subject: [CMake] Making and using static and shared libraries on Windows with Visual Studio In-Reply-To: <55BA1C63.2070303@codelibre.net> References: <55BA1C63.2070303@codelibre.net> Message-ID: Roger, Did you try to remove all the explicit template exports? I never had to do it and compiled many static and shared libraries on Windows. Of course VS is going to complain about exporting template classes but as long as you don't try to mix VS versions I think you can safely ingore those warnings. Also, this block of code in a.h, b.h, etc.: #ifndef A_H #define A_H #include #include "aexport.h" #ifdef a_BUILT_AS_STATIC # define a_EXPORT_TEMPLATE #else # ifndef a_EXPORT_TEMPLATE # ifdef a_EXPORTS /* We are building this library */ # define a_EXPORT_TEMPLATE # else /* We are using this library */ # define a_EXPORT_TEMPLATE extern # endif # endif # ifndef A_NO_EXPORT # define A_NO_EXPORT # endif #endif #ifdef _MSC_VER // Explicit template exports. #include a_EXPORT_TEMPLATE template class a_EXPORT std::allocator; a_EXPORT_TEMPLATE template struct a_EXPORT std::char_traits; a_EXPORT_TEMPLATE template class a_EXPORT std::basic_string, std::allocator >; #endif class a_EXPORT a { std::string val; public: a(); std::string const& getval() const; }; #endif // A_H seems redundant. I would remove it. Including aexport.h should be enough. Hope this helps. Guillaume On Thu, Jul 30, 2015 at 8:45 AM, Roger Leigh wrote: > ibraries which -- Guillaume Dumont ========================= dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Thu Jul 30 09:50:32 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 30 Jul 2015 09:50:32 -0400 Subject: [CMake] CMake IR In-Reply-To: <20150730125950.06CE8B0B54@public.kitware.com> References: <20150729084010.94CFEAD02D@public.kitware.com> <20150729112928.D87D7B0C73@public.kitware.com> <55B8E272.9090207@littleendian.com> <20150730125950.06CE8B0B54@public.kitware.com> Message-ID: <55BA2BA8.7060509@kitware.com> On 7/30/2015 7:51 AM, Nagy-Egri M?t? Ferenc via CMake wrote: > Bill: > > I am a member, I just tried sending using the same mail using > the ?secret CC? option. It seems it did not work. > OK, I just checked and it was rejected because of this: Reason: Message has implicit destination I have approved it, but if you could send directly to the list that would be better as I don't look at the rejected posts that often. -Bill From nilsgladitz at gmail.com Thu Jul 30 09:52:16 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 30 Jul 2015 15:52:16 +0200 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: <20150730133737.03E50B108D@public.kitware.com> References: <20150730133737.03E50B108D@public.kitware.com> Message-ID: <55BA2C10.8010607@gmail.com> On 07/29/2015 09:49 AM, Nagy-Egri M?t? Ferenc via cmake-developers wrote: > * > The big selling point would be the ability to introduce arbitrary > front-ends to CMake, not just CMakelists.txt. Every developer could > choose an input language that suits their project/needs/skills. I don't like that idea. Many different languages would make supporting (as in helping someone with his project) and understanding arbitrary CMake projects much harder. I would certainly be for adding a single additional script language though. I am personally still rooting for Lua. Nils From jens.auer at cgi.com Thu Jul 30 10:03:53 2015 From: jens.auer at cgi.com (Auer, Jens) Date: Thu, 30 Jul 2015 14:03:53 +0000 Subject: [CMake] CMake finds wrong ar/ranlib/nm In-Reply-To: <55BA2607.6080507@kitware.com> References: <55B79A1C.9080400@kitware.com> <55BA2607.6080507@kitware.com> Message-ID: I did some more investigation and found out that this only happens when I use CMAKE_BUILD_TYPE=RELEASE. Could this be related to the bug in centos? When I set the build type to release, ar crashes when using lto. Could this make cmake discard the ar in the custom directory and fall-back to the system one? Best wishes, Jens -- Dr. Jens Auer | CGI | Software Engineer CGI Deutschland Ltd. & Co. KG Rheinstra?e 95 | 64295 Darmstadt | Germany T: +49 6151 36860 154 jens.auer at cgi.com Unsere Pflichtangaben gem?? ? 35a GmbHG / ?? 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben. CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail. > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Bill Hoffman > Sent: 30 July 2015 15:27 > To: cmake at cmake.org > Subject: Re: [CMake] CMake finds wrong ar/ranlib/nm > > On 7/30/2015 3:17 AM, Auer, Jens wrote: > > Thanks a lot. Obviously, setting the environment when calling cmake is > > not enough. The command scl enable devtoolset-3 "cmake ../src" > > sets the path etc and runs the cmake command, but it seems that cmake > > opens a new subshell with default settings. I've added the settings to > > .bashrc and it now finds the correct ar/ranlib etc. > I don't believe it. CMake does not open a new shell, something else is going on. > Sounds like you have other system problems to deal with. > > -Bill > > > > -- > > 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 jens.auer at cgi.com Thu Jul 30 09:53:04 2015 From: jens.auer at cgi.com (Auer, Jens) Date: Thu, 30 Jul 2015 13:53:04 +0000 Subject: [CMake] Passing generator expressions in variables In-Reply-To: References: Message-ID: Just to add to my question: I do not expect that set(alib "$") expands to the list of files, I just want to pass the string "$" to add_executable and then evaluate it there. From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Auer, Jens Sent: 30 July 2015 09:15 To: cmake at cmake.org Subject: [CMake] Passing generator expressions in variables Hi, I am trying to dynamically assemble a list of generator expressions and use them in add_executable. The background is that I have some macros to add targets, e.g. add_my_library(TARGET liba SOURCES ...) # this class add_library(liba OBJECT ...) internally add_my_executable(TARGET a DEPENDS liba libb SOURCES ...) In add_my_executable, I create a list of $ strings for all d {liba, libb}. However, cmake complains that it cannot find the source file $. A simplified example of what I want to do is this: add_library(A OBJECT a.cpp) set(alib $ ) With cmake 3.2.2, the first add_executable fails, the second one works. Is there another way to do this? Best wishes, Jens -- Dr. Jens Auer | CGI | Software Engineer CGI Deutschland Ltd. & Co. KG Rheinstra?e 95 | 64295 Darmstadt | Germany T: +49 6151 36860 154 jens.auer at cgi.com Unsere Pflichtangaben gem?? ? 35a GmbHG / ?? 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben. CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dank at kegel.com Thu Jul 30 10:10:52 2015 From: dank at kegel.com (Dan Kegel) Date: Thu, 30 Jul 2015 09:10:52 -0500 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: <55BA2C10.8010607@gmail.com> References: <20150730133737.03E50B108D@public.kitware.com> <55BA2C10.8010607@gmail.com> Message-ID: >> The big selling point would be the ability to introduce arbitrary >> front-ends to CMake, not just CMakelists.txt. Every developer could >> choose an input language that suits their project/needs/skills. > > I don't like that idea. > > Many different languages would make supporting (as in helping > someone with his project) and understanding arbitrary CMake projects much harder. +1 Also, adding XML of any sort to CMake would instantly taint it with ugly-stink. From DLRdave at aol.com Thu Jul 30 10:30:13 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 30 Jul 2015 10:30:13 -0400 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: References: <20150730133737.03E50B108D@public.kitware.com> <55BA2C10.8010607@gmail.com> Message-ID: json is SOOO much sexier than XML..... ;-) On Thu, Jul 30, 2015 at 10:10 AM, Dan Kegel wrote: >>> The big selling point would be the ability to introduce arbitrary >>> front-ends to CMake, not just CMakelists.txt. Every developer could >>> choose an input language that suits their project/needs/skills. >> >> I don't like that idea. >> >> Many different languages would make supporting (as in helping >> someone with his project) and understanding arbitrary CMake projects much harder. > > +1 > > Also, adding XML of any sort to CMake would instantly taint it with ugly-stink. > -- > > 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 dank at kegel.com Thu Jul 30 10:48:00 2015 From: dank at kegel.com (Dan Kegel) Date: Thu, 30 Jul 2015 09:48:00 -0500 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: References: <20150730133737.03E50B108D@public.kitware.com> <55BA2C10.8010607@gmail.com> Message-ID: On Thu, Jul 30, 2015 at 9:30 AM, David Cole wrote: > json is SOOO much sexier than XML..... ;-) shiny, shiny json :-) Agreed, json is not covered with ugly-stink. I like it and use it daily. I'm not at all sure that stateless build languages are a win in the multiplatform general case. They probably work well as a way to feed parameters to a single build backend, but not so good as a way to handle multiple backends. gyp is one attempt to do this, and it worked, but it's painful to use and requires deep understanding of the gyp model. So, +1 for the idea of adding a better language on the side of cmake, -1 for adding multiple languages (especially anything from Microsoft), and -1 for going fully stateless. I wouldn't mind getting rid of the cache, it's a bizarre concept that appears to be a workaround for users who can't stand starting cmake from a script, and it complicates my cmake scripts, but that's not a battle I'd like to wage. - Dan From bill.hoffman at kitware.com Thu Jul 30 11:15:21 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 30 Jul 2015 11:15:21 -0400 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: References: <20150730133737.03E50B108D@public.kitware.com> <55BA2C10.8010607@gmail.com> Message-ID: <55BA3F89.50902@kitware.com> On 7/30/2015 10:48 AM, Dan Kegel wrote: > I wouldn't mind getting rid of the cache, it's a bizarre concept that appears > to be a workaround for users who can't stand starting cmake from a script, > and it complicates my cmake scripts, but that's not a battle I'd like to wage. No, it is how CMake stores things it finds during the configure step. If you did not have it you would have to rediscover everything for every run on a build tree, and have no place to store user selections in the GUI. -Bill From rleigh at codelibre.net Thu Jul 30 10:29:34 2015 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Thu, 30 Jul 2015 15:29:34 +0100 (BST) Subject: [CMake] Making and using static and shared libraries on Windows with Visual Studio In-Reply-To: References: <55BA1C63.2070303@codelibre.net> Message-ID: <5c62c1707629aac6cdb67833c3ce0673.squirrel@g.mail.aa.net.uk> > Did you try to remove all the explicit template exports? I never had to do > it and compiled many static and shared libraries on Windows. Of course VS > is going to complain about exporting template classes but as long as you > don't try to mix VS versions I think you can safely ingore those warnings. Thanks for the suggestions. The above seems true, though I think I'll likely retain it for DLL builds and lose it for static builds. If nothing else it removes the warnings and will hopefully make it safer for corner-case failures by end users of the library? Hopefully MSVC is clever enough to elide duplicate instantiations when it links the DLL? Relating to CMake, the guidance from Microsoft for correctly exporting templates here: https://support.microsoft.com/en-us/kb/168958 uses an foo_EXPORT_TEMPLATE macro in addition to foo_EXPORT. This is basically empty in the DLL for export, and "extern" for imports. I wonder if this is something that GenerateExportHeader should be generating in addition to the typical export macro? Regards, Roger From dank at kegel.com Thu Jul 30 11:56:33 2015 From: dank at kegel.com (Dan Kegel) Date: Thu, 30 Jul 2015 10:56:33 -0500 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: <55BA3F89.50902@kitware.com> References: <20150730133737.03E50B108D@public.kitware.com> <55BA2C10.8010607@gmail.com> <55BA3F89.50902@kitware.com> Message-ID: Am 30.07.2015 10:15 vorm. schrieb "Bill Hoffman" : > > On 7/30/2015 10:48 AM, Dan Kegel wrote: >> >> I wouldn't mind getting rid of the cache, it's a bizarre concept that appears >> to be a workaround for users who can't stand starting cmake from a script, >> and it complicates my cmake scripts, but that's not a battle I'd like to wage. > > No, it is how CMake stores things it finds during the configure step. If you did not have it you would have to rediscover everything for every run on a build tree, and have no place to store user selections in the GUI. I believe the latter, but not the former. I never use the GUI, and consider the cache an anti-feature there solely to support GUI users. It complicates my life, and I'd love to see it go. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Geoffrey.Viola at asirobots.com Thu Jul 30 11:27:07 2015 From: Geoffrey.Viola at asirobots.com (Geoffrey Viola) Date: Thu, 30 Jul 2015 15:27:07 +0000 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: <20150730133737.03E50B108D@public.kitware.com> References: <20150730133737.03E50B108D@public.kitware.com> Message-ID: I think this topic addresses improving the greatest CMake's greatest weakness. > It would modularize the internals of CMake in a cleaner fashion Good point. Having built part of a generator, I would appreciate cleaner generator interfaces. That way it's clear what implementations are necessary to support which CMake features. > The big selling point would be the ability to introduce arbitrary front-ends to CMake, not just CMakelists.txt. Every developer could choose an input language that suits their project/needs/skills. When trying to get a team to adopt CMake, learning this new language is a barrier for entry. Doing a trade study on build tools made SCons looks pretty good because it is in python, but ultimately we decided on CMake because I used it before. Geoffrey Viola SOFTWARE ENGINEER asirobots.com This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. From mike.jackson at bluequartz.net Thu Jul 30 13:15:44 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Thu, 30 Jul 2015 13:15:44 -0400 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: References: <20150730133737.03E50B108D@public.kitware.com> <55BA2C10.8010607@gmail.com> <55BA3F89.50902@kitware.com> Message-ID: <7DC53675-CED8-4E95-9DBA-5E8E8A94758C@bluequartz.net> On Jul 30, 2015, at 11:56 AM, Dan Kegel wrote: > > Am 30.07.2015 10:15 vorm. schrieb "Bill Hoffman" : > > > > On 7/30/2015 10:48 AM, Dan Kegel wrote: > >> > >> I wouldn't mind getting rid of the cache, it's a bizarre concept that appears > >> to be a workaround for users who can't stand starting cmake from a script, > >> and it complicates my cmake scripts, but that's not a battle I'd like to wage. > > > > No, it is how CMake stores things it finds during the configure step. If you did not have it you would have to rediscover everything for every run on a build tree, and have no place to store user selections in the GUI. > > I believe the latter, but not the former. > I never use the GUI, and consider the cache an anti-feature there solely to support GUI users. It complicates my life, and I'd love to see it go. > Which don't you believe? The part where if you don't have a cache then you have to rediscover everything? Simply delete the CMakeCache.txt file and rerun CMake. You will rediscover everything. If you do not have some sort of "state file" then exactly how would one store their selections? Since you are comfortable on the command line I'll assume you love typing: cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/usr/foo -DCXX_COMPILE_FLAGS=All -DKEEP_GOING_WITH_EVEN_MORE_ARGUMENTS -G Ninja ../YourProject. For shorter invocations this isn't so bad to type. We have our project down to a single argument, but we preload from, wait for it, a cache file. But what about those folks who are simply NOT comfortable on the command line and always use the GUI? If CMake _never_ had a GUI then your argument might have some merit. If your next thought is something like ".. Well just write an alias in your .bashrc so you do not have to type it out each time.." then didn't you just basically create a "cache" file? And if you vote for "just rediscover everything, every time" then you have never run CMake on a larger project on a Windows machine with Visual Studio. Now _that_ is slow. I think the history of the design implementations kind of shows that a Cache is more helpful than hurtful. Plus when Project developers decide to hard code their own version of dependent libraries and give you no way of over riding those settings OTHER than hand editing the cache file, then be thankful you have the cache file there. Just my 2 cents. Mike Jackson -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Thu Jul 30 13:36:44 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 30 Jul 2015 13:36:44 -0400 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: References: <20150730133737.03E50B108D@public.kitware.com> <55BA2C10.8010607@gmail.com> <55BA3F89.50902@kitware.com> Message-ID: <55BA60AC.8010406@kitware.com> On 7/30/2015 11:56 AM, Dan Kegel wrote: > I believe the latter, but not the former. > I never use the GUI, and consider the cache an anti-feature there solely > to support GUI users. It complicates my life, and I'd love to see it go. It is certainly not there just for the GUI. Every try-compile, find_library, find_program result is stored there as well. If you did this each time, it would be not only slow to re-run a build, but it might come up with different answers each time. If it went it would complicate your life even more. In what way do you think it is causing you trouble? Also, CMake needs to be able to auto-rerun when its input changes and this is how the command line -D options are saved along with all the other system introspection results. -Bill From mohammedrashadkm at gmail.com Thu Jul 30 14:36:11 2015 From: mohammedrashadkm at gmail.com (Rashad M) Date: Thu, 30 Jul 2015 20:36:11 +0200 Subject: [CMake] BundleUtilities not working In-Reply-To: <55B7B637.7050307@kitware.com> References: <55B77CAD.8050506@classdesign.com> <55B799A5.6000701@kitware.com> <55B7A098.7060006@classdesign.com> <55B7B209.5030407@kitware.com> <55B7B324.7060800@classdesign.com> <55B7B637.7050307@kitware.com> Message-ID: Hi all, We have a similar way here to get dll dependencies recursively and create a zip archive. Ideally, this could be integrated in cmake but not sure if that will be ok on cmake side. The code doesn't uses fixup_bundle(..) but follows a similar function syntax. package_mingw( ARCH "${mxearch}" MXEROOT "${mxeroot}" PREFIX_DIR "${archive_name}" PEFILES "${pefiles}" SEARCHDIRS "") more details here: https://git.orfeo-toolbox.org/otb.git/blob/HEAD:/CMakeLists.txt#l422 Note: this was only tested on a cross compiling build and contains some code specific for our project. [1] https://git.orfeo-toolbox.org/otb.git/blob/HEAD:/CMake/MinGWPackage.cmake On Tue, Jul 28, 2015 at 7:04 PM, Brad King wrote: > On 07/28/2015 12:51 PM, Bill Somerville wrote: > > The possible lack of grep is a potential issue so your read > > back from file suggestion is interesting, is there a recognized place to > > write temporary files like this? > > IIRC the code in question runs during "cmake -P cmake_install.cmake" > scripts so CMAKE_CURRENT_BINARY_DIR may be a reasonable choice. > If for any reason you need to randomize the file name then you > could use string(RANDOM). > > Since this is specific to Windows perhaps $ENV{TEMP} will be useful, > though I don't recall off the top of my head whether applications > are supposed to read that directly. Certainly a randomized file > name would be needed if a shared temp dir were used. > > -Brad > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Regards, Rashad -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at classdesign.com Thu Jul 30 14:55:04 2015 From: bill at classdesign.com (Bill Somerville) Date: Thu, 30 Jul 2015 19:55:04 +0100 Subject: [CMake] BundleUtilities not working In-Reply-To: References: <55B77CAD.8050506@classdesign.com> <55B799A5.6000701@kitware.com> <55B7A098.7060006@classdesign.com> <55B7B209.5030407@kitware.com> <55B7B324.7060800@classdesign.com> <55B7B637.7050307@kitware.com> Message-ID: <55BA7308.2010804@classdesign.com> On 30/07/2015 19:36, Rashad M wrote: > Hi all, Hi Rashad > > We have a similar way here to get dll dependencies recursively and > create a zip archive. Ideally, this could be integrated in cmake but > not sure if that will be ok on cmake side. The code doesn't uses > fixup_bundle(..) but follows a similar function syntax. > > package_mingw( > ARCH "${mxearch}" > MXEROOT "${mxeroot}" > PREFIX_DIR "${archive_name}" > PEFILES "${pefiles}" > SEARCHDIRS "") > more details here: > https://git.orfeo-toolbox.org/otb.git/blob/HEAD:/CMakeLists.txt#l422 > Note: this was only tested on a cross compiling build and contains > some code specific for our project. > > [1] > https://git.orfeo-toolbox.org/otb.git/blob/HEAD:/CMake/MinGWPackage.cmake That is all very Windows specific CMake already uses the same technique as your code but in a more platform independent way. You may want to consider optimizing in the same way as has been added to the BundleUtilities.cmake helper GetPrerequisites.cmake in: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f01a8823 since the objdump -p output on large framework libraries like Qt (10000+ lines) is very inefficient when processed as a CMake variable. In our CMake built Qt5 project we are getting huge speed ups on the install phase on Windows with this change. Regards Bill Somerville. > > On Tue, Jul 28, 2015 at 7:04 PM, Brad King > wrote: > > On 07/28/2015 12:51 PM, Bill Somerville wrote: > > The possible lack of grep is a potential issue so your read > > back from file suggestion is interesting, is there a recognized > place to > > write temporary files like this? > > IIRC the code in question runs during "cmake -P cmake_install.cmake" > scripts so CMAKE_CURRENT_BINARY_DIR may be a reasonable choice. > If for any reason you need to randomize the file name then you > could use string(RANDOM). > > Since this is specific to Windows perhaps $ENV{TEMP} will be useful, > though I don't recall off the top of my head whether applications > are supposed to read that directly. Certainly a randomized file > name would be needed if a shared temp dir were used. > > -Brad > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. > For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > > > > -- > Regards, > Rashad -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Thu Jul 30 15:08:20 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Thu, 30 Jul 2015 21:08:20 +0200 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: <20150730133736.F3306B108C@public.kitware.com> References: <20150730133736.F3306B108C@public.kitware.com> Message-ID: <4947487.txPiyU2bYA@tuxedo.neundorf.net> On Wednesday, July 29, 2015 07:49:07 Nagy-Egri M?t? Ferenc via cmake- developers wrote: ... > I believe CMake is an invaluable tool, but it could do far better. 0/10 > CMake users I?ve met say they are ?happy? CMake users. The learning curve > is steep, and the skills gained are not reusable. CMake could gain even > greater momentum (not by ditching, but) by offering alternate input > languages with entities (classes, functions, macros, etc.) that feel > natural in the given context. Well, the cmake language is not really pretty, but in my experience it is usually good enough. Having a somewhat better language like e.g. Lua may be a good thing. There is actually an advantage in not thaving a full-featured scripting language: users are less tempted to turn the build scripts into actual "programs" containing logic and doing a lot of stuff. I have seen that happen with scons builds... as developer you had to understand two programs: the actual software, and the build "program". There were already experiments with Lua and also with Javascript for cmake, but they didn't succeed so far. Alex From Nicholas.Crast at saabsensis.com Thu Jul 30 16:05:12 2015 From: Nicholas.Crast at saabsensis.com (Crast, Nicholas) Date: Thu, 30 Jul 2015 20:05:12 +0000 Subject: [CMake] List of files not containing string Message-ID: <36A43B0E1E88D84791516F9D44BC4833281C27D5@corpmail01.corp.sensis.com> All, This seems like a pretty simple task, but I cannot figure out a good way to do it. I want to get a list of all files in a directory that do not have a certain string in the filename. Can someone help? -Nick ---------------------------------------- Nick Crast Software Engineer Saab Sensis Corporation Phone: 315-445-5703 Email: Nicholas.Crast at saabsensis.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Jul 30 16:38:05 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 30 Jul 2015 16:38:05 -0400 Subject: [CMake] List of files not containing string In-Reply-To: <36A43B0E1E88D84791516F9D44BC4833281C27D5@corpmail01.corp.sensis.com> References: <36A43B0E1E88D84791516F9D44BC4833281C27D5@corpmail01.corp.sensis.com> Message-ID: Get the list of all files, loop over them, and filter out the ones that DO have the string in the name ...? On Thu, Jul 30, 2015 at 4:05 PM, Crast, Nicholas wrote: > All, > > > > This seems like a pretty simple task, but I cannot figure out a good way to > do it. I want to get a list of all files in a directory that do not have a > certain string in the filename. > > > > Can someone help? > > > > -Nick > > > > ---------------------------------------- > > Nick Crast > > Software Engineer > > Saab Sensis Corporation > > Phone: 315-445-5703 > > Email: Nicholas.Crast at saabsensis.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 ewmailing at gmail.com Thu Jul 30 17:51:35 2015 From: ewmailing at gmail.com (Eric Wing) Date: Thu, 30 Jul 2015 14:51:35 -0700 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: <4947487.txPiyU2bYA@tuxedo.neundorf.net> References: <20150730133736.F3306B108C@public.kitware.com> <4947487.txPiyU2bYA@tuxedo.neundorf.net> Message-ID: Disclaimer: My name is attached to the failed CMake/Lua attempt. In principle, I like the idea of what you propose. However, in practice, I think it might be too big and too ambitious. Here are some quick thoughts I have: - I am in the camp that I do not like the CMake language. And it is often the hardest selling point in my experience, even when you convince them that CMake can do all the cross-platform stuff. (I?m seeing more competition from Gyp these days, but in my limited personal experience, people still have not been able to port highly complex projects to as many target platforms with Gyp, whereas CMake could handle them (and the perceived gains of Gyp disappeared in these complex scenarios)). - Along those lines, part of the problem we seemed to hit was that pure declarative build instructions didn?t hold up well in the complex case. I haven?t done much with Gyp in this manner, but those around me that were trying seemed to hit the wall pretty fast in this. But I have used Ant, and that was a terrible experience for anything that required conditionals. - I would definitely like to see better interoperability with IDEs and tools. I would personally love a simple cross-platform gui project manager that basically allowed you to create targets, add/remove files to be compiled to a target, and set specific compile/link flags on a per-target or per-file basis, sort of like you can do in most IDEs (but if you tried using CMake, your changes get clobbered in the next regeneration?though even better would be able to do this directly in the native IDEs). - I am little concerned about encouraging people to add on any arbitrary language. There are two different problems that this could potentially cause: (1) CMake bloat, (2) Dependency hell - CMake currently can bootstrap itself with just a C++ compiler. That is a good thing. I recently had to get CMake up on a Raspberry Pi. I was fortunate that CMake had few dependencies and was relatively small. (Not counting Qt which was an unmitigated disaster.) - Building other projects using CMake can be painful depending on their dependency chain. While this is not technically CMake?s responsibility, encouraging users to use non-canonical tools can make things a nightmare. CMake has been pretty good about providing fundamental mechanisms you need that work on all platforms. But if users are encouraged to say, ?I?ll just use Perl+CPAN or Ruby with these gems?, instead of the standard CMake mechanisms, things get awful quickly. (I finally just reproduced a build of JavaScriptCore for Windows after over a year of trying?it has dependencies on Perl, Python, Ruby, and a bunch of other things I can?t remember, all of which are a terrible pain to get working on Windows.) - In that same line of thought, the reason Lua was a good candidate is because it its tiny which avoids adding bloat, it is pure ANSI C, which means it compiles everywhere CMake already compiles, and it was designed to be an embedded scripting language doing the exact type of things that the current CMake language is asked to do. (Dr. Ken Martin said they were impressed with Lua and would have used it if they had known about it originally.) (By the way, if you haven,t already, I encourage you to read through the old Lua threads circa 2008.) - Incidentally, the Lua table is pretty much the same concept/pre-cursor to JSON in JavaScript. Lua lends it self to both data driven formats as well as custom DSLs pretty well. If Lua were part of the core, you could build a the data-oriented format files without any additional dependencies. - I don?t think the IR will help anything related to the work of adding new languages like Swift. The hard part there is not really the CMake language as much as understanding the overall system design/architecture. No matter what language you pick, that part will always be hard. - Mostly, I?m concerned that this project is too big and ambitious in scope to see completion unless you have funding and a team to drive it. The Lua attempt is a failure, but not for technical reasons. It was a manpower problem. Dr. Ken Martin proved the concept could work in something like 13 hours. But at the time Kitware said they weren?t going to go down that road, so anybody still interested in it was left to make it happen ourselves. We gave it a shot, but none of us really had the time to commit to finish the task, which is much smaller than the one you are proposing. (Granted, we wasted a lot of time trying to bridge CVS (which CMake was still using at the time) with DVCS, so you at least won?t have to worry about constant merge-hell.) -Eric From nicolas.despres at gmail.com Fri Jul 31 02:53:10 2015 From: nicolas.despres at gmail.com (=?UTF-8?Q?Nicolas_Despr=C3=A8s?=) Date: Fri, 31 Jul 2015 08:53:10 +0200 Subject: [CMake] CMake IR In-Reply-To: <20150730125950.06CE8B0B54@public.kitware.com> References: <20150729084010.94CFEAD02D@public.kitware.com> <20150729112928.D87D7B0C73@public.kitware.com> <55B8E272.9090207@littleendian.com> <20150730125950.06CE8B0B54@public.kitware.com> Message-ID: On Thu, Jul 30, 2015 at 1:51 PM, Nagy-Egri M?t? Ferenc wrote: [...] > @Nicolas: > > Yes, these tools indeed have been working for the past few decades. Others > also suggested why don?t I generate CMakelists.txt instead? > > The problem is that the current limitations of CMake all originate from > the way the workflow is organized. Multi-configuration makefiles are > trivial to implement if you do them by hand. All targets append the > architecture after their name (app-x86, app-x64, lib-x86, etc.) and there > were all-x86 and all-x64 targets, and there were the usual ?all? target > that references all-x86, all-x64. In CMake the workflow is baked into > selecting an architecture at the earliest points in the configuration > process and stores it as a global variable (state!) which then shoots all > multi-configuration generators in the knee. > > Yes, it is possible to remove this limitation from CMake, but it would > take roughly a year. Holding onto this limitation alone just because it is > historically the way how CMake has been designed immediately rules it out > from ~75% of application development going on in the world in the future > (mobile app devel), which is funny because building cross-platform mobile > apps is the future, and this is just the market that could benefit of CMake > the most. > I always used CMake for generating Makefile targeting a single architecture. I tried few times to generate Visual Studio project and XCode project and my first impression was quite good. But I have not a lot of experiences in this area. I agree with you that the users will need multi architecture support more in the future. -- Nicolas Despr?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens.auer at cgi.com Fri Jul 31 03:37:10 2015 From: jens.auer at cgi.com (Auer, Jens) Date: Fri, 31 Jul 2015 07:37:10 +0000 Subject: [CMake] Passing generator expressions in variables In-Reply-To: References: Message-ID: Okay, please forget this question. I misread the error message, and my example had a type. The errors actually are generated in another macro which tries to iterate over the source files of a target, and fails to find the generator expression. Best wishes, Jens -- Dr. Jens Auer | CGI | Software Engineer CGI Deutschland Ltd. & Co. KG Rheinstra?e 95 | 64295 Darmstadt | Germany T: +49 6151 36860 154 jens.auer at cgi.com Unsere Pflichtangaben gem?? ? 35a GmbHG / ?? 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben. CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail. From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Auer, Jens Sent: 30 July 2015 15:53 To: cmake at cmake.org Subject: Re: [CMake] Passing generator expressions in variables Just to add to my question: I do not expect that set(alib "$") expands to the list of files, I just want to pass the string "$" to add_executable and then evaluate it there. From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Auer, Jens Sent: 30 July 2015 09:15 To: cmake at cmake.org Subject: [CMake] Passing generator expressions in variables Hi, I am trying to dynamically assemble a list of generator expressions and use them in add_executable. The background is that I have some macros to add targets, e.g. add_my_library(TARGET liba SOURCES ...) # this class add_library(liba OBJECT ...) internally add_my_executable(TARGET a DEPENDS liba libb SOURCES ...) In add_my_executable, I create a list of $ strings for all d {liba, libb}. However, cmake complains that it cannot find the source file $. A simplified example of what I want to do is this: add_library(A OBJECT a.cpp) set(alib $ ) With cmake 3.2.2, the first add_executable fails, the second one works. Is there another way to do this? Best wishes, Jens -- Dr. Jens Auer | CGI | Software Engineer CGI Deutschland Ltd. & Co. KG Rheinstra?e 95 | 64295 Darmstadt | Germany T: +49 6151 36860 154 jens.auer at cgi.com Unsere Pflichtangaben gem?? ? 35a GmbHG / ?? 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben. CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohammedrashadkm at gmail.com Fri Jul 31 05:30:09 2015 From: mohammedrashadkm at gmail.com (Rashad M) Date: Fri, 31 Jul 2015 11:30:09 +0200 Subject: [CMake] BundleUtilities not working In-Reply-To: <55BA7308.2010804@classdesign.com> References: <55B77CAD.8050506@classdesign.com> <55B799A5.6000701@kitware.com> <55B7A098.7060006@classdesign.com> <55B7B209.5030407@kitware.com> <55B7B324.7060800@classdesign.com> <55B7B637.7050307@kitware.com> <55BA7308.2010804@classdesign.com> Message-ID: On Thu, Jul 30, 2015 at 8:55 PM, Bill Somerville wrote: > On 30/07/2015 19:36, Rashad M wrote: > > Hi all, > > Hi Rashad > > > We have a similar way here to get dll dependencies recursively and create > a zip archive. Ideally, this could be integrated in cmake but not sure if > that will be ok on cmake side. The code doesn't uses fixup_bundle(..) but > follows a similar function syntax. > > package_mingw( > ARCH "${mxearch}" > MXEROOT "${mxeroot}" > PREFIX_DIR "${archive_name}" > PEFILES "${pefiles}" > SEARCHDIRS "") > more details here: > https://git.orfeo-toolbox.org/otb.git/blob/HEAD:/CMakeLists.txt#l422 > Note: this was only tested on a cross compiling build and contains some > code specific for our project. > > [1] > https://git.orfeo-toolbox.org/otb.git/blob/HEAD:/CMake/MinGWPackage.cmake > > That is all very Windows specific CMake already uses the same technique as > your code but in a more platform independent way. You may want to consider > optimizing in the same way as has been added to the BundleUtilities.cmake > helper GetPrerequisites.cmake in: > Hi Bill, Indeed these are all windows specific and that is the point here. To be precise, these are more connected with mingw toolchain. I only tested them on cross-compile toolchain. > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f01a8823 > > > since the objdump -p output on large framework libraries like Qt (10000+ > lines) is very inefficient when processed as a CMake variable. In our CMake > built Qt5 project we are getting huge speed ups on the install phase on > Windows with this change. > I see. we use Qt4 and doesn't have any issue with speed. Maybe because I am using a minimal set of components from Qt, Core, Gui, Xml, Sql. I will test this nex enhancement and move to BundleUtilitles later. Thanks > > Regards > Bill Somerville. > > > > On Tue, Jul 28, 2015 at 7:04 PM, Brad King wrote: > >> On 07/28/2015 12:51 PM, Bill Somerville wrote: >> > The possible lack of grep is a potential issue so your read >> > back from file suggestion is interesting, is there a recognized place to >> > write temporary files like this? >> >> IIRC the code in question runs during "cmake -P cmake_install.cmake" >> scripts so CMAKE_CURRENT_BINARY_DIR may be a reasonable choice. >> If for any reason you need to randomize the file name then you >> could use string(RANDOM). >> >> Since this is specific to Windows perhaps $ENV{TEMP} will be useful, >> though I don't recall off the top of my head whether applications >> are supposed to read that directly. Certainly a randomized file >> name would be needed if a shared temp dir were used. >> >> -Brad >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: >> http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > > > -- > Regards, > Rashad > > > -- Regards, Rashad -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Fri Jul 31 03:05:07 2015 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Fri, 31 Jul 2015 07:05:07 +0000 Subject: [CMake] =?utf-8?q?=5Bcmake-developers=5D_CMake_IR?= In-Reply-To: References: <20150730133736.F3306B108C@public.kitware.com> <4947487.txPiyU2bYA@tuxedo.neundorf.net>, Message-ID: @all: Thank you folks for the input and the active discussion (not shifting into flame and troll wars). @Dave&Dan: I agree that JSON looks better. I have no fetish about XML and I could be convinced on just about anything in the choice of the IR. The only important point is that it SHOULD EXIST and be well defined. Hooking all the generators straight into the script interpreter is not good. The only reason I intially chose XML and XSD is because they are readily available in just about any language. (Take the C++ codegen lib for instance) The big difference is that XSD is a widely adopted recommendation. Every lib supports it. The moment JSON can provide a schema that is as widely adopted as XSD, I have no objection against JSON. I read through http://www.w3schools.com/Schema/default.asp in a matter of a few hours and it as simple as things can get. But spawning a JSON schema for this project alone would feel like being back at square 1. Even if nothings becomes of this idea, if CMake could manifest such a thing (like LLVM is for? just about everything C++ related), it would both distill the internals into something easier to comprehend, and at least significantly increase interoperability with IDEs and it?s own generators. (Deferred generation would be a welcome side-effect. The generators would only be invoked once the IR is complete. Whether the generator make use of the global info or spawn build invocations and targets on their first encounter is up to the generator to decide.) @Dan: I don?t quite understand resistance toward MS tech. Windows resides on +80% of PCs in the world, CMake already has VS and NMake generators? if there existed multiple input languages, I do not understand why one of them couldn?t be a native Windows script language. @Eric: Thank you for the extensive and thorough answer. I have not taken a look at Gyp, but will surely do. As for conditionals and complex scenarios. If the people who encountered such barriers could elaborate a little on what their experiences were, maybe design could take such cases into consideration from day one. As for the GUI editor of a project, it has occured to me (and others too) that such a tool would be darn useful. If it were a seperate tool, I?d still use it just about every day, but you are correct that this feature would be best embedded into the IDE. I am actively engaged with the folk at the Visual C++ team who are looking for a way to hook CMake into the IDE. So, if all goes well it might even happen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Jul 31 07:17:42 2015 From: d3ck0r at gmail.com (J Decker) Date: Fri, 31 Jul 2015 04:17:42 -0700 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: <20150731100917.C632C8C654@public.kitware.com> References: <20150730133736.F3306B108C@public.kitware.com> <4947487.txPiyU2bYA@tuxedo.neundorf.net> <20150731100917.C632C8C654@public.kitware.com> Message-ID: > > > As for the GUI editor of a project, it has occured to me (and others too) > that such a tool would be darn useful. If it were a seperate tool, I?d > still use it just about every day, but you are correct that this feature > would be best embedded into the IDE. I am actively engaged with the folk at > the Visual C++ team who are looking for a way to hook CMake into the IDE. > So, if all goes well it might even happen. > > TortoiseCMake :) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From japedo24 at gmail.com Fri Jul 31 07:18:45 2015 From: japedo24 at gmail.com (japedo24) Date: Fri, 31 Jul 2015 13:18:45 +0200 Subject: [CMake] Fwd: CMake and Visual Studio 9 2008: use gfortran instead of ifort In-Reply-To: References: Message-ID: Hi guys, I am currently working on some CMake build scripts that were designed for crossplatform use. However they are not working perfectly under windows. The isolated testcase looks like this: initialize a fortran project. CMake always tries to use 'ifort' from Visual Studio as compiler but I do not even have that installed. Instead I want to use gfortran from MingW (which is set in my %PATH% variable). The messy (because I tried so much stuff :) CMakeLists.txt looks like this: cmake_minimum_required( VERSION 2.8.12 ) message( "-- env(fc): $ENV{FC}") message( "-- cmake generator fc: ${CMAKE_GENERATOR_FC}") set(FC "gfortran" CACHE PATH "" FORCE) set(CMAKE_GENERATOR_FC "gfortran" CACHE PATH "" FORCE) set(CMAKE_Fortran_COMPILER_INIT "gfortran" CACHE PATH "" FORCE) set(CMAKE_Fortran_COMPILER_LIST "gfortran" CACHE PATH "" FORCE) set(ENV{FC} "gfortran" CACHE PATH "" FORCE) set(CMAKE_Fortran_COMPILER "gfortran" CACHE STRING "" FORCE) SET(CMAKE_Fortran_COMPILER_ENV_VAR "FC") project( example Fortran ) # why does this always print ifort instead of gfortran? message("-- fortran compiler ${CMAKE_Fortran_COMPILER} ") include(CheckLanguage) check_language(Fortran) if(CMAKE_Fortran_COMPILER) enable_language(Fortran) else() message(STATUS "No native Fortran support ") endif() So for me none of these options to switch from ifort to gfortran works. The output is always the same: cmake -G "Visual Studio 9 2008" .. -- env(fc): -- cmake generator fc: gfortran -- Check for working Fortran compiler using: Visual Studio 9 2008 -- broken -> fails: "The Fortran compiler ifort is not able to compile a simple test program." Maybe there is someone around here who can explain this issue to me. The CMake docs can't help me and neither googling for hours. Please let me know if you need further system informations. Thanks in advance! - japedo24 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nicholas.Crast at saabsensis.com Fri Jul 31 09:13:08 2015 From: Nicholas.Crast at saabsensis.com (Crast, Nicholas) Date: Fri, 31 Jul 2015 13:13:08 +0000 Subject: [CMake] List of files not containing string In-Reply-To: References: <36A43B0E1E88D84791516F9D44BC4833281C27D5@corpmail01.corp.sensis.com> Message-ID: <36A43B0E1E88D84791516F9D44BC4833281C28B9@corpmail01.corp.sensis.com> Well that's a way to do it, but there's not a way to do all of that in one shot? ---------------------------------------- Nick Crast Software Engineer Saab Sensis Corporation Phone: 315-445-5703 Email: Nicholas.Crast at saabsensis.com -----Original Message----- From: David Cole [mailto:DLRdave at aol.com] Sent: Thursday, July 30, 2015 4:39 PM To: Crast, Nicholas Cc: cmake at cmake.org Subject: Re: [CMake] List of files not containing string Get the list of all files, loop over them, and filter out the ones that DO have the string in the name ...? On Thu, Jul 30, 2015 at 4:05 PM, Crast, Nicholas wrote: > All, > > > > This seems like a pretty simple task, but I cannot figure out a good > way to do it. I want to get a list of all files in a directory that do > not have a certain string in the filename. > > > > Can someone help? > > > > -Nick > > > > ---------------------------------------- > > Nick Crast > > Software Engineer > > Saab Sensis Corporation > > Phone: 315-445-5703 > > Email: Nicholas.Crast at saabsensis.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 d3ck0r at gmail.com Fri Jul 31 09:31:41 2015 From: d3ck0r at gmail.com (J Decker) Date: Fri, 31 Jul 2015 06:31:41 -0700 Subject: [CMake] List of files not containing string In-Reply-To: <36A43B0E1E88D84791516F9D44BC4833281C28B9@corpmail01.corp.sensis.com> References: <36A43B0E1E88D84791516F9D44BC4833281C27D5@corpmail01.corp.sensis.com> <36A43B0E1E88D84791516F9D44BC4833281C28B9@corpmail01.corp.sensis.com> Message-ID: On Fri, Jul 31, 2015 at 6:13 AM, Crast, Nicholas < Nicholas.Crast at saabsensis.com> wrote: > Well that's a way to do it, but there's not a way to do all of that in one > shot? > > make a macro to do it? it's not like that's all that much to do... files( glob file_list *) foreach( file ${file_list} ) if( NOT file MATCHES "[whatever]" ) set( real_list ${real_list} ${file} ) endif() endforeach() ? > ---------------------------------------- > Nick Crast > Software Engineer > Saab Sensis Corporation > Phone: 315-445-5703 > Email: Nicholas.Crast at saabsensis.com > > -----Original Message----- > From: David Cole [mailto:DLRdave at aol.com] > Sent: Thursday, July 30, 2015 4:39 PM > To: Crast, Nicholas > Cc: cmake at cmake.org > Subject: Re: [CMake] List of files not containing string > > Get the list of all files, loop over them, and filter out the ones that DO > have the string in the name ...? > > > > On Thu, Jul 30, 2015 at 4:05 PM, Crast, Nicholas < > Nicholas.Crast at saabsensis.com> wrote: > > All, > > > > > > > > This seems like a pretty simple task, but I cannot figure out a good > > way to do it. I want to get a list of all files in a directory that do > > not have a certain string in the filename. > > > > > > > > Can someone help? > > > > > > > > -Nick > > > > > > > > ---------------------------------------- > > > > Nick Crast > > > > Software Engineer > > > > Saab Sensis Corporation > > > > Phone: 315-445-5703 > > > > Email: Nicholas.Crast at saabsensis.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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dank at kegel.com Fri Jul 31 11:06:31 2015 From: dank at kegel.com (Dan Kegel) Date: Fri, 31 Jul 2015 10:06:31 -0500 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: <20150731100917.ECE53A52DA@public.kitware.com> References: <20150730133736.F3306B108C@public.kitware.com> <4947487.txPiyU2bYA@tuxedo.neundorf.net> <20150731100917.ECE53A52DA@public.kitware.com> Message-ID: On Fri, Jul 31, 2015 at 2:05 AM, Nagy-Egri M?t? Ferenc wrote: > I agree that JSON looks better. I have no fetish about XML and I could be > convinced on just about anything in the choice of the IR. The only important > point is that it SHOULD EXIST and be well defined. Hooking all the > generators straight into the script interpreter is not good. Are you saying that cmake should switch from being imperative to being declarative? That's really quite a large change. > I don?t quite understand resistance toward MS tech. Windows resides on +80% > of PCs in the world, CMake already has VS and NMake generators? if there > existed multiple input languages, I do not understand why one of them > couldn?t be a native Windows script language. It's a free world, so if CMake was turned into a library or a JSON interface, of course you could write a binding in any language you choose. Those of us who remember Microsoft's past behavior (e.g. there was a great training presentation from Microsoft about how Microsoft evangelists should not consider themselves friends of developers, but rather remember that their goal was always to drive adoption of Microsoft tools, regardless of whether it was in the best interest of developers) may react suspiciously to any development that might lead to a Microsoft language being the preferred front end to a cross-platform tool. - Dan From ruslan_baratov at yahoo.com Fri Jul 31 12:33:48 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 31 Jul 2015 19:33:48 +0300 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: <55BA60AC.8010406@kitware.com> References: <20150730133737.03E50B108D@public.kitware.com> <55BA2C10.8010607@gmail.com> <55BA3F89.50902@kitware.com> <55BA60AC.8010406@kitware.com> Message-ID: <55BBA36C.4070403@yahoo.com> On 30-Jul-15 20:36, Bill Hoffman wrote: > On 7/30/2015 11:56 AM, Dan Kegel wrote: >> I believe the latter, but not the former. >> I never use the GUI, and consider the cache an anti-feature there solely >> to support GUI users. It complicates my life, and I'd love to see it >> go. > It is certainly not there just for the GUI. Every try-compile, > find_library, find_program result is stored there as well. If you did > this each time, it would be not only slow to re-run a build, but it > might come up with different answers each time. If it went it would > complicate your life even more. [...] > In what way do you think it is causing you trouble? > Here is an example: # CMakeLists.txt cmake_minimum_required(VERSION 3.0) project(Foo) if(A) set(B "Hello A" CACHE STRING "Do we use A?") else() set(B "There is no A" CACHE STRING "Do we use A?") endif() User thinks: okay, if I set A=ON I will have B equal to "Hello A". What user really have: > rm -rf _builds > cmake -H. -B_builds > cmake -H. -B_builds -DA=ON > grep '\' _builds/CMakeCache.txt B:STRING=There is no A I'm not saying cache is a bad idea, I'm just saying that when users hit such kind of situations that's one of the reason why they said CMake is not a good script language. Just like CMake before CMP0054: user see `if("a" STREQUAL "b")` and think "okay, 'a' is not equal to 'b' so this condition is always false"... nope! Ruslo From dank at kegel.com Fri Jul 31 12:38:27 2015 From: dank at kegel.com (Dan Kegel) Date: Fri, 31 Jul 2015 11:38:27 -0500 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: <55BBA36C.4070403@yahoo.com> References: <20150730133737.03E50B108D@public.kitware.com> <55BA2C10.8010607@gmail.com> <55BA3F89.50902@kitware.com> <55BA60AC.8010406@kitware.com> <55BBA36C.4070403@yahoo.com> Message-ID: On Fri, Jul 31, 2015 at 11:33 AM, Ruslan Baratov wrote: >>> I never use the GUI, and consider the cache an anti-feature there solely >>> to support GUI users. It complicates my life, and I'd love to see it go. >> >> In what way do you think it is causing you trouble? > > Here is an example: > > # CMakeLists.txt > cmake_minimum_required(VERSION 3.0) > project(Foo) > > if(A) > set(B "Hello A" CACHE STRING "Do we use A?") > else() > set(B "There is no A" CACHE STRING "Do we use A?") > endif() > > User thinks: okay, if I set A=ON I will have B equal to "Hello A". > > What user really have: > > > rm -rf _builds > > cmake -H. -B_builds > > cmake -H. -B_builds -DA=ON > > grep '\' _builds/CMakeCache.txt > B:STRING=There is no A > > I'm not saying cache is a bad idea, I'm just saying that when users hit such > kind of situations that's one of the reason why they said CMake is not a > good script language. Just like CMake before CMP0054: user see `if("a" > STREQUAL "b")` and think "okay, 'a' is not equal to 'b' so this condition is > always false"... nope! Here's another example from real life. Maybe I'm just being an idiot, but this is what I had to do to set a default: IF(DEFINED CMAKE_BUILD_TYPE AND (NOT ${CMAKE_BUILD_TYPE} STREQUAL "None")) SET(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING "Choose the type of build, options are: Debug Release RelWithDebInfo") ELSE() SET(CMAKE_BUILD_TYPE "RelWithDebInfo" CACHE STRING "Choose the type of build, options are: Debug Release RelWithDebInfo" FORCE) ENDIF() Can someone give me the proper one-line way to set a default for CMAKE_BUILD_TYPE, or is this an authentic problem? - Dan From bill.hoffman at kitware.com Fri Jul 31 12:43:20 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri, 31 Jul 2015 12:43:20 -0400 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: <55BBA36C.4070403@yahoo.com> References: <20150730133737.03E50B108D@public.kitware.com> <55BA2C10.8010607@gmail.com> <55BA3F89.50902@kitware.com> <55BA60AC.8010406@kitware.com> <55BBA36C.4070403@yahoo.com> Message-ID: <55BBA5A8.2020003@kitware.com> On 7/31/2015 12:33 PM, Ruslan Baratov wrote: > > rm -rf _builds > > cmake -H. -B_builds > > cmake -H. -B_builds -DA=ON > > grep '\' _builds/CMakeCache.txt > B:STRING=There is no A > > I'm not saying cache is a bad idea, I'm just saying that when users hit > such kind of situations that's one of the reason why they said CMake is > not a good script language. Just like CMake before CMP0054: user see > `if("a" STREQUAL "b")` and think "okay, 'a' is not equal to 'b' so this > condition is always false"... nope! OK, it is a bit confusing. One solution would be to treat the cache variables with some sort of separate look up. Basically put all cache stuff into its own namespace. Something like: $CACHE{A} Then, it would never be confused with the the variable A. However, getting rid of the cache would not be something that could be done. -Bill From dank at kegel.com Fri Jul 31 12:47:11 2015 From: dank at kegel.com (Dan Kegel) Date: Fri, 31 Jul 2015 11:47:11 -0500 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: <55BBA5A8.2020003@kitware.com> References: <20150730133737.03E50B108D@public.kitware.com> <55BA2C10.8010607@gmail.com> <55BA3F89.50902@kitware.com> <55BA60AC.8010406@kitware.com> <55BBA36C.4070403@yahoo.com> <55BBA5A8.2020003@kitware.com> Message-ID: On Fri, Jul 31, 2015 at 11:43 AM, Bill Hoffman wrote: > Something like: > $CACHE{A} > > Then, it would never be confused with the the variable A. However, getting > rid of the cache would not be something that could be done. Having a cache for invariants is a good thing if it could be done without confusing users and making scripting harder. From dschepler at scalable-networks.com Fri Jul 31 12:44:27 2015 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Fri, 31 Jul 2015 16:44:27 +0000 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: References: <20150730133737.03E50B108D@public.kitware.com> <55BA2C10.8010607@gmail.com> <55BA3F89.50902@kitware.com> <55BA60AC.8010406@kitware.com> <55BBA36C.4070403@yahoo.com>, Message-ID: This seems to work for me: set(CMAKE_BUILD_TYPE_INIT RelWithDebInfo) -- Daniel Schepler ________________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of Dan Kegel [dank at kegel.com] Sent: Friday, July 31, 2015 9:38 AM To: Ruslan Baratov Cc: cmake; Bill Hoffman Subject: Re: [CMake] [cmake-developers] CMake IR On Fri, Jul 31, 2015 at 11:33 AM, Ruslan Baratov wrote: >>> I never use the GUI, and consider the cache an anti-feature there solely >>> to support GUI users. It complicates my life, and I'd love to see it go. >> >> In what way do you think it is causing you trouble? > > Here is an example: > > # CMakeLists.txt > cmake_minimum_required(VERSION 3.0) > project(Foo) > > if(A) > set(B "Hello A" CACHE STRING "Do we use A?") > else() > set(B "There is no A" CACHE STRING "Do we use A?") > endif() > > User thinks: okay, if I set A=ON I will have B equal to "Hello A". > > What user really have: > > > rm -rf _builds > > cmake -H. -B_builds > > cmake -H. -B_builds -DA=ON > > grep '\' _builds/CMakeCache.txt > B:STRING=There is no A > > I'm not saying cache is a bad idea, I'm just saying that when users hit such > kind of situations that's one of the reason why they said CMake is not a > good script language. Just like CMake before CMP0054: user see `if("a" > STREQUAL "b")` and think "okay, 'a' is not equal to 'b' so this condition is > always false"... nope! Here's another example from real life. Maybe I'm just being an idiot, but this is what I had to do to set a default: IF(DEFINED CMAKE_BUILD_TYPE AND (NOT ${CMAKE_BUILD_TYPE} STREQUAL "None")) SET(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING "Choose the type of build, options are: Debug Release RelWithDebInfo") ELSE() SET(CMAKE_BUILD_TYPE "RelWithDebInfo" CACHE STRING "Choose the type of build, options are: Debug Release RelWithDebInfo" FORCE) ENDIF() Can someone give me the proper one-line way to set a default for CMAKE_BUILD_TYPE, or is this an authentic problem? - Dan -- 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 Nicholas.Crast at saabsensis.com Fri Jul 31 13:07:31 2015 From: Nicholas.Crast at saabsensis.com (Crast, Nicholas) Date: Fri, 31 Jul 2015 17:07:31 +0000 Subject: [CMake] List of files not containing string In-Reply-To: References: <36A43B0E1E88D84791516F9D44BC4833281C27D5@corpmail01.corp.sensis.com> <36A43B0E1E88D84791516F9D44BC4833281C28B9@corpmail01.corp.sensis.com> Message-ID: <36A43B0E1E88D84791516F9D44BC4833281C298A@corpmail01.corp.sensis.com> Understood. I am doing it this way, I was just thinking maybe there was some more sophisticated pattern matching that I could do (get all files matching this regular expression) without looping through the whole list. Thanks -Nick ---------------------------------------- Nick Crast Software Engineer Saab Sensis Corporation Phone: 315-445-5703 Email: Nicholas.Crast at saabsensis.com From: J Decker [mailto:d3ck0r at gmail.com] Sent: Friday, July 31, 2015 9:33 AM To: Crast, Nicholas Cc: David Cole; cmake at cmake.org Subject: Re: [CMake] List of files not containing string On Fri, Jul 31, 2015 at 6:13 AM, Crast, Nicholas > wrote: Well that's a way to do it, but there's not a way to do all of that in one shot? make a macro to do it? it's not like that's all that much to do... files( glob file_list *) foreach( file ${file_list} ) if( NOT file MATCHES "[whatever]" ) set( real_list ${real_list} ${file} ) endif() endforeach() ? ---------------------------------------- Nick Crast Software Engineer Saab Sensis Corporation Phone: 315-445-5703 Email: Nicholas.Crast at saabsensis.com -----Original Message----- From: David Cole [mailto:DLRdave at aol.com] Sent: Thursday, July 30, 2015 4:39 PM To: Crast, Nicholas Cc: cmake at cmake.org Subject: Re: [CMake] List of files not containing string Get the list of all files, loop over them, and filter out the ones that DO have the string in the name ...? On Thu, Jul 30, 2015 at 4:05 PM, Crast, Nicholas > wrote: > All, > > > > This seems like a pretty simple task, but I cannot figure out a good > way to do it. I want to get a list of all files in a directory that do > not have a certain string in the filename. > > > > Can someone help? > > > > -Nick > > > > ---------------------------------------- > > Nick Crast > > Software Engineer > > Saab Sensis Corporation > > Phone: 315-445-5703 > > Email: Nicholas.Crast at saabsensis.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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dank at kegel.com Fri Jul 31 13:21:32 2015 From: dank at kegel.com (Dan Kegel) Date: Fri, 31 Jul 2015 12:21:32 -0500 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: References: <20150730133737.03E50B108D@public.kitware.com> <55BA2C10.8010607@gmail.com> <55BA3F89.50902@kitware.com> <55BA60AC.8010406@kitware.com> <55BBA36C.4070403@yahoo.com> Message-ID: On Fri, Jul 31, 2015 at 11:44 AM, Daniel Schepler wrote: >> Here's another example from real life. Maybe I'm just being an idiot, >> but this is what I had to do to set a default: >> >> IF(DEFINED CMAKE_BUILD_TYPE AND (NOT ${CMAKE_BUILD_TYPE} STREQUAL "None")) >> SET(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING "Choose the >> type of build, options are: Debug Release RelWithDebInfo") >> ELSE() >> SET(CMAKE_BUILD_TYPE "RelWithDebInfo" CACHE STRING "Choose the type >> of build, options are: Debug Release RelWithDebInfo" FORCE) >> ENDIF() >> >> Can someone give me the proper one-line way to set a default for >> CMAKE_BUILD_TYPE, or is this an authentic problem? > > This seems to work for me: > set(CMAKE_BUILD_TYPE_INIT RelWithDebInfo) Wow, never heard of that variable, thanks Is that documented? Can you just slam _INIT on the end of any cache variable to give it a default value, or is that a special case? - Dan From ruslan_baratov at yahoo.com Fri Jul 31 13:47:03 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 31 Jul 2015 20:47:03 +0300 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: <55BBA5A8.2020003@kitware.com> References: <20150730133737.03E50B108D@public.kitware.com> <55BA2C10.8010607@gmail.com> <55BA3F89.50902@kitware.com> <55BA60AC.8010406@kitware.com> <55BBA36C.4070403@yahoo.com> <55BBA5A8.2020003@kitware.com> Message-ID: <55BBB497.2050005@yahoo.com> On 31-Jul-15 19:43, Bill Hoffman wrote: > On 7/31/2015 12:33 PM, Ruslan Baratov wrote: >> > rm -rf _builds >> > cmake -H. -B_builds >> > cmake -H. -B_builds -DA=ON >> > grep '\' _builds/CMakeCache.txt >> B:STRING=There is no A >> >> I'm not saying cache is a bad idea, I'm just saying that when users hit >> such kind of situations that's one of the reason why they said CMake is >> not a good script language. Just like CMake before CMP0054: user see >> `if("a" STREQUAL "b")` and think "okay, 'a' is not equal to 'b' so this >> condition is always false"... nope! > OK, it is a bit confusing. One solution would be to treat the cache > variables with some sort of separate look up. Basically put all cache > stuff into its own namespace. > > Something like: > $CACHE{A} > > Then, it would never be confused with the the variable A. However, > getting rid of the cache would not be something that could be done. > > -Bill I'm not sure I understand this solution. If you mean that user should not mix cache/non-cache variables with the same name, I guess yes (good idea for policy by the way). But it will not fix that kind of issues: cmake_minimum_required(VERSION 3.0) project(Foo) set(A "OFF" CACHE BOOL "This is A") if(A) # Yes, A is cache variable set(B "Hello A" CACHE STRING "Do we use A?") else() set(B "There is no A" CACHE STRING "Do we use A?") endif() result will be quite the same. The fundamental reason of this is that every cache (as a general term) have a context where it can be used, and if context changing we can't reuse same cached value. For variable B this context is value of A: > cmake -H. -B_builds # use default value OFF save to cache: B="There is no A" context: A=OFF > cmake -H. -B_builds -DA=ON load from cache: B="There is no A" context: A=OFF # that's the problem, context is not the same, but we still using variable from cache For more complex example let's use CMAKE_PREFIX_PATH and find_package: find_package(Foo CONFIG REQUIRED) message("Foo_DIR: ${Foo_DIR}") > rm -rf _builds > cmake -H. -B_builds -DCMAKE_PREFIX_PATH="location-A" Foo_DIR: location-A > cmake -H. -B_builds -DCMAKE_PREFIX_PATH="location-B" Foo_DIR: location-A # Still location-A! > rm -rf _builds > cmake -H. -B_builds -DCMAKE_PREFIX_PATH="location-B" Foo_DIR: location-B You can said that it's kind of obvious that you must clear the cache if you're changing such critical variables like CMAKE_PREFIX_PATH but in this case think about tools that want to do such things automatically and efficiently. There is no big difference between A and CMAKE_PREFIX_PATH, in both cases it's just a CMake variable. Ruslan From ruslan_baratov at yahoo.com Fri Jul 31 13:59:47 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 31 Jul 2015 20:59:47 +0300 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: References: <20150730133737.03E50B108D@public.kitware.com> <55BA2C10.8010607@gmail.com> <55BA3F89.50902@kitware.com> <55BA60AC.8010406@kitware.com> <55BBA36C.4070403@yahoo.com> Message-ID: <55BBB793.2020600@yahoo.com> On 31-Jul-15 19:44, Daniel Schepler wrote: > This seems to work for me: > set(CMAKE_BUILD_TYPE_INIT RelWithDebInfo) By the way you need to set it before first 'project' command. Also it will not have any effects for multi-config generators like Xcode or Visual Studio. From dschepler at scalable-networks.com Fri Jul 31 17:57:50 2015 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Fri, 31 Jul 2015 21:57:50 +0000 Subject: [CMake] [cmake-developers] CMake IR In-Reply-To: References: <20150730133737.03E50B108D@public.kitware.com> <55BA2C10.8010607@gmail.com> <55BA3F89.50902@kitware.com> <55BA60AC.8010406@kitware.com> <55BBA36C.4070403@yahoo.com> , Message-ID: It doesn't look like it's documented, at least in the command line --help-variable. It's a special case, which I think works for a lot of the build flag related cache variables (though for a lot of the others, you probably need to put values in e.g. a c_flag_overrides.cmake included by setting CMAKE_USER_MAKE_RULES_OVERRIDE so they can be dependent on detected platform/compiler settings). -- Daniel Schepler ________________________________________ From: daniel.r.kegel at gmail.com [daniel.r.kegel at gmail.com] on behalf of Dan Kegel [dank at kegel.com] Sent: Friday, July 31, 2015 10:21 AM To: Daniel Schepler Cc: cmake Subject: Re: [CMake] [cmake-developers] CMake IR On Fri, Jul 31, 2015 at 11:44 AM, Daniel Schepler wrote: >> Here's another example from real life. Maybe I'm just being an idiot, >> but this is what I had to do to set a default: >> >> IF(DEFINED CMAKE_BUILD_TYPE AND (NOT ${CMAKE_BUILD_TYPE} STREQUAL "None")) >> SET(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING "Choose the >> type of build, options are: Debug Release RelWithDebInfo") >> ELSE() >> SET(CMAKE_BUILD_TYPE "RelWithDebInfo" CACHE STRING "Choose the type >> of build, options are: Debug Release RelWithDebInfo" FORCE) >> ENDIF() >> >> Can someone give me the proper one-line way to set a default for >> CMAKE_BUILD_TYPE, or is this an authentic problem? > > This seems to work for me: > set(CMAKE_BUILD_TYPE_INIT RelWithDebInfo) Wow, never heard of that variable, thanks Is that documented? Can you just slam _INIT on the end of any cache variable to give it a default value, or is that a special case? - Dan