From dhouston at staffmail.ed.ac.uk Sun May 1 05:30:04 2016 From: dhouston at staffmail.ed.ac.uk (Douglas Houston) Date: Sun, 01 May 2016 10:30:04 +0100 Subject: [CMake] Unknown CMake command "macro_ensure_version" Message-ID: <20160501103004.10252qr4qffndb6s@www.staffmail.ed.ac.uk> Hi, I am trying to use Cmake to compile a program on Scientific Linux release 6.7, and I get the following error with both the precompiled binary and my own compiled version of Cmake: [root at drhwks]# ~/cmake-3.5.2-Linux-x86_64/bin/cmake ~/openbabel-2.3.2 CMake Error at CMakeLists.txt:20 (include): include could not find load file: MacroEnsureVersion -- Using included inchi library. -- Could NOT find wxWidgets (missing: wxWidgets_LIBRARIES wxWidgets_INCLUDE_DI RS) CMake Error at CMakeLists.txt:231 (macro_ensure_version): Unknown CMake command "macro_ensure_version". -- Configuring incomplete, errors occurred! See also "/root/openbabel-2.3.2/build/CMakeFiles/CMakeOutput.log". See also "/root/openbabel-2.3.2/build/CMakeFiles/CMakeError.log". [root at drhwks build]# ls -lht | head total 24K -rw-r--r--. 1 root root 17K May 1 10:13 CMakeCache.txt drwxr-xr-x. 5 root root 4.0K Apr 30 09:09 CMakeFiles [root at drhwks build]# rm CMake CMakeCache.txt CMakeFiles/ [root at drhwks build]# rm -rf CMake* [root at drhwks build]# ~/cmake-3.5.2-Linux-x86_64/bin/cmake ~/openbabel-2.3.2 -- The C compiler identification is GNU 4.4.7 -- The CXX compiler identification is GNU 4.4.7 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Error at CMakeLists.txt:20 (include): include could not find load file: MacroEnsureVersion -- Using included inchi library. -- Found LibXml2: /usr/lib64/libxml2.so (found version "2.7.6") -- Found ZLIB: /usr/lib64/libz.so (found version "1.2.3") -- Could NOT find wxWidgets (missing: wxWidgets_LIBRARIES wxWidgets_INCLUDE_DI RS) -- Looking for conio.h -- Looking for conio.h - not found -- Looking for sys/time.h -- Looking for sys/time.h - found -- Looking for time.h -- Looking for time.h - found -- Looking for strings.h -- Looking for strings.h - found -- Looking for rpc/xdr.h -- Looking for rpc/xdr.h - found -- Looking for regex.h -- Looking for regex.h - found -- Looking for C++ include sstream -- Looking for C++ include sstream - found -- Looking for rint -- Looking for rint - not found -- Looking for snprintf -- Looking for snprintf - found -- Looking for sranddev -- Looking for sranddev - not found -- Looking for strcasecmp -- Looking for strcasecmp - found -- Looking for strncasecmp -- Looking for strncasecmp - found -- Looking for dlopen in dl -- Looking for dlopen in dl - found -- Looking for sys/types.h -- Looking for sys/types.h - found -- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stddef.h -- Looking for stddef.h - found -- Check size of clock_t -- Check size of clock_t - done CMake Error at CMakeLists.txt:231 (macro_ensure_version): Unknown CMake command "macro_ensure_version". -- Configuring incomplete, errors occurred! See also "/root/openbabel-2.3.2/build/CMakeFiles/CMakeOutput.log". See also "/root/openbabel-2.3.2/build/CMakeFiles/CMakeError.log". Can anyone please help? Regards, Douglas Houston -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From zhongle at proplussolution.com Sun May 1 06:54:06 2016 From: zhongle at proplussolution.com (vakano) Date: Sun, 1 May 2016 03:54:06 -0700 (MST) Subject: [CMake] How to set the dependency in cmake Message-ID: <1462100046185-7593382.post@n2.nabble.com> Hi, In make, gcc got the option -MMD to generate the dependency list of the object file(.o.d), is there any way know how to set it in the cmake? Thanks, vakano -- View this message in context: http://cmake.3232098.n2.nabble.com/How-to-set-the-dependency-in-cmake-tp7593382.html Sent from the CMake mailing list archive at Nabble.com. From nicholas11braden at gmail.com Sun May 1 08:55:32 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Sun, 1 May 2016 07:55:32 -0500 Subject: [CMake] Unknown CMake command "macro_ensure_version" In-Reply-To: <20160501103004.10252qr4qffndb6s@www.staffmail.ed.ac.uk> References: <20160501103004.10252qr4qffndb6s@www.staffmail.ed.ac.uk> Message-ID: I found several different versions of basically the same code in many projects, but it looks like openbabel is what you are trying to compile: https://github.com/baoilleach/openbabel-svn-mirror/blob/master/cmake/modules/MacroEnsureVersion.cmake Do you have this file in /cmake/modules/ ? It looks like that directory is being properly added to CMAKE_MODULE_PATH here: https://github.com/baoilleach/openbabel-svn-mirror/blob/master/CMakeLists.txt#L6-L7 Can you verify that you have those lines in the CMakeLists.txt you have downloaded? On Sun, May 1, 2016 at 4:30 AM, Douglas Houston wrote: > Hi, > > I am trying to use Cmake to compile a program on Scientific Linux release > 6.7, and I get the following error with both the precompiled binary and my > own compiled version of Cmake: > > > > [root at drhwks]# ~/cmake-3.5.2-Linux-x86_64/bin/cmake ~/openbabel-2.3.2 > CMake Error at CMakeLists.txt:20 (include): > include could not find load file: > > MacroEnsureVersion > > > -- Using included inchi library. > -- Could NOT find wxWidgets (missing: wxWidgets_LIBRARIES > wxWidgets_INCLUDE_DI > RS) > CMake Error at CMakeLists.txt:231 (macro_ensure_version): > Unknown CMake command "macro_ensure_version". > > > -- Configuring incomplete, errors occurred! > See also "/root/openbabel-2.3.2/build/CMakeFiles/CMakeOutput.log". > See also "/root/openbabel-2.3.2/build/CMakeFiles/CMakeError.log". > [root at drhwks build]# ls -lht | head > total 24K > -rw-r--r--. 1 root root 17K May 1 10:13 CMakeCache.txt > drwxr-xr-x. 5 root root 4.0K Apr 30 09:09 CMakeFiles > [root at drhwks build]# rm CMake > CMakeCache.txt CMakeFiles/ > [root at drhwks build]# rm -rf CMake* > [root at drhwks build]# ~/cmake-3.5.2-Linux-x86_64/bin/cmake ~/openbabel-2.3.2 > -- The C compiler identification is GNU 4.4.7 > -- The CXX compiler identification is GNU 4.4.7 > -- Check for working C compiler: /usr/bin/cc > -- Check for working C compiler: /usr/bin/cc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Check for working CXX compiler: /usr/bin/c++ > -- Check for working CXX compiler: /usr/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > CMake Error at CMakeLists.txt:20 (include): > include could not find load file: > > MacroEnsureVersion > > > -- Using included inchi library. > -- Found LibXml2: /usr/lib64/libxml2.so (found version "2.7.6") > -- Found ZLIB: /usr/lib64/libz.so (found version "1.2.3") > -- Could NOT find wxWidgets (missing: wxWidgets_LIBRARIES > wxWidgets_INCLUDE_DI > RS) > -- Looking for conio.h > -- Looking for conio.h - not found > -- Looking for sys/time.h > -- Looking for sys/time.h - found > -- Looking for time.h > -- Looking for time.h - found > -- Looking for strings.h > -- Looking for strings.h - found > -- Looking for rpc/xdr.h > -- Looking for rpc/xdr.h - found > -- Looking for regex.h > -- Looking for regex.h - found > -- Looking for C++ include sstream > -- Looking for C++ include sstream - found > -- Looking for rint > -- Looking for rint - not found > -- Looking for snprintf > -- Looking for snprintf - found > -- Looking for sranddev > -- Looking for sranddev - not found > -- Looking for strcasecmp > -- Looking for strcasecmp - found > -- Looking for strncasecmp > -- Looking for strncasecmp - found > -- Looking for dlopen in dl > -- Looking for dlopen in dl - found > -- Looking for sys/types.h > -- Looking for sys/types.h - found > -- Looking for stdint.h > -- Looking for stdint.h - found > -- Looking for stddef.h > -- Looking for stddef.h - found > -- Check size of clock_t > -- Check size of clock_t - done > CMake Error at CMakeLists.txt:231 (macro_ensure_version): > Unknown CMake command "macro_ensure_version". > > > -- Configuring incomplete, errors occurred! > See also "/root/openbabel-2.3.2/build/CMakeFiles/CMakeOutput.log". > See also "/root/openbabel-2.3.2/build/CMakeFiles/CMakeError.log". > > > > Can anyone please help? > > Regards, > Douglas Houston > > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > -- > > 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 attila.krasznahorkay at gmail.com Mon May 2 03:48:57 2016 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Mon, 2 May 2016 09:48:57 +0200 Subject: [CMake] LINK_FLAGS directory property In-Reply-To: References: Message-ID: <6163C0CA-B916-474C-BFEA-4BE8771D6850@gmail.com> Hi Matt, Have you tried using the CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS cache variables? These actually set these flags globally, and not just for one directory, but on the directory level they are easy to override. You can just do something like this in a subdirectory: string( REPLACE "-Wl,--as-needed" "" CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}" ) Cheers, Attila > On 27 Apr 2016, at 17:57, Matthew Keeler wrote: > > Is there an equivalent directory property for the target level LINK_FLAGS property. I can?t see anything according to the documentation but was hoping there was an oversight and something actually existed. > > What I am trying to do is pass extra flags to the linker for every target in my project and I didn?t want to have to set it per target. I tried using the link_libraries command but the flags I am adding are msvc specific and start with ?/? and cmake seems to be turning these into ?\? when its passed to the linker. Then the linker thinks its trying to link in another file and everything blows up. > > Also a secondary question is what does the INTERPROCEDURAL_OPTIMIZATIONS property at the directory level do. I assume on Windows it passes /GL to the compiler but will this also add /LCTG to the linker flags and prevent incremental linking. If I turn this property on will it also do it for debug configurations or just optimized configurations? > > -- > Matt Keeler > > -- > > 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 attila.krasznahorkay at gmail.com Mon May 2 04:00:50 2016 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Mon, 2 May 2016 10:00:50 +0200 Subject: [CMake] Override CMAKE_SHARED_LINKER_FLAGS for one particular library Message-ID: <577D254C-6C1D-4092-BFFB-B0BEA6981534@gmail.com> Dear All, I have a similar issue as Matt Keeler. In our project we have some global linker flags that we set for all targets using the CMAKE_EXE_LINKER_FLAGS, CMAKE_SHARED_LINKER_FLAGS and CMAKE_MODULE_LINKER_FLAGS cache variables. Now it turns out that for some libraries in the project I need to modify these flags. I can't modify the flags on the directory level, I need to modify them at the target level. I tried just setting extra flags in LINK_FLAGS for my specific targets. But the problem is that the placement of the flags set in this target specific property is not "well defined" wrt. the global properties. In this particular case we use "-Wl,--as-needed" globally for all of our targets. But for some particular libraries I'd like to turn this off. When I add "-Wl,--no-as-needed" to the LINK_FLAGS property of this library, it is put before the other flag in my final build configuration. And as such, it has no effect. I tried modifying CMAKE_SHARED_LINKER_FLAGS before the add_library call for this library, and then restoring it to its original value afterwards. (Since as I said, I can't modify the flag for the entire directory.) But this didn't work as expected. Since by the generation stage CMake doesn't remember that the variable was set differently in the different lines of the directory's CMakeLists.txt file. So, any ideas? I'd really hate to give up on using these global variables, and starting to set the flags one by one for all of our targets. Since it's a lot less work to just remove the flag for the targets that don't need it. Cheers, Attila From netheril96 at gmail.com Mon May 2 05:16:53 2016 From: netheril96 at gmail.com (Siyuan Ren) Date: Mon, 2 May 2016 17:16:53 +0800 Subject: [CMake] Xcode generator results in a project file without optimization Message-ID: I have CMake 3.5.2. I write a simple CMakeLists.txt like the below ``` project(mytest) add_executable(mytest test.cpp) ``` Then generate the Xcode project file with `cmake -G Xcode .`. Open the project file in Xcode, and I found the optimization level on all kinds of build, including "Debug", "Release", "RelWithDebInfo", "MinSizeRel", to be "None (-O0)". Do I do something wrong? Or CMake Xcode generator cannot even handle the simplest project right? From mkeeler at tenable.com Mon May 2 10:20:53 2016 From: mkeeler at tenable.com (Matthew Keeler) Date: Mon, 2 May 2016 10:20:53 -0400 Subject: [CMake] LINK_FLAGS directory property In-Reply-To: <6163C0CA-B916-474C-BFEA-4BE8771D6850@gmail.com> References: <6163C0CA-B916-474C-BFEA-4BE8771D6850@gmail.com> Message-ID: I am doing that for some things but it gets quite cumbersome as I have to override those for several different configurations. I guess that is the only way to do it currently.? --? Matt Keeler On May 2, 2016 at 03:48:59, Attila Krasznahorkay (attila.krasznahorkay at gmail.com) wrote: Hi Matt, Have you tried using the CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS cache variables? These actually set these flags globally, and not just for one directory, but on the directory level they are easy to override. You can just do something like this in a subdirectory: string( REPLACE "-Wl,--as-needed" "" CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}" ) Cheers, Attila > On 27 Apr 2016, at 17:57, Matthew Keeler wrote: > > Is there an equivalent directory property for the target level LINK_FLAGS property. I can?t see anything according to the documentation but was hoping there was an oversight and something actually existed. > > What I am trying to do is pass extra flags to the linker for every target in my project and I didn?t want to have to set it per target. I tried using the link_libraries command but the flags I am adding are msvc specific and start with ?/? and cmake seems to be turning these into ?\? when its passed to the linker. Then the linker thinks its trying to link in another file and everything blows up. > > Also a secondary question is what does the INTERPROCEDURAL_OPTIMIZATIONS property at the directory level do. I assume on Windows it passes /GL to the compiler but will this also add /LCTG to the linker flags and prevent incremental linking. If I turn this property on will it also do it for debug configurations or just optimized configurations? > > -- > Matt Keeler > > -- > > 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 dumont.guillaume at gmail.com Mon May 2 11:03:52 2016 From: dumont.guillaume at gmail.com (Guillaume Dumont) Date: Mon, 2 May 2016 11:03:52 -0400 Subject: [CMake] Emulating --whole-archive with MSVC Message-ID: Hi, I have been playing with the WINDOWS_EXPORT_ALL_SYMBOLS recently and found the feature very useful. I reused part of the this functionality to emulate the --whole-archive link flag with MSVC. Here is the process I used: 1. Use a POST_BUILD custom command to list the object files linked in the static library (dumpbin /ARCHIVEMEMBERS mylib.lib and write this to a file. 2. Use a cmake script to call cmake -E __create_def and create a header file with #pragma comment(linker, /include:" for every symbol in the generated .def file. 3. Consuming projects including this header file when linking to mylib.lib It seems that it would not be too hard to add this feature to cmake to that it can be done via a target property similar to the WINDOWS_EXPORT_ALL_SYMBOLS. For example: 1. WINDOWS_LINK_WHOLE_ARCHIVE is set on the library 2. CMake catches this and list all the object files into a file and calls itself via cmake -E __create_whole_archive_rsp_file which creates a response file containing a list of /INCLUDE:"" 3. CMake adds this response file to the INTERFACE_LINK_LIBRARIES of the target so that consuming projects automatically link in all the symbols defined in the library. 4. Then cmake would have the handle the installation of this response file, etc. See this for documentation of rsp files: https://msdn.microsoft.com/en-us/library/9xch38h8.aspx This would probably have the side effect of solving https://cmake.org/Bug/view.php?id=13032 which is nice. Most of this is already possible via cmake code but could be made much easier if it was just a property to set on a target. Would it be possible to implement such a feature in CMake? Do you see any problem with the process mentionned above? Is it currently possible to add a response file to the link line via target_link_libraries or via target properties? Thank you -- Guillaume Dumont ========================= dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon May 2 13:06:50 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 2 May 2016 13:06:50 -0400 Subject: [CMake] Emulating --whole-archive with MSVC In-Reply-To: References: Message-ID: <5727892A.6070601@kitware.com> On 05/02/2016 11:03 AM, Guillaume Dumont wrote: > emulate the --whole-archive link flag with MSVC FYI, this is the purpose of OBJECT libraries in CMake. However, currently OBJECT libraries cannot be installed or used externally. This limitation is primarily due to difficulty in defining semantics, particularly in the case of transitive linking. > 1. WINDOWS_LINK_WHOLE_ARCHIVE is set on the library > 2. CMake catches this and list all the object files into a file and > calls itself via cmake -E __create_whole_archive_rsp_file which creates > a response file containing a list of /INCLUDE:"" > 3. CMake adds this response file to the INTERFACE_LINK_LIBRARIES of > the target so that consuming projects automatically link in all the > symbols defined in the library. > 4. Then cmake would have the handle the installation of this response file, etc. Currently adding --whole-archive to INTERFACE_LINK_LIBRARIES is not well defined. It is only safe to add such flags in the target_link_libraries call of the final binary. This would be done on the client side. Therefore all of the above steps to simulate it should be done on the client side too and there is no need to do anything ahead of time or install anything. The way we express this on the client side with OBJECT libraries is to specify $ as sources of the consuming target in its add_library or add_executable call. This eliminates any sense of "linking" to the library in CMake's model of the project and therefore avoids having to define semantics for usage requirements and transitive linking of object libraries. > Is it currently possible to add a response file to the link line via > target_link_libraries or via target properties? Yes, but it is safe only to do this on the final binary and cannot currently be expressed as usage requirements on the library itself. For upstream support of the relevant use cases I'd prefer to see if OBJECT libraries can be made to handle them. This will be more portable than the platform-specific solution proposed here. Discussion of this work would be better held on the dev list: https://cmake.org/mailman/listinfo/cmake-developers -Brad From jonas.collberg at orzone.com Tue May 3 09:10:15 2016 From: jonas.collberg at orzone.com (Jonas Collberg) Date: Tue, 3 May 2016 15:10:15 +0200 Subject: [CMake] Automatic moc, uic and rcc every build Message-ID: Hi, I'm using CMake to create project configuration files for Visual Studio 2015 (generator: "Visual Studio 14 2015 Win64") and Qt Creator (generator: "CodeBlocks - NMake Makefiles"). The biggest remaining problem I have is that every time I build or run a project using the CodeBlocks generator, CMake goes through some time-consuming and unnecessary (?) processing for every project. The output of this processing step are the three lines: Automatic moc, uic and rcc for target X Built target X_automoc Built target X This processing of the automoc targets is done even though no changes have been made to the source. I've created a small repository with a demonstration of the problem at https://bitbucket.org/joncol/cmake_qt_test. I use CMake version 3.5.2. When building (or running) the project via the CodeBlocks build configuration, you get the "Automatic moc, uic and rcc for target myapp" output every time. In my linked minimal example, it doesn't take much time, but for my real work (large existing code base with many projects) it takes a significant amount of time to do this. Does anyone know of a way around this seemingly unnecessary processing of automatic targets? Regards, Jonas Collberg -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Tue May 3 17:42:55 2016 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 3 May 2016 17:42:55 -0400 Subject: [CMake] ExternalProject_Add + imported targets: no rule to make yourlibrary.so In-Reply-To: References: Message-ID: On 4/28/2016 4:31 PM, SnakE wrote: > set_target_properties(foo PROPERTIES IMPORTED_LOCATION foo.so) https://cmake.org/cmake/help/v3.0/prop_tgt/IMPORTED_LOCATION.html?highlight=imported_location "Full path to the main file on disk for an IMPORTED target." You need to use a full path to foo.so, works by luck with make. -Bill From dschepler at scalable-networks.com Thu May 5 17:00:09 2016 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Thu, 5 May 2016 21:00:09 +0000 Subject: [CMake] CXX_COMPILE_FEATURES entry for thread safety of static local variable initialization Message-ID: I don't see this in a quick scan through CMAKE_DIR/share/cmake-3.5/Help/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.rst. This would be the C++11 addition under http://en.cppreference.com/w/cpp/language/storage_duration#Static_local_variables - or, the feature matrix at https://msdn.microsoft.com/en-us/library/hh567368.aspx refers to this as "Magic statics" and refers to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm . Before I file a bug requesting an addition for this, I thought I'd check to see if there's something relevant in the C++ feature list that I missed in my quick scan. For now, I'm using a custom definition of #define CXX_STATIC_LOCAL_VAR_THREAD_SAFE_INIT \ (defined(__GNUC__) || defined(__clang__) || \ (defined(_MSC_VER) && _MSC_VER >= 1900)) // VS 2015 / vc14 (given that the rest of our program has a strong requirement on other C++11 features anyway). -- Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.espak at ucl.ac.uk Fri May 6 17:32:01 2016 From: m.espak at ucl.ac.uk (Miklos Espak) Date: Fri, 6 May 2016 22:32:01 +0100 Subject: [CMake] No cmake.exe in latest CMake windows binaries Message-ID: Hi, I tried to upgrade CMake on Windows, hoping that it solves an issue with the execute_process command. (It does not seem to work from bash.) So, I downloaded the latest zip, this one: https://cmake.org/files/v3.5/cmake-3.5.2-win32-x86.zip But it does not seem to contain neither cmake.exe nor cmake-gui.exe. It has cpack and ctest, though. The reason for not using the installer is that it is noted on the download page that previous CMake versions (<=3.4) should be uninstalled before installing 3.5.x, but we do actually need to keep the old versions for now. Is it possible to have 3.3 and 3.5 side by side? Do I need to compile 3.5 on my own? Cheers, Miklos -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.espak at ucl.ac.uk Fri May 6 17:44:08 2016 From: m.espak at ucl.ac.uk (Miklos Espak) Date: Fri, 6 May 2016 22:44:08 +0100 Subject: [CMake] CMake execute_process command on bash on Windows Message-ID: Hi, I want to run CMake from bash on Windows, but the configuration fails at the 'execute_command' calls in our CMakeLists files. The WORKING_DIRECTORY argument does not seem to make any effect. I got around it by prepending "cd ; ..." before the command to execute. But then I got other problems. (The output was not stored in the output variable.) This was with CMake 3.3.2. Has anybody got experience with using CMake from bash on Windows? Has anybody tried? Cheers, Miklos -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Fri May 6 18:30:24 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 6 May 2016 15:30:24 -0700 (PDT) Subject: [CMake] CMake execute_process command on bash on Windows In-Reply-To: References: Message-ID: On 2016-05-06 22:44+0100 Miklos Espak wrote: > Hi, > > I want to run CMake from bash on Windows, but the configuration fails at > the 'execute_command' calls in our CMakeLists files. The WORKING_DIRECTORY > argument does not seem to make any effect. I got around it by prepending > "cd ; ..." before the command to execute. But then I got > other problems. (The output was not stored in the output variable.) > > This was with CMake 3.3.2. > > Has anybody got experience with using CMake from bash on Windows? Has > anybody tried? To help others here understand any issues you have encountered, I suggest you should indicate the source of the bash.exe that you are using, what kind of Windows (Cygwin, MinGW-w64/MSYS2, MinGW/MSYS, or bare Windows?), and what generator you are using. I have no recent first-hand experience myself, but as the guy who collects test reports from PLplot users I have heard lots of second-hand reports that our test system (based on CMake custom commands that run bash test scripts) works well for Cygwin, MinGW-w64/MSYS2, and MinGW/MSYS. Also, one of the PLplot developers tried the idea of putting bash.exe (from Cygwin, IIRC) on the PATH and then running PLplot tests for the MSVC case, but he could not get it to work for reasons he could not understand. I thought at the time there might have been issues about the way he was manipulating the PATH directly from Windows so I suggested instead he run bash.exe, and set the PATH (and other required environment variables) from bash using a known file filled with export commands that he "source"d, but he never followed up with that experiment. So from my perspective the "jury is still out" on the combination of CMake, bash, and MSVC, but that combination should be fine on the other Windows platforms I have mentioned. 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 m.espak at ucl.ac.uk Fri May 6 18:46:39 2016 From: m.espak at ucl.ac.uk (Miklos Espak) Date: Fri, 6 May 2016 23:46:39 +0100 Subject: [CMake] CMake execute_process command on bash on Windows In-Reply-To: References: Message-ID: I used the bash that is deployed with Git for Windows, and the generator was for VS 2012, 64bit. You mean, the behaviour of the execute_process command depends on the generator rather then the host shell and platform? Miklos On 6 May 2016 at 23:30, Alan W. Irwin wrote: > On 2016-05-06 22:44+0100 Miklos Espak wrote: > > Hi, >> >> I want to run CMake from bash on Windows, but the configuration fails at >> the 'execute_command' calls in our CMakeLists files. The WORKING_DIRECTORY >> argument does not seem to make any effect. I got around it by prepending >> "cd ; ..." before the command to execute. But then I got >> other problems. (The output was not stored in the output variable.) >> >> This was with CMake 3.3.2. >> >> Has anybody got experience with using CMake from bash on Windows? Has >> anybody tried? >> > > To help others here understand any issues you have encountered, I > suggest you should indicate the source of the bash.exe that you are > using, what kind of Windows (Cygwin, MinGW-w64/MSYS2, MinGW/MSYS, > or bare Windows?), and what generator you are using. > > I have no recent first-hand experience myself, but as the guy who > collects test reports from PLplot users I have heard lots of > second-hand reports that our test system (based on CMake custom > commands that run bash test scripts) works well for Cygwin, > MinGW-w64/MSYS2, and MinGW/MSYS. Also, one of the PLplot developers > tried the idea of putting bash.exe (from Cygwin, IIRC) on the PATH and > then running PLplot tests for the MSVC case, but he could not get it > to work for reasons he could not understand. I thought at the time > there might have been issues about the way he was manipulating the > PATH directly from Windows so I suggested instead he run bash.exe, and > set the PATH (and other required environment variables) from bash > using a known file filled with export commands that he "source"d, but > he never followed up with that experiment. So from my perspective the > "jury is still out" on the combination of CMake, bash, and MSVC, but > that combination should be fine on the other Windows platforms I have > mentioned. > > 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 > __________________________ > -- > > 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 zhongle at proplussolution.com Fri May 6 19:25:36 2016 From: zhongle at proplussolution.com (vakano) Date: Fri, 6 May 2016 16:25:36 -0700 (MST) Subject: [CMake] How does cmake handle object dependency(.o.d) in QtCreator Message-ID: <1462577136819-7593397.post@n2.nabble.com> Hi, GCC got an option -MMD to export object dependency (.o.d) for header files incremental build, in netbeans, there is an option called enable dependency checking, it will generate an .dep.inc and includes this file in make file automatically, my question is how to set this dependency handling in Qt Creator. Is there some extra setting for cmake? Thanks, Le -- View this message in context: http://cmake.3232098.n2.nabble.com/How-does-cmake-handle-object-dependency-o-d-in-QtCreator-tp7593397.html Sent from the CMake mailing list archive at Nabble.com. From african_boy at web.com.na Fri May 6 20:02:22 2016 From: african_boy at web.com.na (African Boy) Date: Fri, 06 May 2016 20:02:22 -0400 Subject: [CMake] No cmake.exe in latest CMake windows binaries In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Sat May 7 02:02:55 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 6 May 2016 23:02:55 -0700 (PDT) Subject: [CMake] CMake execute_process command on bash on Windows In-Reply-To: References: Message-ID: On 2016-05-06 23:46+0100 Miklos Espak wrote: > I used the bash that is deployed with Git for Windows, and the generator > was for VS 2012, 64bit. > > You mean, the behaviour of the execute_process command depends on the > generator rather then the host shell and platform? Ideally not, but you never know, there may be some generator-related issue or even some non-generator issue in the particular CMake version (3.3.2) that you are currently using. And it certainly sounds like a bug if the WORKING_DIRECTORY argument is being ignored for execute_process. To help you proceed further I suggest three debugging questions you should be asking yourself. 1. Can you boil down the issue to a simple test case (a few-line CMakeLists.txt file that calls execute_process) that anybody with access to Windows MSVC and bash.exe could try out for themselves? Once you publish that simple test case here, you might be able to get some quick help if you are calling execute_process incorrectly. 2. What happens if you use the "NMake Makefiles" generator instead for that simple test case? I mention that one because my impression is (just from what I have heard from time to time on this list about many fixes for VS generators) it might be more reliable than the VS-related generator you are currently using. 3. What happens if you use a later version of CMake, i.e., 3.4.3 or 3.5.2 with the "NMake Makefiles" generator for that simple test case? 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 dushistov at gmail.com Sun May 8 10:33:27 2016 From: dushistov at gmail.com (Evgeniy Dushistov) Date: Sun, 8 May 2016 17:33:27 +0300 Subject: [CMake] qt+cmake != qt+qmake on mac os x Message-ID: Hi, I created simple hello world with qt5 (5.6) using cmake 3.5.2: set(test_app_UIS mainwin.ui) set(test_app_MOC_HDRS mainwin.hpp) qt5_wrap_ui(test_app_UIS_H ${test_app_UIS}) qt5_wrap_cpp(test_app_MOC_SRCS ${test_app_MOC_HDRS}) add_executable(test_app ${test_app_UIS_H} ${test_app_MOC_SRCS} ${test_app_MOC_HDRS} mainwin.cpp main.cpp) target_link_libraries(test_app Qt5::Widgets) it builds and I can run it, but there is strange bug: after start I can not access menu, but if I give focus to another application, and then return back to test_app it is possible to open menu. I build the same application with qmake and bug disappear. the difference was how qmake and cmake place executables inside build directory: qmake put binary inside test_app.app directory, with content like: Info.plist MacOS PkgInfo Resources cmake put binary in the same way as on linux - just binary test_app So, to work with cmake + qt on mac I have write some special cmake with pre_build hook to generate suitable structure? Or there is more convenient way to resolve this problem? From craig.scott at crascit.com Sun May 8 16:20:23 2016 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 9 May 2016 06:20:23 +1000 Subject: [CMake] qt+cmake != qt+qmake on mac os x In-Reply-To: References: Message-ID: Add the MACOSX_BUNDLE keyword to your add_executable() command. See the CMake docs for details. On Mon, May 9, 2016 at 12:33 AM, Evgeniy Dushistov wrote: > Hi, > > I created simple hello world with qt5 (5.6) using cmake 3.5.2: > > set(test_app_UIS mainwin.ui) > set(test_app_MOC_HDRS mainwin.hpp) > qt5_wrap_ui(test_app_UIS_H ${test_app_UIS}) > qt5_wrap_cpp(test_app_MOC_SRCS ${test_app_MOC_HDRS}) > add_executable(test_app ${test_app_UIS_H} ${test_app_MOC_SRCS} > ${test_app_MOC_HDRS} mainwin.cpp main.cpp) > target_link_libraries(test_app Qt5::Widgets) > > it builds and I can run it, but there is strange bug: > > after start I can not access menu, but if I give focus to another > application, > and then return back to test_app it is possible to open menu. > > I build the same application with qmake and bug disappear. > > the difference was how qmake and cmake place executables inside build > directory: > > qmake put binary inside test_app.app directory, with content like: > Info.plist MacOS PkgInfo Resources > > cmake put binary in the same way as on linux - just binary test_app > > So, to work with cmake + qt on mac I have write some special cmake > with pre_build hook to generate suitable structure? Or there is more > convenient way to resolve this problem? > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dushistov at gmail.com Mon May 9 04:21:50 2016 From: dushistov at gmail.com (Evgeniy Dushistov) Date: Mon, 9 May 2016 11:21:50 +0300 Subject: [CMake] qt+cmake != qt+qmake on mac os x In-Reply-To: References: Message-ID: On Sun, May 8, 2016 at 11:20 PM, Craig Scott wrote: > Add the MACOSX_BUNDLE keyword to your add_executable() command. See the > CMake docs for details. Thanks, it works. From gjasny at googlemail.com Mon May 9 10:03:16 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Mon, 9 May 2016 16:03:16 +0200 Subject: [CMake] Xcode generator results in a project file without optimization In-Reply-To: References: Message-ID: <573098A4.5040104@googlemail.com> On 02/05/16 11:16, Siyuan Ren wrote: > I have CMake 3.5.2. > > I write a simple CMakeLists.txt like the below > > ``` > project(mytest) > add_executable(mytest test.cpp) > ``` > > Then generate the Xcode project file with `cmake -G Xcode .`. Open the > project file in Xcode, and I found the optimization level on all kinds > of build, including "Debug", "Release", "RelWithDebInfo", > "MinSizeRel", to be "None (-O0)". > > Do I do something wrong? Or CMake Xcode generator cannot even handle > the simplest project right? Works for me: xcodebuild -showBuildSettings -target mytest -configuration Release|grep OPTIMI GCC_OPTIMIZATION_LEVEL = 3 Which version of Xcode do you use? From patrick.boettcher at posteo.de Mon May 9 10:52:55 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Mon, 9 May 2016 16:52:55 +0200 Subject: [CMake] Two-stage build - how to include and know existing targets Message-ID: <20160509165255.2230bc1d@posteo.de> Hi list, In my project I have to build things in two stages (different compilers and different flags between the two stages). Both are built with CMake. I'm looking for a way of how to correctly include the generated products from one project (libraries in my case) in the other project's build. Right now I'm using export(TARGETS ... FILE something.cmake) in project 1 which gives me everything I need (a file I can include in the other build). With the exception of not knowing targets I have to consider. Project 1 can freely define one or more targets with any name. I need to consider all of them in the project 2. How can I do it nicely? Currently I'm thinking of adding manually a variable containing a list of all targets to "something.cmake" once created with export. Thanks, -- Patrick. From robert.maynard at kitware.com Mon May 9 10:58:25 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 9 May 2016 10:58:25 -0400 Subject: [CMake] default release build flags In-Reply-To: <572254C3.1060308@gmail.com> References: <572254C3.1060308@gmail.com> Message-ID: I think that changing the Release mode to generate non portable code is very nasty side-effect that would bite numerous projects down the road. I think a better avenue would be to think about adding another build configuration called ReleaseNative which would produce highly optimized non portable code. ( Name would need iteration ). Are you encountering this issue mainly when building locally or for HPC machines? I ask because maybe expanding the cross compilation infrastructure to set native flags would be a better avenue. On Thu, Apr 28, 2016 at 2:21 PM, Burlen Loring wrote: > Hi Guys, > > I'd like to discuss changing the defaults of CMAKE_C/CXX_FLAGS_RELEASE on > gcc, and potentially gcc like compilers such as clang and intel. > > Currently the default is "-O3 -DNDEBUG". I would like to discuss changing > this to "-O3 -march=native -mtune=native -DNDEBUG". This change will enable > numerous optimizations and produce faster code targeted for the cpu in use > during the compilation. > > The majority of people want cpu specific optimization enabled when compiling > code for use on their system. however many folks (specifically users of > scientific codes who are often not computer scientists) don't realize > requirement of passing march and mtune flags to enable cpu specific > instruction sets. Of course there are a small number of developers making > binaries for distribution who do not want to use cpu specific instructions, > but the number of developers make binaries for distribution is small > compared to folks who just need to compile code for their own use, and the > folks making binaries are well aware of the issues and can be expected to > know to disable such features. > > on my system here is the difference > > -03: > > $gcc -O3 -Q --help=target | grep enabled > -m64 [enabled] > -m80387 [enabled] > -m96bit-long-double [enabled] > -malign-stringops [enabled] > -mfancy-math-387 [enabled] > -mfentry [enabled] > -mfp-ret-in-387 [enabled] > -mglibc [enabled] > -mhard-float [enabled] > -mieee-fp [enabled] > -mlong-double-80 [enabled] > -mno-sse4 [enabled] > -mpush-args [enabled] > -mred-zone [enabled] > -mstackrealign [enabled] > -mtls-direct-seg-refs [enabled] > > -O3 -march=native -mtune=native > > $gcc -O3 -march=native -mtune=native -Q --help=target | grep enabled > -m64 [enabled] > -m80387 [enabled] > -m96bit-long-double [enabled] > -maes [enabled] > -malign-stringops [enabled] > -mavx [enabled] > -mcx16 [enabled] > -mf16c [enabled] > -mfancy-math-387 [enabled] > -mfentry [enabled] > -mfp-ret-in-387 [enabled] > -mfsgsbase [enabled] > -mfxsr [enabled] > -mglibc [enabled] > -mhard-float [enabled] > -mieee-fp [enabled] > -mlong-double-80 [enabled] > -mmmx [enabled] > -mpclmul [enabled] > -mpopcnt [enabled] > -mpush-args [enabled] > -mrdrnd [enabled] > -mred-zone [enabled] > -msahf [enabled] > -msse [enabled] > -msse2 [enabled] > -msse3 [enabled] > -msse4 [enabled] > -msse4.1 [enabled] > -msse4.2 [enabled] > -mssse3 [enabled] > -mstackrealign [enabled] > -mtls-direct-seg-refs [enabled] > -mxsave [enabled] > -mxsaveopt [enabled] > > notice specifically the lack of sse and avx in -O3! these instruction sets > play a major role in providing computational performance in modern cpus, and > that's why I think they should be enable by default in cmake Release builds. > clang and intel also support these flags, although there may be better > alternatives. > > What do you think? > > Burlen > > -- > > 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 konrad.wilhelm.kleine at gmail.com Mon May 9 11:11:32 2016 From: konrad.wilhelm.kleine at gmail.com (Konrad Kleine) Date: Mon, 9 May 2016 17:11:32 +0200 Subject: [CMake] GPG-Verifying the integrity of a CMake release: BAD signature from "Brad King" Message-ID: Hi, I'm trying to verify the integrity of a CMake release using GPG. I'm getting the error, that there's a BAD signature from "Brad King". Now I wonder what could be the reason for this issue. To make it easily reproducible, here's my Dockerfile, describing the process for you to test it yourself. If you don't know docker, just run the commands after "RUN" on a centos/RHEL machine. FROM centos:7 RUN yum install -y gpg # Get CMake from official website ADD https://cmake.org/files/v3.5/cmake-3.5.2-Linux-x86_64.tar.gz /tmp ADD https://cmake.org/files/v3.5/cmake-3.5.2-SHA-256.txt /tmp ADD https://cmake.org/files/v3.5/cmake-3.5.2-SHA-256.txt.asc /tmp # Install CMake to /opt/cmake* RUN tar xzf /tmp/cmake-*.tar.gz -C /opt RUN echo "alias cmake=/opt/cmake*/bin/cmake" > ~/.bashrc # Import Brad King's key from public PGP/GPG server RUN gpg --keyserver pgp.mit.edu --recv 7BFB4EDA # Ultimately trust Brad's key (non-interactively) # (see http://blog.tersmitten.nl/how-to-ultimately-trust-a-public-key-non-interactively.html ) RUN echo "$( \ gpg --list-keys --fingerprint \ | grep 7BFB4EDA -A 1 \ | tail -1 \ | tr -d '[:space:]' \ | awk 'BEGIN { FS = "=" } ; { print $2 }' \ ):6:" \ | gpg --import-ownertrust; # Verify the integrity of the downloaded cmake tarball against Brad King's key RUN gpg --verbose --verify /tmp/cmake*.asc /tmp/cmake*.tar.gz Here's the output which indicates that something is wrong with the signature: docker build -t docker_image_centos . Sending build context to Docker daemon 19.46 kB Step 1 : FROM centos:7 ---> 28e524afdd05 Step 2 : RUN yum install -y rpm-build gcc-c++ make doxygen gpg git rpmlint ---> Using cache ---> 14ac7b398da3 Step 3 : ADD https://cmake.org/files/v3.5/cmake-3.5.2-Linux-x86_64.tar.gz /tmp Downloading [==================================================>] 28.43 MB/28.43 MB ---> Using cache ---> 7580075ff224 Step 4 : ADD https://cmake.org/files/v3.5/cmake-3.5.2-SHA-256.txt /tmp Downloading 1.3 kB ---> Using cache ---> 2baf274427a5 Step 5 : ADD https://cmake.org/files/v3.5/cmake-3.5.2-SHA-256.txt.asc /tmp Downloading 819 B ---> Using cache ---> 3fe12e2bb3c9 Step 6 : RUN tar xzf /tmp/cmake-*.tar.gz -C /opt ---> Using cache ---> a045dc6c3c14 Step 7 : RUN echo "alias cmake=/opt/cmake*/bin/cmake" > ~/.bashrc ---> Using cache ---> 86072dec6ba5 Step 8 : RUN gpg --keyserver pgp.mit.edu --recv 7BFB4EDA ---> Running in 7becb0710a74 gpg: directory `/root/.gnupg' created gpg: new configuration file `/root/.gnupg/gpg.conf' created gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/root/.gnupg/secring.gpg' created gpg: keyring `/root/.gnupg/pubring.gpg' created gpg: requesting key 7BFB4EDA from hkp server pgp.mit.edu gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key 7BFB4EDA: public key "Brad King" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) ---> 0f01ef261745 Removing intermediate container 7becb0710a74 Step 9 : RUN echo "$( gpg --list-keys --fingerprint | grep 7BFB4EDA -A 1 | tail -1 | tr -d '[:space:]' | awk 'BEGIN { FS = "=" } ; { print $2 }' ):6:" | gpg --import-ownertrust; ---> Running in 74316f6291cb gpg: inserting ownertrust of 6 ---> b94c3ff29994 Removing intermediate container 74316f6291cb Step 10 : RUN gpg --verbose --verify /tmp/cmake*.asc /tmp/cmake*.tar.gz ---> Running in 31e58a9e6637 Version: GnuPG v2 gpg: armor header: gpg: Signature made Fri Apr 15 15:41:34 2016 UTC using RSA key ID 34921684 gpg: using subkey 34921684 instead of primary key 7BFB4EDA gpg: using PGP trust model gpg: checking the trustdb gpg: 1 keys cached (24 signatures) gpg: 1 keys processed (0 validity counts cleared) gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: BAD signature from "Brad King" gpg: binary signature, digest algorithm SHA256 The command '/bin/sh -c gpg --verbose --verify /tmp/cmake*.asc /tmp/cmake*.tar.gz' returned a non-zero code: 1 Am I doing something wrong? How is a release supposed to be verified using GPG? Thank you in advance! Konrad -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon May 9 12:48:02 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 9 May 2016 12:48:02 -0400 Subject: [CMake] GPG-Verifying the integrity of a CMake release: BAD signature from "Brad King" In-Reply-To: References: Message-ID: <5730BF42.20705@kitware.com> On 05/09/2016 11:11 AM, Konrad Kleine wrote: > ADD https://cmake.org/files/v3.5/cmake-3.5.2-Linux-x86_64.tar.gz /tmp > ADD https://cmake.org/files/v3.5/cmake-3.5.2-SHA-256.txt /tmp > ADD https://cmake.org/files/v3.5/cmake-3.5.2-SHA-256.txt.asc /tmp [snip] > # Verify the integrity of the downloaded cmake tarball against Brad King's key > RUN gpg --verbose --verify /tmp/cmake*.asc /tmp/cmake*.tar.gz The "cmake-3.5.2-SHA-256.txt.asc" file is a signature of the SHA-256 summary file "cmake-3.5.2-SHA-256.txt". You need to check that signature: $ curl -O https://cmake.org/files/v3.5/cmake-3.5.2-SHA-256.txt $ curl -O https://cmake.org/files/v3.5/cmake-3.5.2-SHA-256.txt.asc $ gpg --verbose --verify cmake-3.5.2-SHA-256.txt.asc cmake-3.5.2-SHA-256.txt ... gpg: Good signature from "Brad King" ... Then check that the SHA-256 matches the binary: $ curl -O https://cmake.org/files/v3.5/cmake-3.5.2-Linux-x86_64.tar.gz $ grep "$(shasum -a 256 cmake-3.5.2-Linux-x86_64.tar.gz)" cmake-3.5.2-SHA-256.txt 5f7aeaebe33521647625e0411467de71a2886743e4aa2c179e04c9e141c6c8cd cmake-3.5.2-Linux-x86_64.tar.gz -Brad From irwin at beluga.phys.uvic.ca Mon May 9 14:54:31 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 9 May 2016 11:54:31 -0700 (PDT) Subject: [CMake] GPG-Verifying the integrity of a CMake release: BAD signature from "Brad King" In-Reply-To: References: Message-ID: On 2016-05-09 17:11+0200 Konrad Kleine wrote: > Hi, > > I'm trying to verify the integrity of a CMake release using GPG. I'm > getting the error, that there's a BAD signature from "Brad King". Now I > wonder what could be the reason for this issue. > [...] > # Verify the integrity of the downloaded cmake tarball against Brad King's > key > RUN gpg --verbose --verify /tmp/cmake*.asc /tmp/cmake*.tar.gz I am virtually positive the above command is the source of the issue because gpg cannot be used to verify a raw tarball (i.e, the above /tmp/cmake*.tar.gz file). Instead, gpg should be used to verify the cmake-3.5.2-SHA-256.txt file as follows: gpg --verify cmake-3.5.2-SHA-256.txt.asc When I do that here (with everything downloaded from the official CMake site) I get the following results: gpg: assuming signed data in cmake-3.5.2-SHA-256.txt' gpg: Signature made Fri 15 Apr 2016 08:41:34 AM PDT using RSA key ID 34921684 gpg: Good signature from "Brad King" gpg: aka "Brad King " gpg: aka "[jpeg image of size 4005]" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: CBA2 3971 357C 2E65 90D9 EFD3 EC8F EF3A 7BFB 4EDA Subkey fingerprint: C6C2 6532 4BBE BDC3 50B5 13D0 2D2C EF10 3492 1684 Then once cmake-3.5.2-SHA-256.txt has been verified this way with a good signature then I run grep cmake-3.5.2.tar.gz cmake-3.5.2-SHA-256.txt |sha256sum --check with the result cmake-3.5.2.tar.gz: OK which verifies the raw tarball is consistent with the digitally signed and verified sum file. 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 marcus.hanwell at kitware.com Mon May 9 15:13:38 2016 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 9 May 2016 15:13:38 -0400 Subject: [CMake] default release build flags In-Reply-To: <572254C3.1060308@gmail.com> References: <572254C3.1060308@gmail.com> Message-ID: On Thu, Apr 28, 2016 at 2:21 PM, Burlen Loring wrote: > Hi Guys, > > I'd like to discuss changing the defaults of CMAKE_C/CXX_FLAGS_RELEASE on > gcc, and potentially gcc like compilers such as clang and intel. > > Currently the default is "-O3 -DNDEBUG". I would like to discuss changing > this to "-O3 -march=native -mtune=native -DNDEBUG". This change will enable > numerous optimizations and produce faster code targeted for the cpu in use > during the compilation. > As someone who was bitten by a project enabling -march=native in their CMake-based build system, and the days of debugging as this was a nested dependency built in a superbuild to create a package I hope we never make that a default. As a former Gentoo developer who has seen that -O3 is often not the best default flag for optimized builds I would actually suggest changing the default to "-O2 -DNDEBUG". The binaries are normally smaller, compile times faster, and the resulting code faster. Quoting from the wiki (https://wiki.gentoo.org/wiki/GCC_optimization): '-O3: the highest level of optimization possible. It enables optimizations that are expensive in terms of compile time and memory usage. Compiling with -O3 is not a guaranteed way to improve performance, and in fact, in many cases, can slow down a system due to larger binaries and increased memory usage. -O3 is also known to break several packages. Using -O3 is not recommended.' I think adding a RelWithNative or RelAgressiveOpt might be an option, but there are a number of things like distcc that makes applying -march=native undesirable. For those that know what they are doing certainly, but there are side effects and debugging can be tricky for the poor packagers too (who often have limited resources, and do not expect this). My $0.03 cents as someone who may have lost a little hair over this ;-) Marcus From irods.ben.keller at gmail.com Mon May 9 18:01:11 2016 From: irods.ben.keller at gmail.com (Ben Keller) Date: Mon, 9 May 2016 18:01:11 -0400 Subject: [CMake] Target's IMPORTED_LOCATION_* when CMAKE_INSTALL_PREFIX is "/" Message-ID: CMake version 3.5.0 When exporting from a project, the PROJECTTargets.cmake file contains logic for computing the _IMPORT_PREFIX. This _IMPORT_PREFIX is then used in the PROJECTTargets-.cmake to generate the IMPORTED_LOCATION_. If _IMPORT_PREFIX is "/", then the IMPORTED_LOCATION_ properties all start with two leading slashes ("//"). Exactly two leading slashes is apparently a special case in POSIX file paths, such that its interpretation is left up to the implementation. As best as I can tell, the PROJECTTargets.cmake file should be setting _IMPORT_PREFIX to the empty string instead of "/" to prevent the double leading slashes in PROJECTTargets-.cmake. A result of this is that when importing a library installed to /usr/lib, the IMPORTED_LOCATION_DEBUG ends up being "//usr/lib/libmylib.so". CMake doesn't contract the two leading slashes (as it apparently shouldn't), so executables linking against the mylib target end up with "//usr/lib" in their RPATH. Example of generated cmake code: [ -- From PROJECTTargets.cmake -- ] # Compute the installation prefix relative to this file. get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH) get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH) [ -- From PROJECTTargets-.cmake -- ] IMPORTED_LOCATION_DEBUG "${_IMPORT_PREFIX}/path/to/file.so" -------------- next part -------------- An HTML attachment was scrubbed... URL: From netheril96 at gmail.com Mon May 9 19:52:56 2016 From: netheril96 at gmail.com (Siyuan Ren) Date: Tue, 10 May 2016 07:52:56 +0800 Subject: [CMake] Xcode generator results in a project file without optimization In-Reply-To: <573098A4.5040104@googlemail.com> References: <573098A4.5040104@googlemail.com> Message-ID: Version 7.3.1 (7D1014) On Mon, May 9, 2016 at 10:03 PM, Gregor Jasny wrote: > On 02/05/16 11:16, Siyuan Ren wrote: >> I have CMake 3.5.2. >> >> I write a simple CMakeLists.txt like the below >> >> ``` >> project(mytest) >> add_executable(mytest test.cpp) >> ``` >> >> Then generate the Xcode project file with `cmake -G Xcode .`. Open the >> project file in Xcode, and I found the optimization level on all kinds >> of build, including "Debug", "Release", "RelWithDebInfo", >> "MinSizeRel", to be "None (-O0)". >> >> Do I do something wrong? Or CMake Xcode generator cannot even handle >> the simplest project right? > > Works for me: > xcodebuild -showBuildSettings -target mytest -configuration Release|grep > OPTIMI > GCC_OPTIMIZATION_LEVEL = 3 > > > Which version of Xcode do you use? From patrick.boettcher at posteo.de Tue May 10 01:59:48 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Tue, 10 May 2016 07:59:48 +0200 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries Message-ID: <20160510075948.1f445585@posteo.de> Hi list, What is the differences between PRIVATE and PUBLIC when used with target_link_libraries? I read the help and understood that it works like in C++: PRIVATE will make everything which was PUBLIC before also PRIVATE if inherited privately. An example: add_library(lib1 INTERFACE) target_include_directories(lib1 INTERFACE /tmp) add_library(lib2 src2.c) target_include_directories(lib2 PUBLIC /bin) target_link_libraries(lib2 PRIVATE lib1) # PRIVATE here add_library(lib3 src3.c) target_include_directories(lib3 PUBLIC /bin) target_link_libraries(lib3 PUBLIC lib1) # PUBLIC here add_executable(exe1 exe.c) target_link_libraries(exe1 lib2) add_executable(exe2 exe.c) target_link_libraries(exe2 lib3) When building exe2 both include-dirs (from lib1 and lib3) are present: [..] -I/bin -I/tmp [..] as they are for exe1 - however I would have expected to not see /tmp because lib3 and lib1 are linked privately. Where is my mistake? Thanks, -- Patrick. From gjasny at googlemail.com Tue May 10 03:38:57 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Tue, 10 May 2016 09:38:57 +0200 Subject: [CMake] Xcode generator results in a project file without optimization In-Reply-To: References: <573098A4.5040104@googlemail.com> Message-ID: <57319011.30706@googlemail.com> On 10/05/16 01:52, Siyuan Ren wrote: > Version 7.3.1 (7D1014) Could you please share your build and source directory with me? From m.espak at ucl.ac.uk Tue May 10 03:43:24 2016 From: m.espak at ucl.ac.uk (Miklos Espak) Date: Tue, 10 May 2016 08:43:24 +0100 Subject: [CMake] Running cpack without source folder Message-ID: Hi, given a complete build folder with all external projects, is it possible to run cpack without touching the sources? As I see, it now starts with configuring and building the project. (Skipping what is up-to-date, usually everything.) This can cause a problem if you switched branch after the built has finished and before running cpack. Does cpack actually need anything from the sources? If not, is it possible to tell cpack not to try to reconfig/rebuild the project? Cheers, Miklos -------------- next part -------------- An HTML attachment was scrubbed... URL: From claudio.caraffi at gmail.com Tue May 10 04:01:39 2016 From: claudio.caraffi at gmail.com (Claudio C) Date: Tue, 10 May 2016 10:01:39 +0200 Subject: [CMake] No cmake.exe in latest CMake windows binaries Message-ID: I don't know the package on the website has been updated in the meantime, but cmake.exe and cmake-gui.exe are there now, in the bin subfolder. Message: 1 Date: Fri, 6 May 2016 22:32:01 +0100 From: Miklos Espak To: "cmake at cmake.org" Subject: [CMake] No cmake.exe in latest CMake windows binaries Message-ID: Content-Type: text/plain; charset="utf-8" Hi, I tried to upgrade CMake on Windows, hoping that it solves an issue with the execute_process command. (It does not seem to work from bash.) So, I downloaded the latest zip, this one: https://cmake.org/files/v3.5/cmake-3.5.2-win32-x86.zip But it does not seem to contain neither cmake.exe nor cmake-gui.exe. It has cpack and ctest, though. The reason for not using the installer is that it is noted on the download page that previous CMake versions (<=3.4) should be uninstalled before installing 3.5.x, but we do actually need to keep the old versions for now. Is it possible to have 3.3 and 3.5 side by side? Do I need to compile 3.5 on my own? Cheers, Miklos -------------- next part -------------- An HTML attachment was scrubbed... URL: -- Ing. Claudio Caraffi, PhD E-Mail: claudio.caraffi at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From claudio.caraffi at gmail.com Tue May 10 04:13:18 2016 From: claudio.caraffi at gmail.com (Claudio C) Date: Tue, 10 May 2016 10:13:18 +0200 Subject: [CMake] Give clear warning if --build, -E or --find-package Message-ID: I have seen this issue has been closed: https://cmake.org/Bug/view.php?id=16093#bugnotes I understand the synopsis shows that those "options" (so they are called) have to be given as first, but I think then it should be made explicit in the option description and/or cmake should give a clear error if such an option doesn't appear as first. -- Ing. Claudio Caraffi, PhD E-Mail: claudio.caraffi at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.espak at ucl.ac.uk Tue May 10 04:14:43 2016 From: m.espak at ucl.ac.uk (Miklos Espak) Date: Tue, 10 May 2016 09:14:43 +0100 Subject: [CMake] No cmake.exe in latest CMake windows binaries In-Reply-To: References: Message-ID: I do not know it either, I see the files now, but that time I tried to download and unzip the installer two-three times and I did not find it there. I might have done something wrong. Thanks for checking. Miklos On 10 May 2016 at 09:01, Claudio C wrote: > I don't know the package on the website has been updated in the meantime, > but cmake.exe and cmake-gui.exe are there now, in the bin subfolder. > > > Message: 1 > Date: Fri, 6 May 2016 22:32:01 +0100 > From: Miklos Espak > To: "cmake at cmake.org" > Subject: [CMake] No cmake.exe in latest CMake windows binaries > Message-ID: > RBrMgjg-5LtGX5-XZ5Ykag6YgU0w at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > I tried to upgrade CMake on Windows, hoping that it solves an issue with > the execute_process command. (It does not seem to work from bash.) > > So, I downloaded the latest zip, this one: > > https://cmake.org/files/v3.5/cmake-3.5.2-win32-x86.zip > > But it does not seem to contain neither cmake.exe nor cmake-gui.exe. It > has > cpack and ctest, though. > > The reason for not using the installer is that it is noted on the download > page that previous CMake versions (<=3.4) should be uninstalled before > installing 3.5.x, but we do actually need to keep the old versions for now. > > Is it possible to have 3.3 and 3.5 side by side? Do I need to compile 3.5 > on my own? > > Cheers, > Miklos > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: /attachments/20160506/2d1433a1/attachment-0001.html> > > > -- > Ing. Claudio Caraffi, PhD > E-Mail: claudio.caraffi at gmail.com > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Tue May 10 05:39:49 2016 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Tue, 10 May 2016 11:39:49 +0200 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: <20160510075948.1f445585@posteo.de> References: <20160510075948.1f445585@posteo.de> Message-ID: <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> Hi Patrick, I *think* that these public/private rules behave a bit differently for static libraries than they do for shared ones. But I have to admit, that based on this code I also would've guessed that -I/tmp would not show up in the build of exe1... I did manage to use public and private dependencies as expected in my own configurations, so I'm not exactly sure what's going wrong in your case. Which version of CMake did you use for the test? Cheers, Attila > On 10 May 2016, at 07:59, Patrick Boettcher wrote: > > Hi list, > > What is the differences between PRIVATE and PUBLIC when used with > target_link_libraries? > > I read the help and understood that it works like in C++: PRIVATE will > make everything which was PUBLIC before also PRIVATE if inherited > privately. > > An example: > > add_library(lib1 INTERFACE) > target_include_directories(lib1 INTERFACE /tmp) > > add_library(lib2 src2.c) > target_include_directories(lib2 PUBLIC /bin) > target_link_libraries(lib2 PRIVATE lib1) # PRIVATE here > > add_library(lib3 src3.c) > target_include_directories(lib3 PUBLIC /bin) > target_link_libraries(lib3 PUBLIC lib1) # PUBLIC here > > add_executable(exe1 exe.c) > target_link_libraries(exe1 lib2) > > add_executable(exe2 exe.c) > target_link_libraries(exe2 lib3) > > > When building exe2 both include-dirs (from lib1 and lib3) are present: > > [..] -I/bin -I/tmp [..] > > as they are for exe1 - however I would have expected to not see /tmp > because lib3 and lib1 are linked privately. > > Where is my mistake? > > Thanks, > -- > Patrick. > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From attila.krasznahorkay at gmail.com Tue May 10 05:42:29 2016 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Tue, 10 May 2016 11:42:29 +0200 Subject: [CMake] Running cpack without source folder In-Reply-To: References: Message-ID: <6F99E556-06F3-41EE-98AA-B1D001F620EB@gmail.com> Hi, If you run the cpack executable directly, it should not reconfigure/rebuild your project. As far as I know... How do you run it now? "make package"? That will reconfigure/rebuild the project not really because of CPack, but because of how the Makefiles are set up. Cheers, Attila > On 10 May 2016, at 09:43, Miklos Espak wrote: > > Hi, > > given a complete build folder with all external projects, is it possible to run cpack without touching the sources? > > As I see, it now starts with configuring and building the project. (Skipping what is up-to-date, usually everything.) This can cause a problem if you switched branch after the built has finished and before running cpack. > > Does cpack actually need anything from the sources? If not, is it possible to tell cpack not to try to reconfig/rebuild the project? > > Cheers, > Miklos > > -- > > 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 m.espak at ucl.ac.uk Tue May 10 09:23:35 2016 From: m.espak at ucl.ac.uk (Miklos Espak) Date: Tue, 10 May 2016 14:23:35 +0100 Subject: [CMake] Running cpack without source folder In-Reply-To: <6F99E556-06F3-41EE-98AA-B1D001F620EB@gmail.com> References: <6F99E556-06F3-41EE-98AA-B1D001F620EB@gmail.com> Message-ID: Hi Attila, indeed, I was running cpack as 'make package'. Everything is fine if I run "cpack --config ./CPackConfig.cmake". Thanks very much. Miklos On 10 May 2016 at 10:42, Attila Krasznahorkay < attila.krasznahorkay at gmail.com> wrote: > Hi, > > If you run the cpack executable directly, it should not > reconfigure/rebuild your project. As far as I know... > > How do you run it now? "make package"? That will reconfigure/rebuild the > project not really because of CPack, but because of how the Makefiles are > set up. > > Cheers, > Attila > > > On 10 May 2016, at 09:43, Miklos Espak wrote: > > > > Hi, > > > > given a complete build folder with all external projects, is it possible > to run cpack without touching the sources? > > > > As I see, it now starts with configuring and building the project. > (Skipping what is up-to-date, usually everything.) This can cause a problem > if you switched branch after the built has finished and before running > cpack. > > > > Does cpack actually need anything from the sources? If not, is it > possible to tell cpack not to try to reconfig/rebuild the project? > > > > Cheers, > > Miklos > > > > -- > > > > 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 tetractius at gmail.com Tue May 10 12:16:44 2016 From: tetractius at gmail.com (tetractius) Date: Tue, 10 May 2016 17:16:44 +0100 Subject: [CMake] Cannot include third-party Framework headers directories as system directories in XCode for avoiding their warning Message-ID: Hi list, I have an issue caused by a warning in the qt5 brew version in osx when using Xcode generator I can safely find the qt framework in the brew cellar: set(CMAKE_PREFIX_PATH /usr/local/opt/qt5) find_package(Qt5Widgets REQUIRED) and with this I can easily add this framework to my project by using target_link_libraries(myApp Qt5::Widgets) and this, as per documentation will cause to add all the -I when compiling the .o files for this target. The problem is that QT has some warning in their headers at the version 5.6 and 5.5.2_1 (that is all the qt5 the versions available in brew) and the -I it is not a system include parameter. So assuming that I cannot avoid to use the brew version and I cannot fix the problems in the qt5 headers, *How can I tell to cmake that these framework include directories are system include directories and thus they need to be included with -isystem in the xcode project?* I tryed to manually pass the flag to the compiler but the target_link_libraries function, when used with the framework, it will always put their include directories in front of mine without the isystem flag. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prosteen at gmail.com Tue May 10 14:58:29 2016 From: prosteen at gmail.com (Phil Osteen) Date: Tue, 10 May 2016 14:58:29 -0400 Subject: [CMake] Find_Boost sets Boost_INCLUDE_DIR before making sure the right version is found Message-ID: I'm not sure if this is a pattern of some sort or if it is unique to Find_Boost, but using EXACT with find_package(Boost), as described here , will fail to find the correct boost version depending on the location of other boost versions. In FindBoost.cmake , a list of potential boost search directories and path suffices are used to look for boost/config.hpp. Once _any_ directory that contains boost/config.hpp is found, Boost_INCLUDE_DIR is set. After which, ${Boost_INCLUDE_DIR}/boost/version.hpp is used to extract the version. If this version does not match the one passed to find_package, cmake declares that it cannot find the specified version. Since find_path has a defined search process, if any other directory that happens to be searched first contains boost/config.hpp, the process will fail, even if the correct directory would have be subsequently found by find_path. One approach to resolve this would be to check the version.hpp value after a find_path call to make sure the correct version was found, and if not, to re-run find_path with, for example NO_CMAKE_PATH, then if that doesn't work, with NO_CMAKE_PATH and NO_CMAKE_ENVIRONMENT_PATH, and so on. I wanted to run this by everybody before writing the patch, perhaps a cleaner approach could be devised. Cheers Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.boettcher at posteo.de Wed May 11 01:13:55 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Wed, 11 May 2016 07:13:55 +0200 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> References: <20160510075948.1f445585@posteo.de> <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> Message-ID: <20160511071355.7209ed8a@vdr> On Tue, 10 May 2016 11:39:49 +0200 Attila Krasznahorkay wrote: > Hi Patrick, > > I *think* that these public/private rules behave a bit differently > for static libraries than they do for shared ones. > > But I have to admit, that based on this code I also would've guessed > that -I/tmp would not show up in the build of exe1... > > I did manage to use public and private dependencies as expected in my > own configurations, so I'm not exactly sure what's going wrong in > your case. Which version of CMake did you use for the test? I'm using cmake 3.5.0. Thank you for your feedback - I'll try to use shared-libraries, to see whether it changes something or not regards, -- Patrick. From tiagomacarios at gmail.com Wed May 11 01:14:07 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Tue, 10 May 2016 22:14:07 -0700 Subject: [CMake] AUTOMOC with files on different folders Message-ID: Hi, I am having trouble using AUTOMOC with a project where header files and source files are in different sub-directories. I wrote a detailed stack overflow question here: http://stackoverflow.com/questions/37151163/cmake-automoc-with-files-on-different-folders and would really appreciate if someone could give me a couple of ideas to try out. Thanks, Tiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Wed May 11 03:05:26 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 11 May 2016 09:05:26 +0200 Subject: [CMake] Xcode generator results in a project file without optimization In-Reply-To: References: <573098A4.5040104@googlemail.com> <57319011.30706@googlemail.com> Message-ID: <5732D9B6.605@googlemail.com> On 11/05/16 08:40, Siyuan Ren wrote: > Attached are a minimal demonstration and a screenshot of what Xcode > shows me when it opens the project. This also works for me. In your Xcode project file also everything looks normal (see GCC_OPTIMIZATION_LEVEL). Could you please switch your Xcode Build Settings View from "Combined" to "Levels"? I suspect you have an xcconfig file loaded via an environment variable which shadows the build settings. Thanks, Gregor -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-05-11 at 09.00.46.png Type: image/png Size: 224659 bytes Desc: not available URL: From attila.krasznahorkay at gmail.com Wed May 11 03:25:24 2016 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Wed, 11 May 2016 09:25:24 +0200 Subject: [CMake] Cannot include third-party Framework headers directories as system directories in XCode for avoiding their warning In-Reply-To: References: Message-ID: Hi, I'm a bit surprised by this. I had to explicitly tell CMake not to treat includes coming from imported targets as system includes. Using this variable: https://cmake.org/cmake/help/v3.0/variable/CMAKE_NO_SYSTEM_FROM_IMPORTED.html https://cmake.org/cmake/help/v3.0/prop_tgt/NO_SYSTEM_FROM_IMPORTED.html So I think this is in general a MacOS specific issue. I remember reading about such issues a while ago. That CMake would not recognise that MacOS X's clang would accept the -isystem argument out of the box. Cheers, Attila > On 10 May 2016, at 18:16, tetractius wrote: > > Hi list, > > I have an issue caused by a warning in the qt5 brew version in osx when using Xcode generator > > I can safely find the qt framework in the brew cellar: > > set(CMAKE_PREFIX_PATH /usr/local/opt/qt5) > find_package(Qt5Widgets REQUIRED) > > and with this I can easily add this framework to my project by using > > target_link_libraries(myApp Qt5::Widgets) > > and this, as per documentation will cause to add all the -I when compiling the .o files for this target. > > The problem is that QT has some warning in their headers at the version 5.6 and 5.5.2_1 (that is all the qt5 the versions available in brew) > and the -I it is not a system include parameter. > > > So assuming that I cannot avoid to use the brew version and I cannot fix the problems in the qt5 headers, > > How can I tell to cmake that these framework include directories are system include directories and thus they need to be included with -isystem in the xcode project? > > I tryed to manually pass the flag to the compiler but the target_link_libraries function, when used with the framework, it will always put their include directories in front of mine without the isystem flag. > > > > -- > > 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 attila.krasznahorkay at gmail.com Wed May 11 03:48:41 2016 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Wed, 11 May 2016 09:48:41 +0200 Subject: [CMake] AUTOMOC with files on different folders In-Reply-To: References: Message-ID: <2AFF0B96-301A-49F5-A154-37C210D7760F@gmail.com> Hi Tiago, This is one of those cases when you have to declare the header files to add_library(...) as well. In that case AUTOMOC should work fine. At least it does for us, in a very similar setup. http://acode-browser.usatlas.bnl.gov/lxr/source/atlas/graphics/VP1/VP1Gui/CMakeLists.txt Cheers, Attila > On 11 May 2016, at 07:14, Tiago Macarios wrote: > > Hi, > > I am having trouble using AUTOMOC with a project where header files and source files are in different sub-directories. I wrote a detailed stack overflow question here: > http://stackoverflow.com/questions/37151163/cmake-automoc-with-files-on-different-folders > and would really appreciate if someone could give me a couple of ideas to try out. > > Thanks, > Tiago > -- > > 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 netheril96 at gmail.com Wed May 11 05:56:24 2016 From: netheril96 at gmail.com (Siyuan Ren) Date: Wed, 11 May 2016 17:56:24 +0800 Subject: [CMake] Xcode generator results in a project file without optimization In-Reply-To: <5732D9B6.605@googlemail.com> References: <573098A4.5040104@googlemail.com> <57319011.30706@googlemail.com> <5732D9B6.605@googlemail.com> Message-ID: OK, I got it. It worked all the time, but I looked at the wrong scheme/target. On Wed, May 11, 2016 at 3:05 PM, Gregor Jasny wrote: > On 11/05/16 08:40, Siyuan Ren wrote: >> Attached are a minimal demonstration and a screenshot of what Xcode >> shows me when it opens the project. > > This also works for me. In your Xcode project file also everything looks > normal (see GCC_OPTIMIZATION_LEVEL). > > Could you please switch your Xcode Build Settings View from "Combined" > to "Levels"? I suspect you have an xcconfig file loaded via an > environment variable which shadows the build settings. > > Thanks, > Gregor > From iosif.neitzke+cmake at gmail.com Wed May 11 06:33:18 2016 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Wed, 11 May 2016 05:33:18 -0500 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: <20160511071355.7209ed8a@vdr> References: <20160510075948.1f445585@posteo.de> <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> <20160511071355.7209ed8a@vdr> Message-ID: >> I *think* that these public/private rules behave a bit differently >> for static libraries than they do for shared ones. They do. Assuming main calls a() and b() defined in A_lib and B_lib respectively, for: add_library(A_lib STATIC a.c) add_library(B_lib STATIC b.c) target_link_libraries(A_lib PRIVATE B_lib) add_executable(main main.c) target_link_libraries(main A_lib) The PRIVATE in "target_link_libraries(A_lib PRIVATE B_lib)" is useless. It is the same as writing "target_link_libraries(A_lib PUBLIC B_lib)", only more confusing to the reader. Static libraries always link to their dependencies publically. https://cmake.org/cmake/help/v3.5/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents However, if you change A_lib to be a shared library with "add_library(A_lib SHARED a.c)" and left the rest of the code the same, you would now get link errors for main not able to find b(), because A_lib now does not pass on its dependency on B, it hides it from main. Change the last line to "target_link_libraries(main A_lib B_lib)" and main builds again. From craig.scott at crascit.com Wed May 11 07:58:34 2016 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 11 May 2016 21:58:34 +1000 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: References: <20160510075948.1f445585@posteo.de> <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> <20160511071355.7209ed8a@vdr> Message-ID: Hopefully the explanation that follows helps clarify what PRIVATE, PUBLIC and INTERFACE mean and do. From my understanding of things, I think there may have been some subtle inaccuracies in some of the discussions so far, so hopefully the following is helpful and if I've got something wrong, then by all means please point out the inaccuracies. - When A links in B as *PRIVATE*, it is saying that A uses B in its implementation, but B is not used in any part of A's public API. Any code that makes calls into A would not need to refer directly to anything from B. An example of this could be a networking library A which can be built to use one of a number of different SSL libraries internally (which B represents). A presents a unified interface for client code which does not reference any of the internal SSL data structures or functions. Client code would have no idea what SSL implementation (B) is being used by A, nor does that client code need to care. - When A links in B as *INTERFACE*, it is saying that A does not use B in its implementation, but B is used in A's public API. Code that calls into A may need to refer to things from B in order to make such calls. One example of this is an interface library which simply forwards calls along to another library but doesn't actually reference the objects on the way through other than by a pointer or reference. Another example is where A is defined in CMake as an interface library, meaning it has no actual implementation itself, it is effectively just a collection of other libraries (I'm probably over-simplifying here, but you get the picture). - When A links in B as *PUBLIC*, it is essentially a combination of PRIVATE and INTERFACE. It says that A uses B in its implementation and B is also used in A's public API. Consider first what this means for include search paths. If something links against A, it will also need any include search paths from B if B is in A's public API. Thus, if A links in B either as PUBLIC or INTERFACE, then any header search paths defined for target B will also apply to anything that links to A. Any PRIVATE header search path for B will NOT be carried through to anything that links only to A. The target_include_directories() command handles this. The situation with compile flags is analogously handled with target_compile_definitions() and target_compile_options(). Now consider the situation for the actual libraries involved. If A is a shared library, then A will have encoded into it a dependency on B. This information can be inspected with tools like ldd on Linux, otool on Mac and something like Dependency Walker (a.k.a. depends.exe) on Windows. If other code links directly to A, then it also will have encoded into it a dependency on A. It will not, however, have a dependency on B unless A links in B as PUBLIC or INTERFACE. So far, so good. If, however, A is a static library, the situation changes. Static libraries do not carry information about other libraries they depend on. For this reason, when A links in B as PRIVATE and another target C links in A, CMake will still add B to the list of libraries to be linked for C because parts of B are needed by A, but A itself doesn't have that dependency encoded into it. So even though B is an internal implementation detail of A, C still needs B added to the linker command, which CMake conveniently handles for you. If you were paying careful attention, you would have noticed that when A links in B as PRIVATE, the include directories of B never propagate to something linking to A, but if A is a static library, then the *linking* of B behaves as though the relationship was PUBLIC. This PRIVATE-becomes-PUBLIC behaviour for static libraries only applies to the *linking*, not to the other dependencies (compiler options/flags and include search paths). The upshot of all this is that if you select PRIVATE, PUBLIC or INTERFACE based on the explanations in the dot points above, then CMake will ensure dependencies propagate through to where they are required, regardless of whether libraries are static or shared. This does, of course, rely on you the developer not missing any dependencies or specifying the wrong PRIVATE/PUBLIC/INTERFACE relationship. As a final note, if you call target_link_libraries() and do not specify any of PRIVATE, PUBLIC or INTERFACE, you may be tempted to believe that it will be treated as PUBLIC. The situation is actually more complicated than that though. It may be treated as PUBLIC or PRIVATE, depending on what other target_link_library() calls and/or target property manipulations have been performed. The documentation for target_link_libraries() talks a bit about this, but you have to go digging into the documentation for the target properties it mentions to get an understanding of what circumstances lead to PRIVATE or PUBLIC behaviour. Hope that helps clarify some things. Sorry if this has gone off on a tangent from the original enquiry, I'm coming in late to this thread. On Wed, May 11, 2016 at 8:33 PM, iosif neitzke < iosif.neitzke+cmake at gmail.com> wrote: > >> I *think* that these public/private rules behave a bit differently > >> for static libraries than they do for shared ones. > > They do. Assuming main calls a() and b() defined in A_lib and B_lib > respectively, for: > add_library(A_lib STATIC a.c) > add_library(B_lib STATIC b.c) > target_link_libraries(A_lib PRIVATE B_lib) > add_executable(main main.c) > target_link_libraries(main A_lib) > > The PRIVATE in "target_link_libraries(A_lib PRIVATE B_lib)" is > useless. It is the same as writing "target_link_libraries(A_lib > PUBLIC B_lib)", only more confusing to the reader. Static libraries > always link to their dependencies publically. > > > https://cmake.org/cmake/help/v3.5/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents > > However, if you change A_lib to be a shared library with > "add_library(A_lib SHARED a.c)" and left the rest of the code the > same, you would now get link errors for main not able to find b(), > because A_lib now does not pass on its dependency on B, it hides it > from main. Change the last line to "target_link_libraries(main A_lib > B_lib)" and main builds again. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From iosif.neitzke+cmake at gmail.com Wed May 11 08:13:04 2016 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Wed, 11 May 2016 07:13:04 -0500 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: References: <20160510075948.1f445585@posteo.de> <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> <20160511071355.7209ed8a@vdr> Message-ID: > When A links in B as PRIVATE, it is saying that A uses B in its > implementation, but B is not used in any part of A's public API. > When A links in B as INTERFACE, it is saying that A does not use B in its > implementation, but B is used in A's public API. > When A links in B as PUBLIC, it is essentially a combination of PRIVATE and > INTERFACE. It says that A uses B in its implementation and B is also used in > A's public API. All totally correct, and that is how visibility for target_link and target_include commands idiomatically should be used, but I don't believe anything in CMake ensures the code architecture adheres to this scheme. From steve.lorimer at gmail.com Wed May 11 09:58:03 2016 From: steve.lorimer at gmail.com (Steve Lorimer) Date: Wed, 11 May 2016 08:58:03 -0500 Subject: [CMake] in source makefile / helper script that enables building out of source? Message-ID: I've recently changed over from using boost-build ( http://www.boost.org/build/) to cmake. Boost build builds in-source. I've become quite used to building and searching etc from the source root ~/src $ b2 module ~/src $ git grep foo This work flow has been broken because I'm not using out of source builds ~/src/build $ make module ~/src/build $ git grep... dang it! ~/src/build $ cd .. ~/src $ git grep foo ~/src $ make modu... dang it! ~/src $ cd build ~/src/build $ make module I can't be the only one who wants to have the benefit of out of source builds and be able to build from in-source. I imagine it would be relatively simple to create a makefile which navigates to a known build directory (eg: build or debug or...), executes make there, and then changes directory back to where it was called from. Before I do just this, I thought it better to try leverage the open source community - hence asking the question. Does anyone have a script or makefile which does just this? TIA Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Wed May 11 10:01:23 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 11 May 2016 17:01:23 +0300 Subject: [CMake] in source makefile / helper script that enables building out of source? In-Reply-To: References: Message-ID: <2224031462975283@web7o.yandex.ru> 11.05.2016, 16:58, "Steve Lorimer" : > I've recently changed over from using boost-build (http://www.boost.org/build/) to cmake. > > Boost build builds in-source. > > I've become quite used to building and searching etc from the source root > >> ~/src $ b2 module >> ~/src $ git grep foo > > This work flow has been broken because I'm not using out of source builds > >> ~/src/build $ make module >> ~/src/build $ git grep... dang it! >> ~/src/build $ cd .. >> ~/src $ git grep foo >> ~/src $ make modu... dang it! >> ~/src $ cd build >> ~/src/build $ make module > I can't be the only one who wants to have the benefit of out of source builds and be able to build from in-source. > > I imagine it would be relatively simple to create a makefile which navigates to a known build directory (eg: build or debug or...), executes make there, and then changes directory back to where it was called from. > > Before I do just this, I thought it better to try leverage the open source community - hence asking the question. > > Does anyone have a script or makefile which does just this? FYI, CMake supports in-source builds (however, particular projects may not) > > TIA > 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 -- Regards, Konstantin From steve.lorimer at gmail.com Wed May 11 10:06:02 2016 From: steve.lorimer at gmail.com (Steve Lorimer) Date: Wed, 11 May 2016 09:06:02 -0500 Subject: [CMake] in source makefile / helper script that enables building out of source? In-Reply-To: <2224031462975283@web7o.yandex.ru> References: <2224031462975283@web7o.yandex.ru> Message-ID: On 11 May 2016 at 09:01, Konstantin Tokarev wrote: > > FYI, CMake supports in-source builds (however, particular projects may not) > Thanks for your response! I am aware of being able to do in-source builds, but would like to continue to reap the benefits of out-of-source builds whilst being able to build from in-source -------------- next part -------------- An HTML attachment was scrubbed... URL: From msarahan at gmail.com Wed May 11 10:34:19 2016 From: msarahan at gmail.com (Michael Sarahan) Date: Wed, 11 May 2016 14:34:19 +0000 Subject: [CMake] Visual Studio 2008 / VS Compiler for Python Message-ID: In compiling TBB, a conda-forge contributor ran across issues with CMake not finding the VS compiler for VS 2008 Win64. https://github.com/conda-forge/staged-recipes/pull/533 The exact error is at https://ci.appveyor.com/project/conda-forge/staged-recipes/build/1.0.2118/job/t2axdaotmty35j6k#L216 Appveyor is an interesting platform, in that they install VS 2008 Express, then the VS compiler for Python (which adds the 64-bit compilation support). How does CMake find compilers? Does it need extra instruction of some sort here? This is occurring in the context of a conda build, so we have already run the appropriate vcvars*.bat script by the time CMake runs ( https://ci.appveyor.com/project/conda-forge/staged-recipes/build/1.0.2118/job/t2axdaotmty35j6k#L185) - but I'm not sure that really influences CMake's ability to find the compiler. Any guidance much appreciated. Best, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Wed May 11 11:58:44 2016 From: paul at mad-scientist.net (Paul Smith) Date: Wed, 11 May 2016 11:58:44 -0400 Subject: [CMake] in source makefile / helper script that enables building out of source? In-Reply-To: References: <2224031462975283@web7o.yandex.ru> Message-ID: <1462982324.3111.33.camel@mad-scientist.net> On Wed, 2016-05-11 at 09:06 -0500, Steve Lorimer wrote: > I am aware of being able to do in-source builds, but would like to > continue to reap the benefits of out-of-source builds whilst being > able to build from in-source Make a shell function or shell script to run your build, that does the cd to the build directory and starts the build. From rleigh at codelibre.net Wed May 11 10:38:44 2016 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Wed, 11 May 2016 14:38:44 +0000 Subject: [CMake] [PATCH] FindBoost does not detect absence of header file In-Reply-To: <570CDA7E.3010403@fz-juelich.de> References: <570CDA7E.3010403@fz-juelich.de> Message-ID: <4aefef251aba00f394a08213b349f1fd@codelibre.net> On 2016-04-12 11:22, Joachim Wuttke wrote: > FindBoost does not detect absence of header files. > > To be specific: Run the following under cmake version 3.5.1: > > set(Boost_NO_BOOST_CMAKE ON) # prevent shortcut > set(Boost_USE_STATIC_LIBS OFF) > set(Boost_USE_MULTITHREADED ON) > set(Boost_USE_STATIC_RUNTIME OFF) > add_definitions(-DBOOST_ALL_DYN_LINK) # line is needed for MSVC > #add_definitions(-DBOOST_LIB_DIAGNOSTIC) # shows during compilation > auto-linked libraries > if(WIN32) > set(boost_libraries_required date_time chrono program_options zlib > bzip2 iostreams system filesystem regex thread) > else() > set(boost_libraries_required date_time chrono program_options > iostreams system filesystem regex thread) > endif() > find_package(Boost 1.48.0 COMPONENTS ${boost_libraries_required} > REQUIRED) > message(STATUS "--> Boost_INCLUDE_DIRS: ${Boost_INCLUDE_DIRS}") > message(STATUS " Boost_LIBRARY_DIRS: ${Boost_LIBRARY_DIRS}") > message(STATUS " Boost_LIBRARIES: ${Boost_LIBRARIES}") > > It will pass, even if files like /usr/include/boost/date_time.hpp &c > are removed > from the system. Attached is a patch to add this extra checking. For each library component, there is a corresponding header which has been present in all versions of boost to date which provide the library; the list used to validate this is also attached. I have also validated that each component works with find_package for Boost 1.58 and 1.60. If your system contains both the libraries and headers, then FindBoost will behave exactly as before. But if you have the libraries without the headers, FindBoost will now fail, rather than passing and then having the build subsequently fail when it tries to use the nonexistent headers. So it's essentially adding an additional header check per component, which will identify situations where the user has an incomplete Boost installation e.g. no all the -dev packages are installed. I can merge this into next for testing, but if anyone wanted to have an initial play with it to verify that it's still functional and that the approach is sound, I can wait off for now. Regards, Roger -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-FindBoost-Add-checks-for-component-specific-headers.patch Type: text/x-diff Size: 6669 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: boost-header-versions.txt URL: From roman.wueger at gmx.at Wed May 11 15:22:24 2016 From: roman.wueger at gmx.at (=?iso-8859-1?Q?Roman_W=FCger?=) Date: Wed, 11 May 2016 21:22:24 +0200 Subject: [CMake] CLang error when building iOS bundle Message-ID: <002601d1abba$7323fc60$596bf520$@gmx.at> Hello list, I got the following error when linking the iOS bundle: clang: error: cannot specify -o when generating multiple output files I didn?t found anything about the error in the internet, so maybe someone has already solved such error? Does any one have a hint what could be wrong? Thank you very much in advance Best Regards Roman P.S.: Here is the last output: CompileC /Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos-i OS-debug/build/appQml/SimpleApp.build/Debug-iphoneos/SimpleApp.build/Objects -normal/armv7/main.o appQml/main.cpp normal armv7 c++ com.apple.compilers.llvm.clang.1_0.compiler cd /Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos-i OS-debug/source export LANG=en_US.US-ASCII export PATH="/Applications/Xcode_7_3_1.app/Contents/Developer/Platforms/iPhoneOS.pl atform/Developer/usr/bin:/Applications/Xcode_7_3_1.app/Contents/Developer/us r/bin::/bin:/opt/Externals:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt /X11/bin:/Applications/Server.app/Contents/ServerRoot/usr/bin:/Applications/ Server.app/Contents/ServerRoot/usr/sbin" /Applications/Xcode_7_3_1.app/Contents/Developer/Toolchains/XcodeDefault.xct oolchain/usr/bin/clang -x c++ -arch armv7 -fmessage-length=233 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -fcolor-diagnostics -std=c++11 -stdlib=libc++ -Wno-trigraphs -fpascal-strings -O0 -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-shorten-64-to-32 -Wno-newline-eof -Wno-c++11-extensions -DCMAKE_INTDIR=\"Debug-iphoneos\" -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_QUICK_LIB -DQT_GUI_LIB -DQT_WIDGETS_LIB -DPLATFORM_IS_IOS -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -DQT_NO_CAST_TO_BYTEARRAY -DWSD_HAS_GENERIC_HIGHLIGHTER -DNOMINMAX -DQT_XML_LIB -isysroot /Applications/Xcode_7_3_1.app/Contents/Developer/Platforms/iPhoneOS.platform /Developer/SDKs/iPhoneOS9.3.sdk -fstrict-aliasing -Wdeprecated-declarations -Winvalid-offsetof -miphoneos-version-min=9.3 -Wno-sign-conversion -I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/build/bin/Debug/include -I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/build/appQml -I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/source/appQml -I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/build/cmake/cmake_wsd -I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/build/cmake -I/opt/Qt/5.6/ios/include -I/opt/Qt/5.6/ios/include/QtWidgets -I/opt/Qt/5.6/ios/include/QtGui -I/opt/Qt/5.6/ios/include/QtCore -I/opt/Qt/5.6/ios/mkspecs/macx-ios-clang -I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/source/libraries/gtest/include -I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/source/libraries -I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/source/libraries/Screens -I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/source/libraries/QmlTools -I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/source/libraries/Tools -I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/source/libraries/Utilities/libraries/GuiTools -I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/source/libraries/Utilities/libraries/Tools -I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/source/libraries/Utilities/libraries/QtTools -I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/source/interfaces -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev eloper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/CoreFoundation.framewo rk/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev eloper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/CoreGraphics.framework /Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev eloper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/CoreText.framework/Hea ders -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev eloper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/Foundation.framework/H eaders -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev eloper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/MobileCoreServices.fra mework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev eloper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/Security.framework/Hea ders -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev eloper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/UIKit.framework/Header s -I/opt/Qt/5.6/ios/include/QtQml -I/opt/Qt/5.6/ios/include/QtNetwork -I/opt/Qt/5.6/ios/include/QtQuick -I/opt/Qt/5.6/ios/include/QtXml -I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/build/appQml/SimpleApp.build/Debug-iphoneos/SimpleApp.build/Deriv edSources/armv7 -I/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/build/appQml/SimpleApp.build/Debug-iphoneos/SimpleApp.build/Deriv edSources -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -F/Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos -iOS-debug/build/bin/Debug -F/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev eloper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks -fvisibility=hidden -fvisibility-inlines-hidden -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Devel oper/SDKs/iPhoneOS9.3.sdk -arch armv7 -std=c++11 -stdlib=libc++ -F /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Devel oper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/CoreFoundation.framework /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Devel oper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/CoreGraphics.framework /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Devel oper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/CoreText.framework /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Devel oper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/Foundation.framework /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Devel oper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/MobileCoreServices.frame work /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Devel oper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/Security.framework /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Devel oper/SDKs/iPhoneOS9.3.sdk/System/Library/Frameworks/UIKit.framework -fPIC -MMD -MT dependencies -MF /Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos-i OS-debug/build/appQml/SimpleApp.build/Debug-iphoneos/SimpleApp.build/Objects -normal/armv7/main.d --serialize-diagnostics /Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos-i OS-debug/build/appQml/SimpleApp.build/Debug-iphoneos/SimpleApp.build/Objects -normal/armv7/main.dia -c /Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos-i OS-debug/source/appQml/main.cpp -o /Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos-i OS-debug/build/appQml/SimpleApp.build/Debug-iphoneos/SimpleApp.build/Objects -normal/armv7/main.o clang: error: cannot specify -o when generating multiple output files ** BUILD FAILED ** The following build commands failed: CompileC /Users/nbuild/workspace/BuildSlave/jenkins/workspace/SimpleiPhoneApp-macos-i OS-debug/build/appQml/SimpleApp.build/Debug-iphoneos/SimpleApp.build/Objects -normal/armv7/main.o appQml/main.cpp normal armv7 c++ com.apple.compilers.llvm.clang.1_0.compiler (1 failure) -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Wed May 11 15:30:31 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 11 May 2016 15:30:31 -0400 Subject: [CMake] [cmake-developers] [PATCH] FindBoost does not detect absence of header file In-Reply-To: <4aefef251aba00f394a08213b349f1fd@codelibre.net> References: <570CDA7E.3010403@fz-juelich.de> <4aefef251aba00f394a08213b349f1fd@codelibre.net> Message-ID: I guess it doesn't really matter but for the libraries that don't have a single include header, should you be using these instead: - container/container_fwd.hpp - exception/all.hpp - filesystem.hpp - math_fwd.hpp (instead of math/quaternion.hpp) - system/config.hpp - type_erasure/config.hpp They're "common" or "central" headers for the libraries instead of specific headers. - Chuck On Wed, May 11, 2016 at 10:38 AM, wrote: > On 2016-04-12 11:22, Joachim Wuttke wrote: > >> FindBoost does not detect absence of header files. >> >> To be specific: Run the following under cmake version 3.5.1: >> >> set(Boost_NO_BOOST_CMAKE ON) # prevent shortcut >> set(Boost_USE_STATIC_LIBS OFF) >> set(Boost_USE_MULTITHREADED ON) >> set(Boost_USE_STATIC_RUNTIME OFF) >> add_definitions(-DBOOST_ALL_DYN_LINK) # line is needed for MSVC >> #add_definitions(-DBOOST_LIB_DIAGNOSTIC) # shows during compilation >> auto-linked libraries >> if(WIN32) >> set(boost_libraries_required date_time chrono program_options zlib >> bzip2 iostreams system filesystem regex thread) >> else() >> set(boost_libraries_required date_time chrono program_options >> iostreams system filesystem regex thread) >> endif() >> find_package(Boost 1.48.0 COMPONENTS ${boost_libraries_required} REQUIRED) >> message(STATUS "--> Boost_INCLUDE_DIRS: ${Boost_INCLUDE_DIRS}") >> message(STATUS " Boost_LIBRARY_DIRS: ${Boost_LIBRARY_DIRS}") >> message(STATUS " Boost_LIBRARIES: ${Boost_LIBRARIES}") >> >> It will pass, even if files like /usr/include/boost/date_time.hpp &c are >> removed >> from the system. >> > > Attached is a patch to add this extra checking. > > For each library component, there is a corresponding header which has been > present in all versions of boost to date which provide the library; the > list used to validate this is also attached. I have also validated that > each component works with find_package for Boost 1.58 and 1.60. > > If your system contains both the libraries and headers, then FindBoost > will behave exactly as before. But if you have the libraries without the > headers, FindBoost will now fail, rather than passing and then having the > build subsequently fail when it tries to use the nonexistent headers. So > it's essentially adding an additional header check per component, which > will identify situations where the user has an incomplete Boost > installation e.g. no all the -dev packages are installed. > > I can merge this into next for testing, but if anyone wanted to have an > initial play with it to verify that it's still functional and that the > approach is sound, I can wait off for now. > > > Regards, > Roger > -- > > 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 rleigh at codelibre.net Wed May 11 15:43:41 2016 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Wed, 11 May 2016 19:43:41 +0000 Subject: [CMake] [cmake-developers] [PATCH] FindBoost does not detect absence of header file In-Reply-To: References: <570CDA7E.3010403@fz-juelich.de> <4aefef251aba00f394a08213b349f1fd@codelibre.net> Message-ID: <5490afda167724ed827b9fd6aa75df32@codelibre.net> On 2016-05-11 19:30, Chuck Atkins wrote: > I guess it doesn't really matter but for the libraries that don't have > a single include header, should you be using these instead: > > * container/container_fwd.hpp > * exception/all.hpp > * filesystem.hpp > * math_fwd.hpp (instead of math/quaternion.hpp) > * system/config.hpp > * type_erasure/config.hpp > > They're "common" or "central" headers for the libraries instead of > specific headers. Thanks for taking a look and making the suggestions. I'll certainly update some of these. However, note that for some of these (e.g. exception, filesystem), that common header didn't exist in earlier releases and so was deliberately not used; in these cases I picked a common header which is present in *all* Boost releases, back to 1.33 except for components which were introduced in later releases. filesystem.hpp was introduced after the initial release with filesytem, likewise exception/all.hpp for exception. Regards, Roger From gjasny at googlemail.com Wed May 11 16:48:33 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 11 May 2016 22:48:33 +0200 Subject: [CMake] [cmake-developers] CLang error when building iOS bundle In-Reply-To: <002601d1abba$7323fc60$596bf520$@gmx.at> References: <002601d1abba$7323fc60$596bf520$@gmx.at> Message-ID: <57339AA1.1030701@googlemail.com> Hello, On 11/05/16 21:22, Roman W?ger wrote: > I got the following error when linking the iOS bundle: > > clang: error: cannot specify -o when generating multiple output files > > I didn?t found anything about the error in the internet, so maybe someone > has already solved such error? > > Does any one have a hint what could be wrong? I cannot see any suspicious things, either (besides that -arch armv7 is listed twice). I would suggest you create a new user on the machine and try there. Or you could remove ~/Library/Developer/Xcode/DerivedData first. Thanks, Gregor From gjasny at googlemail.com Wed May 11 16:52:26 2016 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 11 May 2016 22:52:26 +0200 Subject: [CMake] Cannot include third-party Framework headers directories as system directories in XCode for avoiding their warning In-Reply-To: References: Message-ID: <57339B8A.6070406@googlemail.com> Hello, On 11/05/16 09:25, Attila Krasznahorkay wrote: > I'm a bit surprised by this. I had to explicitly tell CMake not to treat includes coming from imported targets as system includes. Using this variable: > > https://cmake.org/cmake/help/v3.0/variable/CMAKE_NO_SYSTEM_FROM_IMPORTED.html > https://cmake.org/cmake/help/v3.0/prop_tgt/NO_SYSTEM_FROM_IMPORTED.html > > So I think this is in general a MacOS specific issue. I remember reading about such issues a while ago. That CMake would not recognise that MacOS X's clang would accept the -isystem argument out of the box. This is a known bug: http://public.kitware.com/Bug/view.php?id=15687 Please look there for possible work-arounds. Thanks, Gregor From tiagomacarios at gmail.com Wed May 11 18:00:12 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Wed, 11 May 2016 15:00:12 -0700 Subject: [CMake] AUTOMOC with files on different folders In-Reply-To: <2AFF0B96-301A-49F5-A154-37C210D7760F@gmail.com> References: <2AFF0B96-301A-49F5-A154-37C210D7760F@gmail.com> Message-ID: Hi Attila, Thank you for your help. You are right, if I apply the following modifications it works indeed: set( proj_HEADER include/a.h ) add_library(proj SHARED ${proj_SOURCE} ${proj_HEADER}) But now I got a second question. Why is adding the header files necessary? (Sorry the possibly naive question) I thought that adding the header files to the target was an anti-pattern ( http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/ ). Is it related to moc generating header files during the build? If so why is it not a problem when everything is on the same folder? Tiago On Wed, May 11, 2016 at 12:48 AM, Attila Krasznahorkay < attila.krasznahorkay at gmail.com> wrote: > Hi Tiago, > > This is one of those cases when you have to declare the header files to > add_library(...) as well. In that case AUTOMOC should work fine. At least > it does for us, in a very similar setup. > > > http://acode-browser.usatlas.bnl.gov/lxr/source/atlas/graphics/VP1/VP1Gui/CMakeLists.txt > > Cheers, > Attila > > > On 11 May 2016, at 07:14, Tiago Macarios > wrote: > > > > Hi, > > > > I am having trouble using AUTOMOC with a project where header files and > source files are in different sub-directories. I wrote a detailed stack > overflow question here: > > > http://stackoverflow.com/questions/37151163/cmake-automoc-with-files-on-different-folders > > and would really appreciate if someone could give me a couple of ideas > to try out. > > > > Thanks, > > Tiago > > -- > > > > 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 post at hendrik-sattler.de Wed May 11 23:20:58 2016 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Thu, 12 May 2016 05:20:58 +0200 Subject: [CMake] AUTOMOC with files on different folders In-Reply-To: References: <2AFF0B96-301A-49F5-A154-37C210D7760F@gmail.com> Message-ID: Am 12. Mai 2016 00:00:12 MESZ, schrieb Tiago Macarios : >Hi Attila, > >Thank you for your help. You are right, if I apply the following >modifications it works indeed: > >set( proj_HEADER > include/a.h >) > >add_library(proj SHARED ${proj_SOURCE} ${proj_HEADER}) > >But now I got a second question. Why is adding the header files >necessary? >(Sorry the possibly naive question) > >I thought that adding the header files to the target was an >anti-pattern ( >http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/ >). Is it related to moc generating header files during the build? If so >why >is it not a problem when everything is on the same folder? That same page has a Errata section at the end. -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From attila.krasznahorkay at gmail.com Thu May 12 02:23:40 2016 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Thu, 12 May 2016 08:23:40 +0200 Subject: [CMake] AUTOMOC with files on different folders In-Reply-To: References: <2AFF0B96-301A-49F5-A154-37C210D7760F@gmail.com> Message-ID: <20D7131F-DC81-4155-B96C-06BF2EA2C164@gmail.com> Hi Tiago, Indeed, that page is quite a bit misleading. And it seems to be "liked" by Google a lot, as most people come across it. (I also found it myself when looking for CMake documentation early on.) In general, listing all source files belonging to a library/executable, even the ones that are not compiled, is a good habit. As it makes the generated VS and Xcode projects much nicer to use. I didn't look at the internals of the Qt CMake code. I just realised this behaviour while trying to make our own code work. (It's an intuitive behaviour, so it wasn't too hard to figure out.) I guess the code has some fallback to search for headers in the same place as their corresponding source file. Which can make the project still work without declaring the header files, as long as they are in the same directory with the source files. I imagine that doing something more complicated to look for the headers would not be so easy. (I can't even think of a reliable way of doing it myself. You can't just rely on the include paths of your component, as that would introduce a lot of possible problems.) All in all, I just accepted this behaviour as-is. Cheers, Attila > On 12 May 2016, at 05:20, Hendrik Sattler wrote: > > > > Am 12. Mai 2016 00:00:12 MESZ, schrieb Tiago Macarios : >> Hi Attila, >> >> Thank you for your help. You are right, if I apply the following >> modifications it works indeed: >> >> set( proj_HEADER >> include/a.h >> ) >> >> add_library(proj SHARED ${proj_SOURCE} ${proj_HEADER}) >> >> But now I got a second question. Why is adding the header files >> necessary? >> (Sorry the possibly naive question) >> >> I thought that adding the header files to the target was an >> anti-pattern ( >> http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/ >> ). Is it related to moc generating header files during the build? If so >> why >> is it not a problem when everything is on the same folder? > > That same page has a Errata section at the end. > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From roman.wueger at gmx.at Thu May 12 03:13:06 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Thu, 12 May 2016 09:13:06 +0200 Subject: [CMake] CPack and PackageMaker In-Reply-To: <756640448.85837370.1459818731796.JavaMail.zimbra@elemtech.com> References: <000f4242.47dd4f8b0abb6704@dirac.se> <9A894BB6-8BC9-4092-8052-B83C022EB97D@gmx.at> <756640448.85837370.1459818731796.JavaMail.zimbra@elemtech.com> Message-ID: <2AD2DF5D-FE7E-4B0D-8846-BA8496B7B3C6@gmx.at> I think it is ok for the most of the use cases. But what I miss are the signing options: e.g: productbuild --component "FULLPATH_TO_OUTPUTDIR" /Applications --sign "DEVELOPER_CERTIFICATE" --product ".../Info.plist" MyPackage.pkg Best regards Roman > Am 05.04.2016 um 03:12 schrieb clinton at elemtech.com: > > Hi, > > I have updated the patch I sent before and you can find some new code here: > https://github.com/clintonstimpson/CMake/commits/productbuild > > To help, perhaps you can review and test it. > Or help in other ways you think it needs. > > I have done minimal testing. This includes making sure CMake's test suite passes with this generator. > And running those generated pkg files manually to test them. > > Perhaps after a couple reviews, we can start thinking about merging into CMake. > > Thanks, > Clint > > > ----- On Dec 21, 2015, at 11:56 PM, Roman W?ger wrote: > Is there anything I can do to support? > > Best regards > > Am 11.12.2015 um 20:17 schrieb robert.bielik : > > Dear Clint, > > Thank you! Will certainly start with that as a base :) > > Regards > /R > > ------ Ursprungligt meddelande------ > Fr?n: > Datum: fre, 11 dec 2015 20:12 > Till: Robert Bielik; > Kopia: Attila Krasznahorkay;cmake; > ?mne:Re: [CMake] CPack and PackageMaker > > If you are interested, attached is some code I started a couple years ago but never finished, nor did I do much testing. > Perhaps that'll help, or maybe you'll find a better way. > > Clint > > ----- On Dec 11, 2015, at 9:50 AM, Robert Bielik robert.bielik at dirac.se wrote: > > > Dear Attila, > > > > Ok, been struggling getting an installation package to work with the > > pkgbuild/productbild tools, so I think I got the gist of what needs to > > be done, at least to get something going :) > > > > Regards > > /R > > > > Den 2015-12-11 kl. 17:47, skrev Attila Krasznahorkay: > >> Hi Robert, > >> > >> I'm afraid that the sad situation is that nobody has done this yet, or is > >> working on it at the moment. > >> > >> I'm absolutely sure that if you can help with this by any amount, that will be > >> most welcome by the CMake developers. It will certainly be most welcome by me, > >> as I've been disappointed by the lack of this support as well. (But > >> unfortunately can't spare the time to help out in writing this CPack > >> generator.) > >> > >> Cheers, > >> Attila > >> > >>> On 11 Dec 2015, at 17:44, Robert Bielik wrote: > >>> > >>> Really ? No one ? :) > >>> > >>> So it's ok to go ahead and start create a new one ? ;) > >>> > >>> Rgds, > >>> /R > >>> > >>> Den 2015-12-09 kl. 16:56, skrev Robert Bielik: > >>>> Mac OSX: > >>>> > >>>> Since PackageMaker has been deprecated by Apple, the new tools to use are > >>>> pkgbuild [1] and productbuild [2]. > >>>> > >>>> Simple question: Is there any work being done by the CMake community on a new OS > >>>> X CPack backend to support the above tools ? > >>>> > >>>> Regards > >>>> /Robert > >>>> [1] > >>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html > >>>> [2] > >>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.html > >>>> > >>> -- > >>> > >>> Powered by www.kitware.com > >>> > >>> Please keep messages on-topic and check the CMake FAQ at: > >>> http://www.cmake.org/Wiki/CMake_FAQ > >>> > >>> Kitware offers various services to support the CMake community. For more > >>> information on each offering, please visit: > >>> > >>> CMake Support: http://cmake.org/cmake/help/support.html > >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >>> CMake Training Courses: http://cmake.org/cmake/help/training.html > >>> > >>> Visit other Kitware open-source projects at > >>> http://www.kitware.com/opensource/opensource.html > >>> > >>> Follow this link to subscribe/unsubscribe: > >>> http://public.kitware.com/mailman/listinfo/cmake > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > -- > > 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 patrick.boettcher at posteo.de Thu May 12 09:19:09 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Thu, 12 May 2016 15:19:09 +0200 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: References: <20160510075948.1f445585@posteo.de> <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> <20160511071355.7209ed8a@vdr> Message-ID: <20160512151909.6f263b8c@posteo.de> On Wed, 11 May 2016 21:58:34 +1000 Craig Scott wrote: [..] > If you were paying careful attention, you would have noticed that > when A links in B as PRIVATE, the include directories of B never > propagate to something linking to A, but if A is a static library, > then the *linking* of B behaves as though the relationship was > PUBLIC. This PRIVATE-becomes-PUBLIC behaviour for static libraries > only applies to the *linking*, not to the other dependencies > (compiler options/flags and include search paths). The upshot of all > this is that if you select PRIVATE, PUBLIC or INTERFACE based on the > explanations in the dot points above, then CMake will ensure > dependencies propagate through to where they are required, regardless > of whether libraries are static or shared. This does, of course, rely > on you the developer not missing any dependencies or specifying the > wrong PRIVATE/PUBLIC/INTERFACE relationship. Thank you for you long explanation. It was exactly my understanding. So cmake 3.5.0 has a bug then because I don't see the behavior you describe. Have you seen my example I sent in my first mail? http://public.kitware.com/pipermail/cmake/2016-May/063382.html Include-dirs from B are propagated to C which links to A which itself linked privately to B. Should I file a bug? regards, -- Patrick. From patrick.boettcher at posteo.de Thu May 12 09:59:53 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Thu, 12 May 2016 15:59:53 +0200 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: References: <20160510075948.1f445585@posteo.de> <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> <20160511071355.7209ed8a@vdr> <20160512151909.6f263b8c@posteo.de> Message-ID: <20160512155953.06b84751@posteo.de> On Thu, 12 May 2016 08:47:33 -0500 iosif neitzke wrote: > My reading of your examples: > > exe1 gets linked to lib2, and lib2/bin is included. exe1 probably > won't link ultimately because lib2 may need symbols from lib1. > Depends on the structure of the C code between lib2 and lib1. See > John Lakos for further information on that. It links - because it is a STATIC library - so propagated even though it's PRIVATE. My problem is just the include-dir of lib1 (/tmp) which should _not_ be propagated to exe1, but it is propagated. regards, -- Patrick. From iosif.neitzke+cmake at gmail.com Thu May 12 09:47:33 2016 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Thu, 12 May 2016 08:47:33 -0500 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: <20160512151909.6f263b8c@posteo.de> References: <20160510075948.1f445585@posteo.de> <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> <20160511071355.7209ed8a@vdr> <20160512151909.6f263b8c@posteo.de> Message-ID: My reading of your examples: exe1 gets linked to lib2, and lib2/bin is included. exe1 probably won't link ultimately because lib2 may need symbols from lib1. Depends on the structure of the C code between lib2 and lib1. See John Lakos for further information on that. exe2 gets linked to lib3, and gets lib3/bin included because lib3 has PUBLIC in its own target_include_directories command. Because exe2 gets lib3, it also gets lib1 and lib1/tmp. On Thu, May 12, 2016 at 8:19 AM, Patrick Boettcher wrote: > On Wed, 11 May 2016 21:58:34 +1000 > Craig Scott wrote: > > [..] >> If you were paying careful attention, you would have noticed that >> when A links in B as PRIVATE, the include directories of B never >> propagate to something linking to A, but if A is a static library, >> then the *linking* of B behaves as though the relationship was >> PUBLIC. This PRIVATE-becomes-PUBLIC behaviour for static libraries >> only applies to the *linking*, not to the other dependencies >> (compiler options/flags and include search paths). The upshot of all >> this is that if you select PRIVATE, PUBLIC or INTERFACE based on the >> explanations in the dot points above, then CMake will ensure >> dependencies propagate through to where they are required, regardless >> of whether libraries are static or shared. This does, of course, rely >> on you the developer not missing any dependencies or specifying the >> wrong PRIVATE/PUBLIC/INTERFACE relationship. > > Thank you for you long explanation. It was exactly my understanding. > > So cmake 3.5.0 has a bug then because I don't see the behavior you > describe. Have you seen my example I sent in my first mail? > > http://public.kitware.com/pipermail/cmake/2016-May/063382.html > > Include-dirs from B are propagated to C which links to A which itself > linked privately to B. > > Should I file a bug? > > regards, > -- > Patrick. > > > > > > > > From patrick.boettcher at posteo.de Thu May 12 10:10:58 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Thu, 12 May 2016 16:10:58 +0200 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: References: <20160510075948.1f445585@posteo.de> <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> <20160511071355.7209ed8a@vdr> <20160512151909.6f263b8c@posteo.de> <20160512155953.06b84751@posteo.de> Message-ID: <20160512161058.05267640@posteo.de> On Thu, 12 May 2016 09:04:10 -0500 iosif neitzke wrote: > target_include_directories(lib1 INTERFACE /tmp) means /tmp is > propagated with lib1, but not used to build lib1. I know. Could you elaborate how this is related with lib3 PRIVATEly linking to lib1? regards, -- Patrick. From iosif.neitzke+cmake at gmail.com Thu May 12 10:04:10 2016 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Thu, 12 May 2016 09:04:10 -0500 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: <20160512155953.06b84751@posteo.de> References: <20160510075948.1f445585@posteo.de> <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> <20160511071355.7209ed8a@vdr> <20160512151909.6f263b8c@posteo.de> <20160512155953.06b84751@posteo.de> Message-ID: target_include_directories(lib1 INTERFACE /tmp) means /tmp is propagated with lib1, but not used to build lib1. "The INTERFACE, PUBLIC and PRIVATE keywords are required to specify the scope of the following arguments. PRIVATE and PUBLIC items will populate the INCLUDE_DIRECTORIES property of . PUBLIC and INTERFACE items will populate the INTERFACE_INCLUDE_DIRECTORIES property of ." https://cmake.org/cmake/help/v3.5/command/target_include_directories.html On Thu, May 12, 2016 at 8:59 AM, Patrick Boettcher wrote: > On Thu, 12 May 2016 08:47:33 -0500 > iosif neitzke wrote: > >> My reading of your examples: >> >> exe1 gets linked to lib2, and lib2/bin is included. exe1 probably >> won't link ultimately because lib2 may need symbols from lib1. >> Depends on the structure of the C code between lib2 and lib1. See >> John Lakos for further information on that. > > It links - because it is a STATIC library - so propagated even though > it's PRIVATE. > > My problem is just the include-dir of lib1 (/tmp) which should _not_ be > propagated to exe1, but it is propagated. > > regards, > -- > Patrick. From patrick.boettcher at posteo.de Thu May 12 10:26:49 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Thu, 12 May 2016 16:26:49 +0200 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: References: <20160510075948.1f445585@posteo.de> <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> <20160511071355.7209ed8a@vdr> <20160512151909.6f263b8c@posteo.de> <20160512155953.06b84751@posteo.de> <20160512161058.05267640@posteo.de> Message-ID: <20160512162649.150bb0d6@posteo.de> On Thu, 12 May 2016 09:20:10 -0500 iosif neitzke wrote: > I'm sorry, I'm not sure I understand. In your example, there is > target_link_libraries(lib3 PUBLIC lib1). It looks like lib2 has > target_link_libraries(lib2 PRIVATE lib1). Yes. That is correct. When building the code for lib2 and lib3 the include-path of lib1 is provided (as expected). Then when building exe1 (links to lib2) and exe2 (links to lib3) the lib1's include-path is present in both cases. Whereas it should not be present with exe1, at least that is my understanding. -- Patrick. From iosif.neitzke+cmake at gmail.com Thu May 12 10:30:39 2016 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Thu, 12 May 2016 09:30:39 -0500 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: <20160512162649.150bb0d6@posteo.de> References: <20160510075948.1f445585@posteo.de> <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> <20160511071355.7209ed8a@vdr> <20160512151909.6f263b8c@posteo.de> <20160512155953.06b84751@posteo.de> <20160512161058.05267640@posteo.de> <20160512162649.150bb0d6@posteo.de> Message-ID: I guess the key is static libraries don't exactly adhere to the rules of PUBLIC or PRIVATE, so you end up with a library that CMake passes along with a populated INTERFACE_INCLUDE_DIRECTORIES, and so exe1 uses it because it is there? Not sure how it is supposed to work at this point. On Thu, May 12, 2016 at 9:26 AM, Patrick Boettcher wrote: > On Thu, 12 May 2016 09:20:10 -0500 > iosif neitzke wrote: > >> I'm sorry, I'm not sure I understand. In your example, there is >> target_link_libraries(lib3 PUBLIC lib1). It looks like lib2 has >> target_link_libraries(lib2 PRIVATE lib1). > > Yes. That is correct. > > When building the code for lib2 and lib3 the include-path of lib1 is > provided (as expected). > > Then when building exe1 (links to lib2) and exe2 (links to lib3) the > lib1's include-path is present in both cases. > > Whereas it should not be present with exe1, at least that is my > understanding. > > -- > Patrick. From tiagomacarios at gmail.com Thu May 12 10:43:49 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Thu, 12 May 2016 07:43:49 -0700 Subject: [CMake] AUTOMOC with files on different folders In-Reply-To: <20D7131F-DC81-4155-B96C-06BF2EA2C164@gmail.com> References: <2AFF0B96-301A-49F5-A154-37C210D7760F@gmail.com> <20D7131F-DC81-4155-B96C-06BF2EA2C164@gmail.com> Message-ID: Thanks Attila, really appreciate your help. On Wed, May 11, 2016 at 11:23 PM, Attila Krasznahorkay < attila.krasznahorkay at gmail.com> wrote: > Hi Tiago, > > Indeed, that page is quite a bit misleading. And it seems to be "liked" by > Google a lot, as most people come across it. (I also found it myself when > looking for CMake documentation early on.) > > In general, listing all source files belonging to a library/executable, > even the ones that are not compiled, is a good habit. As it makes the > generated VS and Xcode projects much nicer to use. > > I didn't look at the internals of the Qt CMake code. I just realised this > behaviour while trying to make our own code work. (It's an intuitive > behaviour, so it wasn't too hard to figure out.) I guess the code has some > fallback to search for headers in the same place as their corresponding > source file. Which can make the project still work without declaring the > header files, as long as they are in the same directory with the source > files. I imagine that doing something more complicated to look for the > headers would not be so easy. (I can't even think of a reliable way of > doing it myself. You can't just rely on the include paths of your > component, as that would introduce a lot of possible problems.) > > All in all, I just accepted this behaviour as-is. > > Cheers, > Attila > > > On 12 May 2016, at 05:20, Hendrik Sattler > wrote: > > > > > > > > Am 12. Mai 2016 00:00:12 MESZ, schrieb Tiago Macarios < > tiagomacarios at gmail.com>: > >> Hi Attila, > >> > >> Thank you for your help. You are right, if I apply the following > >> modifications it works indeed: > >> > >> set( proj_HEADER > >> include/a.h > >> ) > >> > >> add_library(proj SHARED ${proj_SOURCE} ${proj_HEADER}) > >> > >> But now I got a second question. Why is adding the header files > >> necessary? > >> (Sorry the possibly naive question) > >> > >> I thought that adding the header files to the target was an > >> anti-pattern ( > >> > http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/ > >> ). Is it related to moc generating header files during the build? If so > >> why > >> is it not a problem when everything is on the same folder? > > > > That same page has a Errata section at the end. > > > > -- > > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > > -- > > > > 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 iosif.neitzke+cmake at gmail.com Thu May 12 10:20:10 2016 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Thu, 12 May 2016 09:20:10 -0500 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: <20160512161058.05267640@posteo.de> References: <20160510075948.1f445585@posteo.de> <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> <20160511071355.7209ed8a@vdr> <20160512151909.6f263b8c@posteo.de> <20160512155953.06b84751@posteo.de> <20160512161058.05267640@posteo.de> Message-ID: I'm sorry, I'm not sure I understand. In your example, there is target_link_libraries(lib3 PUBLIC lib1). It looks like lib2 has target_link_libraries(lib2 PRIVATE lib1). http://public.kitware.com/pipermail/cmake/2016-May/063382.html On Thu, May 12, 2016 at 9:10 AM, Patrick Boettcher wrote: > On Thu, 12 May 2016 09:04:10 -0500 > iosif neitzke wrote: > >> target_include_directories(lib1 INTERFACE /tmp) means /tmp is >> propagated with lib1, but not used to build lib1. > > I know. Could you elaborate how this is related with lib3 PRIVATEly linking to > lib1? > > regards, > -- > Patrick. From mike.jackson at bluequartz.net Thu May 12 12:09:42 2016 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Thu, 12 May 2016 12:09:42 -0400 Subject: [CMake] Time Profile our CMake codes Message-ID: <5734AAC6.8000201@bluequartz.net> Is there a way to "time profile" our cmake codes? We have noticed lately that running cmake on our project lately has taken a large uptick in time and we are trying to figure out where the newly added time is coming from. We do a lot of I/O writing temp files, comparing temp files to files that get replaced. We also have a fair number of external libraries that we look for (Boost, Eigen, ITK, VTK, Qt, Qwt, HDF5). If anyone has any ideas we would greatly appreciate it. Although the cmake time on OS X and Linux is not so bad, Windows is getting unbearably slow (even with Ninja/makefiles). Thanks -- Mike Jackson [mike.jackson at bluequartz.net] -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Thu May 12 14:37:06 2016 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Thu, 12 May 2016 14:37:06 -0400 Subject: [CMake] Time Profile our CMake codes In-Reply-To: References: <5734AAC6.8000201@bluequartz.net> Message-ID: <5734CD52.8030000@bluequartz.net> We do the File IO because we need to store lists of various directories for other subprojects and packaging schemes to use. When we first developed the CMake codes the "set_property" function was not really well developed. I am wondering if using global property lists are a better way to go for this. example: get_property(DREAM3DDocRoot GLOBAL PROPERTY DREAM3DDocRoot) -- Mike Jackson [mike.jackson at bluequartz.net] > Nicholas Braden > May 12, 2016 at 2:06 PM > I can't answer your question directly, but IIRC opening files on > Windows is many times more expensive than on other platforms - it > could be the temp file I/O you are doing. > > On Thu, May 12, 2016 at 11:09 AM, Michael Jackson > Michael Jackson > May 12, 2016 at 12:09 PM > Is there a way to "time profile" our cmake codes? We have noticed > lately that running cmake on our project lately has taken a large > uptick in time and we are trying to figure out where the newly added > time is coming from. We do a lot of I/O writing temp files, comparing > temp files to files that get replaced. We also have a fair number of > external libraries that we look for (Boost, Eigen, ITK, VTK, Qt, Qwt, > HDF5). If anyone has any ideas we would greatly appreciate it. > Although the cmake time on OS X and Linux is not so bad, Windows is > getting unbearably slow (even with Ninja/makefiles). > > Thanks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Thu May 12 17:06:32 2016 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 13 May 2016 07:06:32 +1000 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: References: <20160510075948.1f445585@posteo.de> <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> <20160511071355.7209ed8a@vdr> <20160512151909.6f263b8c@posteo.de> <20160512155953.06b84751@posteo.de> <20160512161058.05267640@posteo.de> <20160512162649.150bb0d6@posteo.de> Message-ID: Patrick, I suggest if you can reduce your problem down to a small, reproducible example, then file a bug. I did a test just now with CMake 3.5.2 and everything behaved as expected, including the header search path propagation, so maybe there's something unusual in your project which a simple case doesn't capture. Perhaps also try different generator types in case that results in something different (unlikely, but since you see different behaviour to me, give it a go). On Fri, May 13, 2016 at 12:30 AM, iosif neitzke < iosif.neitzke+cmake at gmail.com> wrote: > I guess the key is static libraries don't exactly adhere to the rules > of PUBLIC or PRIVATE, so you end up with a library that CMake passes > along with a populated INTERFACE_INCLUDE_DIRECTORIES, and so exe1 uses > it because it is there? Not sure how it is supposed to work at this point. > > On Thu, May 12, 2016 at 9:26 AM, Patrick Boettcher > wrote: > > On Thu, 12 May 2016 09:20:10 -0500 > > iosif neitzke wrote: > > > >> I'm sorry, I'm not sure I understand. In your example, there is > >> target_link_libraries(lib3 PUBLIC lib1). It looks like lib2 has > >> target_link_libraries(lib2 PRIVATE lib1). > > > > Yes. That is correct. > > > > When building the code for lib2 and lib3 the include-path of lib1 is > > provided (as expected). > > > > Then when building exe1 (links to lib2) and exe2 (links to lib3) the > > lib1's include-path is present in both cases. > > > > Whereas it should not be present with exe1, at least that is my > > understanding. > > > > -- > > Patrick. > -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Thu May 12 16:07:38 2016 From: scott at towel42.com (Scott Aron Bloom) Date: Thu, 12 May 2016 20:07:38 +0000 Subject: [CMake] Debug vs Release "install" area Message-ID: Looking for some advice. In order to make our Visual Studio debugging environment, as self-contained (and easy to use for the developers) as possible, we use developers must run an install. We also use the resulting release based Install for our packaging into our installer. We change the prefix variable CMAKE_INSTALL_PREFIX, to ${CMAKE_BINARY_DIR}/Install, as well as having a each application call a function that places a .user.vcxproj that sets the PATH appropriately. It really works great, except there is one caveat. VC++ has libraries that are debug vs release dependent, so if your debug build happens to pick up a release DLL (or vice versa) you can (will) be in trouble in random ways. Typically, when I change over, I simply delete the install, and re-install. Ideally, I would like to know is there any way to set the CMAKE_INSTALL_PREFIX variable separately for debug vs release? If so how? A second option, which I thought of... Is to generate a file "DEBUG.BUILD.TXT" and then at the START of the installation process, run a script for debug builds, that says if the file doesn't exist, delete everything and carry on. If running for a release install, if it DOES exist delete and carry on. Any thoughts on this? Thanks Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.boettcher at posteo.de Fri May 13 03:06:29 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Fri, 13 May 2016 09:06:29 +0200 Subject: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries In-Reply-To: References: <20160510075948.1f445585@posteo.de> <99EF762D-8275-4E47-B1EF-BA82E7E4CE7F@gmail.com> <20160511071355.7209ed8a@vdr> <20160512151909.6f263b8c@posteo.de> <20160512155953.06b84751@posteo.de> <20160512161058.05267640@posteo.de> <20160512162649.150bb0d6@posteo.de> Message-ID: <20160513090629.66f31e4a@posteo.de> On Fri, 13 May 2016 07:06:32 +1000 Craig Scott wrote: > Patrick, > > I suggest if you can reduce your problem down to a small, reproducible > example, then file a bug. I did a test just now with CMake 3.5.2 and > everything behaved as expected, including the header search path > propagation, so maybe there's something unusual in your project which > a simple case doesn't capture. Perhaps also try different generator > types in case that results in something different (unlikely, but > since you see different behaviour to me, give it a go). I filed a bug with a test-case reduced to 7 lines of cmake. I reproduced it with GNU Make and Ninja a generator. https://cmake.org/Bug/view.php?id=16102 I'm also reading some cmake-code, but haven't yet found where includes are inherited from linked targets. Currently looking at cmGeneratorTarget::GetIncludeDirectories() ... Thanks for your feedback. best regards, -- Patrick. From norulez at me.com Fri May 13 12:23:19 2016 From: norulez at me.com (NoRulez) Date: Fri, 13 May 2016 18:23:19 +0200 Subject: [CMake] [cmake-developers] CLang error when building iOS bundle In-Reply-To: <57339AA1.1030701@googlemail.com> References: <002601d1abba$7323fc60$596bf520$@gmx.at> <57339AA1.1030701@googlemail.com> Message-ID: <11247973-1580-401B-9722-E037362E23AE@me.com> I don't know why I get this error, but after I link against missing required frameworks (OpenGLES, AssetsLibrary and QuartzCore) the error is gone. Regards Roman > Am 11.05.2016 um 22:48 schrieb Gregor Jasny via CMake : > > Hello, > >> On 11/05/16 21:22, Roman W?ger wrote: >> I got the following error when linking the iOS bundle: >> >> clang: error: cannot specify -o when generating multiple output files >> >> I didn?t found anything about the error in the internet, so maybe someone >> has already solved such error? >> >> Does any one have a hint what could be wrong? > > I cannot see any suspicious things, either (besides that -arch armv7 is > listed twice). I would suggest you create a new user on the machine and > try there. Or you could remove ~/Library/Developer/Xcode/DerivedData first. > > Thanks, > Gregor > -- > > 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 dushistov at gmail.com Fri May 13 15:26:43 2016 From: dushistov at gmail.com (Evgeniy Dushistov) Date: Fri, 13 May 2016 22:26:43 +0300 Subject: [CMake] ctest + timeout -> coredump, how? Message-ID: Hi, I want to get coredump of test that was stopped by ctest because of timeout. I look at source code of cmake (kwsysProcessKill), and looks like there is no way to configure which signal number will be used to kill process. Am I right, and there is no way to force ctest to use signal that cause core dump? If so, is any replacement of ctest that can read ctest's format of files, so it can be easily integrated with cmake? From roman.wueger at gmx.at Fri May 13 16:43:29 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Fri, 13 May 2016 22:43:29 +0200 Subject: [CMake] Debug vs Release "install" area In-Reply-To: References: Message-ID: <432ED62D-E8DA-4575-838F-F92103561F9C@gmx.at> You could use conditional generator expressions e.g $ with a combination of add_custom_command stuff like "${CMAKE_COMMAND} -P yourscript.cmake " to handle the rest. Best Regards Roman > Am 12.05.2016 um 22:07 schrieb Scott Aron Bloom : > > Looking for some advice. > > In order to make our Visual Studio debugging environment, as self-contained (and easy to use for the developers) as possible, we use developers must run an install. We also use the resulting release based Install for our packaging into our installer. > > We change the prefix variable CMAKE_INSTALL_PREFIX, to ${CMAKE_BINARY_DIR}/Install, as well as having a each application call a function that places a .user.vcxproj that sets the PATH appropriately. > > It really works great, except there is one caveat. VC++ has libraries that are debug vs release dependent, so if your debug build happens to pick up a release DLL (or vice versa) you can (will) be in trouble in random ways. > > Typically, when I change over, I simply delete the install, and re-install. > > Ideally, I would like to know is there any way to set the CMAKE_INSTALL_PREFIX variable separately for debug vs release? If so how? > > A second option, which I thought of? > > Is to generate a file ?DEBUG.BUILD.TXT? and then at the START of the installation process, run a script for debug builds, that says if the file doesn?t exist, delete everything and carry on. If running for a release install, if it DOES exist delete and carry on. > > > Any thoughts on this? > > Thanks > > Scott > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri May 13 21:51:55 2016 From: d3ck0r at gmail.com (J Decker) Date: Fri, 13 May 2016 18:51:55 -0700 Subject: [CMake] Debug vs Release "install" area In-Reply-To: <432ED62D-E8DA-4575-838F-F92103561F9C@gmx.at> References: <432ED62D-E8DA-4575-838F-F92103561F9C@gmx.at> Message-ID: there is also BUILD_TYPE (not CMAKE_BUILD_TYPE, which is the initial condition) that often gets translated into. BUILD_TYPE seems to get set to the current building configuration. http://cmake.limitpoint.com/installing-multiple-build-types-in-cmake-generated-visual-studio-projects-2/ https://cmake.org/pipermail/cmake/2011-June/044851.html .... if(SUPPORTS_PARALLEL_BUILD_TYPE) >>> >>> CMAKE_INSTALL_CONFIG_NAME is set to the current configuration name >>> (DEbug, release, minsizerel) as chosen in the visual studio >>> environment.... so to choose which you build - you choose which you >>> build. >>> >>> It doesn't package multiple configurations at once into a single NSIS, >>> but it will package any single configuration. On Fri, May 13, 2016 at 1:43 PM, Roman W?ger wrote: > You could use conditional generator expressions e.g $ with a > combination of add_custom_command stuff like "${CMAKE_COMMAND} -P > yourscript.cmake " to handle the rest. > > Best Regards > Roman > > Am 12.05.2016 um 22:07 schrieb Scott Aron Bloom : > > Looking for some advice. > > > > In order to make our Visual Studio debugging environment, as self-contained > (and easy to use for the developers) as possible, we use developers must run > an install. We also use the resulting release based Install for our > packaging into our installer. > > > > We change the prefix variable CMAKE_INSTALL_PREFIX, to > ${CMAKE_BINARY_DIR}/Install, as well as having a each application call a > function that places a .user.vcxproj that sets the PATH appropriately. > > > > It really works great, except there is one caveat. VC++ has libraries that > are debug vs release dependent, so if your debug build happens to pick up a > release DLL (or vice versa) you can (will) be in trouble in random ways. > > > > Typically, when I change over, I simply delete the install, and re-install. > > > > Ideally, I would like to know is there any way to set the > CMAKE_INSTALL_PREFIX variable separately for debug vs release? If so how? > > > > A second option, which I thought of? > > > > Is to generate a file ?DEBUG.BUILD.TXT? and then at the START of the > installation process, run a script for debug builds, that says if the file > doesn?t exist, delete everything and carry on. If running for a release > install, if it DOES exist delete and carry on. > > > > > > Any thoughts on this? > > Thanks > > > Scott > > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > 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 irwin at beluga.phys.uvic.ca Fri May 13 22:02:58 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 13 May 2016 19:02:58 -0700 (PDT) Subject: [CMake] Debug vs Release "install" area In-Reply-To: References: Message-ID: On 2016-05-12 20:07-0000 Scott Aron Bloom wrote: > Looking for some advice. > > In order to make our Visual Studio debugging environment, as self-contained (and easy to use for the developers) as possible, we use developers must run an install. We also use the resulting release based Install for our packaging into our installer. > > We change the prefix variable CMAKE_INSTALL_PREFIX, to ${CMAKE_BINARY_DIR}/Install, as well as having a each application call a function that places a .user.vcxproj that sets the PATH appropriately. > > It really works great, except there is one caveat. VC++ has libraries that are debug vs release dependent, so if your debug build happens to pick up a release DLL (or vice versa) you can (will) be in trouble in random ways. > > Typically, when I change over, I simply delete the install, and re-install. > > Ideally, I would like to know is there any way to set the CMAKE_INSTALL_PREFIX variable separately for debug vs release? If so how? > > A second option, which I thought of... > > Is to generate a file "DEBUG.BUILD.TXT" and then at the START of the installation process, run a script for debug builds, that says if the file doesn't exist, delete everything and carry on. If running for a release install, if it DOES exist delete and carry on. > > > Any thoughts on this? Can't help you with a Visual studio environment, but for the "Unix Makefiles" generator (and presumably also for the "NMake Makefiles" generator) you typically set CMAKE_INSTALL_PREFIX to an initially empty install tree when you invoke the cmake command from an intially empty build tree. So you have complete control over the names you pick for both the build-tree and install-tree, and you typically choose unique names of those for each different build configuration (such as release or debug). I suspect it is also trivial to have separate sets of the combination of build tree + install tree name for each different type of build in a Visual Studios environment, but I cannot give you specific advice about how to find that "trivial" answer. :-) 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 d3ck0r at gmail.com Fri May 13 22:10:50 2016 From: d3ck0r at gmail.com (J Decker) Date: Fri, 13 May 2016 19:10:50 -0700 Subject: [CMake] Debug vs Release "install" area In-Reply-To: References: Message-ID: I meant to also add; when I first was porting my projects to cmake, I thought this was a thing I wanted to do also... turns out, it's just a lot easier to make 2 build trees and build one release and one debug and have the same output image exactly for both... then install one or the other for use with other projects.... (no renaming files and adding 'd', no extra subdirectories... bin/debug and bin/release... ) On Thu, May 12, 2016 at 1:07 PM, Scott Aron Bloom wrote: > Looking for some advice. > > > > In order to make our Visual Studio debugging environment, as self-contained > (and easy to use for the developers) as possible, we use developers must run > an install. We also use the resulting release based Install for our > packaging into our installer. > > > > We change the prefix variable CMAKE_INSTALL_PREFIX, to > ${CMAKE_BINARY_DIR}/Install, as well as having a each application call a > function that places a .user.vcxproj that sets the PATH appropriately. > > > > It really works great, except there is one caveat. VC++ has libraries that > are debug vs release dependent, so if your debug build happens to pick up a > release DLL (or vice versa) you can (will) be in trouble in random ways. > > > > Typically, when I change over, I simply delete the install, and re-install. > > > > Ideally, I would like to know is there any way to set the > CMAKE_INSTALL_PREFIX variable separately for debug vs release? If so how? > > > > A second option, which I thought of? > > > > Is to generate a file ?DEBUG.BUILD.TXT? and then at the START of the > installation process, run a script for debug builds, that says if the file > doesn?t exist, delete everything and carry on. If running for a release > install, if it DOES exist delete and carry on. > > > > > > Any thoughts on this? > > Thanks > > > Scott > > > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From ruslan_baratov at yahoo.com Sat May 14 07:20:21 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sat, 14 May 2016 14:20:21 +0300 Subject: [CMake] in source makefile / helper script that enables building out of source? In-Reply-To: References: Message-ID: On 11-May-16 16:58, Steve Lorimer wrote: > I've recently changed over from using boost-build > (http://www.boost.org/build/) to cmake. > > Boost build builds in-source. > > I've become quite used to building and searching etc from the source root > > ~/src $ b2 module > ~/src $ git grep foo > > > This work flow has been broken because I'm not using out of source builds > > ~/src/build $ make module > ~/src/build $ git grep... dang it! > ~/src/build $ cd .. > ~/src $ git grep foo > ~/src $ make modu... dang it! > ~/src $ cd build > ~/src/build $ make module > > I can't be the only one who wants to have the benefit of out of source > builds and be able to build from in-source. Will `-C` help? ~/src $ make -C build module or in cross-platform fashion: ~/src $ cmake --build build ~/src $ cmake --build build --target foo --config Debug Ruslo > > I imagine it would be relatively simple to create a makefile which > navigates to a known build directory (eg: build or debug or...), > executes make there, and then changes directory back to where it was > called from. > > Before I do just this, I thought it better to try leverage the open > source community - hence asking the question. > > Does anyone have a script or makefile which does just this? > > TIA > Steve > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Sat May 14 13:41:13 2016 From: scott at towel42.com (Scott Aron Bloom) Date: Sat, 14 May 2016 17:41:13 +0000 Subject: [CMake] Debug vs Release "install" area In-Reply-To: References: <432ED62D-E8DA-4575-838F-F92103561F9C@gmx.at> Message-ID: I was able to use the ${BUILD_TYPE} and the ${CMAKE_INSTALL_CONFIG_NAME} using a INSTALL( CODE Call. Thanks for all the help Scott -----Original Message----- From: J Decker [mailto:d3ck0r at gmail.com] Sent: Friday, May 13, 2016 6:52 PM To: Roman W?ger Cc: Scott Aron Bloom; cmake at cmake.org Subject: Re: [CMake] Debug vs Release "install" area there is also BUILD_TYPE (not CMAKE_BUILD_TYPE, which is the initial condition) that often gets translated into. BUILD_TYPE seems to get set to the current building configuration. http://cmake.limitpoint.com/installing-multiple-build-types-in-cmake-generated-visual-studio-projects-2/ https://cmake.org/pipermail/cmake/2011-June/044851.html .... if(SUPPORTS_PARALLEL_BUILD_TYPE) >>> >>> CMAKE_INSTALL_CONFIG_NAME is set to the current configuration name >>> (DEbug, release, minsizerel) as chosen in the visual studio >>> environment.... so to choose which you build - you choose which you >>> build. >>> >>> It doesn't package multiple configurations at once into a single >>> NSIS, but it will package any single configuration. On Fri, May 13, 2016 at 1:43 PM, Roman W?ger wrote: > You could use conditional generator expressions e.g $ with a > combination of add_custom_command stuff like "${CMAKE_COMMAND} -P > yourscript.cmake " to handle the rest. > > Best Regards > Roman > > Am 12.05.2016 um 22:07 schrieb Scott Aron Bloom : > > Looking for some advice. > > > > In order to make our Visual Studio debugging environment, as > self-contained (and easy to use for the developers) as possible, we > use developers must run an install. We also use the resulting release > based Install for our packaging into our installer. > > > > We change the prefix variable CMAKE_INSTALL_PREFIX, to > ${CMAKE_BINARY_DIR}/Install, as well as having a each application call > a function that places a .user.vcxproj that sets the PATH appropriately. > > > > It really works great, except there is one caveat. VC++ has libraries > that are debug vs release dependent, so if your debug build happens to > pick up a release DLL (or vice versa) you can (will) be in trouble in random ways. > > > > Typically, when I change over, I simply delete the install, and re-install. > > > > Ideally, I would like to know is there any way to set the > CMAKE_INSTALL_PREFIX variable separately for debug vs release? If so how? > > > > A second option, which I thought of? > > > > Is to generate a file ?DEBUG.BUILD.TXT? and then at the START of the > installation process, run a script for debug builds, that says if the > file doesn?t exist, delete everything and carry on. If running for a > release install, if it DOES exist delete and carry on. > > > > > > Any thoughts on this? > > Thanks > > > Scott > > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > 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 scott at towel42.com Sat May 14 14:08:53 2016 From: scott at towel42.com (Scott Aron Bloom) Date: Sat, 14 May 2016 18:08:53 +0000 Subject: [CMake] Debug vs Release "install" area References: <432ED62D-E8DA-4575-838F-F92103561F9C@gmx.at> Message-ID: Just for the archives.. if and when anyone has the same (or a similar) problem this, solved it for me.. INSTALL( CODE " MESSAGE( STATUS \"Making a \${CMAKE_INSTALL_CONFIG_NAME} install area\" ) IF(\"\${CMAKE_INSTALL_CONFIG_NAME}\" MATCHES \"^([Dd][Ee][Bb][Uu][Gg])$\") SET( CMAKE_INSTALL_PREFIX \${CMAKE_INSTALL_PREFIX}.debug ) ENDIF() MESSAGE( STATUS \"Installing to \${CMAKE_INSTALL_PREFIX}\" ) ") The Regex I used, came directly from code that was generated into the cmake_install.cmake file by install(FILES foo.txt DESTINATION . CONFIGURATIONS Debug ) Do I figured it was the best way to do it Scott -----Original Message----- From: Scott Aron Bloom Sent: Saturday, May 14, 2016 10:41 AM To: 'J Decker'; Roman W?ger Cc: cmake at cmake.org Subject: RE: [CMake] Debug vs Release "install" area I was able to use the ${BUILD_TYPE} and the ${CMAKE_INSTALL_CONFIG_NAME} using a INSTALL( CODE Call. Thanks for all the help Scott -----Original Message----- From: J Decker [mailto:d3ck0r at gmail.com] Sent: Friday, May 13, 2016 6:52 PM To: Roman W?ger Cc: Scott Aron Bloom; cmake at cmake.org Subject: Re: [CMake] Debug vs Release "install" area there is also BUILD_TYPE (not CMAKE_BUILD_TYPE, which is the initial condition) that often gets translated into. BUILD_TYPE seems to get set to the current building configuration. http://cmake.limitpoint.com/installing-multiple-build-types-in-cmake-generated-visual-studio-projects-2/ https://cmake.org/pipermail/cmake/2011-June/044851.html .... if(SUPPORTS_PARALLEL_BUILD_TYPE) >>> >>> CMAKE_INSTALL_CONFIG_NAME is set to the current configuration name >>> (DEbug, release, minsizerel) as chosen in the visual studio >>> environment.... so to choose which you build - you choose which you >>> build. >>> >>> It doesn't package multiple configurations at once into a single >>> NSIS, but it will package any single configuration. On Fri, May 13, 2016 at 1:43 PM, Roman W?ger wrote: > You could use conditional generator expressions e.g $ with a > combination of add_custom_command stuff like "${CMAKE_COMMAND} -P > yourscript.cmake " to handle the rest. > > Best Regards > Roman > > Am 12.05.2016 um 22:07 schrieb Scott Aron Bloom : > > Looking for some advice. > > > > In order to make our Visual Studio debugging environment, as > self-contained (and easy to use for the developers) as possible, we > use developers must run an install. We also use the resulting release > based Install for our packaging into our installer. > > > > We change the prefix variable CMAKE_INSTALL_PREFIX, to > ${CMAKE_BINARY_DIR}/Install, as well as having a each application call > a function that places a .user.vcxproj that sets the PATH appropriately. > > > > It really works great, except there is one caveat. VC++ has libraries > that are debug vs release dependent, so if your debug build happens to > pick up a release DLL (or vice versa) you can (will) be in trouble in random ways. > > > > Typically, when I change over, I simply delete the install, and re-install. > > > > Ideally, I would like to know is there any way to set the > CMAKE_INSTALL_PREFIX variable separately for debug vs release? If so how? > > > > A second option, which I thought of? > > > > Is to generate a file ?DEBUG.BUILD.TXT? and then at the START of the > installation process, run a script for debug builds, that says if the > file doesn?t exist, delete everything and carry on. If running for a > release install, if it DOES exist delete and carry on. > > > > > > Any thoughts on this? > > Thanks > > > Scott > > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > 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 manojr at ti.com Sun May 15 23:53:05 2016 From: manojr at ti.com (R, Manoj) Date: Mon, 16 May 2016 03:53:05 +0000 Subject: [CMake] CMAKE toolchain file for TI armcl compiler Message-ID: <5DA0BF7A1FCA064A97B178FC4B4610497309CFC2@DBDE04.ent.ti.com> Hi, I have been trying to build toolchain file for armcl compiler from TI.Attached is the the cmake toolchain file and makefile. I am not able to get my link step working even after trying changing options for like 2 days.Can you please help me analyse where I am going wrong. Regards [https://newoldstamp.com/editor/profilePictures/profile-aafdb6328626d8cd600d5eada210d956-161742.png] Manoj Rajashekaraiah Software Engineer, MCU Software Texas Instruments India Pvt Ltd p: 918025193189 m: 918861001840 e: manojr at ti.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2713 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Toolchain_ti-cgt-arm_5.2.7.cmake Type: application/octet-stream Size: 2741 bytes Desc: Toolchain_ti-cgt-arm_5.2.7.cmake URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MakeFile Type: application/octet-stream Size: 11140 bytes Desc: MakeFile URL: From manojr at ti.com Mon May 16 00:13:50 2016 From: manojr at ti.com (Manoj R) Date: Mon, 16 May 2016 04:13:50 +0000 (UTC) Subject: [CMake] how to really change CMake linker References: <8D1844181DA3E82-1D58-1F38A@webmail-vm030.sysops.aol.com> Message-ID: Mark Abraham writes: > > Hi David, > Thanks very much for your reply! That was extremely helpful, and will let several packages document a functional workflow for the future.On Tue, Aug 12, 2014 at 5:38 AM, David Cole wrote: > Unless it is overridden somewhere else along the way, the following is > used to create the link command line for a C++ executable: > ? ? (found in Modules/CMakeCXXInformation.cmake) > ? ? if(NOT CMAKE_CXX_LINK_EXECUTABLE) > ? ? ? set(CMAKE_CXX_LINK_EXECUTABLE > ? ? ? ? ?" ? > ?-o ") > ? ? endif() > As you can see, by default, the C++ compiler is used as a front end to > link C++ executables... > Similarly for other types of targets, there are > CMAKE_CXX_CREATE_SHARED_LIBRARY and CMAKE_CXX_CREATE_SHARED_MODULE. And > for other languages, there are CMAKE_${LANG}_CREATE_... variables too. > > > Ah, that explains one source of confusion. I read CMAKE_CXX_LINK_EXECUTABLE with LINK as an adjective - specify the executable that does linking - whereas the above use of CREATE makes clear that the sense of LINK is intended to be as a verb - specify how to create an executable. The docs did say that this variable specifies a rule, now that I know what to look for. > > > In order to use the linker you want, you would have to define a custom > CMAKE_CXX_LINK_EXECUTABLE that uses "" in its definition > of the linker command line. > > > Right. It's easy to assume that this would be the default behaviour for constructing linking command lines. It's probably too late to consider a change, but I hope the original reasoning works well somewhere! > > Mark > ? > > HTH, > David C. > > > I am setting this CMAKE_CXX_LINK_EXECUTABLE in one of my projects but the CMAKE is still taking compiler as the link executable SET(CMAKE_CXX_LINK_EXECUTABLE " ${CMAKE_C_FLAGS} -z -- map_file=.map --output_file= ${PLATFORM_CONFIG_L_FLAGS} ${CMD_SRCS} ${LIB}" CACHE STRING "linker executable") > > > From manojr at ti.com Mon May 16 00:09:48 2016 From: manojr at ti.com (Manoj R) Date: Mon, 16 May 2016 04:09:48 +0000 (UTC) Subject: [CMake] how to really change CMake linker References: <8D1844181DA3E82-1D58-1F38A@webmail-vm030.sysops.aol.com> Message-ID: Mark Abraham writes: > > Hi David, > Thanks very much for your reply! That was extremely helpful, and will let several packages document a functional workflow for the future.On Tue, Aug 12, 2014 at 5:38 AM, David Cole wrote: > Unless it is overridden somewhere else along the way, the following is > used to create the link command line for a C++ executable: > ? ? (found in Modules/CMakeCXXInformation.cmake) > ? ? if(NOT CMAKE_CXX_LINK_EXECUTABLE) > ? ? ? set(CMAKE_CXX_LINK_EXECUTABLE > ? ? ? ? ?" ? > ?-o ") > ? ? endif() > As you can see, by default, the C++ compiler is used as a front end to > link C++ executables... > Similarly for other types of targets, there are > CMAKE_CXX_CREATE_SHARED_LIBRARY and CMAKE_CXX_CREATE_SHARED_MODULE. And > for other languages, there are CMAKE_${LANG}_CREATE_... variables too. > > > Ah, that explains one source of confusion. I read CMAKE_CXX_LINK_EXECUTABLE with LINK as an adjective - specify the executable that does linking - whereas the above use of CREATE makes clear that the sense of LINK is intended to be as a verb - specify how to create an executable. The docs did say that this variable specifies a rule, now that I know what to look for. > > > In order to use the linker you want, you would have to define a custom > CMAKE_CXX_LINK_EXECUTABLE that uses "" in its definition > of the linker command line. > > > Right. It's easy to assume that this would be the default behaviour for constructing linking command lines. It's probably too late to consider a change, but I hope the original reasoning works well somewhere! > > Mark > ? > > HTH, > David C. > > > > > > From zcsd2012 at gmail.com Mon May 16 06:57:14 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Mon, 16 May 2016 03:57:14 -0700 (MST) Subject: [CMake] Linking CXX executable xxx :undefined reference to `stlp_std::cout' Message-ID: <1463396234390-7593473.post@n2.nabble.com> Hi all, I was trying to convert an existed c++ project to CMake. The existed worked well with makefile, and i have converted similar one successfully. but when i try to convert this one, some confusing errors occurred, as below? 18:22:10: Running steps for project encryption... 18:22:10: Starting: "/export/opt/cmake-3.2.2/bin/cmake" --build . --target all Linking CXX executable dist/Debug_64/GNU-Linux-x86/encryption CMakeFiles/encryption.dir/encryption.cc.o: In function `main': /export1/chao/nanos/nano_clean/nano_clean/src/encryption/encryption.cc:33: undefined reference to `stlp_std::cout' ... /export1/chao/nanos/nano_clean/nano_clean/lib/STLport/stlport/stl/_string.c:604: undefined reference to `stlp_std::__stl_throw_out_of_range(char const*)' ... (more detail at bottom of this mail) At first i think it can't find iostream, so i include iostream at /export1/chao/nanos/nano_clean/nano_clean/lib/STLport/stlport/ by using 'INCLUDE_DIRECTORIES', but i did not work. Could you please give me some advices? Best regards, Chao detail error messages: 18:22:10: Running steps for project encryption... 18:22:10: Starting: "/export/opt/cmake-3.2.2/bin/cmake" --build . --target all Linking CXX executable dist/Debug_64/GNU-Linux-x86/encryption CMakeFiles/encryption.dir/encryption.cc.o: In function `main': /export1/chao/nanos/nano_clean/nano_clean/src/encryption/encryption.cc:33: undefined reference to `stlp_std::cout' /export1/chao/nanos/nano_clean/nano_clean/src/encryption/encryption.cc:39: undefined reference to `stlp_std::cout' /export1/chao/nanos/nano_clean/nano_clean/src/encryption/encryption.cc:46: undefined reference to `stlp_std::cout' /export1/chao/nanos/nano_clean/nano_clean/src/encryption/encryption.cc:48: undefined reference to `stlp_std::cout' /export1/chao/nanos/nano_clean/nano_clean/src/encryption/encryption.cc:54: undefined reference to `stlp_std::cout' CMakeFiles/encryption.dir/encryption.cc.o:/export1/chao/nanos/nano_clean/nano_clean/src/encryption/encryption.cc:56: more undefined references to `stlp_std::cout' follow CMakeFiles/encryption.dir/encryption.cc.o: In function `stlp_std::ios_base::_M_check_exception_mask()': /export1/chao/nanos/nano_clean/nano_clean/lib/STLport/stlport/stl/_ios_base.h:191: undefined reference to `stlp_std::ios_base::_M_throw_failure()' CMakeFiles/encryption.dir/encryption.cc.o: In function `stlp_std::priv::_String_base >::_M_throw_out_of_range() const': /export1/chao/nanos/nano_clean/nano_clean/lib/STLport/stlport/stl/_string.c:604: undefined reference to `stlp_std::__stl_throw_out_of_range(char const*)' CMakeFiles/encryption.dir/encryption.cc.o: In function `stlp_std::priv::_String_base >::_M_throw_length_error() const': /export1/chao/nanos/nano_clean/nano_clean/lib/STLport/stlport/stl/_string.c:600: undefined reference to `stlp_std::__stl_throw_length_error(char const*)' CMakeFiles/encryption.dir/encryption.cc.o: In function `char* boost::detail::lcast_put_unsigned, unsigned int, char>(unsigned int, char*)': /export1/chao/nanos/nano_clean/nano_clean/lib/boost/1.49.0/boost/lexical_cast.hpp:561: undefined reference to `stlp_std::locale::locale()' /export1/chao/nanos/nano_clean/nano_clean/lib/boost/1.49.0/boost/lexical_cast.hpp:562: undefined reference to `stlp_std::locale::classic()' /export1/chao/nanos/nano_clean/nano_clean/lib/boost/1.49.0/boost/lexical_cast.hpp:562: undefined reference to `stlp_std::locale::operator!=(stlp_std::locale const&) const' /export1/chao/nanos/nano_clean/nano_clean/lib/boost/1.49.0/boost/lexical_cast.hpp:617: undefined reference to `stlp_std::locale::~locale()' /export1/chao/nanos/nano_clean/nano_clean/lib/boost/1.49.0/boost/lexical_cast.hpp:617: undefined reference to `stlp_std::locale::~locale()' CMakeFiles/encryption.dir/encryption.cc.o: In function `stlp_std::allocator::_M_allocate(unsigned long, unsigned long&)': /export1/chao/nanos/nano_clean/nano_clean/lib/STLport/stlport/stl/_alloc.h:348: undefined reference to `stlp_std::__malloc_alloc::allocate(unsigned long)' CMakeFiles/encryption.dir/encryption.cc.o: In function `stlp_std::numpunct* stlp_std::priv::_UseFacet >(stlp_std::locale const&, stlp_std::numpunct const*)': /export1/chao/nanos/nano_clean/nano_clean/lib/STLport/stlport/stl/_locale.h:349: undefined reference to `stlp_std::locale::_M_use_facet(stlp_std::locale::id const&) const' CMakeFiles/encryption.dir/encryption.cc.o: In function `stlp_std::locale::id& stlp_std::priv::_GetFacetId >(stlp_std::numpunct const*)': /export1/chao/nanos/nano_clean/nano_clean/lib/STLport/stlport/stl/_locale.h:325: undefined reference to `stlp_std::numpunct::id' collect2: error: ld returned 1 exit status gmake[2]: *** [dist/Debug_64/GNU-Linux-x86/encryption] Error 1 gmake[1]: *** [CMakeFiles/encryption.dir/all] Error 2 gmake: *** [all] Error 2 18:22:10: The process "/export/opt/cmake-3.2.2/bin/cmake" exited with code 2. Error while building/deploying project encryption (kit: kit-chao) When executing step "Make" 18:22:11: Elapsed time: 00:01. -- View this message in context: http://cmake.3232098.n2.nabble.com/Linking-CXX-executable-xxx-undefined-reference-to-stlp-std-cout-tp7593473.html Sent from the CMake mailing list archive at Nabble.com. From wafflecode at protonmail.com Tue May 17 01:49:20 2016 From: wafflecode at protonmail.com (TCW) Date: Tue, 17 May 2016 01:49:20 -0400 Subject: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? Message-ID: Hello all, On linux, what's the correct way to support building with several different C compilers, each with some extra compiler-specifc flags for Debug and Release modes? (Eventually I'll need to add Visual Studio on Windows too. ) For now, I'm following what's mentioned in the cmake FAQ and using CXX=/blah cmake, etc. (From: https://cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F) But this is getting quite cumbersome as I'm experimenting with different flags for each compiler, and I'd rather avoid polluting my fairly clean CMakeLists file with a bunch of if/else branches to set flags. In the cmake manual I see reference to a -DCMAKE_TOOLCHAIN_FILE option, but this seems designed for embedded cross-compile scenarios. (Is that right?) (From: https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html) Basically, I'd like to succinctly choose among a set of (slightly) customized compiler choices. For modern cmake usage what is the correct method? Can anybody point me to a well done example for a simple case like this? Thank you! tcw -------------- next part -------------- An HTML attachment was scrubbed... URL: From wafflecode at protonmail.com Tue May 17 01:49:20 2016 From: wafflecode at protonmail.com (TCW) Date: Tue, 17 May 2016 01:49:20 -0400 Subject: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? Message-ID: Hello all, On linux, what's the correct way to support building with several different C compilers, each with some extra compiler-specifc flags for Debug and Release modes? (Eventually I'll need to add Visual Studio on Windows too. ) For now, I'm following what's mentioned in the cmake FAQ and using CXX=/blah cmake, etc. (From: https://cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F) But this is getting quite cumbersome as I'm experimenting with different flags for each compiler, and I'd rather avoid polluting my fairly clean CMakeLists file with a bunch of if/else branches to set flags. In the cmake manual I see reference to a -DCMAKE_TOOLCHAIN_FILE option, but this seems designed for embedded cross-compile scenarios. (Is that right?) (From: https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html) Basically, I'd like to succinctly choose among a set of (slightly) customized compiler choices. For modern cmake usage what is the correct method? Can anybody point me to a well done example for a simple case like this? Thank you! tcw -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Tue May 17 09:47:13 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Tue, 17 May 2016 09:47:13 -0400 Subject: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? In-Reply-To: References: Message-ID: Hi TCW, A typical approach for this is in the top level CMakeLists.txt to have: include(CompilerFlags) And then you can isolate the detection and specialization logic in a separate CompilerFlags.cmake: if(CMAKE_COMPILER_IS_GNUC) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --gcc-options") elseif(CMAKE_C_COMPILER_ID MATCHES "Intel") set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --icc-options") elseif(CMAKE_C_COMPILER_ID MATCHES "PGI) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --pgcc-options") elseif(MSVC) if(MSVC_VERSION GREATER_THAN 1700) ... elseif(...) ... endif() endif() And then similarly for C++. - Chuck On Tue, May 17, 2016 at 1:49 AM, TCW via CMake wrote: > Hello all, > > On linux, what's the correct way to support building with several > different C compilers, each with some extra compiler-specifc flags for > Debug and Release modes? (Eventually I'll need to add Visual Studio on > Windows too. ) > > For now, I'm following what's mentioned in the cmake FAQ and using > CXX=/blah cmake, etc. > > (From: > https://cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F) > > But this is getting quite cumbersome as I'm experimenting with different > flags for each compiler, and I'd rather avoid polluting my fairly clean > CMakeLists file with a bunch of if/else branches to set flags. > > In the cmake manual I see reference to a -DCMAKE_TOOLCHAIN_FILE option, > but this seems designed for embedded cross-compile scenarios. (Is that > right?) > > (From: https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html) > > Basically, I'd like to succinctly choose among a set of (slightly) > customized compiler choices. > > For modern cmake usage what is the correct method? Can anybody point me > to a well done example for a simple case like this? > > Thank you! > tcw > > -- > > 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 smithbreannan at gmail.com Tue May 17 13:08:08 2016 From: smithbreannan at gmail.com (Breannan Smith) Date: Tue, 17 May 2016 13:08:08 -0400 Subject: [CMake] Xcode, -isystem, and qt5_use_modules Message-ID: When I generate a makefile project with CMake that calls qt5_use_modules, qt5_use_modules prepends all Qt5 includes with the -isystem flag. If I generate an Xcode project with the same CMakeLists.txt configuration, however, the -isystem flag is not prepended to includes when Xcode builds the project, leading to an explosion of warnings internal to Qt5. Is the intended behavior to *not* pass -isystem on to Xcode? Is there a workaround or some special step that one must take with qt5_use_modules and Xcode? Thank you for any tips! Best regards, Breannan Smith -------------- next part -------------- An HTML attachment was scrubbed... URL: From wafflecode at protonmail.com Tue May 17 13:21:03 2016 From: wafflecode at protonmail.com (TCW) Date: Tue, 17 May 2016 13:21:03 -0400 Subject: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? In-Reply-To: References: Message-ID: Hi Chuck, Interesting. The flat list is not so bad i guess. (As an include.) I was thinking that cmake might support some kind of hierarchical platform definition system like Qt's qmake. (Not that it's without foibles either.) On the compiler selection question I'm still wondering if normative cmake usage really is, for example: cmake -D CMAKE_C_COMPILER=/opt/path/to/icc -D CMAKE_CXX_COMPILER=/opt/path/to/icpc ../path/to/src That is would be as opposed to the much shorter (but purely imagineary): cmake --tools=intel_16.0 ../path/to/src or, cmake --tools=gcc_5.3 ../path/to/src or, cmake --tools=gcc_6.1 ../path/to/src Where "intel_16.0" and the like map to some locally defined path (and perhaps also flag) definitions. Do folks really use the long form above? (perhaps wrapping it in a shell script or the like?) As someone very to to cmake, I wonder if I'm missing some key insight in to normal cmake workflow, or if this kind of compiler selection is, in fact, rare enough to not be cleanly supported. Thank you, Waffle -------- Original Message -------- Subject: Re: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? Local Time: May 17, 2016 9:47 AM UTC Time: May 17, 2016 1:47 PM From: chuck.atkins at kitware.com To: wafflecode at protonmail.com CC: cmake at cmake.org Hi TCW, A typical approach for this is in the top level CMakeLists.txt to have: include(CompilerFlags) And then you can isolate the detection and specialization logic in a separate CompilerFlags.cmake: if(CMAKE_COMPILER_IS_GNUC) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --gcc-options") elseif(CMAKE_C_COMPILER_ID MATCHES "Intel") set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --icc-options") elseif(CMAKE_C_COMPILER_ID MATCHES "PGI) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --pgcc-options") elseif(MSVC) if(MSVC_VERSION GREATER_THAN 1700) ... elseif(...) ... endif() endif() And then similarly for C++. - Chuck On Tue, May 17, 2016 at 1:49 AM, TCW via CMake wrote: Hello all, On linux, what's the correct way to support building with several different C compilers, each with some extra compiler-specifc flags for Debug and Release modes? (Eventually I'll need to add Visual Studio on Windows too. ) For now, I'm following what's mentioned in the cmake FAQ and using CXX=/blah cmake, etc. (From: https://cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F) But this is getting quite cumbersome as I'm experimenting with different flags for each compiler, and I'd rather avoid polluting my fairly clean CMakeLists file with a bunch of if/else branches to set flags. In the cmake manual I see reference to a -DCMAKE_TOOLCHAIN_FILE option, but this seems designed for embedded cross-compile scenarios. (Is that right?) (From: https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html) Basically, I'd like to succinctly choose among a set of (slightly) customized compiler choices. For modern cmake usage what is the correct method? Can anybody point me to a well done example for a simple case like this? Thank you! tcw -- 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 tim.gallagher at gatech.edu Tue May 17 13:49:46 2016 From: tim.gallagher at gatech.edu (Gallagher, Timothy P) Date: Tue, 17 May 2016 17:49:46 +0000 Subject: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? In-Reply-To: References: , Message-ID: We do what Chuck showed inside our CMakeLists for different flags for each compiler. To answer your other question, I prefer to use the shorter form: > CC=icc FC=ifort CXX=icpc cmake /path/to/source which sets the CC, FC and CXX environment variables only for that ccmake command without changing them in my global environment (using bash shell, it may work in others also). Once CMake has set the compilers, it doesn't change them so future calls can just be > cmake ./ Usually when I have to do a lot of compiler jockeying, I set up the module system (common on HPC's to handle different software stacks) so I can just do something like: > module load intel-compilers > cmake /path/to/source > module swap intel-compilers gnu-compilers > cmake /path/to/source and so on. Tim ________________________________ From: CMake on behalf of TCW via CMake Sent: Tuesday, May 17, 2016 1:21 PM To: Chuck Atkins Cc: cmake at cmake.org Subject: Re: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? Hi Chuck, Interesting. The flat list is not so bad i guess. (As an include.) I was thinking that cmake might support some kind of hierarchical platform definition system like Qt's qmake. (Not that it's without foibles either.) On the compiler selection question I'm still wondering if normative cmake usage really is, for example: cmake -D CMAKE_C_COMPILER=/opt/path/to/icc -D CMAKE_CXX_COMPILER=/opt/path/to/icpc ../path/to/src That is would be as opposed to the much shorter (but purely imagineary): cmake --tools=intel_16.0 ../path/to/src or, cmake --tools=gcc_5.3 ../path/to/src or, cmake --tools=gcc_6.1 ../path/to/src Where "intel_16.0" and the like map to some locally defined path (and perhaps also flag) definitions. Do folks really use the long form above? (perhaps wrapping it in a shell script or the like?) As someone very to to cmake, I wonder if I'm missing some key insight in to normal cmake workflow, or if this kind of compiler selection is, in fact, rare enough to not be cleanly supported. Thank you, Waffle -------- Original Message -------- Subject: Re: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? Local Time: May 17, 2016 9:47 AM UTC Time: May 17, 2016 1:47 PM From: chuck.atkins at kitware.com To: wafflecode at protonmail.com CC: cmake at cmake.org Hi TCW, A typical approach for this is in the top level CMakeLists.txt to have: include(CompilerFlags) And then you can isolate the detection and specialization logic in a separate CompilerFlags.cmake: if(CMAKE_COMPILER_IS_GNUC) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --gcc-options") elseif(CMAKE_C_COMPILER_ID MATCHES "Intel") set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --icc-options") elseif(CMAKE_C_COMPILER_ID MATCHES "PGI) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --pgcc-options") elseif(MSVC) if(MSVC_VERSION GREATER_THAN 1700) ... elseif(...) ... endif() endif() And then similarly for C++. - Chuck On Tue, May 17, 2016 at 1:49 AM, TCW via CMake > wrote: Hello all, On linux, what's the correct way to support building with several different C compilers, each with some extra compiler-specifc flags for Debug and Release modes? (Eventually I'll need to add Visual Studio on Windows too. ) For now, I'm following what's mentioned in the cmake FAQ and using CXX=/blah cmake, etc. (From: https://cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F) But this is getting quite cumbersome as I'm experimenting with different flags for each compiler, and I'd rather avoid polluting my fairly clean CMakeLists file with a bunch of if/else branches to set flags. In the cmake manual I see reference to a -DCMAKE_TOOLCHAIN_FILE option, but this seems designed for embedded cross-compile scenarios. (Is that right?) (From: https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html) Basically, I'd like to succinctly choose among a set of (slightly) customized compiler choices. For modern cmake usage what is the correct method? Can anybody point me to a well done example for a simple case like this? Thank you! tcw -- 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 frank.bruetting at gmail.com Wed May 18 09:38:01 2016 From: frank.bruetting at gmail.com (=?UTF-8?Q?Frank_Br=C3=BCtting?=) Date: Wed, 18 May 2016 15:38:01 +0200 Subject: [CMake] Error if CMAKE_SYSTEM_NAME is placed wrongly Message-ID: Hi, when I place set(CMAKE_SYSTEM_NAME Generic) after cmake_minimum_required() and project() and set(VERSION_MAYOR/MINOR), incremental ?make?s still work, but once the build directory is cleared and ?cmake ..? is invoked, ?make? always leads to the error ?avr-gcc: error: unrecognized command line option '-rdynamic'?. Would be nice if there's a way to prevent this situation. I don't know if it really is a bug or if ?cmake ..? always has to be invoked after editing CMakeLists.txt, but this is a really nasty situation for a cmake beginner. Best regards, Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Wed May 18 11:45:39 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 18 May 2016 11:45:39 -0400 Subject: [CMake] Error if CMAKE_SYSTEM_NAME is placed wrongly In-Reply-To: References: Message-ID: > when I place set(CMAKE_SYSTEM_NAME Generic) after cmake_minimum_required() > and project() and set(VERSION_MAYOR/MINOR), > CMAKE_SYSTEM_NAME really shouldn't be in a CMakeLists.txt file at all. It should instead be in a stand alone toolchain file defining your various cross-compiling requirements and then passed to cmake with -DCMAKE_TOOLCHAIN_FILE=/path/to/Toolchain.cmake. CMake has certain rules for when the toolchain file get's loaded very early on and processed to make sure that the subsequent processing of the CMakeLists.txt is done with the appropriate platform and compiler information set. - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From wafflecode at protonmail.com Wed May 18 13:20:26 2016 From: wafflecode at protonmail.com (TCW) Date: Wed, 18 May 2016 13:20:26 -0400 Subject: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? In-Reply-To: References: , Message-ID: Chuck, Tim: Thank you both for the help. I'll give these ideas a try and see how they shake out. The "module" command is a new one to me. Looks like it can be helpful for a variety of tasks. I do still wish cmake had a method to select a tool family that was: 1) Succinct (i.e. short to type) 2) Explicit (i.e. actually present as argument to cmake, not environment based.) 3) Workable by default (i.e. If tools are installed in default location, no need to modify my CMakeLists unless I actually need to change flags.) Is this worth filing as a feature request? If so, any suggestions about how to word this? Thanks again, Waffle -------- Original Message -------- Subject: Re: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? Local Time: May 17, 2016 1:49 PM UTC Time: May 17, 2016 5:49 PM From: tim.gallagher at gatech.edu To: chuck.atkins at kitware.com,wafflecode at protonmail.com,cmake at cmake.org We do what Chuck showed inside our CMakeLists for different flags for each compiler. To answer your other question, I prefer to use the shorter form: > CC=icc FC=ifort CXX=icpc cmake /path/to/source which sets the CC, FC and CXX environment variables only for that ccmake command without changing them in my global environment (using bash shell, it may work in others also). Once CMake has set the compilers, it doesn't change them so future calls can just be > cmake ./ Usually when I have to do a lot of compiler jockeying, I set up the module system (common on HPC's to handle different software stacks) so I can just do something like: > module load intel-compilers > cmake /path/to/source > module swap intel-compilers gnu-compilers > cmake /path/to/source and so on. Tim ------ From: CMake on behalf of TCW via CMake Sent: Tuesday, May 17, 2016 1:21 PM To: Chuck Atkins Cc: cmake at cmake.org Subject: Re: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? Hi Chuck, Interesting. The flat list is not so bad i guess. (As an include.) I was thinking that cmake might support some kind of hierarchical platform definition system like Qt's qmake. (Not that it's without foibles either.) On the compiler selection question I'm still wondering if normative cmake usage really is, for example: cmake -D CMAKE_C_COMPILER=/opt/path/to/icc -D CMAKE_CXX_COMPILER=/opt/path/to/icpc ../path/to/src That is would be as opposed to the much shorter (but purely imagineary): cmake --tools=intel_16.0 ../path/to/src or, cmake --tools=gcc_5.3 ../path/to/src or, cmake --tools=gcc_6.1 ../path/to/src Where "intel_16.0" and the like map to some locally defined path (and perhaps also flag) definitions. Do folks really use the long form above? (perhaps wrapping it in a shell script or the like?) As someone very to to cmake, I wonder if I'm missing some key insight in to normal cmake workflow, or if this kind of compiler selection is, in fact, rare enough to not be cleanly supported. Thank you, Waffle -------- Original Message -------- Subject: Re: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? Local Time: May 17, 2016 9:47 AM UTC Time: May 17, 2016 1:47 PM From: chuck.atkins at kitware.com To: wafflecode at protonmail.com CC: cmake at cmake.org Hi TCW, A typical approach for this is in the top level CMakeLists.txt to have: include(CompilerFlags) And then you can isolate the detection and specialization logic in a separate CompilerFlags.cmake: if(CMAKE_COMPILER_IS_GNUC) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --gcc-options") elseif(CMAKE_C_COMPILER_ID MATCHES "Intel") set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --icc-options") elseif(CMAKE_C_COMPILER_ID MATCHES "PGI) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --pgcc-options") elseif(MSVC) if(MSVC_VERSION GREATER_THAN 1700) ... elseif(...) ... endif() endif() And then similarly for C++. - Chuck On Tue, May 17, 2016 at 1:49 AM, TCW via CMake wrote: Hello all, On linux, what's the correct way to support building with several different C compilers, each with some extra compiler-specifc flags for Debug and Release modes? (Eventually I'll need to add Visual Studio on Windows too. ) For now, I'm following what's mentioned in the cmake FAQ and using CXX=/blah cmake, etc. (From: [ https://cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F](https://cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F)) But this is getting quite cumbersome as I'm experimenting with different flags for each compiler, and I'd rather avoid polluting my fairly clean CMakeLists file with a bunch of if/else branches to set flags. In the cmake manual I see reference to a -DCMAKE_TOOLCHAIN_FILE option, but this seems designed for embedded cross-compile scenarios. (Is that right?) (From: [ https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html](https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html)) Basically, I'd like to succinctly choose among a set of (slightly) customized compiler choices. For modern cmake usage what is the correct method? Can anybody point me to a well done example for a simple case like this? Thank you! tcw -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: [ http://www.cmake.org/Wiki/CMake_FAQ](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](http://cmake.org/cmake/help/support.html) CMake Consulting: [ http://cmake.org/cmake/help/consulting.html](http://cmake.org/cmake/help/consulting.html) CMake Training Courses: [ http://cmake.org/cmake/help/training.html](http://cmake.org/cmake/help/training.html) Visit other Kitware open-source projects at [ http://www.kitware.com/opensource/opensource.html](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 tim.gallagher at gatech.edu Wed May 18 13:33:22 2016 From: tim.gallagher at gatech.edu (Gallagher, Timothy P) Date: Wed, 18 May 2016 17:33:22 +0000 Subject: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? In-Reply-To: References: , , Message-ID: That mechanism sort of exists through Toolchain files: https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html CMake ships with numerous platforms -- look in Modules/Platform of your installation directory for examples -- and you can create and ship a set of toolchain files for your project that users can select from. The toolchain could be as simple as something like a file called GNUToolchain.cmake with the line: set(CMAKE_SYSTEM_NAME Linux-GNU) And an IntelToolchain.cmake would look like set(CMAKE_SYSTEM_NAME Linux-Intel) And then you would invoke it the first time you configure a project as: cmake -DCMAKE_TOOLCHAIN_FILE=GNUToolchain.cmake /path/to/src You can write/customize your own platform files as well. Poke around the platform directory and see the kinds of things that can be done in them. It seems to be along the lines of what you would like to do, if you don't want to modify the environment variables. We've opted for the environment variable route -- and it only needs to be set the very first time you configure, it's locked in forever after that -- and the only time we use the toolchain is on Cray systems because they are peculiar to work with sometimes. But with modules, it's really simple to set up and swap environments and so that's what we've gone with. Tim ________________________________ From: TCW Sent: Wednesday, May 18, 2016 1:20 PM To: Gallagher, Timothy P Cc: Chuck Atkins; cmake at cmake.org Subject: Re: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? Chuck, Tim: Thank you both for the help. I'll give these ideas a try and see how they shake out. The "module" command is a new one to me. Looks like it can be helpful for a variety of tasks. I do still wish cmake had a method to select a tool family that was: 1) Succinct (i.e. short to type) 2) Explicit (i.e. actually present as argument to cmake, not environment based.) 3) Workable by default (i.e. If tools are installed in default location, no need to modify my CMakeLists unless I actually need to change flags.) Is this worth filing as a feature request? If so, any suggestions about how to word this? Thanks again, Waffle -------- Original Message -------- Subject: Re: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? Local Time: May 17, 2016 1:49 PM UTC Time: May 17, 2016 5:49 PM From: tim.gallagher at gatech.edu To: chuck.atkins at kitware.com,wafflecode at protonmail.com,cmake at cmake.org We do what Chuck showed inside our CMakeLists for different flags for each compiler. To answer your other question, I prefer to use the shorter form: > CC=icc FC=ifort CXX=icpc cmake /path/to/source which sets the CC, FC and CXX environment variables only for that ccmake command without changing them in my global environment (using bash shell, it may work in others also). Once CMake has set the compilers, it doesn't change them so future calls can just be > cmake ./ Usually when I have to do a lot of compiler jockeying, I set up the module system (common on HPC's to handle different software stacks) so I can just do something like: > module load intel-compilers > cmake /path/to/source > module swap intel-compilers gnu-compilers > cmake /path/to/source and so on. Tim ________________________________ From: CMake on behalf of TCW via CMake Sent: Tuesday, May 17, 2016 1:21 PM To: Chuck Atkins Cc: cmake at cmake.org Subject: Re: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? Hi Chuck, Interesting. The flat list is not so bad i guess. (As an include.) I was thinking that cmake might support some kind of hierarchical platform definition system like Qt's qmake. (Not that it's without foibles either.) On the compiler selection question I'm still wondering if normative cmake usage really is, for example: cmake -D CMAKE_C_COMPILER=/opt/path/to/icc -D CMAKE_CXX_COMPILER=/opt/path/to/icpc ../path/to/src That is would be as opposed to the much shorter (but purely imagineary): cmake --tools=intel_16.0 ../path/to/src or, cmake --tools=gcc_5.3 ../path/to/src or, cmake --tools=gcc_6.1 ../path/to/src Where "intel_16.0" and the like map to some locally defined path (and perhaps also flag) definitions. Do folks really use the long form above? (perhaps wrapping it in a shell script or the like?) As someone very to to cmake, I wonder if I'm missing some key insight in to normal cmake workflow, or if this kind of compiler selection is, in fact, rare enough to not be cleanly supported. Thank you, Waffle -------- Original Message -------- Subject: Re: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each? Local Time: May 17, 2016 9:47 AM UTC Time: May 17, 2016 1:47 PM From: chuck.atkins at kitware.com To: wafflecode at protonmail.com CC: cmake at cmake.org Hi TCW, A typical approach for this is in the top level CMakeLists.txt to have: include(CompilerFlags) And then you can isolate the detection and specialization logic in a separate CompilerFlags.cmake: if(CMAKE_COMPILER_IS_GNUC) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --gcc-options") elseif(CMAKE_C_COMPILER_ID MATCHES "Intel") set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --icc-options") elseif(CMAKE_C_COMPILER_ID MATCHES "PGI) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --pgcc-options") elseif(MSVC) if(MSVC_VERSION GREATER_THAN 1700) ... elseif(...) ... endif() endif() And then similarly for C++. - Chuck On Tue, May 17, 2016 at 1:49 AM, TCW via CMake > wrote: Hello all, On linux, what's the correct way to support building with several different C compilers, each with some extra compiler-specifc flags for Debug and Release modes? (Eventually I'll need to add Visual Studio on Windows too. ) For now, I'm following what's mentioned in the cmake FAQ and using CXX=/blah cmake, etc. (From: https://cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F) But this is getting quite cumbersome as I'm experimenting with different flags for each compiler, and I'd rather avoid polluting my fairly clean CMakeLists file with a bunch of if/else branches to set flags. In the cmake manual I see reference to a -DCMAKE_TOOLCHAIN_FILE option, but this seems designed for embedded cross-compile scenarios. (Is that right?) (From: https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html) Basically, I'd like to succinctly choose among a set of (slightly) customized compiler choices. For modern cmake usage what is the correct method? Can anybody point me to a well done example for a simple case like this? Thank you! tcw -- 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 jsvanbethlehem at gmail.com Thu May 19 03:01:42 2016 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Thu, 19 May 2016 09:01:42 +0200 Subject: [CMake] Finding list of fixed bugs in each CMake release Message-ID: Dear users, In order to try to 'sell' my team upgrading to the newest CMake version, I was looking for a list of bugs that are fixed (I think we have workarounds for some of them, but I'm not sure) in each CMake release. I was expecting to find them in the release notes, and discovered that 'release notes' (which were actually simple posts to this list) for CMake 2.x seem to include them, but from Cmake 3.x onward they don't - I'm referring now to pages like https://cmake.org/cmake/help/v3.5/release/3.5.html. So where can I now find the bugs that are solved in a given version of Cmake? Sincerely, Jakob van Bethlehem -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Thu May 19 03:15:55 2016 From: eike at sf-mail.de (Rolf Eike Beer) Date: Thu, 19 May 2016 09:15:55 +0200 Subject: [CMake] Finding list of fixed bugs in each CMake release In-Reply-To: References: Message-ID: <066f92502f23188dfad926c35124f677@sf-mail.de> Am 2016-05-19 09:01, schrieb Jakob van Bethlehem: > Dear users, > > In order to try to 'sell' my team upgrading to the newest CMake > version, I > was looking for a list of bugs that are fixed (I think we have > workarounds > for some of them, but I'm not sure) in each CMake release. I was > expecting > to find them in the release notes, and discovered that 'release notes' > (which were actually simple posts to this list) for CMake 2.x seem to > include them, but from Cmake 3.x onward they don't - I'm referring now > to > pages like https://cmake.org/cmake/help/v3.5/release/3.5.html. > > So where can I now find the bugs that are solved in a given version of > Cmake? https://cmake.org/Bug/changelog_page.php Eike From niklas.therning at xamarin.com Thu May 19 03:27:28 2016 From: niklas.therning at xamarin.com (Niklas Therning) Date: Thu, 19 May 2016 09:27:28 +0200 Subject: [CMake] Custom languages supported by all generators? Message-ID: Hi, I'd like to add support for compiling C# using enable_language(CSharp) to my project. Similar to cmake-haskell [1]. Before I attempt this I would like to know whether this is something all generators support? I searched through the cmake sources and it looked to me like only the Unix Makefiles and Ninja generators actually support this? I'm particularly interested in the Xcode and Visual Studio generators. I'm using cmake 3.5.2 via Homebrew on OS X and cmake 3.5.2 from cmake.org on Windows 10. [1] https://github.com/kvanberendonck/cmake-haskell Thanks! /Niklas From michael.stuermer at schaeffler.com Thu May 19 04:03:13 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Thu, 19 May 2016 08:03:13 +0000 Subject: [CMake] Custom languages supported by all generators? In-Reply-To: References: Message-ID: <761ab508c034448aac3dabc032bfc06f@DE013666.schaeffler.com> Hi Niklas, native support for C# is not available in CMake. There is some work in progress, but it's not yet integrated: https://github.com/micst/CMake Unfortunately I haven't had the time yet to adapt the topic to the new formatting style, so it doesn't merge well with the current Kitware master :-(... best regards, Michael > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Niklas > Therning > Sent: Thursday, May 19, 2016 9:27 AM > To: cmake at cmake.org > Subject: [CMake] Custom languages supported by all generators? > > Hi, > > I'd like to add support for compiling C# using enable_language(CSharp) to my > project. Similar to cmake-haskell [1]. Before I attempt this I would like to > know whether this is something all generators support? I searched through > the cmake sources and it looked to me like only the Unix Makefiles and Ninja > generators actually support this? I'm particularly interested in the Xcode and > Visual Studio generators. > > I'm using cmake 3.5.2 via Homebrew on OS X and cmake 3.5.2 from > cmake.org on Windows 10. > > [1] https://github.com/kvanberendonck/cmake-haskell > > Thanks! > /Niklas > -- > > 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 niklas.therning at xamarin.com Thu May 19 05:15:01 2016 From: niklas.therning at xamarin.com (Niklas Therning) Date: Thu, 19 May 2016 11:15:01 +0200 Subject: [CMake] Custom languages supported by all generators? In-Reply-To: <761ab508c034448aac3dabc032bfc06f@DE013666.schaeffler.com> References: <761ab508c034448aac3dabc032bfc06f@DE013666.schaeffler.com> Message-ID: Thanks, native support for C# in cmake would be ideal, can't wait for that to happen! What I'm attempting now in the meantime is just to make use of the less powerful, builtin support for adding custom languages, like the repo I linked to does for Haskell. There's also some support for this shipped with cmake already for Java and Swift if you look in the Modules/ folder in your cmake installation. But as I said this only seems to be supported by the Makefiles and Ninja generators? On Thu, May 19, 2016 at 10:03 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > Hi Niklas, > > native support for C# is not available in CMake. There is some work in progress, but it's not yet integrated: > > https://github.com/micst/CMake > > Unfortunately I haven't had the time yet to adapt the topic to the new formatting style, so it doesn't merge well with the current Kitware master :-(... > > best regards, > Michael > >> -----Original Message----- >> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Niklas >> Therning >> Sent: Thursday, May 19, 2016 9:27 AM >> To: cmake at cmake.org >> Subject: [CMake] Custom languages supported by all generators? >> >> Hi, >> >> I'd like to add support for compiling C# using enable_language(CSharp) to my >> project. Similar to cmake-haskell [1]. Before I attempt this I would like to >> know whether this is something all generators support? I searched through >> the cmake sources and it looked to me like only the Unix Makefiles and Ninja >> generators actually support this? I'm particularly interested in the Xcode and >> Visual Studio generators. >> >> I'm using cmake 3.5.2 via Homebrew on OS X and cmake 3.5.2 from >> cmake.org on Windows 10. >> >> [1] https://github.com/kvanberendonck/cmake-haskell >> >> Thanks! >> /Niklas >> -- >> >> 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 jsvanbethlehem at gmail.com Thu May 19 06:57:50 2016 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Thu, 19 May 2016 12:57:50 +0200 Subject: [CMake] A bug that seems solved, but not listed in mantis log Message-ID: Dear users, With cmake 3.2.2 doing the following with VS 2013: add_library(ObjectLib OBJECT source1.cpp source2.cpp) add_library(MyDll SHARED $ From bballet at ivsweb.com Thu May 19 09:07:48 2016 From: bballet at ivsweb.com (Benjamin Ballet) Date: Thu, 19 May 2016 15:07:48 +0200 Subject: [CMake] Visual Studio : can I add a references to a cmake generated vcxproj ? Message-ID: Hi folks Is there a reason not to add a references to a cmake generated project from a classic visual studio project ? Anyone does it on a daily basis ? I'm worrying about the generated ProjectGUID : The guid of the project is stored in the classic visual studio project as well as in the generated vcxproj. I guess that guid may be different between two cmake generation ? If then what will happen ? Thank you ! -- *Benjamin BALLET* Ing?nieur R&D *ACTIVISU* 19, rue Klock - 92110 Clichy *> Standard T?l* : 01 44 69 37 37 *>* www.activisu.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbv1976 at gmail.com Thu May 19 14:16:05 2016 From: sbv1976 at gmail.com (Steven Velez) Date: Thu, 19 May 2016 14:16:05 -0400 Subject: [CMake] What is the purpose of cmake's -N parameter? Message-ID: The docs say: View mode only. > > Only load the cache. Do not actually run configure and generate steps. > But I wonder what you can do with cmake after that to view the cache? The -L parameter seems to display the same set of variables with or without this set, and scripts run in process script mode still seem to have no access to cache values. So, what's left? To state my problem a little more generally I would like a way to discover the project name set in a binary dir by it's associated CMakeLists.txt file. Is this possible without writing my own code to parse either the CMakeLists.txt or CMakeCache.txt? Thanks, Steven -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbv1976 at gmail.com Thu May 19 14:21:04 2016 From: sbv1976 at gmail.com (Steven Velez) Date: Thu, 19 May 2016 14:21:04 -0400 Subject: [CMake] What is the purpose of cmake's -N parameter? In-Reply-To: References: Message-ID: Well, sent that a little too soon. I just realized that in my testing, I wasn't specifying the source directory (which is an error) and when I do "-N" does affect how "-L" behaves... However, -L still leaves a lot of cache variables out (as does -LA), and I would like to see the value of CMAKE_PROJECT_NAME. Any tips? Thanks, Steven On Thu, May 19, 2016 at 2:16 PM, Steven Velez wrote: > The docs say: > > View mode only. >> >> Only load the cache. Do not actually run configure and generate steps. >> > > But I wonder what you can do with cmake after that to view the cache? > > The -L parameter seems to display the same set of variables with or > without this set, and scripts run in process script mode still seem to have > no access to cache values. > > So, what's left? > > To state my problem a little more generally I would like a way to discover > the project name set in a binary dir by it's associated CMakeLists.txt file. > > Is this possible without writing my own code to parse either the > CMakeLists.txt or CMakeCache.txt? > > Thanks, > Steven > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iosif.neitzke+cmake at gmail.com Thu May 19 17:43:02 2016 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Thu, 19 May 2016 16:43:02 -0500 Subject: [CMake] Visual Studio : can I add a references to a cmake generated vcxproj ? In-Reply-To: References: Message-ID: We did on a regular basis during a transition period to hook up existing .vcproj files to a CMake generated solution as we were converting fully to CMake. I believe you can control what GUID gets generated by CMake by using target properties in your CMakeLists.txt file: https://stackoverflow.com/questions/15415007/can-i-get-the-guid-generated-by-cmake-for-a-specific-vcproj-at-cmake-time On Thu, May 19, 2016 at 8:07 AM, Benjamin Ballet via CMake wrote: > Hi folks > > Is there a reason not to add a references to a cmake generated project from > a classic visual studio project ? > > Anyone does it on a daily basis ? > > I'm worrying about the generated ProjectGUID : > The guid of the project is stored in the classic visual studio project as > well as in the generated vcxproj. > I guess that guid may be different between two cmake generation ? If then > what will happen ? > > Thank you ! > > -- > Benjamin BALLET > Ing?nieur R&D > > ACTIVISU > 19, rue Klock - 92110 Clichy >> Standard T?l : 01 44 69 37 37 >> www.activisu.com > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From roman.wueger at gmx.at Fri May 20 02:26:15 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Fri, 20 May 2016 08:26:15 +0200 Subject: [CMake] Windows Phone 10.0 and Windows Phone 8.1 support Message-ID: <844A35E9-C3E3-42C4-8AD0-741CBB91AC06@gmx.at> Hi, I read that CMake has support for those platforms. Is there a way to modify the *.appxrecipe file or is there a chance to add files before packaging to an *.appx file? Thanks in advance Regards Roman From zcsd2012 at gmail.com Fri May 20 04:28:38 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Fri, 20 May 2016 01:28:38 -0700 (MST) Subject: [CMake] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly Message-ID: <1463732918230-7593495.post@n2.nabble.com> Hi, all, I try to use some gcc link option and libs(except libs link by target_link_libraries(...)), i researched and try to use 'CMAKE_EXE_LINKER_FLAGS' in a simple project, as below: in dir, there are 5 files: -hello.h -hello.c -main.c -hello.o -libhello.a hello.o was compiled by hello.c(gcc -c hello.c) and libhello.a contained hello.o. And other 3 files content: 1.In hello.h: void hello(); 2.In hello.c: #include void hello() { printf("hello\n"); } 3.In main.c: #include "hello.h" void main() { hello(); } When i used gcc -o main main.c libhello.a, the exe file: main generated, and it work well. Then i write a CMakeLists.txt, the content as below: set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello") add_executable(main main.c) When i cmake&make this project, an error occurred: main.c:undefined reference to 'hello'. Since i wil add a complicated link option and would not conflict with libs link by target_link_libraries(...), i should figure out how to use 'CMAKE_EXE_LINKER_FLAGS' or other ways, could you please give me some advices? :-) Thanks, Chao -- View this message in context: http://cmake.3232098.n2.nabble.com/How-to-use-CMAKE-EXE-LINKER-FLAGS-correctly-tp7593495.html Sent from the CMake mailing list archive at Nabble.com. From doug.cuthbertson at gmail.com Fri May 20 05:24:58 2016 From: doug.cuthbertson at gmail.com (Doug Cuthbertson) Date: Fri, 20 May 2016 05:24:58 -0400 Subject: [CMake] Setting a value in a sub-project Message-ID: CMake (version 3.5.2) surprised me with how it's passing values to sub-projects, so I was wondering if this is expected behavior. Here's an example of what I mean. Let's say I have a project Foo in a directory of the same name. It contains a third-party library called Bar which has a CMakeLists.txt file that looks like: cmake_minimum_required(VERSION 2.8.12) option(OPT1 "Set to OFF|ON (default is OFF) to control build of Bar library" OFF) if(OPT1) message("Bar: OPT1 is on") else(OPT1) message("Bar: OPT1 is off") endif(OPT1) I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes Bar: cmake_minimum_required(VERSION 2.8.12) set(OPT1 ON FORCE) if(OPT1) message("Foo: OPT1 is on") else(OPT1) message("Foo: OPT1 is off") endif(OPT1) add_subdirectory(Bar) The first time I run cmake the message output is: Foo: OPT1 is on Bar: OPT1 is off If I run cmake again, I get: Foo: OPT1 is on Bar: OPT1 is on If this is expected behavior, is there any way I can ensure Bar receives the value of OPT1 the first time? It makes a huge difference when the option controls, for example, whether a static or dynamic library will be built. Thanks, Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Fri May 20 05:37:18 2016 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 20 May 2016 11:37:18 +0200 Subject: [CMake] Setting a value in a sub-project In-Reply-To: References: Message-ID: Hi Doug, your syntax for `set()` in Foo is incorrect; you're actually setting a non-cache variable OPT1 do the value "ON;FORCE". You want to set the *cache* variable OPT1, which would be done like this: set(OPT1 ON CACHE BOOL "Set to OFF|ON (default is OFF) to control build of Bar library" FORCE) Petr On 20 May 2016 at 11:24, Doug Cuthbertson wrote: > > CMake (version 3.5.2) surprised me with how it's passing values to > sub-projects, so I was wondering if this is expected behavior. Here's an > example of what I mean. Let's say I have a project Foo in a directory of > the same name. It contains a third-party library called Bar which has a > CMakeLists.txt file that looks like: > > cmake_minimum_required(VERSION 2.8.12) > > option(OPT1 > "Set to OFF|ON (default is OFF) to control build of Bar library" OFF) > > if(OPT1) > message("Bar: OPT1 is on") > else(OPT1) > message("Bar: OPT1 is off") > endif(OPT1) > > I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes Bar: > > cmake_minimum_required(VERSION 2.8.12) > > set(OPT1 ON FORCE) > if(OPT1) > message("Foo: OPT1 is on") > else(OPT1) > message("Foo: OPT1 is off") > endif(OPT1) > add_subdirectory(Bar) > > The first time I run cmake the message output is: > > Foo: OPT1 is on > Bar: OPT1 is off > > If I run cmake again, I get: > > Foo: OPT1 is on > Bar: OPT1 is on > > If this is expected behavior, is there any way I can ensure Bar receives > the value of OPT1 the first time? It makes a huge difference when the > option controls, for example, whether a static or dynamic library will be > built. > > Thanks, > Doug > > -- > > 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 doug.cuthbertson at gmail.com Fri May 20 05:46:22 2016 From: doug.cuthbertson at gmail.com (Doug Cuthbertson) Date: Fri, 20 May 2016 05:46:22 -0400 Subject: [CMake] Setting a value in a sub-project In-Reply-To: References: Message-ID: Hi Petr, Thank you so much. I'll try it when I get in to work this morning. Doug On Fri, May 20, 2016 at 5:37 AM, Petr Kmoch wrote: > Hi Doug, > > your syntax for `set()` in Foo is incorrect; you're actually setting a > non-cache variable OPT1 do the value "ON;FORCE". > > You want to set the *cache* variable OPT1, which would be done like this: > > set(OPT1 ON CACHE BOOL "Set to OFF|ON (default is OFF) to control build > of Bar library" FORCE) > > Petr > > On 20 May 2016 at 11:24, Doug Cuthbertson > wrote: > >> >> CMake (version 3.5.2) surprised me with how it's passing values to >> sub-projects, so I was wondering if this is expected behavior. Here's an >> example of what I mean. Let's say I have a project Foo in a directory of >> the same name. It contains a third-party library called Bar which has a >> CMakeLists.txt file that looks like: >> >> cmake_minimum_required(VERSION 2.8.12) >> >> option(OPT1 >> "Set to OFF|ON (default is OFF) to control build of Bar library" >> OFF) >> >> if(OPT1) >> message("Bar: OPT1 is on") >> else(OPT1) >> message("Bar: OPT1 is off") >> endif(OPT1) >> >> I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes >> Bar: >> >> cmake_minimum_required(VERSION 2.8.12) >> >> set(OPT1 ON FORCE) >> if(OPT1) >> message("Foo: OPT1 is on") >> else(OPT1) >> message("Foo: OPT1 is off") >> endif(OPT1) >> add_subdirectory(Bar) >> >> The first time I run cmake the message output is: >> >> Foo: OPT1 is on >> Bar: OPT1 is off >> >> If I run cmake again, I get: >> >> Foo: OPT1 is on >> Bar: OPT1 is on >> >> If this is expected behavior, is there any way I can ensure Bar receives >> the value of OPT1 the first time? It makes a huge difference when the >> option controls, for example, whether a static or dynamic library will be >> built. >> >> Thanks, >> Doug >> >> -- >> >> 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 jsvanbethlehem at gmail.com Fri May 20 07:03:51 2016 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Fri, 20 May 2016 13:03:51 +0200 Subject: [CMake] Setting a value in a sub-project In-Reply-To: References: Message-ID: You don't have to create a cache variable for this. Put yourself in the position of CMake; * While scanning the CMakeLists.txt of Foo CMake encounters the set(OPT1 ON FORCE) command, which tells CMake to create a *variable* called OPT1 with value ON * Then CMake is asked to include Bar * While scanning Bar, CMake encounters the option() command, so it will create an option called OPT1 * end then.... nothing, CMake finished scanning Only the second time around, when CMake encounters the set(OPT1..) command, it will have gained knowledge of the presence of the OPT1 option, and hence it will realize it needs to change that option instead of creating a variable with that name. So to me, your output is exactly as expected. I suspect if you include Bar before setting the option, you will get the behaviour you expected. This, to me, makes perfect sense, as Bar is a dependency of Foo, and hence needs to be setup before you start setting up Foo. You wouldn't compile Foo before compiling Bar, so why would that be different for the configuration step. Sincerely, Jakob On Fri, May 20, 2016 at 11:24 AM, Doug Cuthbertson < doug.cuthbertson at gmail.com> wrote: > > CMake (version 3.5.2) surprised me with how it's passing values to > sub-projects, so I was wondering if this is expected behavior. Here's an > example of what I mean. Let's say I have a project Foo in a directory of > the same name. It contains a third-party library called Bar which has a > CMakeLists.txt file that looks like: > > cmake_minimum_required(VERSION 2.8.12) > > option(OPT1 > "Set to OFF|ON (default is OFF) to control build of Bar library" OFF) > > if(OPT1) > message("Bar: OPT1 is on") > else(OPT1) > message("Bar: OPT1 is off") > endif(OPT1) > > I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes Bar: > > cmake_minimum_required(VERSION 2.8.12) > > set(OPT1 ON FORCE) > if(OPT1) > message("Foo: OPT1 is on") > else(OPT1) > message("Foo: OPT1 is off") > endif(OPT1) > add_subdirectory(Bar) > > The first time I run cmake the message output is: > > Foo: OPT1 is on > Bar: OPT1 is off > > If I run cmake again, I get: > > Foo: OPT1 is on > Bar: OPT1 is on > > If this is expected behavior, is there any way I can ensure Bar receives > the value of OPT1 the first time? It makes a huge difference when the > option controls, for example, whether a static or dynamic library will be > built. > > Thanks, > Doug > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Fri May 20 07:18:01 2016 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 20 May 2016 13:18:01 +0200 Subject: [CMake] Setting a value in a sub-project In-Reply-To: References: Message-ID: The situation already involves a cache variable, though: `option(abc "cmt" ON)` is just syntactic sugar for `set(abc ON CACHE BOOL "cmt")`. Petr On 20 May 2016 at 13:03, Jakob van Bethlehem wrote: > You don't have to create a cache variable for this. Put yourself in the > position of CMake; > * While scanning the CMakeLists.txt of Foo CMake encounters the set(OPT1 > ON FORCE) command, which tells CMake to create a *variable* called OPT1 > with value ON > * Then CMake is asked to include Bar > * While scanning Bar, CMake encounters the option() command, so it will > create an option called OPT1 > * end then.... nothing, CMake finished scanning > > Only the second time around, when CMake encounters the set(OPT1..) > command, it will have gained knowledge of the presence of the OPT1 option, > and hence it will realize it needs to change that option instead of > creating a variable with that name. > > So to me, your output is exactly as expected. I suspect if you include Bar > before setting the option, you will get the behaviour you expected. This, > to me, makes perfect sense, as Bar is a dependency of Foo, and hence needs > to be setup before you start setting up Foo. You wouldn't compile Foo > before compiling Bar, so why would that be different for the configuration > step. > > Sincerely, > Jakob > > On Fri, May 20, 2016 at 11:24 AM, Doug Cuthbertson < > doug.cuthbertson at gmail.com> wrote: > >> >> CMake (version 3.5.2) surprised me with how it's passing values to >> sub-projects, so I was wondering if this is expected behavior. Here's an >> example of what I mean. Let's say I have a project Foo in a directory of >> the same name. It contains a third-party library called Bar which has a >> CMakeLists.txt file that looks like: >> >> cmake_minimum_required(VERSION 2.8.12) >> >> option(OPT1 >> "Set to OFF|ON (default is OFF) to control build of Bar library" >> OFF) >> >> if(OPT1) >> message("Bar: OPT1 is on") >> else(OPT1) >> message("Bar: OPT1 is off") >> endif(OPT1) >> >> I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes >> Bar: >> >> cmake_minimum_required(VERSION 2.8.12) >> >> set(OPT1 ON FORCE) >> if(OPT1) >> message("Foo: OPT1 is on") >> else(OPT1) >> message("Foo: OPT1 is off") >> endif(OPT1) >> add_subdirectory(Bar) >> >> The first time I run cmake the message output is: >> >> Foo: OPT1 is on >> Bar: OPT1 is off >> >> If I run cmake again, I get: >> >> Foo: OPT1 is on >> Bar: OPT1 is on >> >> If this is expected behavior, is there any way I can ensure Bar receives >> the value of OPT1 the first time? It makes a huge difference when the >> option controls, for example, whether a static or dynamic library will be >> built. >> >> Thanks, >> Doug >> >> -- >> >> 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 jsvanbethlehem at gmail.com Fri May 20 08:14:25 2016 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Fri, 20 May 2016 14:14:25 +0200 Subject: [CMake] Setting a value in a sub-project In-Reply-To: References: Message-ID: Ah, nice. Good to know. But then still that cache variable is not created until *after* it was set by Foo, because it is only created when adding the Bar subdirectory, which explains the output. Sincerely, Jakob On Fri, May 20, 2016 at 1:18 PM, Petr Kmoch wrote: > The situation already involves a cache variable, though: `option(abc "cmt" > ON)` is just syntactic sugar for `set(abc ON CACHE BOOL "cmt")`. > > Petr > > > On 20 May 2016 at 13:03, Jakob van Bethlehem > wrote: > >> You don't have to create a cache variable for this. Put yourself in the >> position of CMake; >> * While scanning the CMakeLists.txt of Foo CMake encounters the set(OPT1 >> ON FORCE) command, which tells CMake to create a *variable* called OPT1 >> with value ON >> * Then CMake is asked to include Bar >> * While scanning Bar, CMake encounters the option() command, so it will >> create an option called OPT1 >> * end then.... nothing, CMake finished scanning >> >> Only the second time around, when CMake encounters the set(OPT1..) >> command, it will have gained knowledge of the presence of the OPT1 option, >> and hence it will realize it needs to change that option instead of >> creating a variable with that name. >> >> So to me, your output is exactly as expected. I suspect if you include >> Bar before setting the option, you will get the behaviour you expected. >> This, to me, makes perfect sense, as Bar is a dependency of Foo, and hence >> needs to be setup before you start setting up Foo. You wouldn't compile Foo >> before compiling Bar, so why would that be different for the configuration >> step. >> >> Sincerely, >> Jakob >> >> On Fri, May 20, 2016 at 11:24 AM, Doug Cuthbertson < >> doug.cuthbertson at gmail.com> wrote: >> >>> >>> CMake (version 3.5.2) surprised me with how it's passing values to >>> sub-projects, so I was wondering if this is expected behavior. Here's an >>> example of what I mean. Let's say I have a project Foo in a directory of >>> the same name. It contains a third-party library called Bar which has a >>> CMakeLists.txt file that looks like: >>> >>> cmake_minimum_required(VERSION 2.8.12) >>> >>> option(OPT1 >>> "Set to OFF|ON (default is OFF) to control build of Bar library" >>> OFF) >>> >>> if(OPT1) >>> message("Bar: OPT1 is on") >>> else(OPT1) >>> message("Bar: OPT1 is off") >>> endif(OPT1) >>> >>> I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes >>> Bar: >>> >>> cmake_minimum_required(VERSION 2.8.12) >>> >>> set(OPT1 ON FORCE) >>> if(OPT1) >>> message("Foo: OPT1 is on") >>> else(OPT1) >>> message("Foo: OPT1 is off") >>> endif(OPT1) >>> add_subdirectory(Bar) >>> >>> The first time I run cmake the message output is: >>> >>> Foo: OPT1 is on >>> Bar: OPT1 is off >>> >>> If I run cmake again, I get: >>> >>> Foo: OPT1 is on >>> Bar: OPT1 is on >>> >>> If this is expected behavior, is there any way I can ensure Bar receives >>> the value of OPT1 the first time? It makes a huge difference when the >>> option controls, for example, whether a static or dynamic library will be >>> built. >>> >>> Thanks, >>> Doug >>> >>> -- >>> >>> 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 chuck.atkins at kitware.com Fri May 20 08:43:42 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Fri, 20 May 2016 08:43:42 -0400 Subject: [CMake] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly In-Reply-To: <1463732918230-7593495.post@n2.nabble.com> References: <1463732918230-7593495.post@n2.nabble.com> Message-ID: Is there a reason to not use target_link_libraries here? For the purposes of your example there's no reason to be using CMAKE_EXE_LINKER_FLAGS. What are you actually trying to accomplish? Because there is almost certainly a better way to achieve your desired result than via CMAKE_EXE_LINKER_FLAGS. - Chuck On Fri, May 20, 2016 at 4:28 AM, Chaos Zhang wrote: > Hi, all, > > I try to use some gcc link option and libs(except libs link by > target_link_libraries(...)), i researched and try to use > 'CMAKE_EXE_LINKER_FLAGS' in a simple project, as below: > in dir, there are 5 files: > > -hello.h > -hello.c > -main.c > -hello.o > -libhello.a > > hello.o was compiled by hello.c(gcc -c hello.c) and libhello.a contained > hello.o. And other 3 files content: > 1.In hello.h: > > void hello(); > > 2.In hello.c: > > #include > void hello() > { > printf("hello\n"); > } > > 3.In main.c: > > #include "hello.h" > void main() > { > hello(); > } > > When i used gcc -o main main.c libhello.a, the exe file: main generated, > and > it work well. > Then i write a CMakeLists.txt, the content as below: > > set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello") > add_executable(main main.c) > > When i cmake&make this project, an error occurred: main.c:undefined > reference to 'hello'. > > Since i wil add a complicated link option and would not conflict with libs > link by target_link_libraries(...), i should figure out how to use > 'CMAKE_EXE_LINKER_FLAGS' or other ways, could you please give me some > advices? :-) > > Thanks, > Chao > > > > -- > View this message in context: > http://cmake.3232098.n2.nabble.com/How-to-use-CMAKE-EXE-LINKER-FLAGS-correctly-tp7593495.html > Sent from the CMake mailing list archive at Nabble.com. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zcsd2012 at gmail.com Fri May 20 08:57:22 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Fri, 20 May 2016 05:57:22 -0700 (MST) Subject: [CMake] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly In-Reply-To: References: <1463732918230-7593495.post@n2.nabble.com> Message-ID: <1463749042750-7593503.post@n2.nabble.com> Nice to see you again, Mr. Atkins. I was trying to add a very long gcc link option to a ELF file, there are some options, like -whole-archive? -rpath?and i don't known how to set in CMake, so i decided to use original gcc option, is there better way to solve this? Chuck Atkins wrote > Is there a reason to not use target_link_libraries here? For the purposes > of your example there's no reason to be using CMAKE_EXE_LINKER_FLAGS. > What > are you actually trying to accomplish? Because there is almost certainly a > better way to achieve your desired result than via CMAKE_EXE_LINKER_FLAGS. > > - Chuck > > On Fri, May 20, 2016 at 4:28 AM, Chaos Zhang < > zcsd2012@ > > wrote: > >> Hi, all, >> >> I try to use some gcc link option and libs(except libs link by >> target_link_libraries(...)), i researched and try to use >> 'CMAKE_EXE_LINKER_FLAGS' in a simple project, as below: >> in dir, there are 5 files: >> >> -hello.h >> -hello.c >> -main.c >> -hello.o >> -libhello.a >> >> hello.o was compiled by hello.c(gcc -c hello.c) and libhello.a contained >> hello.o. And other 3 files content: >> 1.In hello.h: >> >> void hello(); >> >> 2.In hello.c: >> >> #include > >> void hello() >> { >> printf("hello\n"); >> } >> >> 3.In main.c: >> >> #include "hello.h" >> void main() >> { >> hello(); >> } >> >> When i used gcc -o main main.c libhello.a, the exe file: main generated, >> and >> it work well. >> Then i write a CMakeLists.txt, the content as below: >> >> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello") >> add_executable(main main.c) >> >> When i cmake&make this project, an error occurred: main.c:undefined >> reference to 'hello'. >> >> Since i wil add a complicated link option and would not conflict with >> libs >> link by target_link_libraries(...), i should figure out how to use >> 'CMAKE_EXE_LINKER_FLAGS' or other ways, could you please give me some >> advices? :-) >> >> Thanks, >> Chao >> >> >> >> -- >> View this message in context: >> http://cmake.3232098.n2.nabble.com/How-to-use-CMAKE-EXE-LINKER-FLAGS-correctly-tp7593495.html >> Sent from the CMake mailing list archive at Nabble.com. >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- View this message in context: http://cmake.3232098.n2.nabble.com/How-to-use-CMAKE-EXE-LINKER-FLAGS-correctly-tp7593495p7593503.html Sent from the CMake mailing list archive at Nabble.com. From doug.cuthbertson at gmail.com Fri May 20 10:21:51 2016 From: doug.cuthbertson at gmail.com (Doug Cuthbertson) Date: Fri, 20 May 2016 10:21:51 -0400 Subject: [CMake] Setting a value in a sub-project In-Reply-To: References: Message-ID: Petr - using: set(OPT1 ON CACHE BOOL "Set to OFF|ON (default is OFF) to control build of Bar library" FORCE) works like a champ! Jakob - Thanks for the suggestion, but I can't put "add_subdirectory(Bar)" before setting the variable(s) in Foo's CMakeLists.txt, because cmake finishes configuring everything under Bar before it reads the set commands in Foo. Thanks again for all your help. Doug On Fri, May 20, 2016 at 8:14 AM, Jakob van Bethlehem < jsvanbethlehem at gmail.com> wrote: > Ah, nice. Good to know. But then still that cache variable is not created > until *after* it was set by Foo, because it is only created when adding the > Bar subdirectory, which explains the output. > > Sincerely, > Jakob > > > On Fri, May 20, 2016 at 1:18 PM, Petr Kmoch wrote: > >> The situation already involves a cache variable, though: `option(abc >> "cmt" ON)` is just syntactic sugar for `set(abc ON CACHE BOOL "cmt")`. >> >> Petr >> >> >> On 20 May 2016 at 13:03, Jakob van Bethlehem >> wrote: >> >>> You don't have to create a cache variable for this. Put yourself in the >>> position of CMake; >>> * While scanning the CMakeLists.txt of Foo CMake encounters the set(OPT1 >>> ON FORCE) command, which tells CMake to create a *variable* called OPT1 >>> with value ON >>> * Then CMake is asked to include Bar >>> * While scanning Bar, CMake encounters the option() command, so it will >>> create an option called OPT1 >>> * end then.... nothing, CMake finished scanning >>> >>> Only the second time around, when CMake encounters the set(OPT1..) >>> command, it will have gained knowledge of the presence of the OPT1 option, >>> and hence it will realize it needs to change that option instead of >>> creating a variable with that name. >>> >>> So to me, your output is exactly as expected. I suspect if you include >>> Bar before setting the option, you will get the behaviour you expected. >>> This, to me, makes perfect sense, as Bar is a dependency of Foo, and hence >>> needs to be setup before you start setting up Foo. You wouldn't compile Foo >>> before compiling Bar, so why would that be different for the configuration >>> step. >>> >>> Sincerely, >>> Jakob >>> >>> On Fri, May 20, 2016 at 11:24 AM, Doug Cuthbertson < >>> doug.cuthbertson at gmail.com> wrote: >>> >>>> >>>> CMake (version 3.5.2) surprised me with how it's passing values to >>>> sub-projects, so I was wondering if this is expected behavior. Here's an >>>> example of what I mean. Let's say I have a project Foo in a directory of >>>> the same name. It contains a third-party library called Bar which has a >>>> CMakeLists.txt file that looks like: >>>> >>>> cmake_minimum_required(VERSION 2.8.12) >>>> >>>> option(OPT1 >>>> "Set to OFF|ON (default is OFF) to control build of Bar library" >>>> OFF) >>>> >>>> if(OPT1) >>>> message("Bar: OPT1 is on") >>>> else(OPT1) >>>> message("Bar: OPT1 is off") >>>> endif(OPT1) >>>> >>>> I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes >>>> Bar: >>>> >>>> cmake_minimum_required(VERSION 2.8.12) >>>> >>>> set(OPT1 ON FORCE) >>>> if(OPT1) >>>> message("Foo: OPT1 is on") >>>> else(OPT1) >>>> message("Foo: OPT1 is off") >>>> endif(OPT1) >>>> add_subdirectory(Bar) >>>> >>>> The first time I run cmake the message output is: >>>> >>>> Foo: OPT1 is on >>>> Bar: OPT1 is off >>>> >>>> If I run cmake again, I get: >>>> >>>> Foo: OPT1 is on >>>> Bar: OPT1 is on >>>> >>>> If this is expected behavior, is there any way I can ensure Bar >>>> receives the value of OPT1 the first time? It makes a huge difference when >>>> the option controls, for example, whether a static or dynamic library will >>>> be built. >>>> >>>> Thanks, >>>> Doug >>>> >>>> -- >>>> >>>> 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 chuck.atkins at kitware.com Fri May 20 10:55:33 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Fri, 20 May 2016 10:55:33 -0400 Subject: [CMake] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly In-Reply-To: <1463749042750-7593503.post@n2.nabble.com> References: <1463732918230-7593495.post@n2.nabble.com> <1463749042750-7593503.post@n2.nabble.com> Message-ID: > -rpath RPATHs are automatically added by CMake to executables so they can use libraries from the build tree. > -whole-archive > whole-archive is definitely trickier since you shouldn't be applying it to the entire executable but instead wrapping individual libraries with it. Conveniently, you can pass link options directly with target_link_libraries. So you could have: # Just an example, find_library calls should really be isolated to separate find modules find_library(FOO_LIBRARY foo) set(FOO_LIBRARY "-Wl,--whole-archive ${FOO_LIBRARY} -Wl,--no-whole-archive") add_executable(hello main.c) target_link_libraries(hello ${FOO_LIBRARY}) >> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello") > CMAKE_EXE_LINKER_FLAGS should work for other more general cases that aren't tied to specific libraries. The problem with your example is likely not using an absolute path for -L since the compilation is actually taking place in a nested work directory somewhere. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Fri May 20 11:58:09 2016 From: paul at mad-scientist.net (Paul Smith) Date: Fri, 20 May 2016 11:58:09 -0400 Subject: [CMake] Argh! Thwarted at every turn! Message-ID: <1463759889.27462.50.camel@mad-scientist.net> I'm using CMake 3.5.2 generating for Linux / OSX / Visual Studio. I'm creating a shared library. This shared library is constructed mostly from other libraries (which are also built in other directories by this cmake setup). I have been doing this for a long time and it worked fine: add_library(mylibrary SHARED foo.cpp foo.h bar.cpp bar.h ...) target_link_libraries(mylibrary PRIVATE mylib1 mylib2 VerData ...) Fine. Now the problem is that I need to generate a link map and I have a script that parses the object files in mylibrary to create the link map (the link map is only created/used on Linux of course). Well, I can't find any way to get a listing of the .o files that are generated by compiling the .cpp files in the add_library() call above. So, instead I decided to turn those files into a library, themselves, then I can use $ with my add_custom_command() that runs the link map generator script. However, then I have something like this: add_library(libIntern STATIC foo.cpp foo.h bar.cpp bar.h ...) add_library(mylibrary SHARED linkmap) target_link_libraries(mylibrary PRIVATE libIntern mylib1 mylib2 VerData ...) add_custom_command(OUTPUT linkmap COMMAND genmap $ ...) set_property(TARGET mylibrary APPEND PROPERTY LINK_DEPENDS linkmap) But this doesn't work because since libIntern is a static library only the symbols that are referenced somewhere else are included, and no symbols are actually referenced anymore since there are no source files in the library. So then I thought, well, I'll use an OBJECT library for the internal one: add_library(libIntern OBJECT foo.cpp foo.h bar.cpp bar.h ...) add_library(mylibrary SHARED $) target_link_libraries(mylibrary PRIVATE mylib1 mylib2 VerData ...) add_custom_command(OUTPUT linkmap COMMAND genmap $ ...) set_property(TARGET mylibrary APPEND PROPERTY LINK_DEPENDS linkmap) That worked for mylibrary... but of course I can't use $ anymore with an OBJECT library. And I can't use $ in my custom command either. In fact I can't find any way to get a list of the object files that are part of libIntern. So then I finally said "whatever" and created another static library out of the OBJECT library, just for use with my linkmap generating script: add_library(libIntern OBJECT foo.cpp foo.h bar.cpp bar.h ...) add_library(mylibrary SHARED linkmap $) target_link_libraries(mylibrary PRIVATE mylib1 mylib2 VerData ...) add_library(internStatic STATIC $) add_custom_command(OUTPUT linkmap COMMAND genmap $ ...) set_property(TARGET mylibrary APPEND PROPERTY LINK_DEPENDS linkmap) This is not nice but it does work... Except for one thing. Some of the files in foo.cpp ... depend on a header file which is generated as part of the build, using a separate custom command, and I handle this by compiling a little static library that needs this header file: add_custom_command(OUTPUT verdata.h COMMAND ...) set_source_files_properties(verdata.h PROPERTIES HEADER_FILE_ONLY TRUE) add_library(VerData STATIC Version.cpp Version.h) set_property(SOURCE Version.cpp APPEND PROPERTY OBJECT_DEPENDS verdata.h) Then the VerData library is added to target_link_libraries() everywhere. Coming from a strictly makefile background it doesn't seem to me that this should be sufficient, but in fact it appears to work. But in my new setup you can see that the OBJECT library no longer depends on the VerData library, which means that the auto-generated header file is not ensured to be created before the compilation of the objects in libIntern. And in fact, I get compilation errors because the verdata.h file is not generated before these compilations (particularly in Xcode, for some reason). And, I don't know how to solve this problem: I can't find any way to add a new prerequisite to the the libIntern OBJECT library to ensure that the VerData library is built first. I can't add a target_link_libraries() to an OBJECT library. I sure don't want to have to explicitly set the OBJECT_DEPENDS property on every single source file! All I want to do is call a script passing the object files to generate a link map before I create my shared library, and I've gone all the way down this rabbit hole... Help! From paul at mad-scientist.net Fri May 20 12:38:12 2016 From: paul at mad-scientist.net (Paul Smith) Date: Fri, 20 May 2016 12:38:12 -0400 Subject: [CMake] Argh! Thwarted at every turn! In-Reply-To: <1463759889.27462.50.camel@mad-scientist.net> References: <1463759889.27462.50.camel@mad-scientist.net> Message-ID: <1463762292.27462.55.camel@mad-scientist.net> On Fri, 2016-05-20 at 11:58 -0400, Paul Smith wrote: > This is not nice but it does work... Gah! The last of my problems can be solved with add_dependencies(). Somehow I didn't see this and was looking through all the target properties with set_properties() to find a way to add a dependency... sigh. Well, if anyone has a simpler way to solve the basic problem (generating a link map which requires the .o files that will be used to construct the shared library as input) I'm still interested. So in makefile-ese I want to do something like this: mylib.so: $(OBJFILES) linkmap lib1 lib2 lib3 $(CXX) ... -o $@ -Wl,--version-script=linkmap ... linkmap: $(OBJFILES) genlinkmap -o $@ $^ From paul at mad-scientist.net Fri May 20 14:34:14 2016 From: paul at mad-scientist.net (Paul Smith) Date: Fri, 20 May 2016 14:34:14 -0400 Subject: [CMake] cmake 3.5.2 Xcode generator bug Message-ID: <1463769254.20046.6.camel@mad-scientist.net> Just discovered a bug in the Xcode generator; this works fine with Makefile generator (on OSX or Linux) and Visual Studio, but fails on Xcode: $ cat CMakeLists.txt cmake_minimum_required(VERSION 3.5) project(BadXcode) add_library(obj OBJECT foo.cpp) add_library(shared SHARED $) $ touch foo.cpp $ mkdir obj $ cd obj $ cmake -G Xcode .. $ cmake --build . The build succeeds, but it never creates the libshared.dylib file: $ find . -name lib\* ./BadXcode.build/Debug/obj.build/Objects-normal/libobj.a I'm not sure why we're creating a .a here, when we're making an OBJECT library, but whatever... the main thing is there's no libshared.dylib: $ find . -name \*.dylib $ find . -name \*shared\* ./BadXcode.build/Debug/shared.build ./CMakeScripts/shared_postBuildPhase.makeDebug ./CMakeScripts/shared_postBuildPhase.makeMinSizeRel ./CMakeScripts/shared_postBuildPhase.makeRelease ./CMakeScripts/shared_postBuildPhase.makeRelWithDebInfo If I use the Makefile generator instead, it works as expected: $ rm -rf * $ cmake .. $ cmake --build . Scanning dependencies of target obj [ 50%] Building CXX object CMakeFiles/obj.dir/foo.cpp.o [ 50%] Built target obj Scanning dependencies of target shared [100%] Linking CXX shared library libshared.dylib [100%] Built target shared $ find . -name lib\* ./libshared.dylib From paul at mad-scientist.net Fri May 20 14:46:34 2016 From: paul at mad-scientist.net (Paul Smith) Date: Fri, 20 May 2016 14:46:34 -0400 Subject: [CMake] cmake 3.5.2 Xcode generator bug In-Reply-To: <1463769254.20046.6.camel@mad-scientist.net> References: <1463769254.20046.6.camel@mad-scientist.net> Message-ID: <1463769994.20046.8.camel@mad-scientist.net> On Fri, 2016-05-20 at 14:34 -0400, Paul Smith wrote: > Just discovered a bug in the Xcode generator; this works fine with > Makefile generator (on OSX or Linux) and Visual Studio, but fails on > Xcode: Meh. Looks like this is documented in add_library(): > Some native build systems may not like targets that have only object > files, so consider adding at least one real source file to any target > that references $. Unfortunately for me, I really have to have all the object files in the OBJECT library (see my previous email about generating linker map files based on the contents), and there're no other files to add into the library. Sigh. From chrysalisx at gmail.com Fri May 20 22:02:14 2016 From: chrysalisx at gmail.com (Walter Gray) Date: Sat, 21 May 2016 02:02:14 +0000 Subject: [CMake] Cross Compilation & Source file generators Message-ID: I've got a project with a number of target platforms, including some that I have to cross-compile to such as android, that uses protobuf. If you're unfamiliar, the crux of the issue is that there is both a library, libprotobuf, and an 'compiler', protoc, that takes .proto files and generates a .h/.cc pair that are then included in the project. When cross compiling, want to use the libprotobuf that was compiled on andriod, but the protoc that was compiled for my host environment. How could this be achieved? Currently, my build machine has several different directories where I store the external libraries that have been compiled for the various platforms/compilers that we support (Libraries-arm32, Libraries-x64, Libraries-x64-vc14, ect). Solutions that require modifying protobuf's -config.cmake file are welcome, I've already submitted several PR's improving it. I'd like to establish what the best practice for this kind of situation is as I have the same issue with Flatbuffers. On a slightly unrelated note, is there some way to write something like the AUTOUIC system without modifying cmake itself? It would be lovely if all I had to do was include the .proto file in the source file list. Thanks! Walter -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrysalisx at gmail.com Fri May 20 22:13:38 2016 From: chrysalisx at gmail.com (Walter Gray) Date: Sat, 21 May 2016 02:13:38 +0000 Subject: [CMake] Cross Compilation & Source file generators In-Reply-To: References: Message-ID: A small addendum - The way I am currently solving this problem is by replacing the version of protoc in the library folder for android with one that works on the host machine, but this is really not the best since it means that the library distribution is tied to the host AND the target. Thinking in terms of concepts, I think I would want a find_package that understood the difference between finding a package for executing and finding a package for linking, but that'd be a pretty fundamental change. On Fri, May 20, 2016 at 7:02 PM Walter Gray wrote: > I've got a project with a number of target platforms, including some that > I have to cross-compile to such as android, that uses protobuf. If you're > unfamiliar, the crux of the issue is that there is both a library, > libprotobuf, and an 'compiler', protoc, that takes .proto files and > generates a .h/.cc pair that are then included in the project. > > When cross compiling, want to use the libprotobuf that was compiled on > andriod, but the protoc that was compiled for my host environment. How > could this be achieved? > > Currently, my build machine has several different directories where I > store the external libraries that have been compiled for the various > platforms/compilers that we support (Libraries-arm32, Libraries-x64, > Libraries-x64-vc14, ect). > > Solutions that require modifying protobuf's -config.cmake file are > welcome, I've already submitted several PR's improving it. I'd like to > establish what the best practice for this kind of situation is as I have > the same issue with Flatbuffers. > > On a slightly unrelated note, is there some way to write something like > the AUTOUIC system without modifying cmake itself? It would be lovely if > all I had to do was include the .proto file in the source file list. > > Thanks! > Walter > -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Sat May 21 02:26:59 2016 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Sat, 21 May 2016 08:26:59 +0200 Subject: [CMake] Cross Compilation & Source file generators In-Reply-To: References: Message-ID: <3BD6EFC1-6496-4FA0-BA57-BB4F6919B706@hendrik-sattler.de> Hi, Did you read the Wiki page about cross compiling with CMake? CMake can already restrict searching for libraries to certain directories when cross compiling. HS Am 21. Mai 2016 04:13:38 MESZ, schrieb Walter Gray : >A small addendum - The way I am currently solving this problem is by >replacing the version of protoc in the library folder for android with >one >that works on the host machine, but this is really not the best since >it >means that the library distribution is tied to the host AND the target. > >Thinking in terms of concepts, I think I would want a find_package that >understood the difference between finding a package for executing and >finding a package for linking, but that'd be a pretty fundamental >change. > >On Fri, May 20, 2016 at 7:02 PM Walter Gray >wrote: > >> I've got a project with a number of target platforms, including some >that >> I have to cross-compile to such as android, that uses protobuf. If >you're >> unfamiliar, the crux of the issue is that there is both a library, >> libprotobuf, and an 'compiler', protoc, that takes .proto files and >> generates a .h/.cc pair that are then included in the project. >> >> When cross compiling, want to use the libprotobuf that was compiled >on >> andriod, but the protoc that was compiled for my host environment. >How >> could this be achieved? >> >> Currently, my build machine has several different directories where I >> store the external libraries that have been compiled for the various >> platforms/compilers that we support (Libraries-arm32, Libraries-x64, >> Libraries-x64-vc14, ect). >> >> Solutions that require modifying protobuf's -config.cmake file are >> welcome, I've already submitted several PR's improving it. I'd like >to >> establish what the best practice for this kind of situation is as I >have >> the same issue with Flatbuffers. >> >> On a slightly unrelated note, is there some way to write something >like >> the AUTOUIC system without modifying cmake itself? It would be lovely >if >> all I had to do was include the .proto file in the source file list. >> >> Thanks! >> Walter >> > > >------------------------------------------------------------------------ -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From dave.demarle at kitware.com Sat May 21 09:10:57 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Sat, 21 May 2016 09:10:57 -0400 Subject: [CMake] Cross Compilation & Source file generators In-Reply-To: References: Message-ID: Take a look at paraview's internal copy of protobuf. We compile protoc in the host tools pass and then use it when we build libprotobuf in the cross compile pass. On May 20, 2016 10:14 PM, "Walter Gray" wrote: > A small addendum - The way I am currently solving this problem is by > replacing the version of protoc in the library folder for android with one > that works on the host machine, but this is really not the best since it > means that the library distribution is tied to the host AND the target. > > Thinking in terms of concepts, I think I would want a find_package that > understood the difference between finding a package for executing and > finding a package for linking, but that'd be a pretty fundamental change. > > On Fri, May 20, 2016 at 7:02 PM Walter Gray wrote: > >> I've got a project with a number of target platforms, including some that >> I have to cross-compile to such as android, that uses protobuf. If you're >> unfamiliar, the crux of the issue is that there is both a library, >> libprotobuf, and an 'compiler', protoc, that takes .proto files and >> generates a .h/.cc pair that are then included in the project. >> >> When cross compiling, want to use the libprotobuf that was compiled on >> andriod, but the protoc that was compiled for my host environment. How >> could this be achieved? >> >> Currently, my build machine has several different directories where I >> store the external libraries that have been compiled for the various >> platforms/compilers that we support (Libraries-arm32, Libraries-x64, >> Libraries-x64-vc14, ect). >> >> Solutions that require modifying protobuf's -config.cmake file are >> welcome, I've already submitted several PR's improving it. I'd like to >> establish what the best practice for this kind of situation is as I have >> the same issue with Flatbuffers. >> >> On a slightly unrelated note, is there some way to write something like >> the AUTOUIC system without modifying cmake itself? It would be lovely if >> all I had to do was include the .proto file in the source file list. >> >> Thanks! >> Walter >> > > -- > > 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 craig.scott at crascit.com Sat May 21 17:10:31 2016 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 22 May 2016 07:10:31 +1000 Subject: [CMake] Cross Compilation & Source file generators In-Reply-To: References: Message-ID: There's also the technique described in this stack overflow question/answer: http://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run I'd probably recommend the superbuild approach used by Paraview though if your build can be structured that way. With the superbuild approach, it's a bit easier to tell what's going on. The method in the above link would only be better if you really needed to keep everything in the one single build. On Sat, May 21, 2016 at 11:10 PM, David E DeMarle wrote: > Take a look at paraview's internal copy of protobuf. We compile protoc in > the host tools pass and then use it when we build libprotobuf in the cross > compile pass. > On May 20, 2016 10:14 PM, "Walter Gray" wrote: > >> A small addendum - The way I am currently solving this problem is by >> replacing the version of protoc in the library folder for android with one >> that works on the host machine, but this is really not the best since it >> means that the library distribution is tied to the host AND the target. >> >> Thinking in terms of concepts, I think I would want a find_package that >> understood the difference between finding a package for executing and >> finding a package for linking, but that'd be a pretty fundamental change. >> >> On Fri, May 20, 2016 at 7:02 PM Walter Gray wrote: >> >>> I've got a project with a number of target platforms, including some >>> that I have to cross-compile to such as android, that uses protobuf. If >>> you're unfamiliar, the crux of the issue is that there is both a library, >>> libprotobuf, and an 'compiler', protoc, that takes .proto files and >>> generates a .h/.cc pair that are then included in the project. >>> >>> When cross compiling, want to use the libprotobuf that was compiled on >>> andriod, but the protoc that was compiled for my host environment. How >>> could this be achieved? >>> >>> Currently, my build machine has several different directories where I >>> store the external libraries that have been compiled for the various >>> platforms/compilers that we support (Libraries-arm32, Libraries-x64, >>> Libraries-x64-vc14, ect). >>> >>> Solutions that require modifying protobuf's -config.cmake file are >>> welcome, I've already submitted several PR's improving it. I'd like to >>> establish what the best practice for this kind of situation is as I have >>> the same issue with Flatbuffers. >>> >>> On a slightly unrelated note, is there some way to write something like >>> the AUTOUIC system without modifying cmake itself? It would be lovely if >>> all I had to do was include the .proto file in the source file list. >>> >>> Thanks! >>> Walter >>> >> >> -- >> >> 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 > -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From random.romik at gmail.com Sat May 21 20:19:28 2016 From: random.romik at gmail.com (Roman) Date: Sat, 21 May 2016 17:19:28 -0700 Subject: [CMake] CMake custom link executable command, how to extract linker options? Message-ID: Hello, I want to use custom executable linking command in my CMake script, namely Synopsys VCS. VCS is a wrapper over GCC, but it uses special syntax for passing LD options: vcs -LDFLAGS "" I've tried to play with CMAKE_CXX_LINK_EXECUTABLE: set(CMAKE_CXX_LINK_EXECUTABLE "echo CXXFLAGS: LINK_FLAGS: LINK_LIBRARIES: OBJECTS: ") When I build project i got: CXXFLAGS: LINK_FLAGS: LINK_LIBRARIES: -rdynamic ../slib/libslib.a ../dlib/libdlib.so -Wl,-rpath,/home/ripopov/proj_cmake/build/dlib OBJECTS: CMakeFiles/sim.dir/sc_main.cpp.o So all linker flags together with libraries are in . And is empty. Why it works this way? And how can I extract linker flags from LINK_LIBRARIES? I've posted same question on stackoverflow: http://stackoverflow.com/questions/37368434/cmake-custom-link-executable-command-how-to-extract-linker-options -- Best regards, Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.enright at gmail.com Sat May 21 21:31:56 2016 From: michael.enright at gmail.com (Michael Enright) Date: Sat, 21 May 2016 18:31:56 -0700 Subject: [CMake] Simple CMake project on Msys2/Win10-64 gives Complex "Platform" error Message-ID: I'm getting a message that says my platform is not known to CMake, which seems very unlikely. Here are the details. Today, I have installed cmake using pacman on Msys2, I created a basic CMakeLists.txt to compile a single c++ file into a test application, called 'test'. I have tested that the source code compiles using g++ directly. When I try to use "cmake ." to configure this project to build, I get a bunch of normal messages, interspersed with REPEATED output of this: System is unknown to cmake, create: Platform/MINGW64_NT-10.0 to use this system, please send your config file to cmake at www.cmake.org so it can be added to cmake -- Detecting CXX compile features - done How do I make this message go away? A detailed walk through of how to actually author the file mentioned is an acceptable answer. Also, what's with the scary message about the name 'test' being reserved? Finally, I know better, normally, than to use "cmake ." but I'm sure that is not the source of this issue. As soon as I fix this issue I'll throw this directory away and go back to real work. $ cmake --version cmake version 3.2.3 -------------- next part -------------- project(test) set (CMAKE_CXX_STANDARD 11) set (CMAKE_C_STANDARD 11) add_executable(test test.cpp) From konstantin at podsvirov.pro Sun May 22 02:28:40 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Sun, 22 May 2016 09:28:40 +0300 Subject: [CMake] Simple CMake project on Msys2/Win10-64 gives Complex "Platform" error In-Reply-To: References: Message-ID: <2147091463898520@web30h.yandex.ru> Hello Michael! 22.05.2016, 04:32, "Michael Enright" : > I'm getting a message that says my platform is not known to CMake > which seems very unlikely. Here are the details. > > Today I have installed cmake using pacman on Msys2, > I created a basic CMakeLists.txt to compile a single c++ file into a > test application called 'test'. I have tested that the source code > compiles using g++ directly. I also have a small experience of using the MSYS2 project. I will try to share my experience. > When I try to use "cmake ." to configure this project to build, I get > a bunch of normal messages, interspersed with REPEATED output of this: > System is unknown to cmake, create: > Platform/MINGW64_NT-10.0 to use this system, please send your config > file to cmake at www.cmake.org so it can be added to cmake > -- Detecting CXX compile features - done > > How do I make this message go away? A detailed walk through of how to > actually author the file mentioned is an acceptable answer. Which generator did you use? Try to use the "MSYS Makefiles": cmake -G"MSYS Makefiles" ... Many examples of different projects you can find here: https://github.com/Alexpux/MINGW-packages > Also, what's with the scary message about the name 'test' being reserved? > > Finally, I know better, normally, than to use "cmake ." but I'm sure > that is not the source of this issue. As soon As I fix this issue I'll > throw this directory away and go back to real work. > > $ cmake --version > cmake version: 3.2.3 > ,-- > > 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 I have the assumption that CMake is not correctly determined by the generator by default for this environment. But I'm no expert and this question still needs further study. For publicity will say that I have a project osgQtQuick: https://github.com/podsvirov/osgqtquick This project is now included in MSYS2. Here is a script build the package: https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-osgqtquick/PKGBUILD -- Regards, Konstantin Podsvirov From zcsd2012 at gmail.com Mon May 23 02:23:59 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Sun, 22 May 2016 23:23:59 -0700 (MST) Subject: [CMake] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly In-Reply-To: References: <1463732918230-7593495.post@n2.nabble.com> <1463749042750-7593503.post@n2.nabble.com> Message-ID: <1463984639443-7593518.post@n2.nabble.com> Thanks a lot! `set(FOO_LIBRARY "-Wl,--whole-archive ${FOO_LIBRARY} -Wl,--no-whole-archive")` worked when the content of ${FOO_LIBRARY} look like `-Ldir -llib`, if just use lib name as the content of ${FOO_LIBRARY}, error while occur. Chuck Atkins wrote >> -rpath > > > RPATHs are automatically added by CMake to executables so they can use > libraries from the build tree. > > > >> -whole-archive >> > > whole-archive is definitely trickier since you shouldn't be applying it to > the entire executable but instead wrapping individual libraries with it. > Conveniently, you can pass link options directly with > target_link_libraries. So you could have: > > # Just an example, find_library calls should really be isolated to > separate > find modules > find_library(FOO_LIBRARY foo) > set(FOO_LIBRARY "-Wl,--whole-archive ${FOO_LIBRARY} > -Wl,--no-whole-archive") > > add_executable(hello main.c) > target_link_libraries(hello ${FOO_LIBRARY}) > > >>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello") >> > > CMAKE_EXE_LINKER_FLAGS should work for other more general cases that > aren't > tied to specific libraries. The problem with your example is likely not > using an absolute path for -L since the compilation is actually taking > place in a nested work directory somewhere. > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- View this message in context: http://cmake.3232098.n2.nabble.com/How-to-use-CMAKE-EXE-LINKER-FLAGS-correctly-tp7593495p7593518.html Sent from the CMake mailing list archive at Nabble.com. From roman.wueger at gmx.at Mon May 23 03:25:52 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Mon, 23 May 2016 09:25:52 +0200 Subject: [CMake] Empty ERROR_VARIABLE in execute_process Message-ID: <9280D474-4C0F-49C1-8D0F-BAD13D9A9061@gmx.at> Hello, when I run qmllint from the command line to test an error I get: C:\Tests>C:\Qt\5.6\msvc2015\bin\qmllint.exe test.qml test.qml:1 : Syntax error C:\Tests>echo %ERRORLEVEL% -1 C:\Tests> If I call this from a CMake script execute_process(COMMAND C:/Qt/5.6/msvc2015/bin/qmllint.exe C:/Tests/test.qml RESULT_VARIABLE _resVar OUTPUT_VARIABLE _outVar ERROR_VARIABLE _errVar OUTPUT_STRIP_TRAILING_WHITESPACE ERROR_STRIP_TRAILING_WHITESPACE) message("_resVar: ${_resVar}") message("_outVar: ${_outVar}") message("_errVar: ${_errVar}") The output is: 1> _resVar: -1 1> _outVar: 1> _errVar: It seems that the error pipe isn?t read correctly, because _errVar is empty. And hints? Regards Roman From roman.wueger at gmx.at Mon May 23 07:00:44 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Mon, 23 May 2016 13:00:44 +0200 Subject: [CMake] Empty ERROR_VARIABLE in execute_process In-Reply-To: <9280D474-4C0F-49C1-8D0F-BAD13D9A9061@gmx.at> References: <9280D474-4C0F-49C1-8D0F-BAD13D9A9061@gmx.at> Message-ID: <2B99673B-1F79-42C6-8471-7628F89933B6@gmx.at> As an addition: If I run "C:\Qt\5.6\msvc2015\bin\qmllint.exe test.qml 1> stdout.txt 2> stderr.txt" Then the error is written to stderr.txt. Regards Roman > Am 23.05.2016 um 09:25 schrieb Roman W?ger : > > Hello, > > when I run qmllint from the command line to test an error I get: > > C:\Tests>C:\Qt\5.6\msvc2015\bin\qmllint.exe test.qml > test.qml:1 : Syntax error > > C:\Tests>echo %ERRORLEVEL% > -1 > > C:\Tests> > > > If I call this from a CMake script > > execute_process(COMMAND C:/Qt/5.6/msvc2015/bin/qmllint.exe C:/Tests/test.qml > RESULT_VARIABLE _resVar > OUTPUT_VARIABLE _outVar > ERROR_VARIABLE _errVar > OUTPUT_STRIP_TRAILING_WHITESPACE > ERROR_STRIP_TRAILING_WHITESPACE) > > message("_resVar: ${_resVar}") > message("_outVar: ${_outVar}") > message("_errVar: ${_errVar}") > > The output is: > > 1> _resVar: -1 > 1> _outVar: > 1> _errVar: > > It seems that the error pipe isn?t read correctly, because _errVar is empty. > > And hints? > > 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 From dave.demarle at kitware.com Mon May 23 08:17:25 2016 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 23 May 2016 08:17:25 -0400 Subject: [CMake] Cross Compilation & Source file generators In-Reply-To: References: Message-ID: Just to clarify, although ParaView's superbuild assists you to set up and compile in either "compile TOOLS" or "CROSS compile" mode (or the default "HOST" mode) the protobuf inclusion I was speaking of in is found within paraview's source code and is not an external project. See ${PVSOURCE}/ThirdParty/protobuf hope that helps On Saturday, May 21, 2016, Craig Scott wrote: > There's also the technique described in this stack overflow > question/answer: > > > http://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run > > I'd probably recommend the superbuild approach used by Paraview though if > your build can be structured that way. With the superbuild approach, it's a > bit easier to tell what's going on. The method in the above link would only > be better if you really needed to keep everything in the one single build. > > > > > On Sat, May 21, 2016 at 11:10 PM, David E DeMarle < > dave.demarle at kitware.com> wrote: > >> Take a look at paraview's internal copy of protobuf. We compile protoc in >> the host tools pass and then use it when we build libprotobuf in the cross >> compile pass. >> On May 20, 2016 10:14 PM, "Walter Gray" wrote: >> >>> A small addendum - The way I am currently solving this problem is by >>> replacing the version of protoc in the library folder for android with one >>> that works on the host machine, but this is really not the best since it >>> means that the library distribution is tied to the host AND the target. >>> >>> Thinking in terms of concepts, I think I would want a find_package that >>> understood the difference between finding a package for executing and >>> finding a package for linking, but that'd be a pretty fundamental change. >>> >>> On Fri, May 20, 2016 at 7:02 PM Walter Gray >>> wrote: >>> >>>> I've got a project with a number of target platforms, including some >>>> that I have to cross-compile to such as android, that uses protobuf. If >>>> you're unfamiliar, the crux of the issue is that there is both a library, >>>> libprotobuf, and an 'compiler', protoc, that takes .proto files and >>>> generates a .h/.cc pair that are then included in the project. >>>> >>>> When cross compiling, want to use the libprotobuf that was compiled on >>>> andriod, but the protoc that was compiled for my host environment. How >>>> could this be achieved? >>>> >>>> Currently, my build machine has several different directories where I >>>> store the external libraries that have been compiled for the various >>>> platforms/compilers that we support (Libraries-arm32, Libraries-x64, >>>> Libraries-x64-vc14, ect). >>>> >>>> Solutions that require modifying protobuf's -config.cmake file are >>>> welcome, I've already submitted several PR's improving it. I'd like to >>>> establish what the best practice for this kind of situation is as I have >>>> the same issue with Flatbuffers. >>>> >>>> On a slightly unrelated note, is there some way to write something like >>>> the AUTOUIC system without modifying cmake itself? It would be lovely if >>>> all I had to do was include the .proto file in the source file list. >>>> >>>> Thanks! >>>> Walter >>>> >>> >>> -- >>> >>> 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 >> > > > > -- > Craig Scott > Melbourne, Australia > http://crascit.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Wagner at neuberger.net Mon May 23 09:49:14 2016 From: Martin.Wagner at neuberger.net (Wagner Martin) Date: Mon, 23 May 2016 13:49:14 +0000 Subject: [CMake] C header file cross dependency Message-ID: <56E920142ED81D4FBE3260E4B9D1DB3E97208951@ROTSRV13.Neuberger.local> Hi @all, I'm quite new to CMake. If I've made a mistake or something is much easier to solve, please tell me. I'd like to use CMake in embedded development (Build System: Linux, Target: ARM Microcontroller) to get rid of complicated makefiles. We're building multiple devices where stuff like embedded rtos and peripheral drivers are identical, so I'd like to separate this part from the user application. I've achieved that by creating an object library out of all source and header files, and packing those files using CPack. This archive is then statically linked against the user application. So far this worked fine. However, now I have to use driver functions in the rtos source code and vice versa, resulting in cross-dependencies for header files: #include uart.h #include terminal.h function() {} #include terminal.h #include uart.h function() {} How do I resolve something like this? Right now CMake evaluates the compiler includes in the order that subdirectories are added. This gives me an compilation error in uart.c that terminal.h cannot be found. Thank you for your help! Regards, Martin Some excerpt of my project. I've tried to keep the example as simple as possible. My directory structure looks something like that: / CMakeLists.txt src + +CMakeLists.txt (1) +drivers+ | +uart.c | +uart.h | +... | +CMakeLists.txt (2) +os-----+ | +terminal.c | +terminal.h | +... | +CMakeLists.txt (3) (1): SET(drivers "drivers") SET(terminal "terminal") SET(drivers_lib ${drivers}) SET(terminal_lib ${terminal}) SET(ARCHIVE_INSTALL_DIR lib) SET(INCLUDE_INSTALL_DIR include) SET(headers_private "_headers_private") # internal headers SET(headers_public "_headers_public") # public headers go into package ADD_SUBDIRECTORY(${drivers}) ADD_SUBDIRECTORY(${terminal}) ## ---- Targets ------------------------------------------------------------------- ADD_LIBRARY(bsp ${object_libs}) INSTALL(TARGETS bsp DESTINATION ${ARCHIVE_INSTALL_DIR}) (2): ## drivers ## ---- Sources ------------------------------------------------------------------- SET(sources "uart.c" ) ## ---- Header includes ----------------------------------------------------------- SET(headers "${CMAKE_CURRENT_SOURCE_DIR}/" ) SET(${drivers}${headers_public} ${headers} PARENT_SCOPE) INCLUDE_DIRECTORIES(${headers} ${${terminal}${headers_public}} ) ## ---- Targets ------------------------------------------------------------------- ADD_LIBRARY(${drivers_lib} OBJECT ${sources}) # add to list of Object Targets SET(object_libs ${object_libs} $ PARENT_SCOPE) INSTALL(DIRECTORY ${headers} DESTINATION ${INCLUDE_INSTALL_DIR} FILES_MATCHING PATTERN "*.h") (3), mostly like (2): ## rtos ## ---- Sources ------------------------------------------------------------------- SET(sources "terminal.c" ) ## ---- Header includes ----------------------------------------------------------- SET(headers "${CMAKE_CURRENT_SOURCE_DIR}/" ) SET(${terminal}${headers_public} ${headers} PARENT_SCOPE) INCLUDE_DIRECTORIES(${headers} ${${drivers}${headers_public}} ) ## ---- Targets ------------------------------------------------------------------- ADD_LIBRARY(${terminal_lib} OBJECT ${sources}) # add to list of Object Targets SET(object_libs ${object_libs} $ PARENT_SCOPE) INSTALL(DIRECTORY ${headers} DESTINATION ${INCLUDE_INSTALL_DIR} FILES_MATCHING PATTERN "*.h") And finally this creates the package in root directory CMakeLists.txt: SET(CPACK_PROJECT_CONFIG_FILE ${CMAKE_BINARY_DIR}/CPackOptions.cmake) # CPackOptions.cmake contains package file name SET(CPACK_GENERATOR "TBZ2") INCLUDE(CPack) I've searched for a solution for this problem for ~1 day, most results only deal with one directional dependencies or link a shared library/executable at the end, which does not help me. When changing (2) "INCLUDE_DIRECTORIES" to INCLUDE_DIRECTORIES(${headers} "/home/user/workspace/arm_bsp/src/terminal/" ) compilation works as expected, but breaks independence of child folders to parent folders. I defenitively do not want to do that. CMake Version is "cmake version 3.0.2" (stock Debian 8) From Harry at codexdigital.com Mon May 23 10:05:03 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Mon, 23 May 2016 14:05:03 +0000 Subject: [CMake] CPack and PackageMaker References: <99EE2FB8-698C-4476-A1A5-8A9223D2B24A@codexdigital.com> Message-ID: <363C3873-ED8E-4B92-8A40-BE9EB19129BE@codexdigital.com> Thanks for your work on this, I hope this can get into the main codebase soon. Currently we use internal productbuild and pkgbuild scripts from our pre-cmake days. Reading through your patch now I have some feedback: 1. Package ID: The pkgid for pkgbuild can often be something other than "com.CPACK_PACKAGE_VENDOR.CPACK_PACKAGE_NAME.component->Name". It might be useful to introduce a new variable "CPACK_PRODUCTBUILD__PKGID" which could override the default behaviour if desired. 2. Pkgbuild Install Location: >From man: "--install-location install-path Specify the default install location for the contents of the package. For example, if you specify a single application component, you might specify an install-path of /Applications. pkgbuild attempts to infer a sensible install path if this option is not used, but it may not choose correctly. Note that whether or not the default install location is actually used by the OS X Installer depends on the distribution file you deploy with the package." Is there any reason why you are not using the default behaviour? We have always used it previously and it would seem to be better than defining "/". 3. Pkgbuild Version: "--version" in pkgbuild command line could be set to "CPACK_PACKAGE_VERSION" to allow normal version checking. 4. Productbuild Version: "--version" in productbuild command line could be set to "CPACK_PACKAGE_VERSION" as well. 5. Finding programs: "// TODO: find pkgbuild and productbuild" could be replaced with cmSystemTools::FindProgram for the two executables and return error messages if they are unavailable (which is unlikely). Harry Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 Website | Facebook | Twitter [http://www.codexdigital.com/?action=asset&id=E55D8A6F-AF62-4978-8FF1-435A85AFADBF] -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Mon May 23 10:04:51 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 23 May 2016 10:04:51 -0400 Subject: [CMake] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly In-Reply-To: <1463984639443-7593518.post@n2.nabble.com> References: <1463732918230-7593495.post@n2.nabble.com> <1463749042750-7593503.post@n2.nabble.com> <1463984639443-7593518.post@n2.nabble.com> Message-ID: If you know the full path to the library then I'd suggest using it as /path/to/foo/libfoo.a (or .so if it's shared) instead of -L/path/to/foo -lfoo. CMake will adjust the flags to -L and -l if needed but the preference is always to use the full library path. - Chuck On Mon, May 23, 2016 at 2:23 AM, Chaos Zhang wrote: > Thanks a lot! `set(FOO_LIBRARY "-Wl,--whole-archive ${FOO_LIBRARY} > -Wl,--no-whole-archive")` worked when the content of ${FOO_LIBRARY} look > like `-Ldir -llib`, if just use lib name as the content of ${FOO_LIBRARY}, > error while occur. > > Chuck Atkins wrote > >> -rpath > > > > > > RPATHs are automatically added by CMake to executables so they can use > > libraries from the build tree. > > > > > > > >> -whole-archive > >> > > > > whole-archive is definitely trickier since you shouldn't be applying it > to > > the entire executable but instead wrapping individual libraries with it. > > Conveniently, you can pass link options directly with > > target_link_libraries. So you could have: > > > > # Just an example, find_library calls should really be isolated to > > separate > > find modules > > find_library(FOO_LIBRARY foo) > > set(FOO_LIBRARY "-Wl,--whole-archive ${FOO_LIBRARY} > > -Wl,--no-whole-archive") > > > > add_executable(hello main.c) > > target_link_libraries(hello ${FOO_LIBRARY}) > > > > > >>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello") > >> > > > > CMAKE_EXE_LINKER_FLAGS should work for other more general cases that > > aren't > > tied to specific libraries. The problem with your example is likely not > > using an absolute path for -L since the compilation is actually taking > > place in a nested work directory somewhere. > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > > > > > > -- > View this message in context: > http://cmake.3232098.n2.nabble.com/How-to-use-CMAKE-EXE-LINKER-FLAGS-correctly-tp7593495p7593518.html > Sent from the CMake mailing list archive at Nabble.com. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.r.stephens at gmail.com Mon May 23 10:08:05 2016 From: bruce.r.stephens at gmail.com (Bruce Stephens) Date: Mon, 23 May 2016 15:08:05 +0100 Subject: [CMake] Fwd: Using CPack to package things not built using CMake In-Reply-To: References: Message-ID: Sorry, that should obviously have gone to this mailing list. ---------- Forwarded message ---------- From: Bruce Stephens Date: Mon, May 23, 2016 at 2:40 PM Subject: Using CPack to package things not built using CMake To: cmake-developers at cmake.org Suppose I have a build which uses a number of external projects (perhaps built using ExternalProject_Add) but which use a variety of build systems. And I want to package the result (so I arrange for the external projects to build expecting themselves to be installed under /opt/foo). What are good ways to do that, without going in and replacing all the existing build systems with CMake (which is likely the route we'll take for some, but doing all doesn't seem practical)? A possibility is just to build static rather than shared libraries; for quite a few cases that would mean nothing would need to be installed. Another one (which would be a bit more general, I think) is to replace the build with a CMake wrapper, so the building bit calls the underlying build script but the install part is all done in CMake. In these cases the numbers of files is usually quite small, so doing that shouldn't be too annoying, and would presumably produce the right scripts to use in CPack. Any better ideas (or problems I'm missing with the last idea I suggest)? From chuck.atkins at kitware.com Mon May 23 10:21:37 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 23 May 2016 10:21:37 -0400 Subject: [CMake] Fwd: Using CPack to package things not built using CMake In-Reply-To: References: Message-ID: Hi Bruce, CPack basically packages up everything that gets "installed". We've got a number of superbuilds as we call them that work this way. Basically you have all of your external projects perform their install into the same temporary location somewhere in the build tree, like ${project_name_BINARY_DIR}/install_staging. Then in the top level project, you use: install(DIRECTORY ${project_name_BINARY_DIR}/install_staging/ DESTINATION .) Now CPack will package the entire staged install tree which should contain the installations of all the external projects. - Chuck On Mon, May 23, 2016 at 10:08 AM, Bruce Stephens wrote: > Sorry, that should obviously have gone to this mailing list. > > ---------- Forwarded message ---------- > From: Bruce Stephens > Date: Mon, May 23, 2016 at 2:40 PM > Subject: Using CPack to package things not built using CMake > To: cmake-developers at cmake.org > > > Suppose I have a build which uses a number of external projects > (perhaps built using ExternalProject_Add) but which use a variety of > build systems. > > And I want to package the result (so I arrange for the external > projects to build expecting themselves to be installed under > /opt/foo). > > What are good ways to do that, without going in and replacing all the > existing build systems with CMake (which is likely the route we'll > take for some, but doing all doesn't seem practical)? > > A possibility is just to build static rather than shared libraries; > for quite a few cases that would mean nothing would need to be > installed. > > Another one (which would be a bit more general, I think) is to replace > the build with a CMake wrapper, so the building bit calls the > underlying build script but the install part is all done in CMake. In > these cases the numbers of files is usually quite small, so doing that > shouldn't be too annoying, and would presumably produce the right > scripts to use in CPack. > > Any better ideas (or problems I'm missing with the last idea I suggest)? > -- > > 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 Mon May 23 10:57:29 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 23 May 2016 10:57:29 -0400 Subject: [CMake] [cmake-developers] Empty ERROR_VARIABLE in execute_process In-Reply-To: <9280D474-4C0F-49C1-8D0F-BAD13D9A9061@gmx.at> References: <9280D474-4C0F-49C1-8D0F-BAD13D9A9061@gmx.at> Message-ID: <57431A59.5070405@kitware.com> On 05/23/2016 03:25 AM, Roman W?ger wrote: > The output is: > > 1> _resVar: -1 > 1> _outVar: > 1> _errVar: > > It seems that the error pipe isn?t read correctly, because _errVar is empty. I cannot reproduce that. With an empty test.qml file I get: _resVar: -1 _outVar: _errVar: test.qml:1 : Expected token `numeric literal' using the same qmllint version: >c:\Qt\5.6.0\5.6\msvc2015_64\bin\qmllint.exe --version qmllint 1.0 and current CMake 'master'. -Brad From roman.wueger at gmx.at Mon May 23 11:34:21 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Mon, 23 May 2016 17:34:21 +0200 Subject: [CMake] [cmake-developers] Empty ERROR_VARIABLE in execute_process In-Reply-To: <57431A59.5070405@kitware.com> References: <9280D474-4C0F-49C1-8D0F-BAD13D9A9061@gmx.at> <57431A59.5070405@kitware.com> Message-ID: <52CB7295-17FC-4DB4-9064-0B5EFFC682E8@gmx.at> I tried it with CMake 3.5.1 and 3.5.2 and now with the master with the same result. I've attached an example which won't work. Regards Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: TestStdErrOut.zip Type: application/zip Size: 1065 bytes Desc: not available URL: -------------- next part -------------- >> Am 23.05.2016 um 16:57 schrieb Brad King : >> >> On 05/23/2016 03:25 AM, Roman W?ger wrote: >> The output is: >> >> 1> _resVar: -1 >> 1> _outVar: >> 1> _errVar: >> >> It seems that the error pipe isn?t read correctly, because _errVar is empty. > > I cannot reproduce that. With an empty test.qml file I get: > > _resVar: -1 > _outVar: > _errVar: test.qml:1 : Expected token `numeric literal' > > using the same qmllint version: > >> c:\Qt\5.6.0\5.6\msvc2015_64\bin\qmllint.exe --version > qmllint 1.0 > > and current CMake 'master'. > > -Brad > From andrew.melo at gmail.com Mon May 23 12:32:39 2016 From: andrew.melo at gmail.com (Andrew Melo) Date: Mon, 23 May 2016 11:32:39 -0500 Subject: [CMake] Chicken/egg w/CMAKE_C_COMPILER Message-ID: Hi all, I'm wanting to enable a couple of different options to enable/disable compiler wrappers in my project. I would like to do something roughly like this (and something similar to make ccache work right) option(ENABLE_FUZZ "Use AFL fuzz wrapper" OFF) if(ENABLE_FUZZ) set(AFL_PATH /*depends on CMAKE_C_COMPILER_ID*/) set(ENV{AFL_CC} ${CMAKE_C_COMPILER}) set(CMAKE_C_COMPILER ${AFL_PATH}) endif() ..but I hit a chicken and the egg problem. If I place project() above this, cmake gets mad that I changed the compiler with "You have changed variables that require your cache to be deleted....", and messes up all of the set variables. If I place project() below this, CMAKE_C_COMPILER_ID is unset, which means I can't choose the right wrapper for AFL_PATH. Finally, if I do none of the above, and force everyone to do "cmake -DCMAKE_C_COMPILER= ..", the user has to remember to always manually set the AFL_CC environment variable each time they build, or the wrong underlying compiler is chosen What's the best move here? Is there some other "magic" variable I can set to change the actual executable cmake calls, while not triggering a cache rebuild? Is there a robust way to get the "presumptive" compiler ID before project() is called? Thanks! Andrew -- -- Andrew Melo From brad.king at kitware.com Mon May 23 13:33:22 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 23 May 2016 13:33:22 -0400 Subject: [CMake] [cmake-developers] Empty ERROR_VARIABLE in execute_process In-Reply-To: <52CB7295-17FC-4DB4-9064-0B5EFFC682E8@gmx.at> References: <9280D474-4C0F-49C1-8D0F-BAD13D9A9061@gmx.at> <57431A59.5070405@kitware.com> <52CB7295-17FC-4DB4-9064-0B5EFFC682E8@gmx.at> Message-ID: <57433EE2.6020307@kitware.com> On 05/23/2016 11:34 AM, Roman W?ger wrote: > I tried it with CMake 3.5.1 and 3.5.2 and now with the master with > the same result. I've attached an example which won't work. I was able to reproduce it with that, but I also tried this: add_custom_target(${PROJECT_NAME}-c2 COMMAND C:/Qt/5.6/msvc2015/bin/qmllint.exe ${CMAKE_CURRENT_SOURCE_DIR}/test.qml ) The output does not appear in this case either. No execute_process is involved, and qmllint is invoked directly by msbuild. This has something to do with qmllint changing output behavior when it is executed inside a VS IDE (MSBuild) build. -Brad From craig.scott at crascit.com Mon May 23 17:16:39 2016 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 24 May 2016 07:16:39 +1000 Subject: [CMake] Chicken/egg w/CMAKE_C_COMPILER In-Reply-To: References: Message-ID: Maybe not the most elegant, but here's one way. You could initiate a trivial dummy sub-build. By this I mean execute a separate CMake run for a dummy project off to the side somewhere and have it generate a file with the results of the queries you want, then include() that generated file in your main build. The sub-build doesn't have to actually build anything, just run CMake. In your main build, you can then use that knowledge to set AFL_PATH, etc. at the point you wanted to above. Loosely, just so you can get an idea, it would go something like this (untested): *Top level CMakeLists.txt*: option(ENABLE_FUZZ "Use AFL fuzz wrapper" OFF) if(ENABLE_FUZZ) execute_process(COMMAND ${CMAKE_COMMAND} -E mkdir ${CMAKE_CURRENT_BINARY_DIR}/afl_test) execute_process(COMMAND ${CMAKE_COMMAND} ${CMAKE_CURRENT_SOURCE_DIR}/afl_test WORKING_DIR ${CMAKE_CURRENT_BINARY_DIR}/afl_test) include(${CMAKE_CURRENT_BINARY_DIR}/afl_test/afl_setup.cmake) endif() project(MyProj) *afl_test/CMakeLists.txt:* project(AFL_TEST) file(WRITE afl_setup.cmake "set(AFL_PATH /* depends on CMAKE_C_COMPILER_ID */) set(ENV{AFL_CC} ${CMAKE_C_COMPILER}) set(CMAKE_C_COMPILER ${AFL_PATH})") Hopefully that gives you enough of an idea to be able to give this approach a try. On Tue, May 24, 2016 at 2:32 AM, Andrew Melo wrote: > Hi all, > > I'm wanting to enable a couple of different options to enable/disable > compiler wrappers in my project. I would like to do something roughly > like this (and something similar to make ccache work right) > > option(ENABLE_FUZZ "Use AFL fuzz wrapper" OFF) > if(ENABLE_FUZZ) > set(AFL_PATH /*depends on CMAKE_C_COMPILER_ID*/) > set(ENV{AFL_CC} ${CMAKE_C_COMPILER}) > set(CMAKE_C_COMPILER ${AFL_PATH}) > endif() > > ..but I hit a chicken and the egg problem. If I place project() above > this, cmake gets mad that I changed the compiler with "You have > changed variables that require your cache to be deleted....", and > messes up all of the set variables. If I place project() below this, > CMAKE_C_COMPILER_ID is unset, which means I can't choose the right > wrapper for AFL_PATH. Finally, if I do none of the above, and force > everyone to do "cmake -DCMAKE_C_COMPILER= ..", the > user has to remember to always manually set the AFL_CC environment > variable each time they build, or the wrong underlying compiler is > chosen > > What's the best move here? Is there some other "magic" variable I can > set to change the actual executable cmake calls, while not triggering > a cache rebuild? Is there a robust way to get the "presumptive" > compiler ID before project() is called? > > Thanks! > Andrew > > > > -- > -- > Andrew Melo > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaffar.sidek10 at gmail.com Mon May 23 18:33:20 2016 From: jaffar.sidek10 at gmail.com (Jaffar Sidek) Date: Tue, 24 May 2016 06:33:20 +0800 Subject: [CMake] Introduction and Cmake's accessibility Message-ID: <57438530.6020806@gmail.com> Hi all. First, a brief intro. My name is Jaffar Sidek and I am a blind computer programmer and user from Singapore. Would also like to thank the list owner for helping me with my subscription since I couldn't get around to filling up the capture thingy on my own. I first came to know about CMake 2 years ago when I cloned a git repository of SFMl from Git Hub. CMake was needed to build the libraries, so I downloaded CMake to give it a shot. However, 2 years ago, unless I opted for the command line option, The CMake GUI option was a total no go for me because my screen reader simply could not see the output and instructions needed for me to make successful use of it. However, I was pleasantly surprised with the usability of the more recent versions, particularly from v3.50 onwards. Nowadays, CMake is at least partially accessible, meaning that I can use the default configuration options to build libraries of software that I need. However, I do wish that Accessibility of CMake can be improved. First, Here are the more helpful components of CMake that I can access and use successfully. 1. the edit boxes where the source and build directories are to be filled in is accessible. since my sfreen reader announces both correctly. The browse buttons for both the source and build directories also work and are announced correctly. 2. The configure and generate buttons are accessible since the list of compilers available on my system and beyond is correctly spoken by my screen reader, and the generate button is also announced correctly. Now for what that is inaccessible which is that CMake, when there are errors in configuration on my part, or when something that it needs is missing, doesn't output those errors in a way that my screen reader can inform me, which means that I have to actually go to the directory where I am building my app to see what is missing and what went wrong so as to fix my build problems. IF this could be fixed, then CMake would be a truly awesome piece of software. There is also a read only edit box of which I don't know what purpose it serves, and when the configuration button is pressed, there is and edit box right after the combo of compiler choices whose purpose i also am not aware of since it is not described my my screen reader. These are the inaccessible parts that i hope can be dealt with. Thanks and cheers! From eeide at cs.utah.edu Mon May 23 18:30:37 2016 From: eeide at cs.utah.edu (Eric Eide) Date: Mon, 23 May 2016 16:30:37 -0600 Subject: [CMake] How to Determine If a Perl Module Is Installed? Message-ID: Hi! I am a CMake newbie, and I have a question about examining the set of available Perl modules on a system. In CMake (version 2.8.12+), how can I test for the presence of a particular Perl module, e.g., "Sys::CPU"? At the time that CMake is run, I would like to check for the presence of various Perl modules. (These are Perl modules that will eventually be needed when the programs in my project are run, but that are not needed to configure, compile, or install my software as a whole.) If a needed Perl module is not available, I want to issue a CMake-time warning or error. I've Googled around for an answer, and also looked in the archives of this list for the past year, without finding an answer. (This makes me wonder if my question is somehow wrong-headed, since I would expect that checking for Perl modules for be a fairly common thing to do!) I am already using CMake's FindPerl module to find the Perl interpreter itself. Thanks! --- Eric. -- ------------------------------------------------------------------------------- Eric Eide . University of Utah School of Computing http://www.cs.utah.edu/~eeide/ . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX From bruce.r.stephens at gmail.com Mon May 23 18:56:15 2016 From: bruce.r.stephens at gmail.com (Bruce Stephens) Date: Mon, 23 May 2016 23:56:15 +0100 Subject: [CMake] How to Determine If a Perl Module Is Installed? In-Reply-To: References: Message-ID: On Mon, May 23, 2016 at 11:30 PM, Eric Eide wrote: > Hi! I am a CMake newbie, and I have a question about examining the set of > available Perl modules on a system. > > In CMake (version 2.8.12+), how can I test for the presence of a particular > Perl module, e.g., "Sys::CPU"? I think use execute_process to execute a command like perl -MSys::CPU -e "" So, something like execute_process(COMMAND ${PERL_EXECUTABLE} -MSys::CPU -e "" ERROR_QUIET RESULT_VARIABLE status) if ${status} is zero then the module exists, otherwise it doesn't. You can wrap it in a function, obviously. From lukaszb at microsoft.com Mon May 23 22:34:28 2016 From: lukaszb at microsoft.com (Lukasz Bartnik) Date: Tue, 24 May 2016 02:34:28 +0000 Subject: [CMake] INSTALL with PERMISSIONS changes the binary Message-ID: Hi Everyone, I'm trying to solve a rather peculiar (at least to me) artifact of CMake's install(). I have a binary file (elf) that I call install() on to copy it and later package with CPack. Specifying no permissions results in a RPM extracting in 0444 mode, whereas specifying USE_SOURCE_PERMISSIONS or setting PERMISSIONS explicitly results in the binary being re-written with the current OS's elf utilities, which changes the binary and later leads to this error when I attempt to execute it: "unsupported version 0 of Verneed record" The file extracted from RPM has different MD5 checksum and size - and when I look into cmake_build/_CPack_Packages/Linux/RPM/..../executable I can see it's been already changed there. Is there any way to make CMake keep permissions in RPM but not change the executable itself? Best regards, Lukasz -------------- next part -------------- An HTML attachment was scrubbed... URL: From eeide at cs.utah.edu Mon May 23 22:52:41 2016 From: eeide at cs.utah.edu (Eric Eide) Date: Mon, 23 May 2016 20:52:41 -0600 Subject: [CMake] How to Determine If a Perl Module Is Installed? In-Reply-To: (Bruce Stephens's message of "Mon, 23 May 2016 23:56:15 +0100") References: Message-ID: Bruce Stephens writes: > execute_process(COMMAND ${PERL_EXECUTABLE} -MSys::CPU -e "" > ERROR_QUIET RESULT_VARIABLE status) Thank you very much for the tip! The command above works very well for me. As a CMake newbie, I was afraid that I was overlooking some sort of "prepackaged" version of this. Eric. -- ------------------------------------------------------------------------------- Eric Eide . University of Utah School of Computing http://www.cs.utah.edu/~eeide/ . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX From roman.wueger at gmx.at Tue May 24 00:09:38 2016 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 24 May 2016 06:09:38 +0200 Subject: [CMake] [cmake-developers] Empty ERROR_VARIABLE in execute_process In-Reply-To: <57433EE2.6020307@kitware.com> References: <9280D474-4C0F-49C1-8D0F-BAD13D9A9061@gmx.at> <57431A59.5070405@kitware.com> <52CB7295-17FC-4DB4-9064-0B5EFFC682E8@gmx.at> <57433EE2.6020307@kitware.com> Message-ID: <0F2A27A3-EB27-4F3C-8F3E-C6538B9D2501@gmx.at> Ok, thanks Brad. Hello Qt Mailing list, First i thought this is a bug in CMake but it has appeared that it seems to be a bug in qmllint: Here the original question: when I run qmllint from the command line to test an error I get: C:\Tests>C:\Qt\5.6\msvc2015\bin\qmllint.exe test.qml test.qml:1 : Syntax error C:\Tests>echo %ERRORLEVEL% -1 C:\Tests> If I call this from a CMake script execute_process(COMMAND C:/Qt/5.6/msvc2015/bin/qmllint.exe C:/Tests/test.qml RESULT_VARIABLE _resVar OUTPUT_VARIABLE _outVar ERROR_VARIABLE _errVar OUTPUT_STRIP_TRAILING_WHITESPACE ERROR_STRIP_TRAILING_WHITESPACE) message("_resVar: ${_resVar}") message("_outVar: ${_outVar}") message("_errVar: ${_errVar}") The output is: 1> _resVar: -1 1> _outVar: 1> _errVar: It seems that the error pipe isn?t read correctly, because _errVar is empty. And hints? Regards Roman > Am 23.05.2016 um 19:33 schrieb Brad King : > >> On 05/23/2016 11:34 AM, Roman W?ger wrote: >> I tried it with CMake 3.5.1 and 3.5.2 and now with the master with >> the same result. I've attached an example which won't work. > > I was able to reproduce it with that, but I also tried this: > > add_custom_target(${PROJECT_NAME}-c2 > COMMAND C:/Qt/5.6/msvc2015/bin/qmllint.exe ${CMAKE_CURRENT_SOURCE_DIR}/test.qml > ) > > The output does not appear in this case either. No execute_process > is involved, and qmllint is invoked directly by msbuild. This has > something to do with qmllint changing output behavior when it is > executed inside a VS IDE (MSBuild) build. > > -Brad > From bruce.r.stephens at gmail.com Tue May 24 04:49:44 2016 From: bruce.r.stephens at gmail.com (Bruce Stephens) Date: Tue, 24 May 2016 09:49:44 +0100 Subject: [CMake] How to Determine If a Perl Module Is Installed? In-Reply-To: References: Message-ID: On Tue, May 24, 2016 at 3:52 AM, Eric Eide wrote: > As a CMake newbie, I was afraid that I was overlooking some sort of > "prepackaged" version of this. Doesn't look like it, but I agree it's the kind of thing that might be usefully included with CMake. From zcsd2012 at gmail.com Tue May 24 05:34:52 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Tue, 24 May 2016 02:34:52 -0700 (MST) Subject: [CMake] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly In-Reply-To: References: <1463732918230-7593495.post@n2.nabble.com> <1463749042750-7593503.post@n2.nabble.com> <1463984639443-7593518.post@n2.nabble.com> Message-ID: <1464082492611-7593539.post@n2.nabble.com> This CMake feature is interesting, the first step i plan is to make the project work first, then i will try to optimize it, and i think this feature would be used next step. Thanks. :-) Chuck Atkins wrote > If you know the full path to the library then I'd suggest using it as > /path/to/foo/libfoo.a (or .so if it's shared) instead of -L/path/to/foo > -lfoo. CMake will adjust the flags to -L and -l if needed but the > preference is always to use the full library path. > > - Chuck > > On Mon, May 23, 2016 at 2:23 AM, Chaos Zhang < > zcsd2012@ > > wrote: > >> Thanks a lot! `set(FOO_LIBRARY "-Wl,--whole-archive ${FOO_LIBRARY} >> -Wl,--no-whole-archive")` worked when the content of ${FOO_LIBRARY} look >> like `-Ldir -llib`, if just use lib name as the content of >> ${FOO_LIBRARY}, >> error while occur. >> >> Chuck Atkins wrote >> >> -rpath >> > >> > >> > RPATHs are automatically added by CMake to executables so they can use >> > libraries from the build tree. >> > >> > >> > >> >> -whole-archive >> >> >> > >> > whole-archive is definitely trickier since you shouldn't be applying it >> to >> > the entire executable but instead wrapping individual libraries with >> it. >> > Conveniently, you can pass link options directly with >> > target_link_libraries. So you could have: >> > >> > # Just an example, find_library calls should really be isolated to >> > separate >> > find modules >> > find_library(FOO_LIBRARY foo) >> > set(FOO_LIBRARY "-Wl,--whole-archive ${FOO_LIBRARY} >> > -Wl,--no-whole-archive") >> > >> > add_executable(hello main.c) >> > target_link_libraries(hello ${FOO_LIBRARY}) >> > >> > >> >>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello") >> >> >> > >> > CMAKE_EXE_LINKER_FLAGS should work for other more general cases that >> > aren't >> > tied to specific libraries. The problem with your example is likely >> not >> > using an absolute path for -L since the compilation is actually taking >> > place in a nested work directory somewhere. >> > >> > -- >> > >> > Powered by www.kitware.com >> > >> > Please keep messages on-topic and check the CMake FAQ at: >> > http://www.cmake.org/Wiki/CMake_FAQ >> > >> > Kitware offers various services to support the CMake community. For >> more >> > information on each offering, please visit: >> > >> > CMake Support: http://cmake.org/cmake/help/support.html >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> > CMake Training Courses: http://cmake.org/cmake/help/training.html >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/cmake >> >> >> >> >> >> -- >> View this message in context: >> http://cmake.3232098.n2.nabble.com/How-to-use-CMAKE-EXE-LINKER-FLAGS-correctly-tp7593495p7593518.html >> Sent from the CMake mailing list archive at Nabble.com. >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- View this message in context: http://cmake.3232098.n2.nabble.com/How-to-use-CMAKE-EXE-LINKER-FLAGS-correctly-tp7593495p7593539.html Sent from the CMake mailing list archive at Nabble.com. From Harry at codexdigital.com Tue May 24 06:15:02 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Tue, 24 May 2016 10:15:02 +0000 Subject: [CMake] Recommended style for multiple CPack generator folder structures Message-ID: On OSX we install an .app to /Applications/Foo/Bar.app. So the install() is set like: add_executable(bar MACOSX_BUNDLE bar.cpp ) install(TARGETS bar COMPONENT bar DESTINATION "Applications/Foo" ) When making DMG (DragNDrop) installers I really want the DMG to contain just the .app bundle rather than the full folder structure. Is there a sensible way to do this? Harry Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 From Harry at codexdigital.com Tue May 24 07:40:17 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Tue, 24 May 2016 11:40:17 +0000 Subject: [CMake] Recommended style for multiple CPack generator folder structures Message-ID: <6E6DDAE1-7158-4505-84BD-6A94EBA215D5@codexdigital.com> In answer to my own question. One way to do it which seems quite neat is as follows. Using multiple installs: install(TARGETS bar COMPONENT bar DESTINATION "Applications/Foo" ) install(TARGETS bar COMPONENT bar-standalone DESTINATION "./" # This must be "./" not "/" as it has to be a relative path ) This in your CPACK_PROJECT_CONFIG_FILE: if (CPACK_GENERATOR STREQUAL DragNDrop) set(CPACK_COMPONENTS_ALL bar-standalone) endif() Harry Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 From clinton at elemtech.com Tue May 24 15:03:48 2016 From: clinton at elemtech.com (clinton at elemtech.com) Date: Tue, 24 May 2016 13:03:48 -0600 (MDT) Subject: [CMake] Recommended style for multiple CPack generator folder structures In-Reply-To: <6E6DDAE1-7158-4505-84BD-6A94EBA215D5@codexdigital.com> References: <6E6DDAE1-7158-4505-84BD-6A94EBA215D5@codexdigital.com> Message-ID: <1294082746.30629151.1464116628014.JavaMail.zimbra@elemtech.com> I prefer one for both installing and creating packages. install(TARGETS bar COMPONENT bar DESTINATION "./" # This must be "./" not "/" as it has to be a relative path ) Then set CMAKE_PREFIX_PATH=/Applications/Foo when you do an install. CMAKE_PREFIX_PATH will be pre-pended to relative paths given in install() commands. Clint ----- On May 24, 2016, at 5:40 AM, Harry Mallon Harry at codexdigital.com wrote: > In answer to my own question. One way to do it which seems quite neat is as > follows. Using multiple installs: > > install(TARGETS bar > COMPONENT bar > DESTINATION "Applications/Foo" > ) > > install(TARGETS bar > COMPONENT bar-standalone > DESTINATION "./" # This must be "./" not "/" as it has to be a relative path > ) > > This in your CPACK_PROJECT_CONFIG_FILE: > > if (CPACK_GENERATOR STREQUAL DragNDrop) > set(CPACK_COMPONENTS_ALL bar-standalone) > endif() > > Harry > > Harry Mallon > CODEX | Software Engineer > 60 Poland Street | London | England | W1F 7NT > E harry at codexdigital.com | T +44 203 7000 989 > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From chrysalisx at gmail.com Tue May 24 16:02:48 2016 From: chrysalisx at gmail.com (Walter Gray) Date: Tue, 24 May 2016 20:02:48 +0000 Subject: [CMake] Cross Compilation & Source file generators In-Reply-To: References: Message-ID: @Hendrik - Yes, unfortunately it didn't help me too much. Superbuilds are not really an appropriate solution here - The project I'm working on is too heavily down an alternative path, and I'm trying to set up the exported .cmake files in the protobuf 3.0 beta to properly support any sort of option. I suppose the question I should have asked is 'When setting up exported package config files, what is the best way to handle the case where some users will want to mix and match components based on platform?'. The concept of a protobuf_PROTOC override variable would certainly do the job, but seems like a bit of a hack. I'd like to establish what the canonical 'best practice' for solving this problem should be in a way that supports using pre-built libraries. I'm thinking if I split the protobuf project's exports into 2 components, one for the libraries and one for protoc, I can have clients call find_package twice with different search paths and component lists, and add some checks to reject a match if, for example, someone targeting arm tries to link libraries compiled for mac. On Mon, May 23, 2016 at 5:17 AM David E DeMarle wrote: > Just to clarify, although ParaView's superbuild assists you to set up and > compile in either "compile TOOLS" or "CROSS compile" mode (or the default > "HOST" mode) the protobuf inclusion I was speaking of in is found within > paraview's source code and is not an external project. > See ${PVSOURCE}/ThirdParty/protobuf > > hope that helps > > On Saturday, May 21, 2016, Craig Scott wrote: > >> There's also the technique described in this stack overflow >> question/answer: >> >> >> http://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run >> >> I'd probably recommend the superbuild approach used by Paraview though if >> your build can be structured that way. With the superbuild approach, it's a >> bit easier to tell what's going on. The method in the above link would only >> be better if you really needed to keep everything in the one single build. >> >> >> >> >> On Sat, May 21, 2016 at 11:10 PM, David E DeMarle < >> dave.demarle at kitware.com> wrote: >> >>> Take a look at paraview's internal copy of protobuf. We compile protoc >>> in the host tools pass and then use it when we build libprotobuf in the >>> cross compile pass. >>> On May 20, 2016 10:14 PM, "Walter Gray" wrote: >>> >>>> A small addendum - The way I am currently solving this problem is by >>>> replacing the version of protoc in the library folder for android with one >>>> that works on the host machine, but this is really not the best since it >>>> means that the library distribution is tied to the host AND the target. >>>> >>>> Thinking in terms of concepts, I think I would want a find_package that >>>> understood the difference between finding a package for executing and >>>> finding a package for linking, but that'd be a pretty fundamental change. >>>> >>>> On Fri, May 20, 2016 at 7:02 PM Walter Gray >>>> wrote: >>>> >>>>> I've got a project with a number of target platforms, including some >>>>> that I have to cross-compile to such as android, that uses protobuf. If >>>>> you're unfamiliar, the crux of the issue is that there is both a library, >>>>> libprotobuf, and an 'compiler', protoc, that takes .proto files and >>>>> generates a .h/.cc pair that are then included in the project. >>>>> >>>>> When cross compiling, want to use the libprotobuf that was compiled on >>>>> andriod, but the protoc that was compiled for my host environment. How >>>>> could this be achieved? >>>>> >>>>> Currently, my build machine has several different directories where I >>>>> store the external libraries that have been compiled for the various >>>>> platforms/compilers that we support (Libraries-arm32, Libraries-x64, >>>>> Libraries-x64-vc14, ect). >>>>> >>>>> Solutions that require modifying protobuf's -config.cmake file are >>>>> welcome, I've already submitted several PR's improving it. I'd like to >>>>> establish what the best practice for this kind of situation is as I have >>>>> the same issue with Flatbuffers. >>>>> >>>>> On a slightly unrelated note, is there some way to write something >>>>> like the AUTOUIC system without modifying cmake itself? It would be lovely >>>>> if all I had to do was include the .proto file in the source file list. >>>>> >>>>> Thanks! >>>>> Walter >>>>> >>>> >>>> -- >>>> >>>> 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 >>> >> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> http://crascit.com >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at classdesign.com Tue May 24 16:55:04 2016 From: bill at classdesign.com (Bill Somerville) Date: Tue, 24 May 2016 21:55:04 +0100 Subject: [CMake] Mac OS X framework building Message-ID: <5984716a-b967-c075-26cc-af179cda9267@classdesign.com> Hi All, I am trying to make a framework using a shared library. The docs say that the target property PUBLIC_HEADER should be a list of interface header files that install(TARGET ...) will populate .../.framework/Headers/ with but I cannot get that to happen. I have set the target property FRAMEWORK to TRUE and the target is a SHARED library. The framework gets created with the Versions and Resources directories etc. and the .plist file and the dylib is added with all the relevant symlinks. No headers are being added and the Headers directory is not being created. Can anyone help with what I am missing or provide a link to a project that creates a Mac OS X framework successfully using install(TARGETS ...)? TIA Bill. From chrysalisx at gmail.com Tue May 24 20:52:29 2016 From: chrysalisx at gmail.com (Walter Gray) Date: Wed, 25 May 2016 00:52:29 +0000 Subject: [CMake] CMake "Core Guidelines"? Message-ID: It occurs to me that, much like C++ itself, there are wide variety of ways to do things in CMake, many of which exist only for legacy compatibility, and the language had a lot of active develpment recently that allows much safer, easier to read programs. C++ now has the Core Guidelines and lots of example projects providing reference for what a good, modern project should look like, even providing automated tools for detecting when you're doing things in a way that is considered archatic, but all CMake has is a blog post and an old powerpoint slide. Seriously, these are the 2 top hits for 'Modern CMake'. Both are almost a year old, neither are in depth, and one references the other: https://rix0r.nl/blog/2015/08/13/cmake-guide/ http://www.slideshare.net/DanielPfeifer1/cmake-48475415 Is there some document that explains how modern cmake is meant to be used, or a particular repository that does so? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dflogeras2 at gmail.com Tue May 24 21:05:14 2016 From: dflogeras2 at gmail.com (Dave Flogeras) Date: Tue, 24 May 2016 22:05:14 -0300 Subject: [CMake] Cross Compilation & Source file generators In-Reply-To: References: Message-ID: Another "outside the box" solution that I have had success with is as follows (Note this solution will only work with Linux): You can use the Linux binfmt_misc driver to execute non-native executables through an interpreter. If you google for qemu binfmt wrapper, you'll find various suitable approaches, but basically, you register a wrapper executable that calls binaries via qemu if the shell detects that it is of a specific type (namely ARM elf). After that, you can run the detected protoc "natively". Note this also has the side benefit of protoc will always match the version of the protobuf headers. I had earlier hacked my build system into finding my ARM installaed protobuf headers, but using the native protoc, but it complained because they weren't exactly the same version, which is unsupported under protobuf IIRC. Hope that helps, Dave On Tue, May 24, 2016 at 5:02 PM, Walter Gray wrote: > @Hendrik - Yes, unfortunately it didn't help me too much. > Superbuilds are not really an appropriate solution here - The project I'm > working on is too heavily down an alternative path, and I'm trying to set > up the exported .cmake files in the protobuf 3.0 beta to properly support > any sort of option. > > I suppose the question I should have asked is 'When setting up exported > package config files, what is the best way to handle the case where some > users will want to mix and match components based on platform?'. > > The concept of a protobuf_PROTOC override variable would certainly do the > job, but seems like a bit of a hack. I'd like to establish what the > canonical 'best practice' for solving this problem should be in a way that > supports using pre-built libraries. > > I'm thinking if I split the protobuf project's exports into 2 components, > one for the libraries and one for protoc, I can have clients call > find_package twice with different search paths and component lists, and add > some checks to reject a match if, for example, someone targeting arm tries > to link libraries compiled for mac. > > On Mon, May 23, 2016 at 5:17 AM David E DeMarle > wrote: > >> Just to clarify, although ParaView's superbuild assists you to set up and >> compile in either "compile TOOLS" or "CROSS compile" mode (or the default >> "HOST" mode) the protobuf inclusion I was speaking of in is found within >> paraview's source code and is not an external project. >> See ${PVSOURCE}/ThirdParty/protobuf >> >> hope that helps >> >> On Saturday, May 21, 2016, Craig Scott wrote: >> >>> There's also the technique described in this stack overflow >>> question/answer: >>> >>> >>> http://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run >>> >>> I'd probably recommend the superbuild approach used by Paraview though >>> if your build can be structured that way. With the superbuild approach, >>> it's a bit easier to tell what's going on. The method in the above link >>> would only be better if you really needed to keep everything in the one >>> single build. >>> >>> >>> >>> >>> On Sat, May 21, 2016 at 11:10 PM, David E DeMarle < >>> dave.demarle at kitware.com> wrote: >>> >>>> Take a look at paraview's internal copy of protobuf. We compile protoc >>>> in the host tools pass and then use it when we build libprotobuf in the >>>> cross compile pass. >>>> On May 20, 2016 10:14 PM, "Walter Gray" wrote: >>>> >>>>> A small addendum - The way I am currently solving this problem is by >>>>> replacing the version of protoc in the library folder for android with one >>>>> that works on the host machine, but this is really not the best since it >>>>> means that the library distribution is tied to the host AND the target. >>>>> >>>>> Thinking in terms of concepts, I think I would want a find_package >>>>> that understood the difference between finding a package for executing and >>>>> finding a package for linking, but that'd be a pretty fundamental change. >>>>> >>>>> On Fri, May 20, 2016 at 7:02 PM Walter Gray >>>>> wrote: >>>>> >>>>>> I've got a project with a number of target platforms, including some >>>>>> that I have to cross-compile to such as android, that uses protobuf. If >>>>>> you're unfamiliar, the crux of the issue is that there is both a library, >>>>>> libprotobuf, and an 'compiler', protoc, that takes .proto files and >>>>>> generates a .h/.cc pair that are then included in the project. >>>>>> >>>>>> When cross compiling, want to use the libprotobuf that was compiled >>>>>> on andriod, but the protoc that was compiled for my host environment. How >>>>>> could this be achieved? >>>>>> >>>>>> Currently, my build machine has several different directories where I >>>>>> store the external libraries that have been compiled for the various >>>>>> platforms/compilers that we support (Libraries-arm32, Libraries-x64, >>>>>> Libraries-x64-vc14, ect). >>>>>> >>>>>> Solutions that require modifying protobuf's -config.cmake file are >>>>>> welcome, I've already submitted several PR's improving it. I'd like to >>>>>> establish what the best practice for this kind of situation is as I have >>>>>> the same issue with Flatbuffers. >>>>>> >>>>>> On a slightly unrelated note, is there some way to write something >>>>>> like the AUTOUIC system without modifying cmake itself? It would be lovely >>>>>> if all I had to do was include the .proto file in the source file list. >>>>>> >>>>>> Thanks! >>>>>> Walter >>>>>> >>>>> >>>>> -- >>>>> >>>>> 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 >>>> >>> >>> >>> >>> -- >>> Craig Scott >>> Melbourne, Australia >>> http://crascit.com >>> >> > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrysalisx at gmail.com Tue May 24 21:28:29 2016 From: chrysalisx at gmail.com (Walter Gray) Date: Wed, 25 May 2016 01:28:29 +0000 Subject: [CMake] Cross Compilation & Source file generators In-Reply-To: References: Message-ID: Nope, sorry. We build android from mac and windows too. And again, I'm more concerned with how protobuf's config.cmake scripts should be set up to easily enable users to deal with this problem. I'm trying to get their build scripts up to date before 3.0.0 leaves beta. On Tue, May 24, 2016 at 6:05 PM Dave Flogeras wrote: > Another "outside the box" solution that I have had success with is as > follows (Note this solution will only work with Linux): > > You can use the Linux binfmt_misc driver to execute non-native executables > through an interpreter. If you google for qemu binfmt wrapper, you'll find > various suitable approaches, but basically, you register a wrapper > executable that calls binaries via qemu if the shell detects that it is of > a specific type (namely ARM elf). > > After that, you can run the detected protoc "natively". Note this also > has the side benefit of protoc will always match the version of the > protobuf headers. I had earlier hacked my build system into finding my ARM > installaed protobuf headers, but using the native protoc, but it complained > because they weren't exactly the same version, which is unsupported under > protobuf IIRC. > > Hope that helps, > Dave > > On Tue, May 24, 2016 at 5:02 PM, Walter Gray wrote: > >> @Hendrik - Yes, unfortunately it didn't help me too much. >> Superbuilds are not really an appropriate solution here - The project I'm >> working on is too heavily down an alternative path, and I'm trying to set >> up the exported .cmake files in the protobuf 3.0 beta to properly support >> any sort of option. >> >> I suppose the question I should have asked is 'When setting up exported >> package config files, what is the best way to handle the case where some >> users will want to mix and match components based on platform?'. >> >> The concept of a protobuf_PROTOC override variable would certainly do the >> job, but seems like a bit of a hack. I'd like to establish what the >> canonical 'best practice' for solving this problem should be in a way that >> supports using pre-built libraries. >> >> I'm thinking if I split the protobuf project's exports into 2 components, >> one for the libraries and one for protoc, I can have clients call >> find_package twice with different search paths and component lists, and add >> some checks to reject a match if, for example, someone targeting arm tries >> to link libraries compiled for mac. >> >> On Mon, May 23, 2016 at 5:17 AM David E DeMarle >> wrote: >> >>> Just to clarify, although ParaView's superbuild assists you to set up >>> and compile in either "compile TOOLS" or "CROSS compile" mode (or the >>> default "HOST" mode) the protobuf inclusion I was speaking of in is found >>> within paraview's source code and is not an external project. >>> See ${PVSOURCE}/ThirdParty/protobuf >>> >>> hope that helps >>> >>> On Saturday, May 21, 2016, Craig Scott wrote: >>> >>>> There's also the technique described in this stack overflow >>>> question/answer: >>>> >>>> >>>> http://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run >>>> >>>> I'd probably recommend the superbuild approach used by Paraview though >>>> if your build can be structured that way. With the superbuild approach, >>>> it's a bit easier to tell what's going on. The method in the above link >>>> would only be better if you really needed to keep everything in the one >>>> single build. >>>> >>>> >>>> >>>> >>>> On Sat, May 21, 2016 at 11:10 PM, David E DeMarle < >>>> dave.demarle at kitware.com> wrote: >>>> >>>>> Take a look at paraview's internal copy of protobuf. We compile protoc >>>>> in the host tools pass and then use it when we build libprotobuf in the >>>>> cross compile pass. >>>>> On May 20, 2016 10:14 PM, "Walter Gray" wrote: >>>>> >>>>>> A small addendum - The way I am currently solving this problem is by >>>>>> replacing the version of protoc in the library folder for android with one >>>>>> that works on the host machine, but this is really not the best since it >>>>>> means that the library distribution is tied to the host AND the target. >>>>>> >>>>>> Thinking in terms of concepts, I think I would want a find_package >>>>>> that understood the difference between finding a package for executing and >>>>>> finding a package for linking, but that'd be a pretty fundamental change. >>>>>> >>>>>> On Fri, May 20, 2016 at 7:02 PM Walter Gray >>>>>> wrote: >>>>>> >>>>>>> I've got a project with a number of target platforms, including some >>>>>>> that I have to cross-compile to such as android, that uses protobuf. If >>>>>>> you're unfamiliar, the crux of the issue is that there is both a library, >>>>>>> libprotobuf, and an 'compiler', protoc, that takes .proto files and >>>>>>> generates a .h/.cc pair that are then included in the project. >>>>>>> >>>>>>> When cross compiling, want to use the libprotobuf that was compiled >>>>>>> on andriod, but the protoc that was compiled for my host environment. How >>>>>>> could this be achieved? >>>>>>> >>>>>>> Currently, my build machine has several different directories where >>>>>>> I store the external libraries that have been compiled for the various >>>>>>> platforms/compilers that we support (Libraries-arm32, Libraries-x64, >>>>>>> Libraries-x64-vc14, ect). >>>>>>> >>>>>>> Solutions that require modifying protobuf's -config.cmake file are >>>>>>> welcome, I've already submitted several PR's improving it. I'd like to >>>>>>> establish what the best practice for this kind of situation is as I have >>>>>>> the same issue with Flatbuffers. >>>>>>> >>>>>>> On a slightly unrelated note, is there some way to write something >>>>>>> like the AUTOUIC system without modifying cmake itself? It would be lovely >>>>>>> if all I had to do was include the .proto file in the source file list. >>>>>>> >>>>>>> Thanks! >>>>>>> Walter >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Craig Scott >>>> Melbourne, Australia >>>> http://crascit.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 biddisco at cscs.ch Wed May 25 04:35:37 2016 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Wed, 25 May 2016 08:35:37 +0000 Subject: [CMake] linking OBJECT libraries : Argument list too long Message-ID: <50320452A334BD42A5EC72BAD21450993DF97402@MBX210.d.ethz.ch> When building OpenBLAS on OSX, the link line generated contains around 350K of text, and the max supported arg length is getconf ARG_MAX - returns 262144. This causes the link phase to abort with Error running link command: Argument list too long The reason for the problem is that many libraries of Type OBJECT are built and produce huge numbers of object files are then added to one very large list which is then passed to the linker. I implemented a simple(ish) fix, that doesn't quite work - for each subdirectory that generates object files, I set the CMAKE_FILES_DIRECTORY and specify the binary directory where the build should go using a single character counter 0,1,2,3,4 which is much shorter than the target name and it reduces the final arg size down almost enough set(COUNTER_ 0) foreach (SUBDIR ${SUBDIRS}) set(CMAKE_FILES_DIRECTORY "/${COUNTER_}") add_subdirectory(${SUBDIR} ${CMAKE_BINARY_DIR}/${COUNTER_}) ..... MATH(EXPR COUNTER_ "${COUNTER_}+1") endforeach () example : make driver_level2 target [ 0%] Building C object OpenBLAS/driver/level2/CMakeFiles/driver_level2.dir/CMakeFiles/ssbmv_U.c.o becomes [ 0%] Building C object 1/CMakeFiles/driver_level2.dir/1/ssbmv_U.c.o and the link line is correspondingly shorter as the driver_level2 has been replaced in 2 places. The problem is that there is still an extra "CMakeFiles/driver_level2.dir" in the path to the object file that I would like to shorten/remove. How can I do that? NB. I am aware that I can turn the OBJECT libraries into normal libraries and link them conventionally, but I'd like to make this path shortening method work. 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 patrick.boettcher at posteo.de Wed May 25 05:39:02 2016 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Wed, 25 May 2016 11:39:02 +0200 Subject: [CMake] C header file cross dependency In-Reply-To: <56E920142ED81D4FBE3260E4B9D1DB3E97208951@ROTSRV13.Neuberger.local> References: <56E920142ED81D4FBE3260E4B9D1DB3E97208951@ROTSRV13.Neuberger.local> Message-ID: <20160525113902.0eb6f70d@posteo.de> On Mon, 23 May 2016 13:49:14 +0000 Wagner Martin wrote: > Hi @all, > > I'm quite new to CMake. If I've made a mistake or something is much > easier to solve, please tell me. > > I'd like to use CMake in embedded development (Build System: Linux, > Target: ARM Microcontroller) to get rid of complicated makefiles. Good thing! > We're building multiple devices where stuff like embedded rtos and > peripheral drivers are identical, so I'd like to separate this part > from the user application. I've achieved that by creating an object > library out of all source and header files, and packing those files > using CPack. This archive is then statically linked against the user > application. > > So far this worked fine. However, now I have to use driver functions > in the rtos source code and vice versa, resulting in > cross-dependencies for header files: > > > > #include uart.h > #include terminal.h > > function() {} > > > > #include terminal.h > #include uart.h > > function() {} > > How do I resolve something like this? Right now CMake evaluates the > compiler includes in the order that subdirectories are added. This > gives me an compilation error in uart.c that terminal.h cannot be > found. This is not a cmake-problem, but seems to be a code-structure-issue. I'm guessing here: if terminal needs the uart-code shouldn't it be the uart-code filling in a terminal-function. Interface vs. implementation? Could you elaborate more on how terminal and uart are linked? Regarding cmake: I suggest you stop using include_directories() and start using target_include_directories() and target_compile_definitions() instead of add_definitions(). Limiting yourself to this way of doing libraries and targets, cmake will force you to structure your code in a more standard way - and will provide you with clean visibility between different targets. Could you provide a working, stripped down example to show the problem provided via github (in an example repo). More comments below. > Some excerpt of my project. I've tried to keep the example as simple > as possible. > > My directory structure looks something like that: > / > CMakeLists.txt > src + > +CMakeLists.txt (1) > +drivers+ > | +uart.c > | +uart.h > | +... > | +CMakeLists.txt (2) > +os-----+ > | +terminal.c > | +terminal.h > | +... > | +CMakeLists.txt (3) > > > (1): > > SET(drivers "drivers") > SET(terminal "terminal") > > SET(drivers_lib ${drivers}) > SET(terminal_lib ${terminal}) > > SET(ARCHIVE_INSTALL_DIR lib) > SET(INCLUDE_INSTALL_DIR include) > > SET(headers_private "_headers_private") # internal headers > SET(headers_public "_headers_public") # public headers go into > package > > ADD_SUBDIRECTORY(${drivers}) > ADD_SUBDIRECTORY(${terminal}) I think it is common practice now to use lower-case for cmake-commands now. > ## drivers > > ## ---- Sources > ------------------------------------------------------------------- > SET(sources "uart.c" > ) > > ## ---- Header includes > ----------------------------------------------------------- > SET(headers "${CMAKE_CURRENT_SOURCE_DIR}/" > ) > SET(${drivers}${headers_public} ${headers} PARENT_SCOPE) > > INCLUDE_DIRECTORIES(${headers} > ${${terminal}${headers_public}} > ) While the ${${var}${var2}} (seems to) work, it is error-prone, IMHO. Standard cmake-commands can work with relative paths and are evaluating them correctly taking into account ${CMAKE_CURRENT_SOURCE_DIR} (most of the time. So you could use ../uart in terminal/ - but it would be better if it comes indirectly via target_include_directories() and target_link_libraries() >[..] > > And finally this creates the package in root directory CMakeLists.txt: > > SET(CPACK_PROJECT_CONFIG_FILE ${CMAKE_BINARY_DIR}/CPackOptions.cmake) > # CPackOptions.cmake contains package file name SET(CPACK_GENERATOR > "TBZ2") INCLUDE(CPack) Due to the circular header-dependency the binaries of terminal and uart should have the same mutual dependency. In this case you could build them in within one target. regards -- Patrick. From ire866306 at gmail.com Wed May 25 12:48:30 2016 From: ire866306 at gmail.com (irene w) Date: Wed, 25 May 2016 12:48:30 -0400 Subject: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later. Message-ID: Hi, I am compiling a simple Qt3 application on Linux using CMake. In my case, I need to build moc_xxx files with custom options and output to a specified directory, So, I was not using CAMKE_AUTO macros. My cmake scripts create a "Qt_tmp" directory and output moc_xxx there. It looked it always failed to link the moc_xxx files for the first time build when there is no "Qt_tmp" directory, and succeeded if I ran build again if the "Qt_tmp" directory and moc_xxx files created by the failed build were kept without removing. However, it'll fail if I delete the "Qt_tmp" directory. Even it failed at the first build, the moc_xxx files were successfully created in the "Qt_tmp" directory. Here is my cmake scripts and the errors I got. Can anyone help me to figure out the issues? Any help would be greatly appreciated. Thanks. CMakeLists.txt --------------------------------------------------------------------------------------------- cmake_minimum_required(VERSION 3.4.1) project (GM_Application CXX) SET (CMAKE_SYSTEM_NAME Linux) SET (CMAKE_CXX_COMPILER ${COMPILER_PATH}${CROSS_COMPILE}g++) set (GM_DIR ${CMAKE_CURRENT_SOURCE_DIR}) set (QT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6) LINK_DIRECTORIES (${QT_DIR}/lib) INCLUDE_DIRECTORIES ("${QT_DIR}/include" "${GM_DIR}" ) ##### Compiling QT moc and ui ##### set (QT_MOC_CMD ${QT_DIR}/bin/moc -I$(QT_DIR)/mkspecs/linux-g++ -I${QT_DIR}/include -I${QT_DIR}/include/QtGui) file (MAKE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) set (Qt_tmp ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) add_custom_target (Moc_GMWindows COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o ${Qt_tmp}/moc_GMWindow.cpp ) ##### Compiling application ##### file (GLOB GM_SOURCES ${GM_DIR}/*.h ${GM_DIR}/*.cpp) file (GLOB Moc_SOURCES ${Qt_tmp}/*.h ${Qt_tmp}/*.cpp) add_executable (GM ${GM_SOURCES} ${Moc_SOURCES}) target_include_directories (GM PRIVATE ${Qt_tmp}) add_dependencies (GM Moc_GMWindows) target_link_libraries (GM QtGui) ------------------------------------------------------------------------------------------- Errors: Scanning dependencies of target Moc_GMWindows [ 0%] Built target Moc_GMWindows Scanning dependencies of target GM [ 14%] Building CXX object GM/CMakeFiles/GM.dir/GM/GM.cpp.o [ 42%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMService.cpp.o [ 67%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMWindow.cpp.o [ 85%] Building CXX object GM/CMakeFiles/GM.dir/GM/main.cpp.o [100%] Linking CXX executable ../bin/GM CMakeFiles/GM.dir/GM/GMWindow.cpp.o: In function `GM::GMWindow::emitAppendMessage(QStrin g)': /GM/GMWindow.cpp:217: undefined reference to `GM::GMWindow::appendMessage(QString)' CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable for GM::GMWindow] +0x8): undefined reference to `GM::GMWindow::metaObject() const' CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable for GM::GMWindow] +0xc): undefined reference to `GM::GMWindow::qt_metacast(char const*)' CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable for GM::GMWindow] +0x10): undefined reference to `GM::GMWindow::qt_metacall(QMetaObject::Call, int, void**)' collect2: ld returned 1 exit status make[2]: *** [bin/GM] Error 1 make[1]: *** [GM/CMakeFiles/GM.dir/all] Error 2 make: *** [all] Error 2 Virus-free. www.avast.com <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaorenl at google.com Wed May 25 14:54:21 2016 From: chaorenl at google.com (Chaoren Lin) Date: Wed, 25 May 2016 11:54:21 -0700 Subject: [CMake] Full source path in generated ninja build file? Message-ID: Hi, currently if the build directory is under the project's root, and the generator is ninja, the generated build files will use relative paths from the build directory for the source files. E.g., if we have a project and its build directory structured like this: project/ CMakeLists.txt src/ foo.cpp build/ CMakeCache.txt CMakeFiles/... build.ninja build.ninja will contain something like this: build CMakeFiles/foo.dir/src/foo.cpp.o: CXX_COMPILER_foo ../src/foo.cpp Now, when you build, and get a compile error, the reported path would be relative to the build directory. This is a somewhat problematic if the build is being run through an IDE that has no concept of the build directory (e.g., it's only supplied with a build command, no concept of what's in the command), since the IDE then can't do anything with the relative path that comes out of the compiler error. The IDE won't be able to open the correct source file when receiving the error. Currently source files in the ninja generator are converted to "NinjaPath" which are just full paths converted to HOME_OUTPUT. Is there a reason we can't just always use full paths for the source files? Thanks, Chaoren -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at therning.org Wed May 25 16:03:24 2016 From: magnus at therning.org (Magnus Therning) Date: Wed, 25 May 2016 22:03:24 +0200 Subject: [CMake] linking OBJECT libraries : Argument list too long In-Reply-To: <50320452A334BD42A5EC72BAD21450993DF97402@MBX210.d.ethz.ch> References: <50320452A334BD42A5EC72BAD21450993DF97402@MBX210.d.ethz.ch> Message-ID: <87eg8pj46r.fsf@therning.org> Biddiscombe, John A. writes: > When building OpenBLAS on OSX, the link line generated contains around > 350K of text, and the max supported arg length is getconf ARG_MAX - > returns 262144. > This causes the link phase to abort with Error running link command: > Argument list too long > > The reason for the problem is that many libraries of Type OBJECT are > built and produce huge numbers of object files are then added to one > very large list which is then passed to the linker. > > I implemented a simple(ish) fix, that doesn't quite work - for each > subdirectory that generates object files, I set the > CMAKE_FILES_DIRECTORY and specify the binary directory where the build > should go using a single character counter 0,1,2,3,4 which is much > shorter than the target name and it reduces the final arg size down > almost enough > > set(COUNTER_ 0) > foreach (SUBDIR ${SUBDIRS}) > set(CMAKE_FILES_DIRECTORY "/${COUNTER_}") > add_subdirectory(${SUBDIR} ${CMAKE_BINARY_DIR}/${COUNTER_}) > ..... > MATH(EXPR COUNTER_ "${COUNTER_}+1") > endforeach () > > example : make driver_level2 target > [ 0%] Building C object OpenBLAS/driver/level2/CMakeFiles/driver_level2.dir/CMakeFiles/ssbmv_U.c.o > becomes > [ 0%] Building C object 1/CMakeFiles/driver_level2.dir/1/ssbmv_U.c.o > > and the link line is correspondingly shorter as the driver_level2 has > been replaced in 2 places. The problem is that there is still an extra > "CMakeFiles/driver_level2.dir" in the path to the object file that I > would like to shorten/remove. > > How can I do that? > > NB. I am aware that I can turn the OBJECT libraries into normal > libraries and link them conventionally, but I'd like to make this path > shortening method work. Wouldn't a better solution be to use an options file, something like ld's @file[1]? /M [1]: http://linux.die.net/man/1/ld -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. ? R.P. Feynman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From juandent at mac.com Thu May 26 12:16:39 2016 From: juandent at mac.com (Juan Dent) Date: Thu, 26 May 2016 10:16:39 -0600 Subject: [CMake] How to run an install command as administrator? Message-ID: <006301d1b769$fc634bb0$f529e310$@mac.com> Hi, I have a simple CMakeLists.txt that tries to install at a place in the drive that requires administrator privileges. How can I make that install command to run as administrator, is there a way in CMake? Regards, Juan -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Thu May 26 13:29:20 2016 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 26 May 2016 10:29:20 -0700 (PDT) Subject: [CMake] How to run an install command as administrator? In-Reply-To: <006301d1b769$fc634bb0$f529e310$@mac.com> References: <006301d1b769$fc634bb0$f529e310$@mac.com> Message-ID: On 2016-05-26 10:16-0600 Juan Dent wrote: > Hi, > > > > I have a simple CMakeLists.txt that tries to install at a place in the drive > that requires administrator privileges. How can I make that install command > to run as administrator, is there a way in CMake? CMake configures a build and install, but does not actually do those tasks. For example, for the "Unix Makefiles" generator, cmake configures the Makefiles, but to do the actual build you typically use make all and to do the actual install (using the installation prefix you have configured with CMake) you typically use make install So the answer to your question for that latter case is to do that action with administrator privileges. For example, on Unix systems you would log in as the root account first before running "make install". And similarly for other generators and other platforms that require administrator privileges to install in the installation location you have specified with CMake. 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 Harry at codexdigital.com Fri May 27 12:34:37 2016 From: Harry at codexdigital.com (Harry Mallon) Date: Fri, 27 May 2016 16:34:37 +0000 Subject: [CMake] [OS X] example CMake file to create a Preference Pane? Message-ID: <993FF608-EF8D-4785-BB48-643F8BD12449@codexdigital.com> You might have found something by now, but for others: This seems to be a good start (I haven't got mine working yet but it is a lot closer) https://github.com/open-eid/updater/blob/master/CMakeLists.txt H Harry Mallon CODEX | Software Engineer 60 Poland Street | London | England | W1F 7NT E harry at codexdigital.com | T +44 203 7000 989 Website | Facebook | Twitter [http://www.codexdigital.com/?action=asset&id=E55D8A6F-AF62-4978-8FF1-435A85AFADBF] -------------- next part -------------- An HTML attachment was scrubbed... URL: From oribrost at gmail.com Fri May 27 16:25:29 2016 From: oribrost at gmail.com (ori brost) Date: Fri, 27 May 2016 23:25:29 +0300 Subject: [CMake] Calculating all C++ dependencies in advance with ninja and gmake makefiles Message-ID: I'm using cmake to generate a build file for a project, using ninja as the low-level build system. I've noticed that ninja calculates dependencies while building the source files. Is there any cmake switch that can add to the build.ninja file a rule that allows generating all dependcies without compiling anything? (i.e. generate a full .ninja_deps) Also, is there a solution like this for gmake makefiles created by cmake? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarra13 at gmail.com Sat May 28 12:51:11 2016 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Sat, 28 May 2016 13:51:11 -0300 Subject: [CMake] CPACK_NSIS_EXTRA_INSTALL_COMMANDS before install Message-ID: <5749CC7F.3030203@gmail.com> Hi, I am using CPACK_NSIS_EXTRA_INSTALL_COMMANDS to create a new page where the user can select file associations (using the full syntax of NSIS). My problem is that the page gets shown after the install is done. I would like to have a variable which puts the NSIS commands before the install. Is there any way or variable to achieve that? gets shown after the install is done.? I would like to have a variable which puts the NSIS commands before the install.
Is there any way or variable to achieve that?

From ggarra13 at gmail.com Sat May 28 12:58:28 2016 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Sat, 28 May 2016 13:58:28 -0300 Subject: [CMake] How to run an install command as administrator? In-Reply-To: <006301d1b769$fc634bb0$f529e310$@mac.com> References: <006301d1b769$fc634bb0$f529e310$@mac.com> Message-ID: <5749CE34.3040906@gmail.com> On 26/05/2016 01:16 p.m., Juan Dent wrote: > > Hi, > > I have a simple CMakeLists.txt that tries to install at a place in the > drive that requires administrator privileges. How can I make that > install command to run as administrator, is there a way in CMake? > If you are on Linux or Mac, it is easy. Just do: $ sudo make install If you are on Windows, create a .bat file with the cmake command you want to run and then RMB on it and select Run As Administrator. -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.teo at acfr.usyd.edu.au Sun May 29 18:44:45 2016 From: t.teo at acfr.usyd.edu.au (Thomas Teo) Date: Mon, 30 May 2016 08:44:45 +1000 Subject: [CMake] CPack: setting multiple RPM pre/post (un)install scripts Message-ID: <45c43625-9775-e6ea-f067-13c86423d9e5@acfr.usyd.edu.au> Hi All, In building an RPM package, I'd like to set multiple (un)install scripts - an application specific one which starts services that are installed by the RPM, and also to call ldconfig so that the shared library list is updated. The CMake/CPack documentation states this is supported (eg https://cmake.org/cmake/help/v3.0/module/CPackRPM.html): May be used to embed a pre (un)installation script in the spec file. The refered (sic) script file*(s)* will be read... (my emphasis) However the example doesn't indicate how one would specify multiple script files. I've tried several different methods: SET(CPACK_RPM_POST_INSTALL_SCRIPT_FILE "${CMAKE_SOURCE_DIR}/a.sh;${CMAKE_SOURCE_DIR}/b.sh" ) SET(CPACK_RPM_POST_INSTALL_SCRIPT_FILE "${CMAKE_SOURCE_DIR}/a.sh,${CMAKE_SOURCE_DIR}/b.sh" ) SET(CPACK_RPM_POST_INSTALL_SCRIPT_FILE "${CMAKE_SOURCE_DIR}/a.sh" "${CMAKE_SOURCE_DIR}/b.sh" ) SET(CPACK_RPM_POST_INSTALL_SCRIPT_FILE "${CMAKE_SOURCE_DIR}/a.sh ${CMAKE_SOURCE_DIR}/b.sh" ) Which often result in the error: CMake Error at /usr/share/cmake-3.4/Modules/CPackRPM.cmake:1377 (if): if given arguments: "EXISTS" "/home/thomas/src//a.sh" "/home/thomas/src//b.sh" Looking at the CMake code in the referenced file (CPackRPM.cmake) it appears that it could never handle multiple script files as there is no iteration. Is it possible the documentation is in error and only one script for each type of action (pre/post, un/install) can be specified? All assistance appreciated. Cheers, Thomas -- Thomas Teo Australian Centre for Field Robotics The University of Sydney t.teo at acfr.usyd.edu.au www.acfr.usyd.edu.au From andrew.melo at gmail.com Sun May 29 19:18:18 2016 From: andrew.melo at gmail.com (Andrew Melo) Date: Sun, 29 May 2016 18:18:18 -0500 Subject: [CMake] CPack: setting multiple RPM pre/post (un)install scripts In-Reply-To: <45c43625-9775-e6ea-f067-13c86423d9e5@acfr.usyd.edu.au> References: <45c43625-9775-e6ea-f067-13c86423d9e5@acfr.usyd.edu.au> Message-ID: Hi On Sunday, May 29, 2016, Thomas Teo wrote: > Hi All, > In building an RPM package, I'd like to set multiple (un)install scripts - > an application specific one which starts services that are installed by the > RPM, and also to call ldconfig so that the shared library list is updated. > The CMake/CPack documentation states this is supported (eg > https://cmake.org/cmake/help/v3.0/module/CPackRPM.html): > > May be used to embed a pre (un)installation script in the spec file. > The refered (sic) script file*(s)* will be read... > (my emphasis) > > However the example doesn't indicate how one would specify multiple script > files. I've tried several different methods: > > SET(CPACK_RPM_POST_INSTALL_SCRIPT_FILE > "${CMAKE_SOURCE_DIR}/a.sh;${CMAKE_SOURCE_DIR}/b.sh" ) > SET(CPACK_RPM_POST_INSTALL_SCRIPT_FILE > "${CMAKE_SOURCE_DIR}/a.sh,${CMAKE_SOURCE_DIR}/b.sh" ) > SET(CPACK_RPM_POST_INSTALL_SCRIPT_FILE "${CMAKE_SOURCE_DIR}/a.sh" > "${CMAKE_SOURCE_DIR}/b.sh" ) > SET(CPACK_RPM_POST_INSTALL_SCRIPT_FILE "${CMAKE_SOURCE_DIR}/a.sh > ${CMAKE_SOURCE_DIR}/b.sh" ) > > > Which often result in the error: > > CMake Error at /usr/share/cmake-3.4/Modules/CPackRPM.cmake:1377 (if): > if given arguments: > > "EXISTS" "/home/thomas/src//a.sh" > "/home/thomas/src//b.sh" > > Looking at the CMake code in the referenced file (CPackRPM.cmake) it > appears that it could never handle multiple script files as there is no > iteration. > Is it possible the documentation is in error and only one script for each > type of action (pre/post, un/install) can be specified? FWIW, I make one script with all the desired actions and it works great. > > All assistance appreciated. > > Cheers, > Thomas > > -- > Thomas Teo > Australian Centre for Field Robotics > The University of Sydney > > t.teo at acfr.usyd.edu.au > www.acfr.usyd.edu.au > > -- > > 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 > -- It's dark in this basement. -------------- next part -------------- An HTML attachment was scrubbed... URL: From domen.vrankar at gmail.com Mon May 30 02:06:55 2016 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Mon, 30 May 2016 08:06:55 +0200 Subject: [CMake] CPack: setting multiple RPM pre/post (un)install scripts In-Reply-To: <45c43625-9775-e6ea-f067-13c86423d9e5@acfr.usyd.edu.au> References: <45c43625-9775-e6ea-f067-13c86423d9e5@acfr.usyd.edu.au> Message-ID: 2016-05-30 0:44 GMT+02:00 Thomas Teo : > Hi All, > In building an RPM package, I'd like to set multiple (un)install scripts - > an application specific one which starts services that are installed by the > RPM, and also to call ldconfig so that the shared library list is updated. > The CMake/CPack documentation states this is supported (eg > https://cmake.org/cmake/help/v3.0/module/CPackRPM.html): > > May be used to embed a pre (un)installation script in the spec file. > The refered (sic) script file*(s)* will be read... > (my emphasis) > > However the example doesn't indicate how one would specify multiple script > files. I've tried several different methods: This could never be done. As Andrew already mentioned you'll have to merge them together yourself before feeding the path to CPackRPM. > Looking at the CMake code in the referenced file (CPackRPM.cmake) it appears > that it could never handle multiple script files as there is no iteration. > Is it possible the documentation is in error and only one script for each > type of action (pre/post, un/install) can be specified? This is documentation error. It's probably best that the user merges multiple scripts as appropriate so I'll fix it in the documentation. Regards, Domen From smjert at gmail.com Mon May 30 08:15:47 2016 From: smjert at gmail.com (Stefano Bonicatti) Date: Mon, 30 May 2016 13:15:47 +0100 Subject: [CMake] Library deduplication and imported target dependencies Message-ID: Hello there. First of all is there any documentation about how CMake handles deduplication of libraries when linking (so to avoid duplicate libraries to be linked unnecessarily)? Now to my issue: I have a library libA which has to link to libB, libC, libD and libE. libA is the only one internal to the CMake buildsystem, the other ones are all external, and all are shared libs. i obtain libB, libC and libD by path (find_package) and libE is an imported target (added with add_library(libE SHARED IMPORTED)). libE is actually compiled through custom commands and have dependencies that i've set with set_target_properties(libE PROPERTIES INTERFACE_LINK_LIBRARIES "${LIBRARY_DEPS}"). The deps are libC, libD, libF, libG and they're set with set(LIBRARY_DEPS ${LIBC} ${LIBD} ${LIBF} ${LIBG}). Now if i look at the libA link command line, i see libC and libD duplicated. The libs libA needs are linked with target_link_libraries and, except for libE which is a target, they are all specified as absolute paths. Now i've also tried removing the quotes around ${LIBRARY_DEPS}, when using it, but this time while it deduplicates libC and libD, libF and libG aren't linked anymore... I've also tried creating imported targets for libC and libD, using them in libA target_link_libraries (while still specifing the absolute path for INTERFACE_LINK_LIBRARIES of libE), but it still doesn't deduplicate them. Any clue? -------------- next part -------------- An HTML attachment was scrubbed... URL: From zcsd2012 at gmail.com Mon May 30 08:35:48 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Mon, 30 May 2016 05:35:48 -0700 (MST) Subject: [CMake] =?utf-8?q?How_to_hundle_gcc_link_options=28like_whole-arc?= =?utf-8?q?hive=2C_--allow-multiple-definition=29_in_CMake=EF=BC=9F?= Message-ID: <1464611748338-7593563.post@n2.nabble.com> Hi, all, Thanks for taking your time to review my email. I have a demo project and it's structure like as below: top_dir CMakeLists.txt sub_dir1 CMakeLists.txt sub_dir2 CMakeLists.txt top_dir/sub_dir1/CMakeLists.txt used to build `lib1` by using `add_library(lib1 ...)`, top_dir/sub_dir2/CMakeLists.txt used to build `exe1` with linking lib1 by `target_link_library(exe1 lib1)`. And the content of top_dir/CMakeLists.txt is as below: add_subdirectory(sub_dir2) add_subdirectory(sub_dir1) Normally, when build target exe1, cmake will check dependency so `lib1` will be built before building exe1. The problem is I am transfering an existed makefile project into CMake, and there are many gcc link options, like "whole-archive ... no-whole-archive, allow-mutiple-definition", if use like `target_link_library(exe1 "-Wl, --whole-archive ../sub_dir1/liblib1.a --no-whole-archive")`(The form like this, and this may not work, it just a e.g.), cmake seem don't built `lib1` any more. Is there any way i can use target_link_library like `target_link_library(exe1 "-Wl, --whole-archive ../sub_dir1/liblib1.a")` and cmake link dependency checking still work, or other way i can transfer these gcc link options into cmake? Thanks a lot, Chao -- View this message in context: http://cmake.3232098.n2.nabble.com/How-to-hundle-gcc-link-options-like-whole-archive-allow-multiple-definition-in-CMake-tp7593563.html Sent from the CMake mailing list archive at Nabble.com. From biddisco at cscs.ch Mon May 30 08:38:57 2016 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Mon, 30 May 2016 12:38:57 +0000 Subject: [CMake] linking OBJECT libraries : Argument list too long In-Reply-To: <87eg8pj46r.fsf@therning.org> References: <50320452A334BD42A5EC72BAD21450993DF97402@MBX210.d.ethz.ch> <87eg8pj46r.fsf@therning.org> Message-ID: <50320452A334BD42A5EC72BAD21450993DFDBA80@MBX110.d.ethz.ch> Magnus > Wouldn't a better solution be to use an options file, something like ld's @file[1]? < Yes. That solution would require me to make some probably significant changes to the cmake internals though, and I hoped to find out where the extra path / directories were coming from and shorten them just using commands in cmakelists etc. thanks JB From t.teo at acfr.usyd.edu.au Mon May 30 20:47:18 2016 From: t.teo at acfr.usyd.edu.au (Thomas Teo) Date: Tue, 31 May 2016 10:47:18 +1000 Subject: [CMake] CPack: setting multiple RPM pre/post (un)install scripts In-Reply-To: References: <45c43625-9775-e6ea-f067-13c86423d9e5@acfr.usyd.edu.au> Message-ID: <0573f55e-a57c-024d-fc59-38ac60be786a@acfr.usyd.edu.au> Hi Domen, Thanks for that confirmation. While rolling it into the main postinstall script might make sense, I would need to run a different script (or not at all) based on the CMake option flags the user had selected. Thus I'd need to generate multiple versions of the script depending on what they'd selected. (Perhaps this might be better handled using RPM components, however that's another task for another day.) What I did do was use the CPACK_RPM_SPEC_MORE_DEFINE parameter: # If the user builds shared, make sure that the RPM package (that might be generated) runs ldconfig when it's installed. IF( BUILD_SHARED_LIBS ) SET(CPACK_RPM_SPEC_MORE_DEFINE "%posttrans -p /sbin/ldconfig") ENDIF( BUILD_SHARED_LIBS ) Which allowed me to set raw rpm spec options which would simply get appended in. For a simple oneliner like ldconfig, this is an even better result as it doesn't require me to create an external script file. Thanks for all suggestions and assistance. Thomas Thomas Teo Australian Centre for Field Robotics The University of Sydney t.teo at acfr.usyd.edu.au www.acfr.usyd.edu.au On 30/05/2016 4:06 PM, Domen Vrankar wrote: From chuck.atkins at kitware.com Tue May 31 10:20:03 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Tue, 31 May 2016 10:20:03 -0400 Subject: [CMake] =?utf-8?q?How_to_hundle_gcc_link_options=28like_whole-arc?= =?utf-8?q?hive=2C_--allow-multiple-definition=29_in_CMake=EF=BC=9F?= In-Reply-To: <1464611748338-7593563.post@n2.nabble.com> References: <1464611748338-7593563.post@n2.nabble.com> Message-ID: Hi Chao, You want to let CMake to as much of the work for you as possible. You're still trying to explicitly pass the path to the library file to target_link_libraries. If you look at the line: target_link_library(exe1 "-Wl, --whole-archive ../sub_dir1/liblib1.a --no-whole-archive") there's no CMake target name so CMake can't know about the dependency. However, if you use the target name instead: top_dir/CMakeLists.txt: cmake_minimum_required(VERSION 3.0) project(foo) add_subdirectory(sub_dir2) add_subdirectory(sub_dir1) top_dir/sub_dir1/CMakeLists.txt add_library(L1 1.c) top_dit/sub_dir2/CMakeLists.txt add_executable(exe1 main.c) target_link_libraries(exe1 "-Wl,--whole-archive" *L1* "-Wl,--no-whole-archive") Notice how in the target_link_libraries line for exe1, the link options are separate instead of 1 big string combining them all and the actual CMake target name, L1, is used instead of the output file libL1.a. You can see the resulting output is what you want: $ make VERBOSE=1 ... [100%] Linking C executable exe1 ... /usr/bin/cc CMakeFiles/exe1.dir/main.c.o -o exe1 -rdynamic *-Wl,--whole-archive ../sub_dir1/libL1.a -Wl,--no-whole-archive* Generally speaking, always use target names in a CMakeLists.txt instead of the actual output file. There are a few situations where you may need the actual file name but they are uncommon and even then you would do it through target properties and generator expressions rather than hard code the library file name. - Chuck On Mon, May 30, 2016 at 8:35 AM, Chaos Zhang wrote: > Hi, all, > > Thanks for taking your time to review my email. I have a demo project and > it's structure like as below: > > top_dir > CMakeLists.txt > sub_dir1 > CMakeLists.txt > sub_dir2 > CMakeLists.txt > > top_dir/sub_dir1/CMakeLists.txt used to build `lib1` by using > `add_library(lib1 ...)`, > top_dir/sub_dir2/CMakeLists.txt used to build `exe1` with linking lib1 by > `target_link_library(exe1 lib1)`. > And the content of top_dir/CMakeLists.txt is as below: > > add_subdirectory(sub_dir2) > add_subdirectory(sub_dir1) > > Normally, when build target exe1, cmake will check dependency so `lib1` > will > be built before building exe1. The problem is I am transfering an existed > makefile project into CMake, and there are many gcc link options, like > "whole-archive ... no-whole-archive, allow-mutiple-definition", if use like > `target_link_library(exe1 "-Wl, --whole-archive ../sub_dir1/liblib1.a > --no-whole-archive")`(The form like this, and this may not work, it just a > e.g.), cmake seem don't built `lib1` any more. Is there any way i can use > target_link_library like `target_link_library(exe1 "-Wl, --whole-archive > ../sub_dir1/liblib1.a")` and cmake link dependency checking still work, or > other way i can transfer these gcc link options into cmake? > > Thanks a lot, > Chao > > > > -- > View this message in context: > http://cmake.3232098.n2.nabble.com/How-to-hundle-gcc-link-options-like-whole-archive-allow-multiple-definition-in-CMake-tp7593563.html > Sent from the CMake mailing list archive at Nabble.com. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Wagner at neuberger.net Tue May 31 10:35:27 2016 From: Martin.Wagner at neuberger.net (Wagner Martin) Date: Tue, 31 May 2016 14:35:27 +0000 Subject: [CMake] C header file cross dependency In-Reply-To: <20160525113902.0eb6f70d@posteo.de> References: <56E920142ED81D4FBE3260E4B9D1DB3E97208951@ROTSRV13.Neuberger.local> <20160525113902.0eb6f70d@posteo.de> Message-ID: <56E920142ED81D4FBE3260E4B9D1DB3E97208E7B@ROTSRV13.Neuberger.local> Thank you for your answer! > > How do I resolve something like this? Right now CMake evaluates the > > compiler includes in the order that subdirectories are added. This > > gives me an compilation error in uart.c that terminal.h cannot be > > found. > > This is not a cmake-problem, but seems to be a code-structure-issue. > > I'm guessing here: if terminal needs the uart-code shouldn't it be the > uart-code filling in a terminal-function. Interface vs. implementation? > Could you elaborate more on how terminal and uart are linked? The terminal code implements a "printf()" equivalent function to log debug and state information. All input is then directly written to the UART. The UART driver now wants to use this terminal logging function. It doesn't care how printf() works. In the end, this is necessary because there is no file system to store the log information to. I would like to have this: uart_write(uart2) -> syslog(prio, errormsg) -> syslog.txt on file system. But I have: uart_write(uart2) -> printf(errormsg) -> uart_write(uart1) -> PC with running terminal software > > Regarding cmake: I suggest you stop using include_directories() and > start using target_include_directories() and > target_compile_definitions() instead of add_definitions(). I will have a look at this. > > Limiting yourself to this way of doing libraries and targets, cmake will > force you to structure your code in a more standard way - and will > provide you with clean visibility between different targets. > > Could you provide a working, stripped down example to show the problem > provided via github (in an example repo). I will try to do this within a few days... > > More comments below. > > > Some excerpt of my project. I've tried to keep the example as simple > > as possible. > > > > My directory structure looks something like that: > > / > > CMakeLists.txt > > src + > > +CMakeLists.txt (1) > > +drivers+ > > | +uart.c > > | +uart.h > > | +... > > | +CMakeLists.txt (2) > > +os-----+ > > | +terminal.c > > | +terminal.h > > | +... > > | +CMakeLists.txt (3) > > > > > > (1): > > > > SET(drivers "drivers") > > SET(terminal "terminal") > > > > SET(drivers_lib ${drivers}) > > SET(terminal_lib ${terminal}) > > > > SET(ARCHIVE_INSTALL_DIR lib) > > SET(INCLUDE_INSTALL_DIR include) > > > > SET(headers_private "_headers_private") # internal headers > > SET(headers_public "_headers_public") # public headers go into > > package > > > > ADD_SUBDIRECTORY(${drivers}) > > ADD_SUBDIRECTORY(${terminal}) > > I think it is common practice now to use lower-case for cmake-commands > now. OK. > > > ## drivers > > > > ## ---- Sources > > ------------------------------------------------------------------- > > SET(sources "uart.c" > > ) > > > > ## ---- Header includes > > ----------------------------------------------------------- > > SET(headers "${CMAKE_CURRENT_SOURCE_DIR}/" > > ) > > SET(${drivers}${headers_public} ${headers} PARENT_SCOPE) > > > > INCLUDE_DIRECTORIES(${headers} > > ${${terminal}${headers_public}} > > ) > > While the ${${var}${var2}} (seems to) work, it is error-prone, IMHO. > > Standard cmake-commands can work with relative paths and are evaluating > them correctly taking into account ${CMAKE_CURRENT_SOURCE_DIR} (most of > the time. So you could use ../uart in terminal/ This is what I did to continue working... > - but it would be better > if it comes indirectly via target_include_directories() and > target_link_libraries() ...and this is why I asked the list :-) > > >[..] > > > > And finally this creates the package in root directory CMakeLists.txt: > > > > SET(CPACK_PROJECT_CONFIG_FILE ${CMAKE_BINARY_DIR}/CPackOptions.cmake) > > # CPackOptions.cmake contains package file name SET(CPACK_GENERATOR > > "TBZ2") INCLUDE(CPack) > > Due to the circular header-dependency the binaries of terminal and uart > should have the same mutual dependency. In this case you could build > them in within one target. Yes, I could do that. But I wanted to get away from one single, monolithic makefile... This is why I created one CMake file for every functional unit of my source code (drivers, RTOS, terminal and so on). regards, Martin From ire866306 at gmail.com Tue May 31 10:52:41 2016 From: ire866306 at gmail.com (irene w) Date: Tue, 31 May 2016 10:52:41 -0400 Subject: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later. In-Reply-To: References: Message-ID: It seems CMakw could not find the generated moc_xxx files. I modified the scripts to specify moc_xxx files is generated, but it still has same errors. ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o ${Qt_tmp}/moc_GMWindow.cpp DEPENDS ${GM_DIR}/GMWindow.h ) ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp) SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES GENERATED 1) SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY OBJECT_DEPENDS ${Qt_tmp}/moc_GMWindow.cpp) ..... add_dependencies (GM generate_foo) Does the Macro "SET_SOURCE_FILES_PROPERTIES" with "GENERATED" setting work for this purposes? Any help would be greatly appreciated ! On Wed, May 25, 2016 at 12:48 PM, irene w wrote: > Hi, > > I am compiling a simple Qt3 application on Linux using CMake. In my case, > I need to build moc_xxx files with custom options and output to a specified > directory, So, I was not using CAMKE_AUTO macros. My cmake scripts create a > "Qt_tmp" directory and output moc_xxx there. > > It looked it always failed to link the moc_xxx files for the first time > build when there is no "Qt_tmp" directory, and succeeded if I ran build > again if the "Qt_tmp" directory and moc_xxx files created by the failed > build were kept without removing. However, it'll fail if I delete > the "Qt_tmp" directory. > > Even it failed at the first build, the moc_xxx files were > successfully created in the "Qt_tmp" directory. > > Here is my cmake scripts and the errors I got. Can anyone help me to > figure out the issues? Any help would be greatly appreciated. Thanks. > > CMakeLists.txt > > --------------------------------------------------------------------------------------------- > cmake_minimum_required(VERSION 3.4.1) > project (GM_Application CXX) > SET (CMAKE_SYSTEM_NAME Linux) > SET (CMAKE_CXX_COMPILER ${COMPILER_PATH}${CROSS_COMPILE}g++) > set (GM_DIR ${CMAKE_CURRENT_SOURCE_DIR}) > set (QT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6) > LINK_DIRECTORIES (${QT_DIR}/lib) > INCLUDE_DIRECTORIES ("${QT_DIR}/include" > "${GM_DIR}" > ) > ##### Compiling QT moc and ui ##### > set (QT_MOC_CMD ${QT_DIR}/bin/moc -I$(QT_DIR)/mkspecs/linux-g++ > -I${QT_DIR}/include -I${QT_DIR}/include/QtGui) > file (MAKE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) > set (Qt_tmp ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp) > add_custom_target (Moc_GMWindows > COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o > ${Qt_tmp}/moc_GMWindow.cpp > ) > > ##### Compiling application ##### > file (GLOB GM_SOURCES ${GM_DIR}/*.h ${GM_DIR}/*.cpp) > file (GLOB Moc_SOURCES ${Qt_tmp}/*.h ${Qt_tmp}/*.cpp) > add_executable (GM ${GM_SOURCES} ${Moc_SOURCES}) > target_include_directories (GM PRIVATE ${Qt_tmp}) > add_dependencies (GM Moc_GMWindows) > target_link_libraries (GM QtGui) > > > ------------------------------------------------------------------------------------------- > Errors: > > Scanning dependencies of target Moc_GMWindows > [ 0%] Built target Moc_GMWindows > Scanning dependencies of target GM > [ 14%] Building CXX object GM/CMakeFiles/GM.dir/GM/GM.cpp.o > [ 42%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMService.cpp.o > [ 67%] Building CXX object GM/CMakeFiles/GM.dir/GM/GMWindow.cpp.o > [ 85%] Building CXX object GM/CMakeFiles/GM.dir/GM/main.cpp.o > [100%] Linking CXX executable ../bin/GM > CMakeFiles/GM.dir/GM/GMWindow.cpp.o: In function > `GM::GMWindow::emitAppendMessage(QStrin > g)': > /GM/GMWindow.cpp:217: undefined reference to > `GM::GMWindow::appendMessage(QString)' > CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable for > GM::GMWindow] > +0x8): undefined reference to `GM::GMWindow::metaObject() const' > CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable for > GM::GMWindow] > +0xc): undefined reference to `GM::GMWindow::qt_metacast(char const*)' > CMakeFiles/GM.dir/GM/GMWindow.cpp.o:(.rodata._ZTVN2GM8GMWindowE[vtable for > GM::GMWindow] > +0x10): undefined reference to > `GM::GMWindow::qt_metacall(QMetaObject::Call, int, void**)' > collect2: ld returned 1 exit status > make[2]: *** [bin/GM] Error 1 > make[1]: *** [GM/CMakeFiles/GM.dir/all] Error 2 > make: *** [all] Error 2 > > > > Virus-free. > www.avast.com > > <#m_6400203814648417669_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zcsd2012 at gmail.com Tue May 31 20:47:02 2016 From: zcsd2012 at gmail.com (Chaos Zhang) Date: Tue, 31 May 2016 17:47:02 -0700 (MST) Subject: [CMake] =?utf-8?q?How_to_hundle_gcc_link_options=28like_whole-arc?= =?utf-8?q?hive=2C_--allow-multiple-definition=29_in_CMake=EF=BC=9F?= In-Reply-To: References: <1464611748338-7593563.post@n2.nabble.com> Message-ID: <1464742022776-7593569.post@n2.nabble.com> Thanks for your generous Mr. Atkins, what you answer me worked well and solved my question. I would keep 'always use target names in a CMakeLists.txt instead of the actual output file' in my mind. :-) Chao Chuck Atkins wrote > Hi Chao, > > You want to let CMake to as much of the work for you as possible. You're > still trying to explicitly pass the path to the library file to > target_link_libraries. If you look at the line: > > target_link_library(exe1 "-Wl, --whole-archive ../sub_dir1/liblib1.a > --no-whole-archive") > > there's no CMake target name so CMake can't know about the dependency. > However, if you use the target name instead: > > top_dir/CMakeLists.txt: > cmake_minimum_required(VERSION 3.0) > project(foo) > add_subdirectory(sub_dir2) > add_subdirectory(sub_dir1) > > top_dir/sub_dir1/CMakeLists.txt > add_library(L1 1.c) > > top_dit/sub_dir2/CMakeLists.txt > add_executable(exe1 main.c) > target_link_libraries(exe1 "-Wl,--whole-archive" *L1* > "-Wl,--no-whole-archive") > > Notice how in the target_link_libraries line for exe1, the link options > are > separate instead of 1 big string combining them all and the actual CMake > target name, L1, is used instead of the output file libL1.a. You can see > the resulting output is what you want: > > $ make VERBOSE=1 > ... > [100%] Linking C executable exe1 > ... > /usr/bin/cc CMakeFiles/exe1.dir/main.c.o -o exe1 -rdynamic > *-Wl,--whole-archive > ../sub_dir1/libL1.a -Wl,--no-whole-archive* > > Generally speaking, always use target names in a CMakeLists.txt instead of > the actual output file. There are a few situations where you may need the > actual file name but they are uncommon and even then you would do it > through target properties and generator expressions rather than hard code > the library file name. > > - Chuck > > On Mon, May 30, 2016 at 8:35 AM, Chaos Zhang < > zcsd2012@ > > wrote: > >> Hi, all, >> >> Thanks for taking your time to review my email. I have a demo project and >> it's structure like as below: >> >> top_dir >> CMakeLists.txt >> sub_dir1 >> CMakeLists.txt >> sub_dir2 >> CMakeLists.txt >> >> top_dir/sub_dir1/CMakeLists.txt used to build `lib1` by using >> `add_library(lib1 ...)`, >> top_dir/sub_dir2/CMakeLists.txt used to build `exe1` with linking lib1 by >> `target_link_library(exe1 lib1)`. >> And the content of top_dir/CMakeLists.txt is as below: >> >> add_subdirectory(sub_dir2) >> add_subdirectory(sub_dir1) >> >> Normally, when build target exe1, cmake will check dependency so `lib1` >> will >> be built before building exe1. The problem is I am transfering an existed >> makefile project into CMake, and there are many gcc link options, like >> "whole-archive ... no-whole-archive, allow-mutiple-definition", if use >> like >> `target_link_library(exe1 "-Wl, --whole-archive ../sub_dir1/liblib1.a >> --no-whole-archive")`(The form like this, and this may not work, it just >> a >> e.g.), cmake seem don't built `lib1` any more. Is there any way i can use >> target_link_library like `target_link_library(exe1 "-Wl, --whole-archive >> ../sub_dir1/liblib1.a")` and cmake link dependency checking still work, >> or >> other way i can transfer these gcc link options into cmake? >> >> Thanks a lot, >> Chao >> >> >> >> -- >> View this message in context: >> http://cmake.3232098.n2.nabble.com/How-to-hundle-gcc-link-options-like-whole-archive-allow-multiple-definition-in-CMake-tp7593563.html >> Sent from the CMake mailing list archive at Nabble.com. >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- View this message in context: http://cmake.3232098.n2.nabble.com/How-to-hundle-gcc-link-options-like-whole-archive-allow-multiple-definition-in-CMake-tp7593563p7593569.html Sent from the CMake mailing list archive at Nabble.com.