From chuck.atkins at kitware.com Mon Aug 1 12:08:25 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 1 Aug 2016 12:08:25 -0400 Subject: [CMake] FindLibXml2.cmake: rename "LIBXML2_DEFINITIONS" In-Reply-To: References: Message-ID: Hi Yaron, I think it should b renamed to "LIBXML2_COMPILE_FLAGS". > Xxx_DEFINITIONS is one of the standard variable names for a given FindXxx.cmake find module, see https://cmake.org/cmake/help/v3.6/manual/cmake-developer.7.html#standard-variable-names . > If u wish, I can submit a patch. > Thank you for the enthusiasm! If you would like to improve on the FindLibXML2 module, which really hasn't been touched in several years aside from formatting changes, rather than mess with the varible names I would instead suggest you look at creating an imported target for what get's found. That would certainly help bring the find module up to more modern CMake conventions and would be greatly appreciated! - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Aug 1 15:26:23 2016 From: brad.king at kitware.com (Brad King) Date: Mon, 1 Aug 2016 15:26:23 -0400 Subject: [CMake] Ninja generator bug when handling Windows .dll without associated import .lib In-Reply-To: References: Message-ID: On 07/21/2016 12:27 PM, Kamen Lilov wrote: > When a Windows .DLL is generated, the Microsoft linker may sometimes > decide that no import library needs to be built. This happens often in > one of our projects, we have many .dll?s that tie themselves into our > infrastructure during static class initialization and export no > functions (although they do work and get called via class method > pointers from elsewhere) > > The Ninja CMake generator seems to always emit a dependency on an > associated import library along with the .dll file. That output needs to be listed or it will not be re-built when missing. The way to tell CMake to build a .dll with no .lib is to specify the add_library command's MODULE library type. This specifies that it is a loaded module and not something that is linked. -Brad From yaronct at gmail.com Mon Aug 1 16:19:01 2016 From: yaronct at gmail.com (Yaron Cohen-Tal) Date: Mon, 1 Aug 2016 23:19:01 +0300 Subject: [CMake] FindLibXml2.cmake: rename "LIBXML2_DEFINITIONS" In-Reply-To: References: Message-ID: Ok, looking at other "FindXXX.cmake" modules I see that you're right, it indeed always denotes what should be added to the "COMPILE_FLAGS" target property, rather than "COMPILE_DEFINITIONS" property. I understand if u don't want to rename it coz it'll break current usage, but just wanna note, it's very confusing and I bet we're not the only ones who use it wrong (I mean not only with libxml2 of course, but in general). Thanx. On Mon, Aug 1, 2016 at 7:08 PM, Chuck Atkins wrote: > Hi Yaron, > > > I think it should b renamed to "LIBXML2_COMPILE_FLAGS". >> > > Xxx_DEFINITIONS is one of the standard variable names for a given > FindXxx.cmake find module, see > https://cmake.org/cmake/help/v3.6/manual/cmake-developer.7.html#standard-variable-names > . > > > >> If u wish, I can submit a patch. >> > > Thank you for the enthusiasm! If you would like to improve on the > FindLibXML2 module, which really hasn't been touched in several years aside > from formatting changes, rather than mess with the varible names I would > instead suggest you look at creating an imported target for what get's > found. That would certainly help bring the find module up to more modern > CMake conventions and would be greatly appreciated! > > - Chuck > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Tue Aug 2 04:16:42 2016 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Tue, 2 Aug 2016 10:16:42 +0200 Subject: [CMake] [Visual Studio] Universal Windows Platform projects In-Reply-To: References: Message-ID: I would also very much like to see a tutorial on this. There are just too darn many options to set for me to believe CMake could ever get the job done. Release notes for Publishing to the store, age rating for my app, can it correctly set source types to be DX resources, DX shaders, etc? there are too many things I have not even heard about relating to CMake. I have a feeling that the WindowsStore CMAKE_SYSTEM_NAME started out as a pilot project but then did not wish to keep up with the evolution of the Microsoft ecosystem. It?s a shame really, because I really did want to prove to collegues of mine, that the MVVM model employed by the canonical design pattern of Windows Store apps has a 1-to-1 mapping in the Qt ecosystem. XAML >> QML events-delegates >> signal-slot The best choice of a build generator would be CMake. However, not having met all the neccessary components, VS project files with the Qt Add-In currently seem to be a better choice. The foundations are very-very similar and I wanted to build a simple application that relies on Qt for the Linux build and pure WinRT for the Windows build. Also, I would also be very much interested in additions to CMake where CTest could take care of Pester tests for PowerShell scripts and as such is able to test PS scripts I wrote which load C++/CX Assemblies. (For those who do not know of C++/CX, it is managed C++, a language extension that can act as a mediator between native C++ and all the .NET family of languages. One may wrap FFTW with managed C++ and load the compiled library (referred to as Assemblies) from C#, F# or PowerShell even and consume it. The ABI of the .NET languages are stable and interoperable.) If someone has a working prototype of CMake compiling a simple UWP Store app that could actually be published? do not hesitate to share! Felad?: Adam Rankin -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Wed Aug 3 03:21:29 2016 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Wed, 3 Aug 2016 09:21:29 +0200 Subject: [CMake] Boost 2 & CMake news Message-ID: Does anyone know of the happening around Boost 2 and its possible adoption of CMake? I know Boost and CMake have a very long and very sad history, but I recall someone reporting on this list that he/she will attend a Boost 2 related conference and will again promote the benefits of CMake as opposed to the Boost Build. What is the status of the initiative? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lp.cordier at dynamixyz.com Wed Aug 3 07:02:08 2016 From: lp.cordier at dynamixyz.com (Louis-Paul CORDIER) Date: Wed, 3 Aug 2016 13:02:08 +0200 Subject: [CMake] target_link_libraries and flags issue with Visual Studio Message-ID: <7747c153-4986-12a7-01dd-d49c8ef0cb31@dynamixyz.com> On the target_link_libraries() command documentation page, it is written that it is possible to pass flags to this function, if they start with a '-' character. This functionnality seems to be broken with Visual Studio. Indeed flags in the Visual Studio linker are using slashes instead of dash. For instance, trying to enable map file generation in the linkers is failing: target_link_libraries(${PROJECT_NAME} -MAP) Resulting output in the linker command line is "-MAP" (note the presence of quotes). It should be /MAP (without quotes) in order to be properly recognized by the linker command-line parser. After few researches, it seems that this issue is similar:http://public.kitware.com/pipermail/cmake/2015-June/060989.html Context: I have a library called lib_project. I have an executable my_project that links against lib_project. When linking the final binary, I need to enable UAC support in order to force execution of the binary as administrator (http://stackoverflow.com/questions/1655089/cmake-requireadministrator). lib_project uses a Windows API that needs administrator level set in the final executable. So I would like to force my_project to set this specific flag, but I would like to see this set in the CmakeLists.txt of lib_project. Regarding the documentation, the following command should do the trick (but not working currently): target_link_libraries(lib_project PUBLIC -level='requireAdministrator' -uiAccess='false') Please not that the -level can bring bugs as it could be interpreted by Cmake as "link against 'evel' library". Do I have pointed a new bug in the Visual Studio generator? Would a target_link_flags() command be a good idea to implement? Best regards, L-P -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Aug 5 14:59:21 2016 From: d3ck0r at gmail.com (J Decker) Date: Fri, 5 Aug 2016 11:59:21 -0700 Subject: [CMake] Why is cmake deleting my files? Message-ID: I'm using "MinGW Makefiles" as a generator... When I change a cmakelists.txt file, a bunch of sources I specify to copy from /.../.c to ${CMAKE_BINARY_DIR}/.../.cpp get deleted in binary by cmake. There are no rules in the makefiles for those files to depend on anything other than the original .c file, so I was really confused why they kept getting regenerated... I started to pay attention and found that cmake, during configure, if a cmakeLists.txt changes goes through and deletes all those files. add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT} DEPENDS ${SOURCE} COMMAND ${CMAKE_COMMAND} -E copy_if_different ${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT} ) all outputs get deleted? -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Aug 5 15:46:47 2016 From: d3ck0r at gmail.com (J Decker) Date: Fri, 5 Aug 2016 12:46:47 -0700 Subject: [CMake] Why is cmake deleting my files? In-Reply-To: References: Message-ID: On Fri, Aug 5, 2016 at 11:59 AM, J Decker wrote: > I'm using "MinGW Makefiles" as a generator... > > > When I change a cmakelists.txt file, a bunch of sources I specify to copy > from /.../.c to ${CMAKE_BINARY_DIR}/.../.cpp get deleted in binary by cmake. > > There are no rules in the makefiles for those files to depend on anything > other than the original .c file, so I was really confused why they kept > getting regenerated... I started to pay attention and found that cmake, > during configure, if a cmakeLists.txt changes goes through and deletes all > those files. > > > add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT} > DEPENDS ${SOURCE} > COMMAND ${CMAKE_COMMAND} -E > copy_if_different ${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT} > ) > > > all outputs get deleted? > The file is opened with CreateFile, then SetDispositionInformationFile \Device\HarddiskVolume15\mingw64-x86\sack-r\release_solution\core\src\utils\deploy\CMakeFiles\sack_deploy.dir\DependInfo.cmake.tmp SUCCESS Delete: True so when the file is closed it's deleted... Seems to be set from __archive_mktemp(const char *tmpdir) passing FILE_FLAG_DELETE_ON_CLOSE; but my files aren't temporary.... that's the only thing that seems to set that flag.... --------- trying to make a simple case; but it's not doing it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Aug 5 16:35:02 2016 From: d3ck0r at gmail.com (J Decker) Date: Fri, 5 Aug 2016 13:35:02 -0700 Subject: [CMake] Why is cmake deleting my files? In-Reply-To: References: Message-ID: On Fri, Aug 5, 2016 at 12:46 PM, J Decker wrote: > > > On Fri, Aug 5, 2016 at 11:59 AM, J Decker wrote: > >> I'm using "MinGW Makefiles" as a generator... >> >> >> When I change a cmakelists.txt file, a bunch of sources I specify to copy >> from /.../.c to ${CMAKE_BINARY_DIR}/.../.cpp get deleted in binary by cmake. >> >> There are no rules in the makefiles for those files to depend on anything >> other than the original .c file, so I was really confused why they kept >> getting regenerated... I started to pay attention and found that cmake, >> during configure, if a cmakeLists.txt changes goes through and deletes all >> those files. >> >> >> add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT} >> DEPENDS ${SOURCE} >> COMMAND ${CMAKE_COMMAND} -E >> copy_if_different ${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME}${FILEEXT} >> ) >> >> >> all outputs get deleted? >> > The file is opened with CreateFile, then > > SetDispositionInformationFile \Device\HarddiskVolume15\ > mingw64-x86\sack-r\release_solution\core\src\utils\ > deploy\CMakeFiles\sack_deploy.dir\DependInfo.cmake.tmp SUCCESS Delete: > True > > so when the file is closed it's deleted... > > Seems to be set from __archive_mktemp(const char *tmpdir) passing > FILE_FLAG_DELETE_ON_CLOSE; but my files aren't temporary.... > that's the only thing that seems to set that flag.... > > --------- > trying to make a simple case; but it's not doing it. > ---------- in the simple case, modifying the COMMANDs in add_custom_command() deletes the output file; I can understand that.... In the complex case, I'm modifying a CMakeLists.txt which doesn't have any bearing on the commands applied to the sources or the other libraries using those sources; but it's still deleting them. In the root CMakeLists.txt, I setup the list of sources for the main project 'bag' and then for each of those sources copy them to ${CMAKE_BINARY_DIR}/original/path/to/source/file[s/.c/.cpp/] and add another library 'bag++' with those sources. I then include a bunch of various subdirectories, one of which I'm currently working in, and while that references the original C source names in the original tree, it doesn't reference any of the C++ sources... or even the built libraries; it's a target that links from all the original sources directly; with a different path than originally specified even (original paths would be like add_library( bag M:/sack/src/memlib/sharemem.c .... ) where the paths used in thie project would be add_exeutable( something "../../../../../src/memlib/sharemem.c" ) It's also different whether I do 'make' which ends up trigger the cmake generation which doesn't delete the files. if I just call 'cmake .' the files do get deleted. no that's not it either... this time after the build finished I re-saved the cmakelists that I've been working on with no changes, and the files all copied again running with just 'make' I dunno maybe I'm using some common variable like MORE_SOURCES or EXTRA_SOURCES or something that's somehow related inadvertantly -------------- next part -------------- An HTML attachment was scrubbed... URL: From dumont.guillaume at gmail.com Sun Aug 7 20:45:42 2016 From: dumont.guillaume at gmail.com (Guillaume Dumont) Date: Sun, 7 Aug 2016 20:45:42 -0400 Subject: [CMake] target_link_libraries and flags issue with Visual Studio In-Reply-To: <7747c153-4986-12a7-01dd-d49c8ef0cb31@dynamixyz.com> References: <7747c153-4986-12a7-01dd-d49c8ef0cb31@dynamixyz.com> Message-ID: Hi, You can use the LINK_FLAGS or LINK_FLAGS_ for this: https://cmake.org/cmake/help/v3.6/prop_tgt/LINK_FLAGS.html Have you tried that? Guillaume On Wed, Aug 3, 2016 at 7:02 AM, Louis-Paul CORDIER wrote: > ase not t -- Guillaume Dumont ========================= dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil.n.carlson at gmail.com Sun Aug 7 22:56:50 2016 From: neil.n.carlson at gmail.com (Neil Carlson) Date: Sun, 7 Aug 2016 20:56:50 -0600 Subject: [CMake] Bad option -fPIE for NAG Fortran compiler Message-ID: I'm updating an older cmake configuration system, and tried using CMAKE_POSITION_INDEPENDENT_CODE. While it mostly does the right thing, I found that the flag -fPIE was being used for a source file that gets compiled into an executable. The NAG Fortran compiler doesn't recognize this flag and exits with an error. I don't know who is setting this; perhaps it is a default guess that specific compiler files (NAG-Fortran.cmake) are supposed to override? I also don't understand what the difference is between PIC and PIE. The NAG compiler doesn't provide a PIE option. But adding this set(CMAKE_Fortran_COMPILE_OPTIONS_PIE "-PIC") seems to work fine (and was almost certainly what was happening before.) Alternatively, since the NAG Fortran compiler actually just generates C code and then uses the underlying system C compiler, I've found this also works set(CMAKE_Fortran_COMPILE_OPTIONS_PIE "-Wc,-fPIE") on Linux. But since that varies with platform, maybe the first option is the safest. Is the bottom of NAG-Fortran.cmake the right place to add this setting? (Brad?) Thanks, Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From leventelist at gmail.com Mon Aug 8 05:46:37 2016 From: leventelist at gmail.com (Lev) Date: Mon, 8 Aug 2016 11:46:37 +0200 Subject: [CMake] symlink copy Message-ID: <20160808114637.11eaba95@jive> All, I have a data files to install that contains symbolic link. When I install first time, everything is okay. However, if I reinstall I get this error: file INSTALL cannot duplicate symlink Is there any workaround to squelch this error? Thank you, Lev -- 73 de HA5OGL Op.: Levente From wolf at wolfsden.cz Mon Aug 8 11:56:28 2016 From: wolf at wolfsden.cz (Wolf) Date: Mon, 8 Aug 2016 17:56:28 +0200 Subject: [CMake] OBJECT libraries and transient include dirs Message-ID: <20160808155627.74r5py2xppb2apqj@wolfsden.cz> Hi all, I'm trying to setup OBJECT library for the first time and I've run into problem that include directories are not transient. Let me illustrate: add_library(foo-object OBJECT src/cache.cpp) target_include_directories(foo-object PUBLIC include) add_library(foo SHARED $) add_library(foo_static STATIC $) This compiles just fine. However, when I try to use it: add_executable(bar src/main.cpp) target_link_libraries(bar foo) with `main.cpp` looking like this: #include "cache.h" int main(int, char**) { return 0; } This doesn't compile, because the include directory from `foo-object` isn't carried over. This seem like slight oversight when designed the OBJECT functionality, would it be possible to fix this in some future version? Or is there some good reason it is like it is? Have a nice day, W. PS: I've come up with following workaround, it should work right? add_library(foo-object OBJECT src/cache.cpp) target_include_directories(foo-object PUBLIC include) get_property(object_include_dirs TARGET foo-object PROPERTY INCLUDE_DIRECTORIES) get_property(object_link_libs TARGET foo-object PROPERTY LINK_LIBRARIES) add_library(foo SHARED $) target_include_directories(foo PUBLIC ${object_include_dirs}) target_link_libraries(foo PUBLIC ${object_link_libs}) add_library(foo_static STATIC $) target_include_directories(foo_static PUBLIC ${object_include_dirs}) target_link_libraries(foo_static PUBLIC ${object_link_libs}) -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From aoe at google.com Tue Aug 9 14:36:39 2016 From: aoe at google.com (Chaoren Lin) Date: Tue, 9 Aug 2016 11:36:39 -0700 Subject: [CMake] Correct way of using CMAKE_FIND_ROOT_PATH_MODE_*? Message-ID: Hi, the documentation regarding cross-compiling says that CMAKE_FIND_ROOT_PATH_MODE_* are usually set to ONLY to prevent searching for libraries on the host. But this also prevents finding libraries via absolute path or relative path to the project. Is there a way to prevent searching host sysroot (/usr/lib, /usr/include, etc), while still allowing find_library via absolute paths or paths relative to the project? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tiagomacarios at gmail.com Wed Aug 10 19:51:16 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Wed, 10 Aug 2016 16:51:16 -0700 Subject: [CMake] Bash on ubuntu on windows as target Message-ID: Hi All, Windows 10 anniversary edition comes with support to execute Linux binaries. I have been trying to use it with one of our projects, but I have been getting a weird error. Maybe someone can help me? The target is pretty simple: set(BASH "C:\\Windows\\System32\\bash.exe") set(ARGS "--help") add_custom_target(linux ${BASH} ${ARGS}) If I then build that project in visual studio (with some extra verbosity) I get: Target "CustomBuild" in file "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets" from project "C:\_Working\delegate\build\linux.vcxproj" (target "_BuildGenerateSourcesAction" depends on it): Using "CustomBuild" task from assembly "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Build.CppTasks.Common.dll". Task "CustomBuild" Write Tracking Logs: x64\Debug\linux\linux.tlog\custombuild.write.1.tlog Read Tracking Logs: x64\Debug\linux\linux.tlog\custombuild.read.1.tlog No output for C:\_WORKING\DELEGATE\BUILD\CMAKEFILES\3FA5525E877A7559336C7D412E1B43B0\LINUX.RULE|C:\_WORKING\DELEGATE\CMAKELISTS.TXT was found in the tracking log; source compilation required. C:\_Working\delegate\CMakeLists.txt will be compiled as it was not found in the tracking log. C:\_Working\delegate\build\CMakeFiles\3fa5525e877a7559336c7d412e1b43b0\linux.rule will be compiled as it was not found in the tracking log. setlocal "C:\Program Files (x86)\CMake\bin\cmake.exe" -HC:/_Working/delegate -BC:/_Working/delegate/build --check-stamp-file C:\_Working\delegate\build\CMakeFiles\generate.stamp if %errorlevel% neq 0 goto :cmEnd :cmEnd endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone :cmErrorLevel exit /b %1 :cmDone if %errorlevel% neq 0 goto :VCEnd setlocal C:\Windows\System32\bash.exe --help if %errorlevel% neq 0 goto :cmEnd :cmEnd endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone :cmErrorLevel exit /b %1 :cmDone if %errorlevel% neq 0 goto :VCEnd Building Custom Rule C:/_Working/delegate/CMakeLists.txt CMake does not need to re-run because C:\_Working\delegate\build\CMakeFiles\generate.stamp is up-to-date. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code -1073740791. Done executing task "CustomBuild" -- FAILED. Done building target "CustomBuild" in project "linux.vcxproj" -- FAILED. The command line seems correct. If I just copy it to the windows prompt it works fine: C:\Users\tmc> C:\Windows\System32\bash.exe --help GNU bash, version 4.3.11(1)-release-(x86_64-pc-linux-gnu) Usage: /bin/bash [GNU long option] [option] ... /bin/bash [GNU long option] [option] script-file ... GNU long options: --debug --debugger --dump-po-strings --dump-strings --help --init-file --login --noediting --noprofile --norc --posix --rcfile --restricted --verbose --version Shell options: -ilrsD or -c command or -O shopt_option (invocation only) -abefhkmnptuvxBCHP or -o option Type `/bin/bash -c "help set"' for more information about shell options. Type `/bin/bash -c help' for more information about shell builtin commands. Use the `bashbug' command to report bugs. I also tried to use it from the visual studio "external tools" and it seems to work. So I am not sure what is going on. Is there a way to debug custom_targets? In case anyone tries the example above on a 64 bit machine: You will need to copy bash.exe from system32 to syswow64 since VS is 32 bits. Tiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From csiga.biga at aol.com Thu Aug 11 02:23:01 2016 From: csiga.biga at aol.com (csiga.biga at aol.com) Date: Thu, 11 Aug 2016 08:23:01 +0200 Subject: [CMake] Bash on ubuntu on windows as target In-Reply-To: References: Message-ID: +1 for the initiative. Wouldn?t it make more sense however to make it a CMAKE_SYSTEM_NAME? If I remember correctly that?s how MinGW works, and this should be something very similar. Felad?: Tiago Macarios -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrik.lehmann at tes-dst.com Thu Aug 11 05:03:55 2016 From: patrik.lehmann at tes-dst.com (Patrik Lehmann) Date: Thu, 11 Aug 2016 11:03:55 +0200 Subject: [CMake] Use GLOB to generate filelist for install package In-Reply-To: <5baee65d-c0aa-0aac-1468-5b04b3bdb69b@tes-dst.com> References: <5baee65d-c0aa-0aac-1468-5b04b3bdb69b@tes-dst.com> Message-ID: Hello, I try to use GLOB to collect the files for my install package, but unfortunately I got the message 'file INSTALL cannot find "C:/Project/include/test1.h;C:/Project/include/test2.h;...' My code: FILE(GLOB MY_INCLUDES_H "${PROJECT_SOURCE_DIR}/include/*.h") INSTALL(FILES "${MY_INCLUDES_H}" DESTINATION "include" COMPONENT CPP_INCLUDES) Is there a way to collect the files this way or is it needed to add every file manually? Kind Regards, Patrik Lehmann From marc.chevrier at sap.com Thu Aug 11 05:22:35 2016 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 11 Aug 2016 09:22:35 +0000 Subject: [CMake] Use GLOB to generate filelist for install package In-Reply-To: References: <5baee65d-c0aa-0aac-1468-5b04b3bdb69b@tes-dst.com> Message-ID: Remove the quotes around the variable MY_INCLUDES_H in the INSTALL command because this is a list. Using quotes, you pass it as a single string. On 11/08/16 11:03, "CMake on behalf of Patrik Lehmann" wrote: Hello, I try to use GLOB to collect the files for my install package, but unfortunately I got the message 'file INSTALL cannot find "C:/Project/include/test1.h;C:/Project/include/test2.h;...' My code: FILE(GLOB MY_INCLUDES_H "${PROJECT_SOURCE_DIR}/include/*.h") INSTALL(FILES "${MY_INCLUDES_H}" DESTINATION "include" COMPONENT CPP_INCLUDES) Is there a way to collect the files this way or is it needed to add every file manually? Kind Regards, Patrik Lehmann -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake From michael.stuermer at schaeffler.com Thu Aug 11 05:29:32 2016 From: michael.stuermer at schaeffler.com (Stuermer, Michael SP/HZA-ZSEP) Date: Thu, 11 Aug 2016 09:29:32 +0000 Subject: [CMake] Use GLOB to generate filelist for install package In-Reply-To: References: <5baee65d-c0aa-0aac-1468-5b04b3bdb69b@tes-dst.com> Message-ID: <7f6a9fc30a454cd19ab0e8249ec639b1@DE013666.schaeffler.com> > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Patrik > Lehmann > Sent: Thursday, August 11, 2016 11:04 AM > To: cmake at cmake.org > Subject: [CMake] Use GLOB to generate filelist for install package > > Hello, > > I try to use GLOB to collect the files for my install package, but unfortunately I > got the message > > 'file INSTALL cannot find > "C:/Project/include/test1.h;C:/Project/include/test2.h;...' > > My code: > > FILE(GLOB MY_INCLUDES_H "${PROJECT_SOURCE_DIR}/include/*.h") > > INSTALL(FILES "${MY_INCLUDES_H}" > DESTINATION "include" > COMPONENT CPP_INCLUDES) > Remove the '"' around the list of headers in your install command: INSTALL(FILES ${MY_INCLUDES_H} ... instead of INSTALL(FILES "${MY_INCLUDES_H}" ... The quotes result in the list to be expanded in only one long string instead of a list of strings. CMake thinks you are only installing one file with a veeeery long name. > > Is there a way to collect the files this way or is it needed to add every file > manually? > > Kind Regards, > Patrik Lehmann > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 patrik.lehmann at tes-dst.com Thu Aug 11 08:22:57 2016 From: patrik.lehmann at tes-dst.com (Patrik Lehmann) Date: Thu, 11 Aug 2016 14:22:57 +0200 Subject: [CMake] Use GLOB to generate filelist for install package In-Reply-To: <7f6a9fc30a454cd19ab0e8249ec639b1@DE013666.schaeffler.com> References: <5baee65d-c0aa-0aac-1468-5b04b3bdb69b@tes-dst.com> <7f6a9fc30a454cd19ab0e8249ec639b1@DE013666.schaeffler.com> Message-ID: <6af34fc8-0448-9bff-5534-bd254345d944@tes-dst.com> Thank You both. Now it works! Am 11.08.2016 um 11:29 schrieb Stuermer, Michael SP/HZA-ZSEP: > >> -----Original Message----- >> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Patrik >> Lehmann >> Sent: Thursday, August 11, 2016 11:04 AM >> To: cmake at cmake.org >> Subject: [CMake] Use GLOB to generate filelist for install package >> >> Hello, >> >> I try to use GLOB to collect the files for my install package, but unfortunately I >> got the message >> >> 'file INSTALL cannot find >> "C:/Project/include/test1.h;C:/Project/include/test2.h;...' >> >> My code: >> >> FILE(GLOB MY_INCLUDES_H "${PROJECT_SOURCE_DIR}/include/*.h") >> >> INSTALL(FILES "${MY_INCLUDES_H}" >> DESTINATION "include" >> COMPONENT CPP_INCLUDES) >> > Remove the '"' around the list of headers in your install command: > > INSTALL(FILES ${MY_INCLUDES_H} ... > > instead of > > INSTALL(FILES "${MY_INCLUDES_H}" ... > > The quotes result in the list to be expanded in only one long string instead of a list of strings. CMake thinks you are only installing one file with a veeeery long name. > > >> Is there a way to collect the files this way or is it needed to add every file >> manually? >> >> Kind Regards, >> Patrik Lehmann >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 tonka3100 at gmail.com Thu Aug 11 09:31:40 2016 From: tonka3100 at gmail.com (tonka tonka) Date: Thu, 11 Aug 2016 15:31:40 +0200 Subject: [CMake] Mantis to GitLab - converter? Message-ID: Dear Kitware, First of all, thank for such great tools like cmake, really enjoy your tools. I?ve saw that you are using GitLab as your sourcecode system. Also I?ve see that you have used Mantis as bugtracker before. I have made the same transition to GitLab, but I?ve not transferred the Manits issues yet. My question is, how do you import the Mantis issue, do you write a tool yourself? If yes, is it opensource/free to use for this onetime convert from Mantis to GitLab. If no, is there any tool which have made the job? Thanks in advance Tonka -------------- next part -------------- An HTML attachment was scrubbed... URL: From MillerHenry at JohnDeere.com Thu Aug 11 11:20:12 2016 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Thu, 11 Aug 2016 15:20:12 +0000 Subject: [CMake] Super builds and export with Namespace Message-ID: <35F6921410093E4CA40D524BD5C18D4C30E67F1F@EDXMB90.jdnet.deere.com> I have a few different cmake based projects that depend on each other (as a tree, no circular dependencies). Mostly this works great, but a few people have expressed interested in a superbuild which builds everything together for various purposes. I can make this work with ExternalProject, but that isn't a useful solution for IDE users. I'm trying to use add_subdirectory and running into a problem with namespaces in my export files Currently projectA has EXPORT(projectA NameSpace ProjectA_) Which works great, when projectB wants to link to a library in projectA it is just FIND_PACKAGE(ProjectA) then TARGET_LINK_LIBRARIES(lib ProjectA_LibraryName). Simple enough without superbuilds. When I get to a superbuild though I don't know how to handle this. It is easy to do write some sort of FindProjectA.cmake or ProjectAConfig.cmake file to make the FIND_PACKAGE work in projectB. However I don't know how to get a ProjectA_LibraryName target that I can link to, the superbuild only knows about LibraryName without the namespace. The only idea I can think of is in the superbuild have a bunch of ADD_LIBRARY (ProjectA_LibraryName ALIAS LibraryName) lines hard coded. This means I have to maintain that file though which I don't like. Does anyone have a better idea? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleigh at codelibre.net Thu Aug 11 12:24:34 2016 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Thu, 11 Aug 2016 16:24:34 +0000 Subject: [CMake] Imported targets and include ordering Message-ID: <4205c36ec18ce088d5c2cf6e1337012b@codelibre.net> I've come across an odd situation where I'm unsure what the most portable and recommended solution would be. I'm linking a program against the CURL and ICU libraries. CURL has traditional variables for the includes and libraries; ICU has imported targets. In FindICU: set_target_properties(${_ICU_imported_target} PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${ICU_INCLUDE_DIR}") In my code: find_package(CURL) find_package(ICU COMPONENTS uc data) [...] list(APPEND libxerces_c_DEPS ${CURL_LIBRARIES}) include_directories(${CURL_INCLUDE_DIRS}) list(APPEND libxerces_c_DEPS ICU::uc ICU::data) And the resulting includes on the compiler invocation: /usr/bin/CC -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -I. -I/tmp/b2/xerces-source/src -Isrc -I/tmp/b2/xerces-source/tests -isystem /tmp/b2/superbuild-install/include -msse2 -MD -MT tests/CMakeFiles/XSValueTest.dir/src/XSValueTest/XSValueTest.cpp.o -MF tests/CMakeFiles/XSValueTest.dir/src/XSValueTest/XSValueTest.cpp.o.d -o tests/CMakeFiles/XSValueTest.dir/src/XSValueTest/XSValueTest.cpp.o -c /tmp/b2/xerces-source/tests/src/XSValueTest/XSValueTest.cpp The problem is this: CURL is in /usr/local/include ICU v55 is in /usr/local/include ICU v57 is in /tmp/b2/superbuild-install/include with its libs in /tmp/b2/superbuild-install/lib CMAKE_PREFIX_PATH is set appropriately, and all the Find module checks are correct. The problem is that the ICU INTERFACE_INCLUDE_DIRECTORIES is treated as a system include. This would be OK, if it were not for the fact that the CURL includes are placed before it. The problem is that it's not a system path. However, the CURL path *is*. And this leads to it building against the ICU55 headers, and then failing to link against the ICU57 libraries. But that's just the situation on this specific (FreeBSD) system; the situation could be reversed on another with a locally built CURL and a system ICU and CURL. I see that I could use NO_SYSTEM_FROM_IMPORTED for the imported target, and/or use BEFORE|AFTER SYSTEM with [target_]include_directories. However, none of these feel appropriate. They would require knowledge I don't have as the cmake script author--either of these libraries could be using system or non-system paths; I don't have the foreknowledge to make that determination. How could an end user override what are system paths and what are not without hand-editing the script? It seems (being naive) that the hardcoded behaviour of treating INTERFACE_INCLUDE_DIRECTORIES as system includes isn't a universally useful default, and while I can override the behaviour, that's a explicit action on the part of the script author, and might be inappropriate for the user's system. Whether a path is a system include or not seems to be something the end user should be able to tune, since the script author and cmake find module authors have no idea what the local situation is for any arbitrary system. For example, it wouldn't hurt for cmake to "know" that /usr/local/include is a system path as a built-in default, and allow additional paths to be added, and then if a random find module adds it such that it's used by a target as a non-system include we know we can ignore it and just use it as a system include instead. Unless I'm misunderstanding the situation and making this work is already possible. Thanks, Roger From tiagomacarios at gmail.com Thu Aug 11 13:12:21 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Thu, 11 Aug 2016 10:12:21 -0700 Subject: [CMake] Bash on ubuntu on windows as target In-Reply-To: <20160811062317.C32BAF5211@public.kitware.com> References: <20160811062317.C32BAF5211@public.kitware.com> Message-ID: Well what I was trying to do was to actually have a target inside the windows build that would trigger the linux build so to build both at the same time. imagine you have a VS project one of the "projects" would be the linux build. So as long as the build folder is different I could have both building in sync everytime. Get the idea? If I just do a full build inside bash everything works great =) On Wed, Aug 10, 2016 at 11:23 PM, <"M?t? Ferenc Nagy-Egri via CMake wrote: > +1 for the initiative. Wouldn?t it make more sense however to make it a > CMAKE_SYSTEM_NAME? If I remember correctly that?s how MinGW works, and this > should be something very similar. > > > > > > *Felad?: *Tiago Macarios > *Elk?ldve: *2016. augusztus 11., cs?t?rt?k 1:51 > *C?mzett: *CMake ML > *T?rgy: *[CMake] Bash on ubuntu on windows as target > > > > Hi All, > > > > Windows 10 anniversary edition comes with support to execute Linux > binaries. I have been trying to use it with one of our projects, but I have > been getting a weird error. Maybe someone can help me? > > > > The target is pretty simple: > > > > set(BASH "C:\\Windows\\System32\\bash.exe") > > set(ARGS "--help") > > add_custom_target(linux ${BASH} ${ARGS}) > > > > If I then build that project in visual studio (with some extra verbosity) > I get: > > > > Target "CustomBuild" in file "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\ > v4.0\V140\Microsoft.CppCommon.targets" from project > "C:\_Working\delegate\build\linux.vcxproj" (target > "_BuildGenerateSourcesAction" depends on it): > > Using "CustomBuild" task from assembly "C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Build. > CppTasks.Common.dll". > > Task "CustomBuild" > > Write Tracking Logs: > > x64\Debug\linux\linux.tlog\custombuild.write.1.tlog > > Read Tracking Logs: > > x64\Debug\linux\linux.tlog\custombuild.read.1.tlog > > No output for C:\_WORKING\DELEGATE\BUILD\CMAKEFILES\ > 3FA5525E877A7559336C7D412E1B43B0\LINUX.RULE|C:\_WORKING\DELEGATE\CMAKELISTS.TXT > was found in the tracking log; source compilation required. > > C:\_Working\delegate\CMakeLists.txt will be compiled as it was not > found in the tracking log. > > C:\_Working\delegate\build\CMakeFiles\3fa5525e877a7559336c7d412e1b43b0\linux.rule > will be compiled as it was not found in the tracking log. > > setlocal > > "C:\Program Files (x86)\CMake\bin\cmake.exe" -HC:/_Working/delegate > -BC:/_Working/delegate/build --check-stamp-file C:\_Working\delegate\build\ > CMakeFiles\generate.stamp > > if %errorlevel% neq 0 goto :cmEnd > > :cmEnd > > endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone > > :cmErrorLevel > > exit /b %1 > > :cmDone > > if %errorlevel% neq 0 goto :VCEnd > > setlocal > > C:\Windows\System32\bash.exe --help > > if %errorlevel% neq 0 goto :cmEnd > > :cmEnd > > endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone > > :cmErrorLevel > > exit /b %1 > > :cmDone > > if %errorlevel% neq 0 goto :VCEnd > > Building Custom Rule C:/_Working/delegate/CMakeLists.txt > > CMake does not need to re-run because C:\_Working\delegate\build\CMakeFiles\generate.stamp > is up-to-date. > > C:\Program Files (x86)\MSBuild\Microsoft.Cpp\ > v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" > exited with code -1073740791. > > Done executing task "CustomBuild" -- FAILED. > > Done building target "CustomBuild" in project "linux.vcxproj" -- FAILED. > > > > > > The command line seems correct. If I just copy it to the windows prompt it > works fine: > > > > C:\Users\tmc> C:\Windows\System32\bash.exe --help > > GNU bash, version 4.3.11(1)-release-(x86_64-pc-linux-gnu) > > Usage: /bin/bash [GNU long option] [option] ... > > /bin/bash [GNU long option] [option] script-file ... > > GNU long options: > > --debug > > --debugger > > --dump-po-strings > > --dump-strings > > --help > > --init-file > > --login > > --noediting > > --noprofile > > --norc > > --posix > > --rcfile > > --restricted > > --verbose > > --version > > Shell options: > > -ilrsD or -c command or -O shopt_option (invocation only) > > -abefhkmnptuvxBCHP or -o option > > Type `/bin/bash -c "help set"' for more information about shell options. > > Type `/bin/bash -c help' for more information about shell builtin commands. > > Use the `bashbug' command to report bugs. > > > > > > I also tried to use it from the visual studio "external tools" and it > seems to work. So I am not sure what is going on. Is there a way to debug > custom_targets? > > > > In case anyone tries the example above on a 64 bit machine: You will need > to copy bash.exe from system32 to syswow64 since VS is 32 bits. > > > > 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 robert.maynard at kitware.com Thu Aug 11 14:56:21 2016 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 11 Aug 2016 14:56:21 -0400 Subject: [CMake] Mantis to GitLab - converter? In-Reply-To: References: Message-ID: Hi tonka, We (Ben) wrote a conversion tool that we use to convert mantis issues over to gitlab. You can find the project at: https://gitlab.kitware.com/utils/mantis-to-gitlab It has an Apache 2.0 license. On Thu, Aug 11, 2016 at 9:31 AM, tonka tonka wrote: > Dear Kitware, > > First of all, thank for such great tools like cmake, really enjoy your > tools. > > I?ve saw that you are using GitLab as your sourcecode system. Also I?ve see > that you have used Mantis as bugtracker before. I have made the same > transition to GitLab, but I?ve not transferred the Manits issues yet. > > My question is, how do you import the Mantis issue, do you write a tool > yourself? > > If yes, is it opensource/free to use for this onetime convert from Mantis to > GitLab. > > If no, is there any tool which have made the job? > > Thanks in advance > > Tonka > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 rleigh at codelibre.net Thu Aug 11 15:01:08 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Thu, 11 Aug 2016 19:01:08 +0000 Subject: [CMake] Imported targets and include ordering In-Reply-To: <4205c36ec18ce088d5c2cf6e1337012b@codelibre.net> References: <4205c36ec18ce088d5c2cf6e1337012b@codelibre.net> Message-ID: On 11/08/2016 16:24, rleigh at codelibre.net wrote: > I've come across an odd situation where I'm unsure what the most > portable and recommended solution would be. > > I'm linking a program against the CURL and ICU libraries. CURL has > traditional variables for the includes and libraries; ICU has imported > targets. > > In FindICU: > set_target_properties(${_ICU_imported_target} PROPERTIES > INTERFACE_INCLUDE_DIRECTORIES "${ICU_INCLUDE_DIR}") > > In my code: > > find_package(CURL) > find_package(ICU COMPONENTS uc data) > [...] > list(APPEND libxerces_c_DEPS ${CURL_LIBRARIES}) > include_directories(${CURL_INCLUDE_DIRS}) > list(APPEND libxerces_c_DEPS ICU::uc ICU::data) > > And the resulting includes on the compiler invocation: > > /usr/bin/CC -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -I. > -I/tmp/b2/xerces-source/src -Isrc -I/tmp/b2/xerces-source/tests -isystem > /tmp/b2/superbuild-install/include -msse2 -MD -MT > tests/CMakeFiles/XSValueTest.dir/src/XSValueTest/XSValueTest.cpp.o -MF > tests/CMakeFiles/XSValueTest.dir/src/XSValueTest/XSValueTest.cpp.o.d -o > tests/CMakeFiles/XSValueTest.dir/src/XSValueTest/XSValueTest.cpp.o -c > /tmp/b2/xerces-source/tests/src/XSValueTest/XSValueTest.cpp > > The problem is this: > CURL is in /usr/local/include > ICU v55 is in /usr/local/include > ICU v57 is in /tmp/b2/superbuild-install/include with its libs in > /tmp/b2/superbuild-install/lib Sorry, I noticed that the compiler invocation was from the wrong source file; it should have -I/usr/local/include right at the start, then -isystem /tmp/b2/superbuild-install/include at the end as above. From ken at Ldb3.com Thu Aug 11 21:10:35 2016 From: ken at Ldb3.com (Ken Boulange) Date: Thu, 11 Aug 2016 18:10:35 -0700 Subject: [CMake] Need fix bid to build CMake generated Library. Message-ID: <01e201d1f436$54e721e0$feb565a0$@Ldb3.com> I am a one man company that needs to get a Library built from C/C++ source using CMake. My system is windows 7 Professional. I am running MVS 8 (Microsoft Visual Studios 8) I need the following library built from the below URL (It's a DICOM image Library): http://dicom.offis.de/dcmtk.php.en It's configured to be built by CMake. I've come close, but not close enough. I am looking for someone to download Cmake and the "http://dicom.offis.de/dcmtk.php.en" source, then run CMake and build the libraries. I am looking for a fixed bid to do it. I have very little cash that is why I need a fixed bid. Can anyone on this list help me? Ken 415 987 9414. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zlynx at acm.org Thu Aug 11 20:48:16 2016 From: zlynx at acm.org (Zan Lynx) Date: Thu, 11 Aug 2016 18:48:16 -0600 Subject: [CMake] Running CxxTest fails on Fedora 24 Message-ID: The Fedora /usr/bin/cxxtestgen script calls /usr/bin/python3. NOT python2 or python. CMake runs /usr/bin/python /usr/bin/cxxtestgen which is linked to python2, and the script fails. I don't quite understand why CMake feels the need to call it explicitly with the Python interpreter that it found instead of using the shebang. Maybe Windows? Eh. I am fixing it in my script by doing this: > FIND_PACKAGE(PythonInterp 3 QUIET) > FIND_PACKAGE(CxxTest) I thought this might help anyone else hitting this. -- Knowledge is Power -- Power Corrupts Study Hard -- Be Evil From petr.kmoch at gmail.com Fri Aug 12 03:35:32 2016 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 12 Aug 2016 09:35:32 +0200 Subject: [CMake] What is a utility target ? In-Reply-To: References: <2cea01d1e6b4$a5a2b2a0$f0e817e0$@codeaurora.org> <39a301d1e83e$25b1f110$7115d330$@codeaurora.org> Message-ID: Hi all, a bit late to the party, but in case it's still relevant: targets have a property named TYPE ( https://cmake.org/cmake/help/latest/prop_tgt/TYPE.html ) which stores the target type as a string: get_property(type TARGET TargetName PROPERTY TYPE) if(type STREQUAL "EXECUTABLE" OR type MATCHES "LIBRARY") # it's was added by add_executable()/add_library() else() # it wasn't endif() Petr On 27 July 2016 at 23:15, Craig Scott wrote: > There may be a way to tell, but nothing is coming to mind at the moment. > Maybe someone else on the list can chime in? > > > On Thu, Jul 28, 2016 at 5:36 AM, Azharuddin Mohammed < > azharudd at codeaurora.org> wrote: > >> Thanks for the explanation, Craig. Is there a way to detect if the target >> was a physical file created using add_library/add_executable, or a >> utility target created using add_custom_target in order to >> conditionally call the target_link_libraries command ? There is the >> condition if(TARGET target-name) , but according to the documentation it >> returns true for any existing logical target name such as those created >> by the *add_executable()* >> >> , *add_library()* >> , >> or *add_custom_target()* >> >> commands. >> >> >> >> *From:* Craig Scott [mailto:craig.scott at crascit.com] >> *Sent:* Monday, July 25, 2016 1:52 PM >> *To:* Azharuddin Mohammed >> *Cc:* CMake >> *Subject:* Re: [CMake] What is a utility target ? >> >> >> >> In the context of that particular part of the CMake documentation, it is >> referring to targets that are not created by add_library() or >> add_executable(). Targets created by add_custom_target() are not something >> CMake knows what to do with if you give them to the target_link_libraries() >> command, since these custom targets may not (and typically won't) >> correspond to a physical file being created (that's what >> add_custom_command() is for). So the term *utility target* can be >> thought of as being a custom target you create for convenience, but not >> something which actually corresponds to a library or executable. Examples >> of utility targets that CMake will automatically create for you include >> things like *all*, *test*, *package*, etc. >> >> >> >> >> >> On Tue, Jul 26, 2016 at 6:39 AM, Azharuddin Mohammed < >> azharudd at codeaurora.org> wrote: >> >> Hi >> >> >> >> CMake Policy CMP0039 (https://cmake.org/cmake/help/ >> v3.0/policy/CMP0039.html) mentions that ?Utility targets may not have >> link dependencies? . Can someone please explain what does ?utility >> targets? mean ? >> >> >> >> Thanks >> >> >> >> - >> >> Azhar >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/ >> opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> >> >> >> >> >> -- >> >> Craig Scott >> >> Melbourne, Australia >> >> http://crascit.com >> > > > > -- > Craig Scott > Melbourne, Australia > http://crascit.com > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 annulen at yandex.ru Fri Aug 12 03:36:44 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 12 Aug 2016 10:36:44 +0300 Subject: [CMake] Running CxxTest fails on Fedora 24 In-Reply-To: References: Message-ID: <82141470987404@web29h.yandex.ru> 12.08.2016, 04:32, "Zan Lynx" : > The Fedora /usr/bin/cxxtestgen script calls /usr/bin/python3. NOT > python2 or python. > > CMake runs /usr/bin/python /usr/bin/cxxtestgen which is linked to > python2, and the script fails. > > I don't quite understand why CMake feels the need to call it explicitly > with the Python interpreter that it found instead of using the shebang. > Maybe Windows? Eh. I think this is a misfeature of python interpreter. For example, perl interprets shebang in such case. > > I am fixing it in my script by doing this: > >> ?FIND_PACKAGE(PythonInterp 3 QUIET) >> ?FIND_PACKAGE(CxxTest) > > I thought this might help anyone else hitting this. > > -- > ????????????????Knowledge is Power -- Power Corrupts > ????????????????????????Study Hard -- Be Evil > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 c3124185 at uon.edu.au Fri Aug 12 05:08:08 2016 From: c3124185 at uon.edu.au (Alex Biddulph) Date: Fri, 12 Aug 2016 19:08:08 +1000 Subject: [CMake] add_compile_options query Message-ID: Hi, I am trying to add some GCC compiler optimisation flags using the add_compile_options directive but am running into some issues due to the nature of the flags. There are 3 flags that I am trying to set: --param l1-cache-size=24 --param l1-cache-line-size=64 --param l2-cache-size=512 If I try to add these as: add_compile_options(--param l1-cache-size=24) add_compile_options(--param l1-cache-line-size=64) add_compile_options(--param l2-cache-size=512) Then the resulting portion of the command line is: --param l1-cache-size=24 l1-cache-line-size=64 l2-cache-size=512 That is, only one of the '--param's is maintained, but all 3 need to be maintained in order for GCC to understand the flags. Is it possible to use add_compile_options to set these flags? Or is there another more effective method? I would like to avoid adding them to CFLAGS and CXXFLAGS if at all possible. Thanks in advance, Alex From marc.chevrier at sap.com Fri Aug 12 07:51:49 2016 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Fri, 12 Aug 2016 11:51:49 +0000 Subject: [CMake] add_compile_options query In-Reply-To: References: Message-ID: Specify flags as strings rather than lists (i.e. add quotes): add_compile_options("--param l1-cache-size=24") add_compile_options("--param l1-cache-line-size=64") add_compile_options("--param l2-cache-size=512") On 12/08/16 11:08, "CMake on behalf of Alex Biddulph" wrote: Hi, I am trying to add some GCC compiler optimisation flags using the add_compile_options directive but am running into some issues due to the nature of the flags. There are 3 flags that I am trying to set: --param l1-cache-size=24 --param l1-cache-line-size=64 --param l2-cache-size=512 If I try to add these as: add_compile_options(--param l1-cache-size=24) add_compile_options(--param l1-cache-line-size=64) add_compile_options(--param l2-cache-size=512) Then the resulting portion of the command line is: --param l1-cache-size=24 l1-cache-line-size=64 l2-cache-size=512 That is, only one of the '--param's is maintained, but all 3 need to be maintained in order for GCC to understand the flags. Is it possible to use add_compile_options to set these flags? Or is there another more effective method? I would like to avoid adding them to CFLAGS and CXXFLAGS if at all possible. Thanks in advance, Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake From ken at Ldb3.com Fri Aug 12 11:50:03 2016 From: ken at Ldb3.com (Ken Boulange) Date: Fri, 12 Aug 2016 08:50:03 -0700 Subject: [CMake] No response so far. -- Looking for fixed contract help building Library with CMake. Message-ID: <00e801d1f4b1$3131efc0$9395cf40$@Ldb3.com> Any help would be appreciated. From: Ken Boulange [mailto:ken at shapesearch.com] Sent: Thursday, August 11, 2016 5:57 PM To: 'cmake at cmake.org' Subject: Looking for fixed contract help building Library with CMake. I am a one man company that needs to get a Library built from C/C++ source using CMake. My system is windows 7 Professional. I am running MVS 8 (Microsoft Visual Studios 8) I need the following library built from the below URL (It's a DICOM image Library): http://dicom.offis.de/dcmtk.php.en It's configured to be built by CMake. I've come close, but not close enough. I am looking for someone to download Cmake and the "http://dicom.offis.de/dcmtk.php.en" source, then run CMake and build the libraries. I am looking for a fixed bid to do it. I have very little cash that is why I need a fixed bid. Can anyone on this list help me? Ken 415 987 9414. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleigh at codelibre.net Fri Aug 12 12:20:31 2016 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Fri, 12 Aug 2016 16:20:31 +0000 Subject: [CMake] No response so far. -- Looking for fixed contract help building Library with CMake. In-Reply-To: <00e801d1f4b1$3131efc0$9395cf40$@Ldb3.com> References: <00e801d1f4b1$3131efc0$9395cf40$@Ldb3.com> Message-ID: On 2016-08-12 15:50, Ken Boulange wrote: > I am a one man company that needs to get a Library built from C/C++ > source using CMake. > > My system is windows 7 Professional. I am running MVS 8 (Microsoft > Visual Studios 8) I need the following library built from the below > URL (It's a DICOM image Library): > > http://dicom.offis.de/dcmtk.php.en > > It's configured to be built by CMake. I've come close, but not close > enough. What are the problems are you having with it? I'm afraid I don't have this version of Visual Studio; I only have 12 and 14. But I tried building with 14 + Ninja and it built without trouble and passed all the unit tests. The optional dependencies like libtiff, libpng are also buildable with cmake, and I build these on Windows daily, so building the collection should certainly be achievable. Regards, Roger From s_buschmann at gmx.de Fri Aug 12 12:28:55 2016 From: s_buschmann at gmx.de (Stefan Buschmann) Date: Fri, 12 Aug 2016 18:28:55 +0200 Subject: [CMake] No response so far. -- Looking for fixed contract help building Library with CMake. In-Reply-To: <00e801d1f4b1$3131efc0$9395cf40$@Ldb3.com> References: <00e801d1f4b1$3131efc0$9395cf40$@Ldb3.com> Message-ID: Did you realize that there already is a download for the library in binary form? See "DCMTK 3.6.0 - support libraries for Windows" on the website you posted. That should be all you need to use that library in your own projects. Do you require any special configuration that you need to build it yourself, or did you just not find the binary download? Stefan. On 12.08.2016 17:50, Ken Boulange wrote: > > Any help would be appreciated. > > *From:*Ken Boulange [mailto:ken at shapesearch.com] > *Sent:* Thursday, August 11, 2016 5:57 PM > *To:* 'cmake at cmake.org' > *Subject:* Looking for fixed contract help building Library with CMake. > > I am a one man company that needs to get a Library built from C/C++ > source using CMake. > > My system is windows 7 Professional. I am running MVS 8 (Microsoft > Visual Studios 8) I need the following library built from the below > URL (It?s a DICOM image Library): > > http://dicom.offis.de/dcmtk.php.en > > It?s configured to be built by CMake. I?ve come close, but not close > enough. > > I am looking for someone to download Cmake and the > ?http://dicom.offis.de/dcmtk.php.en? source, then run CMake and > build the libraries. > > I am looking for a fixed bid to do it. I have very little cash that > is why I need a fixed bid. > > Can anyone on this list help me? > > Ken > > 415 987 9414. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken at Ldb3.com Fri Aug 12 13:03:45 2016 From: ken at Ldb3.com (Ken Boulange) Date: Fri, 12 Aug 2016 10:03:45 -0700 Subject: [CMake] No response so far. -- Looking for fixed contract help building Library with CMake. In-Reply-To: References: <00e801d1f4b1$3131efc0$9395cf40$@Ldb3.com> Message-ID: <013701d1f4bb$7ce85e40$76b91ac0$@Ldb3.com> I did not find the binaries. Rather I misread them. Let me try that. Ken From: Stefan Buschmann [mailto:s_buschmann at gmx.de] Sent: Friday, August 12, 2016 9:29 AM To: Ken Boulange ; cmake at cmake.org Subject: Re: [CMake] No response so far. -- Looking for fixed contract help building Library with CMake. Did you realize that there already is a download for the library in binary form? See "DCMTK 3.6.0 - support libraries for Windows" on the website you posted. That should be all you need to use that library in your own projects. Do you require any special configuration that you need to build it yourself, or did you just not find the binary download? Stefan. On 12.08.2016 17:50, Ken Boulange wrote: Any help would be appreciated. From: Ken Boulange [ mailto:ken at shapesearch.com] Sent: Thursday, August 11, 2016 5:57 PM To: ' cmake at cmake.org' Subject: Looking for fixed contract help building Library with CMake. I am a one man company that needs to get a Library built from C/C++ source using CMake. My system is windows 7 Professional. I am running MVS 8 (Microsoft Visual Studios 8) I need the following library built from the below URL (It's a DICOM image Library): http://dicom.offis.de/dcmtk.php.en It's configured to be built by CMake. I've come close, but not close enough. I am looking for someone to download Cmake and the " http://dicom.offis.de/dcmtk.php.en" source, then run CMake and build the libraries. I am looking for a fixed bid to do it. I have very little cash that is why I need a fixed bid. Can anyone on this list help me? Ken 415 987 9414. -------------- next part -------------- An HTML attachment was scrubbed... URL: From branch at arlut.utexas.edu Fri Aug 12 13:02:13 2016 From: branch at arlut.utexas.edu (Ed Branch) Date: Fri, 12 Aug 2016 12:02:13 -0500 Subject: [CMake] Super builds and export with Namespace Message-ID: <14fbb0d2-267f-284d-1a4a-5848ceda78f4@arlut.utexas.edu> We do it like this: - in projectA/CMakeLists.txt: ---- set( ProjectA_IN_TREE TRUE CACHE INTERNAL "" ) ---- - in projectA/ProjectA-config.cmake.in (which is converted to ProjectA-config.cmake by a call to configure_package_config_file from the CMakePackageConfigHelpers module): ---- if( ProjectA_IN_TREE ) add_library( ProjectA_LibraryName ALIAS LibraryName ) else() include("${CMAKE_CURRENT_LIST_DIR}/ProjectA-targets.cmake") endif() ---- The superbuild then just add_subdirectory(projectA) before add_subdirectory(pojectB), and projectB uses libraries from projectA just like it would if there was no superbuild. From rcdailey.lists at gmail.com Fri Aug 12 15:59:31 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 12 Aug 2016 14:59:31 -0500 Subject: [CMake] Need ideas/opinions on third party library management Message-ID: Hello, There is an internal C++ product at the company I work for which I have written a series of CMake scripts for. This project actually has dependencies on several open source libraries, such as boost, freetype, openssl, etc. Right now what we do is build each of these third party libraries *by hand*, once for every platform we support (Windows, Linux x86, Android NDK). Then we stuff the includes (headers) and libraries (static/shared) in a submodule and the primary code base's CMake scripts pull them in as interface targets. This works well and is light-weight but is a pain when upgrading or changing libraries. It's a pain because if I want to upgrade boost, I have to build it up to 6 times (once for each platform and once for each configuration). I've been thinking of a different approach for a while. I've done some toying around with the "Super Build" concept, where I have a separate CMake project that does nothing but use the ExternalProject module to build libraries in real time along with our project. So the order of operations would be as follows (for our automated build server): 1. Clone our "Third Party" repository 2. Use CMake to generate & build the "Super Build" project (this builds boost, openssl, freetype, etc for the current platform). 3. Clone the main code base's repository 4. Use CMake to generate & build, using find_package() to refer to interface targets exported by those third party libraries built in step 2 Obviously this will make builds take significantly longer, because we're constantly rebuilding the same third party libraries over and over again. However, it virtually eliminates the maintenance burden for third party libraries because they are built inherently with everything else. Note that I can't refer to pre-built libraries in our build environments because we need very specific control over the versions of our libraries as well as the toolchains that were used to build them. Also we may specifically build our libraries a certain way (such as boost). For this reason we do not rely on our external environment or external package managers to fulfill third party dependencies, like most open source projects do on Linux for example. Does this "Super Build" approach sound like a better idea? What other options are available? The downside with the "Super Build" solution is that it will become very difficult to make the transition between building third party and building our code base seamless. I can't do both in the same generate step because find_package() can't be called until the libraries are built & installed. From MillerHenry at JohnDeere.com Fri Aug 12 16:35:02 2016 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Fri, 12 Aug 2016 20:35:02 +0000 Subject: [CMake] Need ideas/opinions on third party library management In-Reply-To: References: Message-ID: <35F6921410093E4CA40D524BD5C18D4C30E69625@EDXMB90.jdnet.deere.com> A superbuild will work, and you can write your own Find*.cmake so that find_package works - you don't need most of what the real Find_package would do for you because you already know what is installed where as you control that. But, can you live with the trade off: long build times? What my company did to solve a similar problem is write a tool (this took most of a year for a couple people, a lot that is very specific to our environment so sharing doesn't make sense) that that will install packages in a docker (linux only) image. Each project we build has a "pin file" that lists the packages that project depends on. When we upgrade boost, the build creates a .rpm package which the tool automatically installs for the build to use. What really makes our approach work is the integration into our CI system, when I change boost I verify the build in just one architecture, then push. The CI system takes over to build every supported architecture, and then it deploys the packages - I don't have to build them all by hand (of course if something fails I need to figure that one out). Then I just have to pin the new package and our build system takes care of ensuring the new version is in place. As I said, the above is complex and very custom to our environment. I'm not entirely happy with it, but I can't come up with anything better for our requirements. In particular I can go backward to any released version of code and rebuild it - meaning we can fix bugs in old versions easily if a customer isn't willing to upgrade. -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert Dailey Sent: Friday, August 12, 2016 3:00 PM To: CMake ; CMake Developers Subject: [CMake] Need ideas/opinions on third party library management Hello, There is an internal C++ product at the company I work for which I have written a series of CMake scripts for. This project actually has dependencies on several open source libraries, such as boost, freetype, openssl, etc. Right now what we do is build each of these third party libraries *by hand*, once for every platform we support (Windows, Linux x86, Android NDK). Then we stuff the includes (headers) and libraries (static/shared) in a submodule and the primary code base's CMake scripts pull them in as interface targets. This works well and is light-weight but is a pain when upgrading or changing libraries. It's a pain because if I want to upgrade boost, I have to build it up to 6 times (once for each platform and once for each configuration). I've been thinking of a different approach for a while. I've done some toying around with the "Super Build" concept, where I have a separate CMake project that does nothing but use the ExternalProject module to build libraries in real time along with our project. So the order of operations would be as follows (for our automated build server): 1. Clone our "Third Party" repository 2. Use CMake to generate & build the "Super Build" project (this builds boost, openssl, freetype, etc for the current platform). 3. Clone the main code base's repository 4. Use CMake to generate & build, using find_package() to refer to interface targets exported by those third party libraries built in step 2 Obviously this will make builds take significantly longer, because we're constantly rebuilding the same third party libraries over and over again. However, it virtually eliminates the maintenance burden for third party libraries because they are built inherently with everything else. Note that I can't refer to pre-built libraries in our build environments because we need very specific control over the versions of our libraries as well as the toolchains that were used to build them. Also we may specifically build our libraries a certain way (such as boost). For this reason we do not rely on our external environment or external package managers to fulfill third party dependencies, like most open source projects do on Linux for example. Does this "Super Build" approach sound like a better idea? What other options are available? The downside with the "Super Build" solution is that it will become very difficult to make the transition between building third party and building our code base seamless. I can't do both in the same generate step because find_package() can't be called until the libraries are built & installed. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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 elizabeth.fischer at columbia.edu Fri Aug 12 16:41:00 2016 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Fri, 12 Aug 2016 16:41:00 -0400 Subject: [CMake] Need ideas/opinions on third party library management In-Reply-To: References: Message-ID: This is what Spack and other meta builders do. See http://github. com/llnl/spack On Aug 12, 2016 3:59 PM, "Robert Dailey" wrote: > Hello, > > There is an internal C++ product at the company I work for which I > have written a series of CMake scripts for. This project actually has > dependencies on several open source libraries, such as boost, > freetype, openssl, etc. > > Right now what we do is build each of these third party libraries *by > hand*, once for every platform we support (Windows, Linux x86, Android > NDK). Then we stuff the includes (headers) and libraries > (static/shared) in a submodule and the primary code base's CMake > scripts pull them in as interface targets. > > This works well and is light-weight but is a pain when upgrading or > changing libraries. It's a pain because if I want to upgrade boost, I > have to build it up to 6 times (once for each platform and once for > each configuration). > > I've been thinking of a different approach for a while. I've done some > toying around with the "Super Build" concept, where I have a separate > CMake project that does nothing but use the ExternalProject module to > build libraries in real time along with our project. So the order of > operations would be as follows (for our automated build server): > > 1. Clone our "Third Party" repository > 2. Use CMake to generate & build the "Super Build" project (this > builds boost, openssl, freetype, etc for the current platform). > 3. Clone the main code base's repository > 4. Use CMake to generate & build, using find_package() to refer to > interface targets exported by those third party libraries built in > step 2 > > Obviously this will make builds take significantly longer, because > we're constantly rebuilding the same third party libraries over and > over again. However, it virtually eliminates the maintenance burden > for third party libraries because they are built inherently with > everything else. > > Note that I can't refer to pre-built libraries in our build > environments because we need very specific control over the versions > of our libraries as well as the toolchains that were used to build > them. Also we may specifically build our libraries a certain way (such > as boost). For this reason we do not rely on our external environment > or external package managers to fulfill third party dependencies, like > most open source projects do on Linux for example. > > Does this "Super Build" approach sound like a better idea? What other > options are available? The downside with the "Super Build" solution is > that it will become very difficult to make the transition between > building third party and building our code base seamless. I can't do > both in the same generate step because find_package() can't be called > until the libraries are built & installed. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 rleigh at codelibre.net Fri Aug 12 17:58:11 2016 From: rleigh at codelibre.net (Roger Leigh) Date: Fri, 12 Aug 2016 21:58:11 +0000 Subject: [CMake] Need ideas/opinions on third party library management In-Reply-To: References: Message-ID: On 12/08/2016 19:59, Robert Dailey wrote: > Hello, > I've been thinking of a different approach for a while. I've done some > toying around with the "Super Build" concept, where I have a separate > CMake project that does nothing but use the ExternalProject module to > build libraries in real time along with our project. So the order of > operations would be as follows (for our automated build server): > > 1. Clone our "Third Party" repository > 2. Use CMake to generate & build the "Super Build" project (this > builds boost, openssl, freetype, etc for the current platform). > 3. Clone the main code base's repository > 4. Use CMake to generate & build, using find_package() to refer to > interface targets exported by those third party libraries built in > step 2 You can simplify this to two steps: 1. Clone the superbuild repository 2. Build the third-party and first-party packages This is the approach we take with the OME super-build https://github.com/ome/ome-cmake-superbuild/ See the packages in https://github.com/ome/ome-cmake-superbuild/tree/develop/packages all the ones with an "ome-" prefix are the first-party libraries; everything else is third-party. They are all external projects. We have cmake options to select all packages, first-party packages only or select individual packages by hand; the recursive dependency resolution will add/ignore dependencies depending upon the chosen policy (defaulting to include third-party dependencies). So when you're building on BSD or Linux, you can say "no third-party dependencies except for gtest", or choose everything, and on Windows where there is no package manager, you always build everything. And on Windows you can build just the dependencies and reuse them later; it has support for using cached builds which we use on the CI side to cut down build times; we only rebuild the cache when the superbuild git tree hash changes; see the scripts/jenkins-build script In addition to that, we have the means to build the first-party libraries in different ways 1. From source release tarball (last stable release) 2. From git (specify remote+branch as cmake options) 3. From a local git checkout (on whatever branch is currently checked out) You can see the selection logic here: https://github.com/ome/ome-cmake-superbuild/blob/develop/packages/ome-files/superbuild.cmake#L4 In practice (1) is for end-users to build the whole thing, and (3) is what I use in practice to develop locally where I have a full set of git repos checked out locally, and I tell the superbuild to build them, along with all the third-party deps; (3) is also what we use on the CI system, with jenkins cloning all the individual repos into the workspace, then doing pretty much the same thing. (2) is OK for one-off builds, but the need for a full git clone for every package is too much for routine use And you can see how first- and third-party dependencies are handled here: https://github.com/ome/ome-cmake-superbuild/blob/develop/packages/ome-files/superbuild.cmake#L48 I might rearrange that so that the classification is in the dependency rather than the dependeee later on though. It kind of evolved this way as we added additional features and needs a little cleanup to make it perfect. Everything in the above repository is BSD licensed, so feel free to use it for inspiration or take what you like. The main point I wanted to make was that with the superbuild *everything* can be an external project, including your own code. And from that point you can add in features like being able to selectively build just the third-party or just your own code, rather than forcing them to be separate manual steps. Regards, Roger From elizabeth.fischer at columbia.edu Fri Aug 12 20:12:03 2016 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Fri, 12 Aug 2016 20:12:03 -0400 Subject: [CMake] Need ideas/opinions on third party library management In-Reply-To: References: Message-ID: > > This is what Spack and other meta builders do. I don't think CMake is the > best place to do it, for a number of reasons. I would not try to re-invent > the wheel here. > See http://github. com/llnl/spack > -- Elizabeth -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Sat Aug 13 19:00:46 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sat, 13 Aug 2016 18:00:46 -0500 Subject: [CMake] Need ideas/opinions on third party library management In-Reply-To: References: Message-ID: I did some brief digging into spack, and it doesn't look like it supports Windows. All I see are shell scripts and the documentation uses POSIX. If I'm going to use a package manager, it needs to be able to support Android (ARM), Windows, and Linux. I have specific toolchains that I'll need the package manager to use for each of these platforms, assuming it compiles these libraries. It also needs to be capable of cross-compiling (in the case of ARM toolchain in the Android NDK). I mean, we can't really call it "reinventing the wheel" if my requirements are so specific that no current tooling can support it. If you have any info on spack related to my requirements please let me know. It looks promising, but so far doesn't seem like it will work out. On Fri, Aug 12, 2016 at 3:41 PM, Elizabeth A. Fischer wrote: > This is what Spack and other meta builders do. See http://github. > com/llnl/spack > > On Aug 12, 2016 3:59 PM, "Robert Dailey" wrote: >> >> Hello, >> >> There is an internal C++ product at the company I work for which I >> have written a series of CMake scripts for. This project actually has >> dependencies on several open source libraries, such as boost, >> freetype, openssl, etc. >> >> Right now what we do is build each of these third party libraries *by >> hand*, once for every platform we support (Windows, Linux x86, Android >> NDK). Then we stuff the includes (headers) and libraries >> (static/shared) in a submodule and the primary code base's CMake >> scripts pull them in as interface targets. >> >> This works well and is light-weight but is a pain when upgrading or >> changing libraries. It's a pain because if I want to upgrade boost, I >> have to build it up to 6 times (once for each platform and once for >> each configuration). >> >> I've been thinking of a different approach for a while. I've done some >> toying around with the "Super Build" concept, where I have a separate >> CMake project that does nothing but use the ExternalProject module to >> build libraries in real time along with our project. So the order of >> operations would be as follows (for our automated build server): >> >> 1. Clone our "Third Party" repository >> 2. Use CMake to generate & build the "Super Build" project (this >> builds boost, openssl, freetype, etc for the current platform). >> 3. Clone the main code base's repository >> 4. Use CMake to generate & build, using find_package() to refer to >> interface targets exported by those third party libraries built in >> step 2 >> >> Obviously this will make builds take significantly longer, because >> we're constantly rebuilding the same third party libraries over and >> over again. However, it virtually eliminates the maintenance burden >> for third party libraries because they are built inherently with >> everything else. >> >> Note that I can't refer to pre-built libraries in our build >> environments because we need very specific control over the versions >> of our libraries as well as the toolchains that were used to build >> them. Also we may specifically build our libraries a certain way (such >> as boost). For this reason we do not rely on our external environment >> or external package managers to fulfill third party dependencies, like >> most open source projects do on Linux for example. >> >> Does this "Super Build" approach sound like a better idea? What other >> options are available? The downside with the "Super Build" solution is >> that it will become very difficult to make the transition between >> building third party and building our code base seamless. I can't do >> both in the same generate step because find_package() can't be called >> until the libraries are built & installed. >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 elizabeth.fischer at columbia.edu Sat Aug 13 19:42:35 2016 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Sat, 13 Aug 2016 19:42:35 -0400 Subject: [CMake] Need ideas/opinions on third party library management In-Reply-To: References: Message-ID: I would look into Anaconda, which does work for Windows. Its version management is not as well developed as Spack, but it's more cross-platform. Auto-builders are just coming into their own, it's a brave new world. I expect things to be more complete in a few years. -- Elizabeth On Sat, Aug 13, 2016 at 7:00 PM, Robert Dailey wrote: > I did some brief digging into spack, and it doesn't look like it > supports Windows. All I see are shell scripts and the documentation > uses POSIX. > > If I'm going to use a package manager, it needs to be able to support > Android (ARM), Windows, and Linux. I have specific toolchains that > I'll need the package manager to use for each of these platforms, > assuming it compiles these libraries. It also needs to be capable of > cross-compiling (in the case of ARM toolchain in the Android NDK). > > I mean, we can't really call it "reinventing the wheel" if my > requirements are so specific that no current tooling can support it. > If you have any info on spack related to my requirements please let me > know. It looks promising, but so far doesn't seem like it will work > out. > > On Fri, Aug 12, 2016 at 3:41 PM, Elizabeth A. Fischer > wrote: > > This is what Spack and other meta builders do. See http://github. > > com/llnl/spack > > > > On Aug 12, 2016 3:59 PM, "Robert Dailey" > wrote: > >> > >> Hello, > >> > >> There is an internal C++ product at the company I work for which I > >> have written a series of CMake scripts for. This project actually has > >> dependencies on several open source libraries, such as boost, > >> freetype, openssl, etc. > >> > >> Right now what we do is build each of these third party libraries *by > >> hand*, once for every platform we support (Windows, Linux x86, Android > >> NDK). Then we stuff the includes (headers) and libraries > >> (static/shared) in a submodule and the primary code base's CMake > >> scripts pull them in as interface targets. > >> > >> This works well and is light-weight but is a pain when upgrading or > >> changing libraries. It's a pain because if I want to upgrade boost, I > >> have to build it up to 6 times (once for each platform and once for > >> each configuration). > >> > >> I've been thinking of a different approach for a while. I've done some > >> toying around with the "Super Build" concept, where I have a separate > >> CMake project that does nothing but use the ExternalProject module to > >> build libraries in real time along with our project. So the order of > >> operations would be as follows (for our automated build server): > >> > >> 1. Clone our "Third Party" repository > >> 2. Use CMake to generate & build the "Super Build" project (this > >> builds boost, openssl, freetype, etc for the current platform). > >> 3. Clone the main code base's repository > >> 4. Use CMake to generate & build, using find_package() to refer to > >> interface targets exported by those third party libraries built in > >> step 2 > >> > >> Obviously this will make builds take significantly longer, because > >> we're constantly rebuilding the same third party libraries over and > >> over again. However, it virtually eliminates the maintenance burden > >> for third party libraries because they are built inherently with > >> everything else. > >> > >> Note that I can't refer to pre-built libraries in our build > >> environments because we need very specific control over the versions > >> of our libraries as well as the toolchains that were used to build > >> them. Also we may specifically build our libraries a certain way (such > >> as boost). For this reason we do not rely on our external environment > >> or external package managers to fulfill third party dependencies, like > >> most open source projects do on Linux for example. > >> > >> Does this "Super Build" approach sound like a better idea? What other > >> options are available? The downside with the "Super Build" solution is > >> that it will become very difficult to make the transition between > >> building third party and building our code base seamless. I can't do > >> both in the same generate step because find_package() can't be called > >> until the libraries are built & installed. > >> -- > >> > >> Powered by www.kitware.com > >> > >> Please keep messages on-topic and check the CMake FAQ at: > >> http://www.cmake.org/Wiki/CMake_FAQ > >> > >> Kitware offers various services to support the CMake community. For more > >> information on each offering, please visit: > >> > >> CMake Support: http://cmake.org/cmake/help/support.html > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > >> Visit other Kitware 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 ruslan_baratov at yahoo.com Sat Aug 13 20:02:51 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sun, 14 Aug 2016 03:02:51 +0300 Subject: [CMake] Need ideas/opinions on third party library management In-Reply-To: References: Message-ID: <4b8332ef-2006-c41b-8a71-30af862f73e5@yahoo.com> Hi, Robert According to your GitHub account you've send a trivial patch about a year ago to the Hunter (https://github.com/ruslo/hunter) package manager. So I wonder what is your experience, have you tried it? Have you run into some troubles? Thanks, Ruslo On 12-Aug-16 22:59, Robert Dailey wrote: > Hello, > > There is an internal C++ product at the company I work for which I > have written a series of CMake scripts for. This project actually has > dependencies on several open source libraries, such as boost, > freetype, openssl, etc. > > Right now what we do is build each of these third party libraries *by > hand*, once for every platform we support (Windows, Linux x86, Android > NDK). Then we stuff the includes (headers) and libraries > (static/shared) in a submodule and the primary code base's CMake > scripts pull them in as interface targets. > > This works well and is light-weight but is a pain when upgrading or > changing libraries. It's a pain because if I want to upgrade boost, I > have to build it up to 6 times (once for each platform and once for > each configuration). > > I've been thinking of a different approach for a while. I've done some > toying around with the "Super Build" concept, where I have a separate > CMake project that does nothing but use the ExternalProject module to > build libraries in real time along with our project. So the order of > operations would be as follows (for our automated build server): > > 1. Clone our "Third Party" repository > 2. Use CMake to generate & build the "Super Build" project (this > builds boost, openssl, freetype, etc for the current platform). > 3. Clone the main code base's repository > 4. Use CMake to generate & build, using find_package() to refer to > interface targets exported by those third party libraries built in > step 2 > > Obviously this will make builds take significantly longer, because > we're constantly rebuilding the same third party libraries over and > over again. However, it virtually eliminates the maintenance burden > for third party libraries because they are built inherently with > everything else. > > Note that I can't refer to pre-built libraries in our build > environments because we need very specific control over the versions > of our libraries as well as the toolchains that were used to build > them. Also we may specifically build our libraries a certain way (such > as boost). For this reason we do not rely on our external environment > or external package managers to fulfill third party dependencies, like > most open source projects do on Linux for example. > > Does this "Super Build" approach sound like a better idea? What other > options are available? The downside with the "Super Build" solution is > that it will become very difficult to make the transition between > building third party and building our code base seamless. I can't do > both in the same generate step because find_package() can't be called > until the libraries are built & installed. From rcdailey.lists at gmail.com Sat Aug 13 20:08:26 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sat, 13 Aug 2016 19:08:26 -0500 Subject: [CMake] Need ideas/opinions on third party library management In-Reply-To: <4b8332ef-2006-c41b-8a71-30af862f73e5@yahoo.com> References: <4b8332ef-2006-c41b-8a71-30af862f73e5@yahoo.com> Message-ID: Wow I actually completely forgot about that lol. I think I was looking into it for some other reasons, not related to work. I will have to look into it again. I don't really remember much about it. Thanks for the reminder. On Sat, Aug 13, 2016 at 7:02 PM, Ruslan Baratov wrote: > Hi, Robert > > According to your GitHub account you've send a trivial patch about a year > ago to the Hunter (https://github.com/ruslo/hunter) package manager. So I > wonder what is your experience, have you tried it? Have you run into some > troubles? > > Thanks, Ruslo > > > On 12-Aug-16 22:59, Robert Dailey wrote: >> >> Hello, >> >> There is an internal C++ product at the company I work for which I >> have written a series of CMake scripts for. This project actually has >> dependencies on several open source libraries, such as boost, >> freetype, openssl, etc. >> >> Right now what we do is build each of these third party libraries *by >> hand*, once for every platform we support (Windows, Linux x86, Android >> NDK). Then we stuff the includes (headers) and libraries >> (static/shared) in a submodule and the primary code base's CMake >> scripts pull them in as interface targets. >> >> This works well and is light-weight but is a pain when upgrading or >> changing libraries. It's a pain because if I want to upgrade boost, I >> have to build it up to 6 times (once for each platform and once for >> each configuration). >> >> I've been thinking of a different approach for a while. I've done some >> toying around with the "Super Build" concept, where I have a separate >> CMake project that does nothing but use the ExternalProject module to >> build libraries in real time along with our project. So the order of >> operations would be as follows (for our automated build server): >> >> 1. Clone our "Third Party" repository >> 2. Use CMake to generate & build the "Super Build" project (this >> builds boost, openssl, freetype, etc for the current platform). >> 3. Clone the main code base's repository >> 4. Use CMake to generate & build, using find_package() to refer to >> interface targets exported by those third party libraries built in >> step 2 >> >> Obviously this will make builds take significantly longer, because >> we're constantly rebuilding the same third party libraries over and >> over again. However, it virtually eliminates the maintenance burden >> for third party libraries because they are built inherently with >> everything else. >> >> Note that I can't refer to pre-built libraries in our build >> environments because we need very specific control over the versions >> of our libraries as well as the toolchains that were used to build >> them. Also we may specifically build our libraries a certain way (such >> as boost). For this reason we do not rely on our external environment >> or external package managers to fulfill third party dependencies, like >> most open source projects do on Linux for example. >> >> Does this "Super Build" approach sound like a better idea? What other >> options are available? The downside with the "Super Build" solution is >> that it will become very difficult to make the transition between >> building third party and building our code base seamless. I can't do >> both in the same generate step because find_package() can't be called >> until the libraries are built & installed. > > > From rainer.poisel at gmail.com Sun Aug 14 02:03:31 2016 From: rainer.poisel at gmail.com (Rainer Poisel) Date: Sun, 14 Aug 2016 06:03:31 +0000 Subject: [CMake] Exporting files that are not targets Message-ID: Hello, I am currently working on a project that exports a static library target including its dependencies so that it can be used with the `find_package()' command. With include files this is quite easy by using the $ and the $ generator expressions in combination with the `installl()' command. However, with dependent libraries which are not built by my project things are a bit more complicated because `target_include_directories()' and `target_link_libraries()' search differently for their arguments. Is there a way to add dependent libraries (they are all static) to my package so that they are automatically found and linked to targets which use my library target? Thanks for your thoughts and your help, Rainer From nicholas11braden at gmail.com Sun Aug 14 15:35:43 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Sun, 14 Aug 2016 14:35:43 -0500 Subject: [CMake] Empty libraries? Message-ID: I noticed it is possible to create empty libraries like this: add_library(header-only "header.hpp") set_property(TARGET header-only PROPERTY LINKER_LANGUAGE CXX) On my machine, MinGW spits out an empty 8-byte libheader-only.a, and Visual Studio works too but outputs nothing. Is this even technically supported at all? Is this considered portable? I already know about INTERFACE library targets - however, it seems that with the above approach, the header file(s) will show up in the IDE, but not with an INTERFACE library, correct? If so, I would rather not use INTERFACE in this case as I would like the header files to show up in generated IDE projects. From bob.infiniteventures at gmail.com Sun Aug 14 15:47:17 2016 From: bob.infiniteventures at gmail.com (Bob Hernon) Date: Sun, 14 Aug 2016 12:47:17 -0700 Subject: [CMake] FAQ broken link, "Why does CMake generate recursive Makefiles?" Message-ID: I don't have access to fix this myself, so I hope someone on this list can. Sorry, I'm not ready to commit to a git membership to report bugs, and hope I'm not butting in where I don't belong. *See FAQ topic link*: https://cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_ recursive_Makefiles.3F *Specific Text * - Miller, Peter A., Recursive Make Considered Harmful , AUUGN Journal of AUUG Inc., 19(1), pp. 14-25, 1998 *Result* That link is broken: 404 error @ "miller.emu.id.au/pmiller/books/rmch/" *New Correct Link:* http://aegis.sourceforge.net/auug97.pdf *Addendum:* I hope you can also include the counter claim, also a research project: *Non-recursive Make Considered Harmful * http://research.microsoft.com/en-us/um/people/simonpj/ papers/ghc-shake/ghc-shake.pdf Indeed, the latter refers to the former and was a research project to compare theories, based on a real 25 year old product problem. I found them both to be interesting considerations, and excellent resources for those wanting to truly understand the issues. I have no relationship to any authors or institutions, just wanted to read the first paper and found the latest URL from my favorite search engine. I'm a brand new CMake user, and I'm excited to get going. Still reading docs, going to install and set up today hopefully. I spent 20 years in the collective at Big Behemoth Global Corp building software and thrilled to find something like CMake where I can apply all those best practices I had learned to love and rely on out here in the real world. Looking forward to a long relationship. Cheers! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Sun Aug 14 17:27:52 2016 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sun, 14 Aug 2016 16:27:52 -0500 Subject: [CMake] Need ideas/opinions on third party library management In-Reply-To: References: Message-ID: On Fri, Aug 12, 2016 at 4:58 PM, Roger Leigh wrote: > You can simplify this to two steps: > > 1. Clone the superbuild repository > 2. Build the third-party and first-party packages > > This is the approach we take with the OME super-build > https://github.com/ome/ome-cmake-superbuild/ > > See the packages in > https://github.com/ome/ome-cmake-superbuild/tree/develop/packages > all the ones with an "ome-" prefix are the first-party libraries; > everything else is third-party. They are all external projects. > > We have cmake options to select all packages, first-party packages only or > select individual packages by hand; the recursive dependency resolution will > add/ignore dependencies depending upon the chosen policy (defaulting to > include third-party dependencies). So when you're building on BSD or Linux, > you can say "no third-party dependencies except for gtest", or choose > everything, and on Windows where there is no package manager, you always > build everything. And on Windows you can build just the dependencies and > reuse them later; it has support for using cached builds which we use on the > CI side to cut down build times; we only rebuild the cache when the > superbuild git tree hash changes; see the scripts/jenkins-build script > > In addition to that, we have the means to build the first-party libraries in > different ways > > 1. From source release tarball (last stable release) > 2. From git (specify remote+branch as cmake options) > 3. From a local git checkout (on whatever branch is currently checked out) > > You can see the selection logic here: > https://github.com/ome/ome-cmake-superbuild/blob/develop/packages/ome-files/superbuild.cmake#L4 > > In practice (1) is for end-users to build the whole thing, and (3) is what I > use in practice to develop locally where I have a full set of git repos > checked out locally, and I tell the superbuild to build them, along with all > the third-party deps; (3) is also what we use on the CI system, with jenkins > cloning all the individual repos into the workspace, then doing pretty much > the same thing. (2) is OK for one-off builds, but the need for a full git > clone for every package is too much for routine use > > And you can see how first- and third-party dependencies are handled here: > https://github.com/ome/ome-cmake-superbuild/blob/develop/packages/ome-files/superbuild.cmake#L48 > > I might rearrange that so that the classification is in the dependency > rather than the dependeee later on though. It kind of evolved this way as > we added additional features and needs a little cleanup to make it perfect. > > Everything in the above repository is BSD licensed, so feel free to use it > for inspiration or take what you like. The main point I wanted to make was > that with the superbuild *everything* can be an external project, including > your own code. And from that point you can add in features like being able > to selectively build just the third-party or just your own code, rather than > forcing them to be separate manual steps. I get where you are going with this, but I don't really think our code base would benefit from treating third party and first party libraries the same in CMake. We can't really use our different libraries in isolation anyway, mostly due to a combination of architectural issues and business logic. Also I have to do some custom target stuff to pull everything together for our Android APK build (our product is targeted for Android platform). I have to do a lot of trickery to integrate with ant to make our builds seamless between java & C++. From neil.n.carlson at gmail.com Mon Aug 15 11:56:03 2016 From: neil.n.carlson at gmail.com (Neil Carlson) Date: Mon, 15 Aug 2016 09:56:03 -0600 Subject: [CMake] dependencies between external projects (not DEPENDS) Message-ID: I'm struggling with how to handle dependencies between external projects in a superbuild. The issue is different than simply ensuring that one gets built before another using the DEPENDS keyword -- that's trivial. Suppose I have two external libraries A and B, where B depends on A. It is not always possible to correctly define variables like A_LIBRARIES that feed into the externalproject_add for B that anticipate what will come out of the A configure/build. There are sometimes additional link libraries that only come to light after A is actually configured. How do people handle these situations? I'm thinking of a multi-pass approach where one runs cmake/make twice. The first installs A skipping the dependent B. The second builds B (skipping a found A) using correctly set variables from a FindA module. Incidentally, is it kosher to have a Find module invoke a find_package? There are examples in of this in standard Find modules. This creates problems in the superbuild context, where say A is found, but rejected by the superbuild because of missing features, for example, but FindB finds A and uses it. Thanks for your advice. -Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From gilles.khouzam at microsoft.com Mon Aug 15 16:20:07 2016 From: gilles.khouzam at microsoft.com (Gilles Khouzam) Date: Mon, 15 Aug 2016 20:20:07 +0000 Subject: [CMake] [Visual Studio] Universal Windows Platform projects In-Reply-To: <20160802082150.80DCDF4EF3@public.kitware.com> References: <20160802082150.80DCDF4EF3@public.kitware.com> Message-ID: Hi Adam, Nagy-Egri I?ve written most of the code to support Windows Universal Apps and would be happy to help you get this working. We have some very prominent customers who are using this functionality to publish their apps and games to the Windows Store. The support is not a pilot project and we try to address the issues that people are facing when something is not fully supported. The first example to look at would be in Tests\VSWinStorePhone, this is the validation project that builds a Windows project that can be targeted to the Windows Store. It has examples of content files, shaders, manifest, resources, tool overrides. If you have questions, I?m here to help. Thanks Gilles Khouzam Engineering Lead Microsoft Windows gilles.khouzam at microsoft.com From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Nagy-Egri M?t? Ferenc via CMake Sent: Tuesday, August 2, 2016 01:17 To: cmake at cmake.org Subject: Re: [CMake] [Visual Studio] Universal Windows Platform projects I would also very much like to see a tutorial on this. There are just too darn many options to set for me to believe CMake could ever get the job done. Release notes for Publishing to the store, age rating for my app, can it correctly set source types to be DX resources, DX shaders, etc? there are too many things I have not even heard about relating to CMake. I have a feeling that the WindowsStore CMAKE_SYSTEM_NAME started out as a pilot project but then did not wish to keep up with the evolution of the Microsoft ecosystem. It?s a shame really, because I really did want to prove to collegues of mine, that the MVVM model employed by the canonical design pattern of Windows Store apps has a 1-to-1 mapping in the Qt ecosystem. XAML >> QML events-delegates >> signal-slot The best choice of a build generator would be CMake. However, not having met all the neccessary components, VS project files with the Qt Add-In currently seem to be a better choice. The foundations are very-very similar and I wanted to build a simple application that relies on Qt for the Linux build and pure WinRT for the Windows build. Also, I would also be very much interested in additions to CMake where CTest could take care of Pester tests for PowerShell scripts and as such is able to test PS scripts I wrote which load C++/CX Assemblies. (For those who do not know of C++/CX, it is managed C++, a language extension that can act as a mediator between native C++ and all the .NET family of languages. One may wrap FFTW with managed C++ and load the compiled library (referred to as Assemblies) from C#, F# or PowerShell even and consume it. The ABI of the .NET languages are stable and interoperable.) If someone has a working prototype of CMake compiling a simple UWP Store app that could actually be published? do not hesitate to share! Felad?: Adam Rankin Elk?ldve: 2016. j?lius 6., szerda 16:42 C?mzett: cmake at cmake.org T?rgy: [CMake] [Visual Studio] Universal Windows Platform projects Hello all, I?ve been trying to identify the correct variables to set to create a UWP project using VS2015, and the projects generated are missing a few critical tags. I?m using CMAKE_SYSTEM_NAME=WindowsStore and CMAKE_SYSTEM_VERSION=10.0. This correctly identifies and sets the target platform tag, but does not set the following ?Globals? Properties in the PropertyGroup of the .vcxproj file true Windows Store 10.0.10240.0 10.0 Has anyone successfully created a UWP project using CMake? Regards, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From gilles.khouzam at microsoft.com Mon Aug 15 16:24:02 2016 From: gilles.khouzam at microsoft.com (Gilles Khouzam) Date: Mon, 15 Aug 2016 20:24:02 +0000 Subject: [CMake] Bash on ubuntu on windows as target In-Reply-To: References: <20160811062317.C32BAF5211@public.kitware.com> Message-ID: That?s an interesting idea, I?m not sure why cmd is failing to invoke bash properly, but I will try and figure it out. Also, for addressing invoking bash.exe without copying it to SysWow64, you can reference it by C:\Windows\Sysnative\bash.exe from a 32-bit process. It still doesn?t make the target succeed, but at least it removes the need to copy the file around. Thanks ~Gilles From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Tiago Macarios Sent: Thursday, August 11, 2016 10:12 To: csiga.biga at aol.com Cc: CMake ML Subject: Re: [CMake] Bash on ubuntu on windows as target Well what I was trying to do was to actually have a target inside the windows build that would trigger the linux build so to build both at the same time. imagine you have a VS project one of the "projects" would be the linux build. So as long as the build folder is different I could have both building in sync everytime. Get the idea? If I just do a full build inside bash everything works great =) On Wed, Aug 10, 2016 at 11:23 PM, <"M?t? Ferenc Nagy-Egri via CMake > wrote: +1 for the initiative. Wouldn?t it make more sense however to make it a CMAKE_SYSTEM_NAME? If I remember correctly that?s how MinGW works, and this should be something very similar. Felad?: Tiago Macarios Elk?ldve: 2016. augusztus 11., cs?t?rt?k 1:51 C?mzett: CMake ML T?rgy: [CMake] Bash on ubuntu on windows as target Hi All, Windows 10 anniversary edition comes with support to execute Linux binaries. I have been trying to use it with one of our projects, but I have been getting a weird error. Maybe someone can help me? The target is pretty simple: set(BASH "C:\\Windows\\System32\\bash.exe") set(ARGS "--help") add_custom_target(linux ${BASH} ${ARGS}) If I then build that project in visual studio (with some extra verbosity) I get: Target "CustomBuild" in file "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets" from project "C:\_Working\delegate\build\linux.vcxproj" (target "_BuildGenerateSourcesAction" depends on it): Using "CustomBuild" task from assembly "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Build.CppTasks.Common.dll". Task "CustomBuild" Write Tracking Logs: x64\Debug\linux\linux.tlog\custombuild.write.1.tlog Read Tracking Logs: x64\Debug\linux\linux.tlog\custombuild.read.1.tlog No output for C:\_WORKING\DELEGATE\BUILD\CMAKEFILES\3FA5525E877A7559336C7D412E1B43B0\LINUX.RULE|C:\_WORKING\DELEGATE\CMAKELISTS.TXT was found in the tracking log; source compilation required. C:\_Working\delegate\CMakeLists.txt will be compiled as it was not found in the tracking log. C:\_Working\delegate\build\CMakeFiles\3fa5525e877a7559336c7d412e1b43b0\linux.rule will be compiled as it was not found in the tracking log. setlocal "C:\Program Files (x86)\CMake\bin\cmake.exe" -HC:/_Working/delegate -BC:/_Working/delegate/build --check-stamp-file C:\_Working\delegate\build\CMakeFiles\generate.stamp if %errorlevel% neq 0 goto :cmEnd :cmEnd endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone :cmErrorLevel exit /b %1 :cmDone if %errorlevel% neq 0 goto :VCEnd setlocal C:\Windows\System32\bash.exe --help if %errorlevel% neq 0 goto :cmEnd :cmEnd endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone :cmErrorLevel exit /b %1 :cmDone if %errorlevel% neq 0 goto :VCEnd Building Custom Rule C:/_Working/delegate/CMakeLists.txt CMake does not need to re-run because C:\_Working\delegate\build\CMakeFiles\generate.stamp is up-to-date. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code -1073740791. Done executing task "CustomBuild" -- FAILED. Done building target "CustomBuild" in project "linux.vcxproj" -- FAILED. The command line seems correct. If I just copy it to the windows prompt it works fine: C:\Users\tmc> C:\Windows\System32\bash.exe --help GNU bash, version 4.3.11(1)-release-(x86_64-pc-linux-gnu) Usage: /bin/bash [GNU long option] [option] ... /bin/bash [GNU long option] [option] script-file ... GNU long options: --debug --debugger --dump-po-strings --dump-strings --help --init-file --login --noediting --noprofile --norc --posix --rcfile --restricted --verbose --version Shell options: -ilrsD or -c command or -O shopt_option (invocation only) -abefhkmnptuvxBCHP or -o option Type `/bin/bash -c "help set"' for more information about shell options. Type `/bin/bash -c help' for more information about shell builtin commands. Use the `bashbug' command to report bugs. I also tried to use it from the visual studio "external tools" and it seems to work. So I am not sure what is going on. Is there a way to debug custom_targets? In case anyone tries the example above on a 64 bit machine: You will need to copy bash.exe from system32 to syswow64 since VS is 32 bits. 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 h.sorby at auckland.ac.nz Mon Aug 15 16:54:34 2016 From: h.sorby at auckland.ac.nz (Hugh Sorby) Date: Mon, 15 Aug 2016 20:54:34 +0000 Subject: [CMake] configure_file not regenerating target file Message-ID: <0429A00EF13DA448A112A150713B0D6FE67CD842@uxcn10-2.UoA.auckland.ac.nz> When I am using GenerateExportHeader from a sub-directory the export header file is not re-generated when the file is deleted. I have discovered that the configure_file command does not regenerate the target file if the target file is deleted and the command is specified from a sub-directory. Attached are three cases exhibiting what I have found. In all cases the following commands exhibit the current behaviour. #unzip the files and from inside the unzipped content cd build cmake .. make make clean make When building test 1 all commands execute successfully, this test does not use configure_file in a sub-directory. When building tests 2 and 3 the second 'make' command fails due to a missing header file, both of these tests use configure_file in a sub-directory. I have tested this on GNU/Linux and OS X using CMake version 3.5.X and 3.5.2 respectively. So my question is: Is this the expected behaviour? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_test_1.zip Type: application/zip Size: 1049 bytes Desc: cmake_test_1.zip URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_test_2.zip Type: application/zip Size: 1478 bytes Desc: cmake_test_2.zip URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_test_3.zip Type: application/zip Size: 1699 bytes Desc: cmake_test_3.zip URL: From intelfx at intelfx.name Mon Aug 15 21:32:33 2016 From: intelfx at intelfx.name (Ivan Shapovalov) Date: Tue, 16 Aug 2016 04:32:33 +0300 Subject: [CMake] Private dependencies of static libraries exported as targets Message-ID: <1471311153.20784.29.camel@intelfx.name> Hello, So I'm trying to learn how to do CMake in a modern way. If I understand correctly, the "modern way" is to use IMPORTED targets. Preamble -------- I have a project which builds a library `foo`. This library can be built as static or shared, depending on value of BUILD_SHARED_LIBS. My CMakeLists.txt does not perform any special handling of either case. It links to a library `bar`, which is an implementation detail, i. e. clients of `foo` do not need to know that I use `bar`. Hence I make it a PRIVATE dependency (let's assume that authors of Bar also try to do modern CMake and package their library using IMPORTED targets): # somewhere in BarConfig.cmake add_library(bar STATIC IMPORTED ...) set_target_properties(bar PROPERTIES ? INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include ? IMPORTED_LOCATION ${_IMPORT_PREFIX}/lib/libfoo.a) # somewhere in my CMakeLists.txt find_package(Bar) add_library(foo ... EXPORT FooTargets) target_include_directories(foo ...) target_link_libraries(foo PRIVATE bar) install(TARGETS foo DESTINATION lib) install(EXPORT FooTargets DESTINATION lib/cmake/Foo) # this file does find_package(Bar) and includes FooTargets.cmake configure_file(FooConfig.cmake.in FooConfig.cmake @ONLY) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake DESTINATION lib/cmake/Foo) Problem ------- If library `foo` is built as shared, then everything is fine because: - if library `bar` is built as static, then its code is simply added ? to library `foo` at link time => everything OK - if library `bar` is built as shared, then the runtime linker will ? recursively load it when library `foo` is loaded => everything OK But, if library `foo` is built as static, then its clients suddenly become required to link to `bar` as well, and this information is not recorded anywhere! Possible Solution #1 -------------------- I could wrap `target_link_libraries()` into a function which says PRIVATE or PUBLIC dependent on whether we are building a SHARED or STATIC library respectively: function(foo_target_link_private_library target library) ? if(BUILD_SHARED_LIBS) ? ? target_link_libraries(${target} PRIVATE ${library}) ? else ? ? target_link_libraries(${target} PUBLIC ${library}) endfunction() But this feels like a hack and adds include path bloat: the clients of `foo` will never need `bar`'s include pathes, even if `bar` is static. I could imagine creating fake targets like `bar_for_static` and copying there `bar`'s IMPORTED_LOCATION and INTERFACE_LINK_FLAGS but not INTERFACE_INCLUDE_DIRECTORIES (and then link to `bar_for_static` in `foo`'s interface), but this is even more gross. Is there anything less hackish or more idiomatic? Thanks, -- Ivan Shapovalov / intelfx / -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From dumont.guillaume at gmail.com Mon Aug 15 21:46:16 2016 From: dumont.guillaume at gmail.com (Guillaume Dumont) Date: Mon, 15 Aug 2016 21:46:16 -0400 Subject: [CMake] Private dependencies of static libraries exported as targets In-Reply-To: <1471311153.20784.29.camel@intelfx.name> References: <1471311153.20784.29.camel@intelfx.name> Message-ID: If you export you targets using install(EXPORT ...) then the foo static library should contain a dependency to bar in its INTERFACE_LINK libraries. If bar is an imported target your config file should use find_dependency so that the bar imported target is resolved by consuming CMake based packages. If bar is just the path to the binary than the absolute path will be recorded in your export files and your foo package will become non relocatable. As far as I know the PRIVATE keyword should have no effect on transitive linking when foo is static and we call: target_link_libraries(foo PRIVATE bar) Hope this helps. On Mon, Aug 15, 2016 at 9:32 PM, Ivan Shapovalov wrote: > ks to a library `bar`, which is an implementation detail, i. e. > clients of `foo` do not need to know that I use `bar`. Hence I make it > a PRIVATE dependency (let's assume that authors of Bar also try to do > modern CMake and pac > -- Guillaume Dumont ========================= dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From intelfx at intelfx.name Mon Aug 15 22:22:25 2016 From: intelfx at intelfx.name (Ivan Shapovalov) Date: Tue, 16 Aug 2016 05:22:25 +0300 Subject: [CMake] Private dependencies of static libraries exported as targets In-Reply-To: References: <1471311153.20784.29.camel@intelfx.name> Message-ID: <1471314145.20784.33.camel@intelfx.name> On 2016-08-15 at 21:46 -0400, Guillaume Dumont wrote: > As far as I know the PRIVATE > keyword > should have no effect on transitive linking when foo is static and we > call: > > target_link_libraries(foo PRIVATE bar) > > Hope this helps. Wow. I did not know that. Should've tested on sample project. It does not solve include path bloat though, but that's a minor issue. One question remains... is this behavior documented somewhere? Anyway, huge thanks, -- Ivan Shapovalov / intelfx / -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From cosmind_1993 at yahoo.com Mon Aug 15 23:17:31 2016 From: cosmind_1993 at yahoo.com (Cosmin Dorcu) Date: Tue, 16 Aug 2016 03:17:31 +0000 (UTC) Subject: [CMake] Visual Studio - Change 'Character Set' property References: <189877885.36480.1471317451435.ref@mail.yahoo.com> Message-ID: <189877885.36480.1471317451435@mail.yahoo.com> Hello, I am using CMake to build VTK for windows (specifically with Visual Studio 2015). My goal is to integrate VTK into an existing MFC C++ app, so I am interested in building and using the MFC module. That module is created by default with the CS (Character Set) flag set to "MBCS", and my project uses "Unicode". This generates an assertion on run, which may indicate there is a bug later down the line. If I build the main app with MBCS, that assertion is gone. My question is: Is it possible to add a new entry in CMake which will change the CS property of the project? If yes, how? Thanks and regards, Cosmin D.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexander.Biddulph at uon.edu.au Mon Aug 15 23:32:44 2016 From: Alexander.Biddulph at uon.edu.au (Alexander Biddulph) Date: Tue, 16 Aug 2016 03:32:44 +0000 Subject: [CMake] add_compile_options query In-Reply-To: References: , , Message-ID: I have tried specifying the parameters with both single and double quotes, both options raise errors on the command line. With no quotes: FAILED: /usr/bin/gcc -march=broadwell -mtune=broadwell -m64 -mabm -madx -maes -mavx -mavx2 -mbmi -mbmi2 -mcx16 -mf16c -mfma -mfsgsbase -mfxsr -mlzcnt -mmmx -mmovbe -mpclmul -mpopcnt -mprfchw -mrdrnd -mrdseed -msahf -msse -msse2 -msse3 -msse4 -msse4.1 -msse4.2 -mssse3 -mxsave -mxsaveopt --param l1-cache-size=24 l1-cache-line-size=64 l2-cache-size=512 -o CMakeFiles/cmTC_59f68.dir/testCCompiler.c.o -c testCCompiler.c gcc: error: l1-cache-line-size=64: No such file or directory gcc: error: l2-cache-size=512: No such file or directory With single quotes: FAILED: /usr/bin/gcc -march=broadwell -mtune=broadwell -m64 -mabm -madx -maes -mavx -mavx2 -mbmi -mbmi2 -mcx16 -mf16c -mfma -mfsgsbase -mfxsr -mlzcnt -mmmx -mmovbe -mpclmul -mpopcnt -mprfchw -mrdrnd -mrdseed -msahf -msse -msse2 -msse3 -msse4 -msse4.1 -msse4.2 -mssse3 -mxsave -mxsaveopt "'--param" "l1-cache-size=24'" "l1-cache-line-size=64'" "l2-cache-size=512'" -o CMakeFiles/cmTC_dad73.dir/testCCompiler.c.o -c testCCompiler.c gcc: error: '--param: No such file or directory gcc: error: l1-cache-size=24': No such file or directory gcc: error: l1-cache-line-size=64': No such file or directory gcc: error: l2-cache-size=512': No such file or directory With double quotes: FAILED: /usr/bin/gcc -march=broadwell -mtune=broadwell -m64 -mabm -madx -maes -mavx -mavx2 -mbmi -mbmi2 -mcx16 -mf16c -mfma -mfsgsbase -mfxsr -mlzcnt -mmmx -mmovbe -mpclmul -mpopcnt -mprfchw -mrdrnd -mrdseed -msahf -msse -msse2 -msse3 -msse4 -msse4.1 -msse4.2 -mssse3 -mxsave -mxsaveopt "--param l1-cache-size=24" "--param l1-cache-line-size=64" "--param l2-cache-size=512" -o CMakeFiles/cmTC_09224.dir/testCCompiler.c.o -c testCCompiler.c gcc: error: unrecognized command line option ?--param l1-cache-size=24? gcc: error: unrecognized command line option ?--param l1-cache-line-size=64? gcc: error: unrecognized command line option ?--param l2-cache-size=512? If I only specify one of the flags (with no single/double quotes) gcc accepts the flag. Thanks, Alex ________________________________ From: CHEVRIER, Marc Sent: Friday, 12 August 2016 9:51:49 PM To: Alexander Biddulph; cmake at cmake.org Subject: Re: [CMake] add_compile_options query Specify flags as strings rather than lists (i.e. add quotes): add_compile_options("--param l1-cache-size=24") add_compile_options("--param l1-cache-line-size=64") add_compile_options("--param l2-cache-size=512") On 12/08/16 11:08, "CMake on behalf of Alex Biddulph" wrote: Hi, I am trying to add some GCC compiler optimisation flags using the add_compile_options directive but am running into some issues due to the nature of the flags. There are 3 flags that I am trying to set: --param l1-cache-size=24 --param l1-cache-line-size=64 --param l2-cache-size=512 If I try to add these as: add_compile_options(--param l1-cache-size=24) add_compile_options(--param l1-cache-line-size=64) add_compile_options(--param l2-cache-size=512) Then the resulting portion of the command line is: --param l1-cache-size=24 l1-cache-line-size=64 l2-cache-size=512 That is, only one of the '--param's is maintained, but all 3 need to be maintained in order for GCC to understand the flags. Is it possible to use add_compile_options to set these flags? Or is there another more effective method? I would like to avoid adding them to CFLAGS and CXXFLAGS if at all possible. Thanks in advance, Alex -- Powered by www.kitware.com [http://www.kitware.com/img/Areas_Index_Home.jpg] Kitware Inc. - leading edge, high-quality software www.kitware.com Kitware's mission is to create state-of-the-art software products and services in visualization and data processing using advanced quality software methods and ... Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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 nicholas11braden at gmail.com Tue Aug 16 03:35:22 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Tue, 16 Aug 2016 02:35:22 -0500 Subject: [CMake] Private dependencies of static libraries exported as targets In-Reply-To: <1471314145.20784.33.camel@intelfx.name> References: <1471311153.20784.29.camel@intelfx.name> <1471314145.20784.33.camel@intelfx.name> Message-ID: Yes, the behavior is documented in several places, the most prominent being here: https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#transitive-usage-requirements On Mon, Aug 15, 2016 at 9:22 PM, Ivan Shapovalov wrote: > On 2016-08-15 at 21:46 -0400, Guillaume Dumont wrote: >> As far as I know the PRIVATE >> keyword >> should have no effect on transitive linking when foo is static and we >> call: >> >> target_link_libraries(foo PRIVATE bar) >> >> Hope this helps. > > Wow. I did not know that. Should've tested on sample project. > It does not solve include path bloat though, but that's a minor issue. > > One question remains... is this behavior documented somewhere? > > Anyway, huge thanks, > -- > Ivan Shapovalov / intelfx / > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 bballet at ivsweb.com Tue Aug 16 08:41:29 2016 From: bballet at ivsweb.com (Benjamin Ballet) Date: Tue, 16 Aug 2016 14:41:29 +0200 Subject: [CMake] [cmake-developers] Need ideas/opinions on third party library management In-Reply-To: <1D3F7CC1-58CE-4B01-A2E2-9AFBB746B384@gmail.com> References: <1D3F7CC1-58CE-4B01-A2E2-9AFBB746B384@gmail.com> Message-ID: Very interesting discussion, we have the same issues here. Florent Castelli, how many third parties libraries do you use ? I think a super build can be a very good solution but I'm wondering how much third party code you have to build. Here we use OpenCV, with, boost, and poco, and other things... So it may be too long. I was personnaly considering having an hybrid solution : include small libraries (like jsoncpp) and pre-build the other for each platforms. 2016-08-16 12:52 GMT+02:00 Florent Castelli : > At Spotify, we use CMake a lot for our large C++ library shared by all the > clients. > After trying to build libraries for each platform and variant, we > basically gave up and we now > use a super-build approach. > > For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android > and iOS. > Each platform has a different CPU target (or many 32/64bit, x86/ARM). > Each platform has many compilers. > Some platforms have instrumentation options (Debug / Release, ASan, MSan?) > and really need > to be compiled properly, otherwise you?ll end up with false positives. > The matrix of builds is REALLY hard to track. Each time we update Boost, > we had to update > a lot of things. > I tried using ExternalProject and use b2 (build tool from Boost) to build > it and instead of having > lots of build jobs with a mirror of the flags, you end up mirroring the > flags in your CMake files > instead, which is still not good enough. > > In the end, I looked at how Boost is actually built. And for most > libraries, it?s plain simple. > A static library with a few files, some define, sometimes a platform > specific source file. > What if instead of having an external build tool, I built it from CMake > instead? > It would propagate all the build flags, target, instrumentation and > compiler information from the main > build to it and just work. > I tried it and it worked in no time! We replaced our Boost 1.59 binary > distribution with the source > distribution and it?s much easier. When people build our library for a > different target, they don?t have > to download new binaries, they just reuse the same sources. > Later on, we found a bug in Boost 1.59 (fixed in later versions) and > patched it. We updated our source > bundle and everything was smooth. > Much later on, we wanted to use 1.61. We just updated the source bundle > again, the list of source > files or compilation flags for the libraries we use didn?t change. It was > again effortless. > > Overall, building boost takes 10s on our developers? machines. The sources > aren?t changed often, > so the cost is pretty low. It needs attention when we upgrade it, but > that?s quite rare. > > We try now to use the same approach for other libraries when we add them. > Some of them are > already using CMake and it?s somewhat easier, but since most people still > target version 2.8 (or 2.6...), > we find it better to rewrite the build scripts ourselves and use modern > features (as in, everything is > a target that propagates requirements, we don?t propagate variables). > It makes it also much easier to build a library for another platform that > wasn?t targeted by the original > project. > > If people are interested, I could share the CMakeLists.txt file we use for > Boost. It doesn?t build all > the libraries (some are hard like Context) and uses some internal macros, > but it should be plain > simple to tweak for your use. > > /Florent > > > On 12 Aug 2016, at 21:59, Robert Dailey > wrote: > > > > Hello, > > > > There is an internal C++ product at the company I work for which I > > have written a series of CMake scripts for. This project actually has > > dependencies on several open source libraries, such as boost, > > freetype, openssl, etc. > > > > Right now what we do is build each of these third party libraries *by > > hand*, once for every platform we support (Windows, Linux x86, Android > > NDK). Then we stuff the includes (headers) and libraries > > (static/shared) in a submodule and the primary code base's CMake > > scripts pull them in as interface targets. > > > > This works well and is light-weight but is a pain when upgrading or > > changing libraries. It's a pain because if I want to upgrade boost, I > > have to build it up to 6 times (once for each platform and once for > > each configuration). > > > > I've been thinking of a different approach for a while. I've done some > > toying around with the "Super Build" concept, where I have a separate > > CMake project that does nothing but use the ExternalProject module to > > build libraries in real time along with our project. So the order of > > operations would be as follows (for our automated build server): > > > > 1. Clone our "Third Party" repository > > 2. Use CMake to generate & build the "Super Build" project (this > > builds boost, openssl, freetype, etc for the current platform). > > 3. Clone the main code base's repository > > 4. Use CMake to generate & build, using find_package() to refer to > > interface targets exported by those third party libraries built in > > step 2 > > > > Obviously this will make builds take significantly longer, because > > we're constantly rebuilding the same third party libraries over and > > over again. However, it virtually eliminates the maintenance burden > > for third party libraries because they are built inherently with > > everything else. > > > > Note that I can't refer to pre-built libraries in our build > > environments because we need very specific control over the versions > > of our libraries as well as the toolchains that were used to build > > them. Also we may specifically build our libraries a certain way (such > > as boost). For this reason we do not rely on our external environment > > or external package managers to fulfill third party dependencies, like > > most open source projects do on Linux for example. > > > > Does this "Super Build" approach sound like a better idea? What other > > options are available? The downside with the "Super Build" solution is > > that it will become very difficult to make the transition between > > building third party and building our code base seamless. I can't do > > both in the same generate step because find_package() can't be called > > until the libraries are built & installed. > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware 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 > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 > -- *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 elizabeth.fischer at columbia.edu Tue Aug 16 08:52:16 2016 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Tue, 16 Aug 2016 08:52:16 -0400 Subject: [CMake] [cmake-developers] Need ideas/opinions on third party library management In-Reply-To: <1D3F7CC1-58CE-4B01-A2E2-9AFBB746B384@gmail.com> References: <1D3F7CC1-58CE-4B01-A2E2-9AFBB746B384@gmail.com> Message-ID: CMake builds for existing libraries are certainly an interesting and useful thing, and deserve to be posted in a GitHub repo somewhere. They should also serve as the basis of a campaign to get the library authors to incorporate the CMake build directly in their repos. But any approach that requires every build to be ported to CMake will be difficult and labor-prone to scale. Writing a meta-build recipe is usually much easier. Spack handles the combinatorial dependencies you mention in a sophisticated, graceful way that most meta-builders do not. Its only problem is it does not (yet) run on Windows. There's no fundamental reason why not; we just need someone to get involved and start trying it on Windows. -- Elizabeth On Tue, Aug 16, 2016 at 6:52 AM, Florent Castelli < florent.castelli at gmail.com> wrote: > At Spotify, we use CMake a lot for our large C++ library shared by all the > clients. > After trying to build libraries for each platform and variant, we > basically gave up and we now > use a super-build approach. > > For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android > and iOS. > Each platform has a different CPU target (or many 32/64bit, x86/ARM). > Each platform has many compilers. > Some platforms have instrumentation options (Debug / Release, ASan, MSan?) > and really need > to be compiled properly, otherwise you?ll end up with false positives. > The matrix of builds is REALLY hard to track. Each time we update Boost, > we had to update > a lot of things. > I tried using ExternalProject and use b2 (build tool from Boost) to build > it and instead of having > lots of build jobs with a mirror of the flags, you end up mirroring the > flags in your CMake files > instead, which is still not good enough. > > In the end, I looked at how Boost is actually built. And for most > libraries, it?s plain simple. > A static library with a few files, some define, sometimes a platform > specific source file. > What if instead of having an external build tool, I built it from CMake > instead? > It would propagate all the build flags, target, instrumentation and > compiler information from the main > build to it and just work. > I tried it and it worked in no time! We replaced our Boost 1.59 binary > distribution with the source > distribution and it?s much easier. When people build our library for a > different target, they don?t have > to download new binaries, they just reuse the same sources. > Later on, we found a bug in Boost 1.59 (fixed in later versions) and > patched it. We updated our source > bundle and everything was smooth. > Much later on, we wanted to use 1.61. We just updated the source bundle > again, the list of source > files or compilation flags for the libraries we use didn?t change. It was > again effortless. > > Overall, building boost takes 10s on our developers? machines. The sources > aren?t changed often, > so the cost is pretty low. It needs attention when we upgrade it, but > that?s quite rare. > > We try now to use the same approach for other libraries when we add them. > Some of them are > already using CMake and it?s somewhat easier, but since most people still > target version 2.8 (or 2.6...), > we find it better to rewrite the build scripts ourselves and use modern > features (as in, everything is > a target that propagates requirements, we don?t propagate variables). > It makes it also much easier to build a library for another platform that > wasn?t targeted by the original > project. > > If people are interested, I could share the CMakeLists.txt file we use for > Boost. It doesn?t build all > the libraries (some are hard like Context) and uses some internal macros, > but it should be plain > simple to tweak for your use. > > /Florent > > > On 12 Aug 2016, at 21:59, Robert Dailey > wrote: > > > > Hello, > > > > There is an internal C++ product at the company I work for which I > > have written a series of CMake scripts for. This project actually has > > dependencies on several open source libraries, such as boost, > > freetype, openssl, etc. > > > > Right now what we do is build each of these third party libraries *by > > hand*, once for every platform we support (Windows, Linux x86, Android > > NDK). Then we stuff the includes (headers) and libraries > > (static/shared) in a submodule and the primary code base's CMake > > scripts pull them in as interface targets. > > > > This works well and is light-weight but is a pain when upgrading or > > changing libraries. It's a pain because if I want to upgrade boost, I > > have to build it up to 6 times (once for each platform and once for > > each configuration). > > > > I've been thinking of a different approach for a while. I've done some > > toying around with the "Super Build" concept, where I have a separate > > CMake project that does nothing but use the ExternalProject module to > > build libraries in real time along with our project. So the order of > > operations would be as follows (for our automated build server): > > > > 1. Clone our "Third Party" repository > > 2. Use CMake to generate & build the "Super Build" project (this > > builds boost, openssl, freetype, etc for the current platform). > > 3. Clone the main code base's repository > > 4. Use CMake to generate & build, using find_package() to refer to > > interface targets exported by those third party libraries built in > > step 2 > > > > Obviously this will make builds take significantly longer, because > > we're constantly rebuilding the same third party libraries over and > > over again. However, it virtually eliminates the maintenance burden > > for third party libraries because they are built inherently with > > everything else. > > > > Note that I can't refer to pre-built libraries in our build > > environments because we need very specific control over the versions > > of our libraries as well as the toolchains that were used to build > > them. Also we may specifically build our libraries a certain way (such > > as boost). For this reason we do not rely on our external environment > > or external package managers to fulfill third party dependencies, like > > most open source projects do on Linux for example. > > > > Does this "Super Build" approach sound like a better idea? What other > > options are available? The downside with the "Super Build" solution is > > that it will become very difficult to make the transition between > > building third party and building our code base seamless. I can't do > > both in the same generate step because find_package() can't be called > > until the libraries are built & installed. > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware 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 > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 ruslan_baratov at yahoo.com Tue Aug 16 09:29:12 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Tue, 16 Aug 2016 16:29:12 +0300 Subject: [CMake] [cmake-developers] Need ideas/opinions on third party library management In-Reply-To: <1D3F7CC1-58CE-4B01-A2E2-9AFBB746B384@gmail.com> References: <1D3F7CC1-58CE-4B01-A2E2-9AFBB746B384@gmail.com> Message-ID: <8a4f01d8-ace7-6067-fe66-0ca4bb8b4f2a@yahoo.com> On 16-Aug-16 13:52, Florent Castelli wrote: > For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android and iOS. > Each platform has a different CPU target (or many 32/64bit, x86/ARM). > Each platform has many compilers. > Some platforms have instrumentation options (Debug / Release, ASan, MSan?) and really need > to be compiled properly, otherwise you?ll end up with false positives. > The matrix of builds is REALLY hard to track. Each time we update Boost, we had to update > a lot of things. Not a problem for Hunter. Linux, OSX, Windows, iOS 9.3, iOS 8.2, Android, GCC, Clang, ASan, LeakSan, ThreadSan, Static Analyzer, libstdc++, libc++, MinGW, Visual Studio 2008-2015: * https://travis-ci.org/ingenue/hunter/builds/140317830 * https://ci.appveyor.com/project/ingenue/hunter/build/1.0.665 This list is not even full, I guess I can add more toolchains in future (GCC variations and C++ standards). To test all matrix I need to push one commit to pkg.boost branch, to upload binaries to server I need to push one commit to upload.boost branch (upload ALL toolchains at one shot). To reuse all updates users just need to set new URL/SHA1 of HunterGate module: https://github.com/ruslo/hunter/releases > Overall, building boost takes 10s on our developers? machines. The sources aren?t changed often, > so the cost is pretty low. What kind of hardware do they have? And what libraries you mean? It takes about 20 seconds on my Linux machine just to unpack 80 MB of Boost release archive. It's even worse on Windows, it takes several minutes for some strange reason even on SSD + Core i7. Using binaries in such cases is a huge time saver because there is no need to compile anything and there is no a lot of junk that they put into release archive (if you remove docs and tests 80 MB became 15 MB). Of course building from source is not an option for such monsters like Qt or OpenCV. Ready-to-use binaries is something critical for real life applications. There is no way to test everything on Travis/AppVeyor without this feature. Ruslo From ruslan_baratov at yahoo.com Tue Aug 16 10:51:12 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Tue, 16 Aug 2016 17:51:12 +0300 Subject: [CMake] [cmake-developers] Need ideas/opinions on third party library management In-Reply-To: <3BE89DE2-20DF-43A2-B202-5580467BF50E@gmail.com> References: <1D3F7CC1-58CE-4B01-A2E2-9AFBB746B384@gmail.com> <8a4f01d8-ace7-6067-fe66-0ca4bb8b4f2a@yahoo.com> <3BE89DE2-20DF-43A2-B202-5580467BF50E@gmail.com> Message-ID: <39f807ac-9380-de31-3d2d-5e9b06e1c647@yahoo.com> On 16-Aug-16 17:04, Florent Castelli wrote: > >> On 16 Aug 2016, at 15:29, Ruslan Baratov > > wrote: >> >> On 16-Aug-16 13:52, Florent Castelli wrote: >>> For example, Boost is used by 5 platforms: Windows, OSX, Linux, >>> Android and iOS. >>> Each platform has a different CPU target (or many 32/64bit, x86/ARM). >>> Each platform has many compilers. >>> Some platforms have instrumentation options (Debug / Release, ASan, >>> MSan?) and really need >>> to be compiled properly, otherwise you?ll end up with false positives. >>> The matrix of builds is REALLY hard to track. Each time we update >>> Boost, we had to update >>> a lot of things. >> Not a problem for Hunter. >> >> Linux, OSX, Windows, iOS 9.3, iOS 8.2, Android, GCC, Clang, ASan, >> LeakSan, ThreadSan, Static Analyzer, libstdc++, libc++, MinGW, >> Visual Studio 2008-2015: >> * https://travis-ci.org/ingenue/hunter/builds/140317830 >> * https://ci.appveyor.com/project/ingenue/hunter/build/1.0.665 >> >> This list is not even full, I guess I can add more toolchains in >> future (GCC variations and C++ standards). >> >> To test all matrix I need to push one commit to pkg.boost branch, to >> upload binaries to server I need to push one commit to upload.boost >> branch (upload ALL toolchains at one shot). To reuse all updates >> users just need to set new URL/SHA1 of HunterGate module: >> https://github.com/ruslo/hunter/releases >> >>> Overall, building boost takes 10s on our developers? machines. The >>> sources aren?t changed often, >>> so the cost is pretty low. >> What kind of hardware do they have? And what libraries you mean? It >> takes about 20 seconds on my Linux machine just to unpack 80 MB of >> Boost release archive. It's even worse on Windows, it takes several >> minutes for some strange reason even on SSD + Core i7. Using binaries >> in such cases is a huge time saver because there is no need to >> compile anything and there is no a lot of junk that they put into >> release archive (if you remove docs and tests 80 MB became 15 MB). > > I consider the time to download Boost isn?t part of the build. I'm not counting that. It takes 20 seconds just to unpack archive that already downloaded. Anyway I'm just wondering what is possible to do with Boost for 10 seconds. Install header-only libraries? Build 1-2 libraries? All of them? :) > The Boost source download is cached outside of the build directory in > a unique folder. > So it?s effectively only done once for all platforms and then reused. This is true for local machines and for custom build servers like your personal Jenkins. For Travis/AppVeyor you have to create root folder with 3rd parties from scratch for each build (at least for free public accounts). > > You?ll also have symbols and the sources available for debugging > properly, and they?re > not always available with a binary distribution. Just to clarify: with Hunter you're creating binaries from sources, so everything you install with `cmake --build _builds --target install` (or `./b2 install` for Boost) is available. > > >> Of course building from source is not an option for such monsters >> like Qt or OpenCV. Ready-to-use binaries is something critical for >> real life applications. There is no way to test everything on >> Travis/AppVeyor without this feature. > > Well, you don?t have to use Travis or AppVeyor. It's the most powerful and easy to setup services I know. If you know any better solutions please share. > Spotify isn?t at the same scale as most > projects hosted there and we have different requirements and resources. > Admittedly, Spotify doesn?t use Qt anymore, so this isn?t a problem > for us. It's not about Qt, it's about expandability. Use 20 of smaller libraries and you will have quite the same issues. > > Note that by integrating everything in the same project, you also have > proper dependencies > and you will only build what you need. You may save some time by doing > that. > And caching is important, when done in the right way! With Hunter you're installing only what you need too, it does respect options like FOO_WITH_OPENSSL or FOO_WITH_QT, it download only binaries for toolchain you're currently working on, etc. Don't want to make a discussion too broad. You said that it's hard to manage binaries for a lot of configuration, I'm saying that it's possible and is very handy. Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Tue Aug 16 17:01:06 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 17 Aug 2016 00:01:06 +0300 Subject: [CMake] Need ideas/opinions on third party library management In-Reply-To: References: Message-ID: On 13-Aug-16 03:12, Elizabeth A. Fischer wrote: > I don't think CMake is the best place to do it, for a number of > reasons. I would not try to re-invent the wheel here. Can you provide any details? I personally think that CMake is a natural and the only place where it should be done. On 16-Aug-16 15:52, Elizabeth A. Fischer wrote: > But any approach that requires every build to be ported to CMake will > be difficult and labor-prone to scale. Writing a meta-build recipe is > usually much easier. It is difficult indeed but it's the only way to reach the goal. I have kind of a meta-build recipe for the Boost, it was the first non-cmake recipe I've added and it's almost 3 year of improvements behind but it's still far from what I get in CMake from the box (of course it's not 3 years of development of just this recipe, but anyway). Just take a look at this code: add_executable(foo foo.cpp) add_library(boo boo.cpp) With CMake: No options: you got executable and static library on host BUILD_SHARED_LIBS: you got shared library CMAKE_MACOSX_BUNDLE: you got bundle instead of executable CMAKE_TOOLCHAIN_FILE=android.cmake: you got library for Android CMAKE_TOOLCHAIN_FILE=ios.cmake: you got armv7 library for iOS CMAKE_TOOLCHAIN_FILE=ios.cmake + CMAKE_IOS_INSTALL_COMBINED: you got armv7 + arm64 + i386 + x86_64 universal library /* your toolchain file here */: ... Debug: you compile with -O0 for *nix or /Od for MSVC MinSizeRel: you compile with -Os for *nix or /O1 /* your custom build type here */: ... Any usage requirements? Propagated AUTOMATICALLY to any project that use your library: compiler flags, definitions, dependent libraries, etc. Optional dependencies? No problems, usage requirements propagated too. Same code! No changes needed. Usage requirements change from one version to another? Again, no problems. So I choose to add CMakeLists.txt almost in all cases when new package needed. Exceptions are big libraries with a lot of components such as Qt or Boost, it's unmaintainable approach, inevitable evil :( Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Tue Aug 16 17:36:21 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 17 Aug 2016 00:36:21 +0300 Subject: [CMake] [cmake-developers] Need ideas/opinions on third party library management In-Reply-To: References: <1D3F7CC1-58CE-4B01-A2E2-9AFBB746B384@gmail.com> Message-ID: <297ede78-49bf-9aa5-bdd9-e8d3c2deaf96@yahoo.com> On 16-Aug-16 16:37, Florent Castelli wrote: > Well, I tried upstreaming the new build scripts to some projects and > it didn?t go well. > Some of the reasons I?ve heard of: > - Windows developpers don?t use CMake, they have project files on the > repository. > The CMake files for Windows will never be updated. They can coexists, it's easier then maintaining forks. If only C++ code changed you got new version "for free". > - I installed CMake 2.8.6 five years ago and I don?t want to update > yet again! > People relying on old versions is quite common and any attempt to > raise the min > version will be frowned upon (see the discussion in the LLVM mailing > lists for example). You can add `if(CMAKE_VERSION VERSION_LESS ...)` condition. It's hard to support such hairy configuration but anyway. > - We prefer to use autotools and don?t want to have to learn CMake. > That?s fair. But also, no one likes to build an autotools backed > project for Android or iOS. Just for your info Hunter use build scheme for autotools project: https://github.com/ruslo/hunter/blob/b4c370e32798cc3da74c37e4156c3bfc77add379/cmake/modules/hunter_autotools_project.cmake It can create universal iOS libraries and works for Android. There are a lot of efforts made by Alexandre Pretyman so this can be possible, it has some peculiarities. I guess he can clarify anything if you need details. Ruslo From dschepler at scalable-networks.com Tue Aug 16 18:09:08 2016 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Tue, 16 Aug 2016 22:09:08 +0000 Subject: [CMake] Need ideas/opinions on third party library management In-Reply-To: References: , Message-ID: For what it's worth, what I've done here is to create binary packages of each third-party library for each supported platform (i.e. .deb packages for Ubuntu, .rpm packages for RHEL/CentOS, Chocolatey packages for Windows). Except for cases where the system already provided sufficient versions of some of the libraries. At the bottom of the internal dependency chain is a base package which sets up the infrastructure (e.g. an /etc/profile.d file to add a shell function to add entries to CMAKE_PREFIX_PATH, LD_LIBRARY_PATH, etc.) and at the top is a set of dependency metapackages, one for each product we have to build. And yes, the middle layer has a combination of large packages like Qt and Boost with smaller packages like Expat and SQLite. Pluses: - Extremely convenient for an internal developer to just follow a few instructions to add our internal repository, then run "apt-get install anchorage-exata-deps". - Similarly convenient for customers developing custom code on top of our code if we provide an archive of the required packages, then they can point apt/yum/chocolatey to a file: URL. - It's not too difficult to support installing multiple parallel versions of the development environment for different versions of the product - just have each one install to a different location, and then the developer selects what to use by running the appropriate shell function. - Greatly simplifies the CMake files for our code, since you just use the standard find_package() command (possibly requiring us to write a Find*.cmake module). - Flexibility of being able to easily experiment with a new or custom-compiled version of one of the dependencies. - If an internal developer happens to prefer working on a platform which we don't officially support (e.g. Debian testing or Mint), it's generally easy to git clone my packaging repositories and build packages for yourself. Minuses: - Duplicate packaging work for each different packaging tool when adding a new third-party library. - I haven't yet automated the process of building binary packages and uploading to our repository; so when updating any package to a new version (or adding a local patch) there's a lot of manual work to do. (dupload and reprepro help a bit for the Ubuntu builds, and nuget has a built-in facility to upload to our server; but I haven't found anything similar for the RPM builds.) - When we do a release and then need to "fork" the repository to a new location, it requires a rebuild of all packages at least on Linux. Overall, most of the pluses apply to everybody, whereas the minuses are just a burden on me (or a future maintainer of the repository). So overall, it's been a big improvement over what we used to do, which was to try to maintain binary builds of the third-party libraries in SVN. -- Daniel Schepler -------------- next part -------------- An HTML attachment was scrubbed... URL: From intelfx at intelfx.name Tue Aug 16 20:44:26 2016 From: intelfx at intelfx.name (Ivan Shapovalov) Date: Wed, 17 Aug 2016 03:44:26 +0300 Subject: [CMake] Private dependencies of static libraries exported as targets In-Reply-To: References: <1471311153.20784.29.camel@intelfx.name> <1471314145.20784.33.camel@intelfx.name> Message-ID: <1471394666.4604.2.camel@intelfx.name> TBH, I do not see the "PRIVATE dependencies are made PUBLIC for the purposes of linking when the dependent is static library" there. --? Ivan Shapovalov / intelfx / On 2016-08-16 at 02:35 -0500, Nicholas Braden wrote: > Yes, the behavior is documented in several places, the most prominent > being here: > https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#t > ransitive-usage-requirements > > > On Mon, Aug 15, 2016 at 9:22 PM, Ivan Shapovalov e> wrote: > > > > On 2016-08-15 at 21:46 -0400, Guillaume Dumont wrote: > > > > > > As far as I know the PRIVATE > > > keyword > > > should have no effect on transitive linking when foo is static > > > and we > > > call: > > > > > > target_link_libraries(foo PRIVATE bar) > > > > > > Hope this helps. > > > > Wow. I did not know that. Should've tested on sample project. > > It does not solve include path bloat though, but that's a minor > > issue. > > > > One question remains... is this behavior documented somewhere? > > > > Anyway, huge thanks, > > -- > Ivan Shapovalov / intelfx / -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From nicholas11braden at gmail.com Tue Aug 16 21:14:09 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Tue, 16 Aug 2016 20:14:09 -0500 Subject: [CMake] Private dependencies of static libraries exported as targets In-Reply-To: <1471394666.4604.2.camel@intelfx.name> References: <1471311153.20784.29.camel@intelfx.name> <1471314145.20784.33.camel@intelfx.name> <1471394666.4604.2.camel@intelfx.name> Message-ID: Ah, I misunderstood what you were asking about. It would be pretty weird if CMake didn't know that static libraries always need all their dependencies linked regardless of privacy, but I agree it should at least be mentioned somewhere. My bad. As for include path bloat, I cannot replicate this in my test project - CMake will link all the dependencies as required but will NOT violate "PRIVATE" for other things like include directories. Could you give an example where you are seeing a static library's private dependency's include path being added when linking the static library? On Tue, Aug 16, 2016 at 7:44 PM, Ivan Shapovalov wrote: > TBH, I do not see the "PRIVATE dependencies are made PUBLIC for the > purposes of linking when the dependent is static library" there. > > -- > Ivan Shapovalov / intelfx / > > > On 2016-08-16 at 02:35 -0500, Nicholas Braden wrote: >> Yes, the behavior is documented in several places, the most prominent >> being here: >> https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#t >> ransitive-usage-requirements >> >> >> On Mon, Aug 15, 2016 at 9:22 PM, Ivan Shapovalov > e> wrote: >> > >> > On 2016-08-15 at 21:46 -0400, Guillaume Dumont wrote: >> > > >> > > As far as I know the PRIVATE >> > > keyword >> > > should have no effect on transitive linking when foo is static >> > > and we >> > > call: >> > > >> > > target_link_libraries(foo PRIVATE bar) >> > > >> > > Hope this helps. >> > >> > Wow. I did not know that. Should've tested on sample project. >> > It does not solve include path bloat though, but that's a minor >> > issue. >> > >> > One question remains... is this behavior documented somewhere? >> > >> > Anyway, huge thanks, >> > -- >> Ivan Shapovalov / intelfx / From elizabeth.fischer at columbia.edu Wed Aug 17 01:36:29 2016 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Wed, 17 Aug 2016 01:36:29 -0400 Subject: [CMake] [cmake-developers] Need ideas/opinions on third party library management In-Reply-To: <7a183ebd-6ffa-16c1-939b-ae617dca9215@gmail.com> References: <1D3F7CC1-58CE-4B01-A2E2-9AFBB746B384@gmail.com> <297ede78-49bf-9aa5-bdd9-e8d3c2deaf96@yahoo.com> <7a183ebd-6ffa-16c1-939b-ae617dca9215@gmail.com> Message-ID: Well, I tried upstreaming the new build scripts to some projects and it didn?t go well. Some of the reasons I?ve heard of: > I installed CMake 2.8.6 five years ago and I don?t want to update yet > again! People relying on old versions is quite common and any attempt > to raise the min version will be frowned upon (see the discussion in > the LLVM mailing lists for example). Spack is really good at installing dependencies, and makes this a LOT easier. In your Spack recipe, you just tell it which version of CMake your package needs. If Spack hasn't already built that version, it will download and install it for you. Building packages by hand, and configuring their dependencies, needs to go the way of stone spears. > We prefer to use autotools and don?t want to have to learn CMake. > That?s fair. But also, no one likes to build an autotools backed > project for Android or iOS. I suppose it's fair. But a Google search of "convert CMake to Autotools" results in 9:1 stories of people abandoning Autotools for CMake. Except for the fact that it works well for users, I can't say enough evil things about Autotools. Part of the benefit of Autotools is it "just works" without requiring the user to install anything. This benefit is of little value once you move to an auto-builder like Spack. The days when you can get any interesting software to work without installing a zillion dependencies first are long gone. > I?ve never heard of Spack before. It looks better than other solutions > I?ve seen before. The great and unique thing about Spack is it can install a zillion versions of each package. For example... if Package B uses MPI, I can build B-1.7 two (or more) times --- once with OpenMPI and once with MPICH. And I can install them side-by-side. If you change any of the dependencies of a package, Spack will see that as a new and separate version. Most auto-builders let you build one software distro, with only one build of each package (or sometimes one build per numerical version of the package or compiler or something). Spack's versioning is a lot more powerful. > But you still have to manage all the options from your build script Not sure what you mean by this. True, there is some redundancy building code. First you put the options and dependencies in a package's CMake build. And then you put them into the Spack build again. Some things could be simplified if we assumed our CMake-based packages would only ever be built with Spack. But we still need to create CMake-based software that can be installed by hand. Hence the redundancy between the CMake build scripts and the Spack package. In practice, this has not been the end of the world. Another nice thing about Spack is there is no difference between your libraries and Third-party libraries. > and publish the binaries somewhere. In its original incarnation, Spack builds from source. It does not publish or install from binary distros (because the build you asked for, with all its dependency variants, is likely not a build that's ever been built before). There's currently work on a project to use Spack to produce binary RPMs, and maybe other forms of binary distribution. > Then you need to teach your build scripts to get the right version. Your build scripts know nothing about Spack. Spack is an auto-builder that sits ON TOP of your build scripts. > I won?t trade my builds from source for a set of prebuilt binaries anytime soon I think :) Spack builds from source, it is not prebuilt binaries. > > I don't think CMake is the best place to do it, > Can you provide any details? I personally think that CMake is a > natural and the only place where it should be done. The most important reason here is because there are combinatorially many versions of a package you COULD install, depending on what versions of its dependencies you link with, and CMake provides nothing to address that issue. See here for an overview of how Spack addresses the combinatorial versioning issue (which no other auto-builder does, to the best of my knowledge): http://hpcugent.github.io/easybuild/files/SC14_BoF_Spack.pdf Once you've built something, it's nice to be able to re-use it. If I have a top-level CMake project that automatically builds three dependencies, will other projects be able to make use of those dependencies I've built? Or do they become private? If libraries cannot be shared between applications, you will get a LOT of library bloat, especially among the low-level libraries that get repeated numerous times. Admittedly, this may not be such an issue in some environments where people are really only focused on building one thing. If you make a project, you might see it as a "top-level" project. But someone else might want to build something bigger on top of your work. You can never assume that "this package is top-level and no one will ever depend on it." Another obvious problem with using CMake for everything is that not all packages come with CMake builds; most do not, in fact. Even if we CAN re-write all the buils into CMake, that is a lot of extra effort. As Florent has discovered, upstream authors do not always see a CMake build in a favorable light, and these re-worked builds are not always as functional as the original. Moreover... writing a Spack recipe is an order of magnitude easier than writing a CMake build. Usually, it's just a matter of calling `configure` or `cmake` with the right options. Although we can maybe imagine a world in which everyone eventually abandons Autotools for CMake, it is still not realistic to expect that Python, Haskell or Java programs will ever come with CMake builds. This would be OK if each language exited in its own silo. But they don't. Python packages (built with setuptools) routinely depend on C-based packages (built with Autotools or CMake). By being agnostic to the build system, auto-builders (like Spack, Macports, HomeBrew, etc) are able to make packages work together, regardless of the build system chosen for each one. In the sense that CMake is a Turing-complete language, there's no fundamental reason you CAN'T write a meta-builder in CMake. But gosh... the language sure is arcane (but still better than Autotools by a long shot). I like to imagine that if CMake were starting off today, it would be written in Python. > It is difficult indeed but it's the only way to reach the goal. Not sure what goal here. My software stack requires about 70 packages. I'm so glad I didn't have to rewrite 70 CMake builds. As long as an Autotools build works (meaning it puts stuff in prefix/bin, prefix/lib, etc. at the end of the day), and I don't have to look at it, why do I care? > Exceptions are big libraries with a lot of components such as Qt or > Boost, it's unmaintainable approach, inevitable evil :( I guess I rely on a lot of evil libraries. > It's not too difficult to support installing multiple parallel > versions of the development environment for different versions of > the product - just have each one install to a different location The problem here is each dev environment is fully repeated, even if only a few of the top-level packages have changed. I heard about one well-known Silicon Valley company that did this, and is maintaining 50 different versions of their Python environment (complete with all their Python libs, both internal and 3d party). They also have special rules about which code you can depend on, and which is designated "top level," meaning you cannot depend on it. Unfortunately, they did not have enough bandwidth or storage in their data center to distribute 50X their dev environment to each node where it needed to be. Spack can help address this problem by allowing sharing of lower-level libraries between different top-level environments. On Tue, Aug 16, 2016 at 9:31 PM, Florent Castelli < florent.castelli at gmail.com> wrote: > On 16/08/2016 23:36, Ruslan Baratov wrote: > >> On 16-Aug-16 16:37, Florent Castelli wrote: >> >>> Well, I tried upstreaming the new build scripts to some projects and it >>> didn?t go well. >>> Some of the reasons I?ve heard of: >>> - Windows developpers don?t use CMake, they have project files on the >>> repository. >>> The CMake files for Windows will never be updated. >>> >> They can coexists, it's easier then maintaining forks. If only C++ code >> changed you got new version "for free". >> >> - I installed CMake 2.8.6 five years ago and I don?t want to update yet >>> again! >>> People relying on old versions is quite common and any attempt to >>> raise the min >>> version will be frowned upon (see the discussion in the LLVM mailing >>> lists for example). >>> >> You can add `if(CMAKE_VERSION VERSION_LESS ...)` condition. It's hard to >> support such hairy configuration but anyway. >> >> - We prefer to use autotools and don?t want to have to learn CMake. >>> That?s fair. But also, no one likes to build an autotools backed >>> project for Android or iOS. >>> >> Just for your info Hunter use build scheme for autotools project: >> https://github.com/ruslo/hunter/blob/b4c370e32798cc3da74c37e >> 4156c3bfc77add379/cmake/modules/hunter_autotools_project.cmake >> It can create universal iOS libraries and works for Android. There are a >> lot of efforts made by Alexandre Pretyman so this can be possible, it has >> some peculiarities. I guess he can clarify anything if you need details. >> >> Ruslo >> > > You're addressing the wrong person here. > > /Florent > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From intelfx at intelfx.name Wed Aug 17 05:11:40 2016 From: intelfx at intelfx.name (Ivan Shapovalov) Date: Wed, 17 Aug 2016 12:11:40 +0300 Subject: [CMake] Private dependencies of static libraries exported as targets In-Reply-To: References: <1471311153.20784.29.camel@intelfx.name> <1471314145.20784.33.camel@intelfx.name> <1471394666.4604.2.camel@intelfx.name> Message-ID: <1471425100.4604.7.camel@intelfx.name> On 2016-08-16 at 20:14 -0500, Nicholas Braden wrote: > Ah, I misunderstood what you were asking about. It would be pretty > weird if CMake didn't know that static libraries always need all > their > dependencies linked regardless of privacy, but I agree it should at > least be mentioned somewhere. My bad. > > As for include path bloat, I cannot replicate this in my test project > - CMake will link all the dependencies as required but will NOT > violate "PRIVATE" for other things like include directories. Could > you > give an example where you are seeing a static library's private > dependency's include path being added when linking the static > library? Please take a look at https://github.com/intelfx/cmake-demo.?This is a sample dependency chain of two libraries and one executable (client -> foo -> bar), both libraries are found and linked as IMPORTED targets.? The client is built with VERBOSE=1 -- notice the compiler command lines. On my system it says (pretty self-explanatory): /usr/bin/c++ -isystem /home/intelfx/devel/__auxiliary/experiments/cmake-static-transitive/prefix/foo/include -isystem /home/intelfx/devel/__auxiliary/experiments/cmake-static-transitive/prefix/bar/include -o CMakeFiles/client.dir/src/ main.cpp.o -c /home/intelfx/devel/__auxiliary/experiments/cmake-static-transitive/client/src/main.cpp -- Ivan Shapovalov / intelfx / -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ruslan_baratov at yahoo.com Wed Aug 17 05:40:29 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 17 Aug 2016 12:40:29 +0300 Subject: [CMake] [cmake-developers] Need ideas/opinions on third party library management In-Reply-To: References: <1D3F7CC1-58CE-4B01-A2E2-9AFBB746B384@gmail.com> <297ede78-49bf-9aa5-bdd9-e8d3c2deaf96@yahoo.com> <7a183ebd-6ffa-16c1-939b-ae617dca9215@gmail.com> Message-ID: On 17-Aug-16 08:36, Elizabeth A. Fischer wrote: > > > I don't think CMake is the best place to do it, > > Can you provide any details? I personally think that CMake is a > > natural and the only place where it should be done. > > The most important reason here is because there are combinatorially > many versions of a package you COULD install, depending on what > versions of its dependencies you link with, and CMake provides nothing > to address that issue. CMake provides an abstraction. "Slots" that you need to fill: if(FOO_WITH_TESTS) # need to have GTest installed find_package(GTest) endif() if(FOO_WITH_OPENSSL) # need to have OpenSSL installed find_package(OpenSSL) endif() And it should drive package manager. At least I find that approach natural and convenient, see no problems with it. You can have as much combinations of versions/options/dependencies as you need: * https://docs.hunter.sh/en/latest/overview/customization/hunter-id.html * https://docs.hunter.sh/en/latest/overview/customization/config-id.html > See here for an overview of how Spack > addresses the combinatorial versioning issue (which no other > auto-builder does, to the best of my knowledge): > > http://hpcugent.github.io/easybuild/files/SC14_BoF_Spack.pdf That's what I was talking about. I think that there is no need to introduce new funky syntax like "spack install mpileaks at 1.1.2 %gcc at 4.7.3 +debug". We already have CMAKE_CXX_COMPILER and CMAKE_BUILD_TYPE/CMAKE_CONFIGURATION_TYPES. Version can be set by CMake options too. Effectively you can do: option(FOO_STABLE_BUILD "Stable build" ON) option(FOO_EXPERIMENTAL_BUILD "Experimental build" OFF) if(APPLE AND IOS AND FOO_STABLE_BUILD) hunter_config(BooPackage VERSION "1.0") endif() if(WIN32 AND FOO_EXPERIMENTAL_BUILD) hunter_config(BooPackage VERSION "2.0-beta" CMAKE_ARGS BOO_NEW_STUFF=YES) endif() > > Once you've built something, it's nice to be able to re-use it. If I > have a top-level CMake project that automatically builds three > dependencies, will other projects be able to make use of those > dependencies I've built? Yes, libraries should be installed to the shared root, not to local folder: * https://docs.hunter.sh/en/latest/overview/shareable.html > Or do they become private? No. Though you can make it private by setting CMake variable. It will use separate directory just like virtualenv do. > If libraries > cannot be shared between applications, you will get a LOT of library > bloat, especially among the low-level libraries that get repeated > numerous times. Admittedly, this may not be such an issue in some > environments where people are really only focused on building one > thing. > > If you make a project, you might see it as a "top-level" project. But > someone else might want to build something bigger on top of your > work. You can never assume that "this package is top-level and no one > will ever depend on it." No issue here, see notes above. > > Another obvious problem with using CMake for everything is that not > all packages come with CMake builds; most do not, in fact. Even if we > CAN re-write all the buils into CMake, that is a lot of extra effort. > As Florent has discovered, upstream authors do not always see a CMake > build in a favorable light, and these re-worked builds are not always > as functional as the original. Moreover... writing a Spack recipe is > an order of magnitude easier than writing a CMake build. Usually, > it's just a matter of calling `configure` or `cmake` with the right > options. Again, converting to CMake is a best option, but not the only possible one. E.g. OpenSSL, Boost, autotool-based package like X11 can be used as is: * https://github.com/ruslo/hunter/blob/b4c370e32798cc3da74c37e4156c3bfc77add379/cmake/projects/Boost/hunter.cmake#L21 * https://github.com/ruslo/hunter/blob/b4c370e32798cc3da74c37e4156c3bfc77add379/cmake/projects/OpenSSL/hunter.cmake#L17 * https://github.com/ruslo/hunter/blob/b4c370e32798cc3da74c37e4156c3bfc77add379/cmake/projects/x11/hunter.cmake#L20 > > Although we can maybe imagine a world in which everyone eventually > abandons Autotools for CMake, it is still not realistic to expect that > Python, Haskell or Java programs will ever come with CMake builds. > This would be OK if each language exited in its own silo. But they > don't. Python packages (built with setuptools) routinely depend on > C-based packages (built with Autotools or CMake). By being agnostic > to the build system, auto-builders (like Spack, Macports, HomeBrew, > etc) are able to make packages work together, regardless of the build > system chosen for each one. That's exactly what Hunter do, but using CMake as a driver. > > In the sense that CMake is a Turing-complete language, there's no > fundamental reason you CAN'T write a meta-builder in CMake. But > gosh... the language sure is arcane (but still better than Autotools > by a long shot). I like to imagine that if CMake were starting off > today, it would be written in Python. Language is a pain, I totally agree. But language will change nothing if design is originally bad. GYP use Python so what? Does the syntax sexy? Does it scale? No, it's just another "Works for me!" tool... > > > It is difficult indeed but it's the only way to reach the goal. > > Not sure what goal here. Extendable, customizable and easy reusable solution. > My software stack requires about 70 > packages. I'm so glad I didn't have to rewrite 70 CMake builds. As > long as an Autotools build works (meaning it puts stuff in prefix/bin, > prefix/lib, etc. at the end of the day), and I don't have to look at > it, why > do I care? That's the point - it doesn't. For example it's not possible to have different build types (Release/Debug) installed into one root but with different suffixes like CMake do. *.pc files created by autotools contain full path so you can't build your code on remote machine and download it to the local one. At least those are the problems we did hit, so if I missing something please let me know. > > > Exceptions are big libraries with a lot of components such as Qt or > > Boost, it's unmaintainable approach, inevitable evil :( > > I guess I rely on a lot of evil libraries. Me too, I'm just saying that I don't use "add new CMakeLists.txt to this project" approach. Ruslo From nicholas11braden at gmail.com Wed Aug 17 06:19:36 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Wed, 17 Aug 2016 05:19:36 -0500 Subject: [CMake] Private dependencies of static libraries exported as targets In-Reply-To: <1471425100.4604.7.camel@intelfx.name> References: <1471311153.20784.29.camel@intelfx.name> <1471314145.20784.33.camel@intelfx.name> <1471394666.4604.2.camel@intelfx.name> <1471425100.4604.7.camel@intelfx.name> Message-ID: Huh, this is weird. It seems to be an issue with the export/import mechanism. If you make a project where everything is in the same CMakeLists.txt and there is no install step, there is no include directory pollution. See my attached project for example. On my system I run this to build: mkdir build && cd build && cmake -G "MinGW Makefiles" .. && cmake --build . -- VERBOSE=1 When it builds main: C:\MinGW\bin\g++.exe @CMakeFiles/main.dir/includes_CXX.rsp -std=gnu++14 -o CMakeFiles\main.dir\main.cpp.obj -c C:\Users\LB\Code\cmake-private-static-dependencies\main.cpp The entirety of the includes_CXX.rsp file: -IC:/Users/LB/Code/cmake-private-static-dependencies/c The project you provided definitely has the include directory pollution problem - the client includes_CXX.rsp file contains an -isystem directive for bar. It looks like the generated FooTargets-noconfig.cmake contains this line (setting properties on foo): IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG "bar" I'm not fully sure but I think this is wrong because it is saying that bar is a public dependency. This seems to be an oversight in CMake, as there is no 'private' alternative of the above variable for imported targets - that is, there is no IMPORTED_LINK_LIBRARIES_NOCONFIG, thus there is no way for CMake to provide special treatment as in my example. It seems CMake literally converts private dependencies of static libraries to public dependencies only when using the export functionality. ...and that's as much as I can figure right now. Can you confirm that my attached example doesn't exhibit the problem? If it doesn't have the include directory pollution problem, I'd be inclined to say it's a bug with the export/import functionality. On Wed, Aug 17, 2016 at 4:11 AM, Ivan Shapovalov wrote: > On 2016-08-16 at 20:14 -0500, Nicholas Braden wrote: >> Ah, I misunderstood what you were asking about. It would be pretty >> weird if CMake didn't know that static libraries always need all >> their >> dependencies linked regardless of privacy, but I agree it should at >> least be mentioned somewhere. My bad. >> >> As for include path bloat, I cannot replicate this in my test project >> - CMake will link all the dependencies as required but will NOT >> violate "PRIVATE" for other things like include directories. Could >> you >> give an example where you are seeing a static library's private >> dependency's include path being added when linking the static >> library? > > Please take a look at https://github.com/intelfx/cmake-demo. This is a > sample dependency chain of two libraries and one executable (client -> > foo -> bar), both libraries are found and linked as IMPORTED targets. > The client is built with VERBOSE=1 -- notice the compiler command > lines. > > On my system it says (pretty self-explanatory): > > /usr/bin/c++ -isystem /home/intelfx/devel/__auxiliary/experiments/cmake-static-transitive/prefix/foo/include -isystem /home/intelfx/devel/__auxiliary/experiments/cmake-static-transitive/prefix/bar/include -o CMakeFiles/client.dir/src/ > main.cpp.o -c /home/intelfx/devel/__auxiliary/experiments/cmake-static-transitive/client/src/main.cpp > > -- > Ivan Shapovalov / intelfx / -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-private-static-dependencies.zip Type: application/zip Size: 1503 bytes Desc: not available URL: From ruslan_baratov at yahoo.com Wed Aug 17 06:48:33 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 17 Aug 2016 13:48:33 +0300 Subject: [CMake] [cmake-developers] Need ideas/opinions on third party library management In-Reply-To: References: <1D3F7CC1-58CE-4B01-A2E2-9AFBB746B384@gmail.com> <8a4f01d8-ace7-6067-fe66-0ca4bb8b4f2a@yahoo.com> <3BE89DE2-20DF-43A2-B202-5580467BF50E@gmail.com> <39f807ac-9380-de31-3d2d-5e9b06e1c647@yahoo.com> Message-ID: <3a6e4062-e3d4-3eaa-94f6-7b05dd29b6d9@yahoo.com> On 17-Aug-16 04:29, Florent Castelli wrote: > >>> The Boost source download is cached outside of the build directory >>> in a unique folder. >>> So it?s effectively only done once for all platforms and then reused. >> This is true for local machines and for custom build servers like >> your personal Jenkins. For Travis/AppVeyor you have to create root >> folder with 3rd parties from scratch for each build (at least for >> free public accounts). > Yes. If you're using a free shared service, that's not something you > can count on. > If you host your CI, you can do neat tricks like this, use ccache or > other similar techs. What if you don't need "tricks" and make everything plain and simple? > >> >>> >>> You?ll also have symbols and the sources available for debugging >>> properly, and they?re >>> not always available with a binary distribution. >> Just to clarify: with Hunter you're creating binaries from sources, >> so everything you install with `cmake --build _builds --target >> install` (or `./b2 install` for Boost) is available. > So you build each dependency separately, install them, and then use > them in your top level dependency. No, in shared root folder. > That works, but you have the extra overhead of the instrumentation for > the whole build. > Even a no-op build will have to recurse in the build folder for each > dependency and run again, which is slow. > This is why I prefer Ninja to the Makefile generator: it has a global > view of everything and you get a quick no-op build. Not sure I understand that. What is the overhead? > >> >>> >>> >>>> Of course building from source is not an option for such monsters >>>> like Qt or OpenCV. Ready-to-use binaries is something critical for >>>> real life applications. There is no way to test everything on >>>> Travis/AppVeyor without this feature. >>> >>> Well, you don?t have to use Travis or AppVeyor. >> It's the most powerful and easy to setup services I know. If you know >> any better solutions please share. > Well, you don't have a full control on the environment, so I wouldn't > say it's the most powerful. Please share your solution. I have worked with Jenkins before and will not say that it's something easy customizable. Shareable folder - yes, good, but other stuff is a complete pain. You can setup Travis in a seconds, add AppVeyor and you got Linux, OSX, Windows testing. How much time will take to start and tune Jenkins master and connect several slaves with different OSes on them? Then add bunch of projects and tune them, then create dev branches for testing and so on. > Convenient for sure. It probably fits smaller structures very well. > Bigger companies have the resources to host their own service most of > the time and requirements that > force them to do so. Those are probably the ones that will have the > manpower to handle a super-build type > build system. Why do not have both? Hunter can share downloads/root/cache on local folder for such CIs like Jenkins/custom so you don't need to rebuild everything. At the same time binaries from server can be downloaded for "build-from-scratch" environment like Travis. Anyway what about users? So you think it's okay to spend several hours of building from sources to just to run simple example of your product? > >> >>> Spotify isn?t at the same scale as most >>> projects hosted there and we have different requirements and resources. >>> Admittedly, Spotify doesn?t use Qt anymore, so this isn?t a problem >>> for us. >> It's not about Qt, it's about expandability. Use 20 of smaller >> libraries and you will have quite the same issues. > As I said before, if I have build scripts for 20 small libraries and I > want to update a build flag affecting the ABI, I don't have to do > anything but just change the flag once. > In your case, you'll have to tweak the 20 build scripts for each > library to reflect it. > The dependencies are only intermediate products you use for the final > one. I don't want to deal with them constantly. It's not true, I don't need to tweak 20 scripts, I just need to tweak one toolchain file. > >> >>> >>> Note that by integrating everything in the same project, you also >>> have proper dependencies >>> and you will only build what you need. You may save some time by >>> doing that. >>> And caching is important, when done in the right way! >> With Hunter you're installing only what you need too, it does respect >> options like FOO_WITH_OPENSSL or FOO_WITH_QT, it download only >> binaries for toolchain you're currently working on, etc. >> >> Don't want to make a discussion too broad. You said that it's hard to >> manage binaries for a lot of configuration, I'm saying that it's >> possible and is very handy. > I'm not saying it's impossible. I'm saying the overhead of managing > binaries is just a burden we shouldn't have to accept in the C/C++ world. > If you can build build everything from source all the time in a > super-build, why wouldn't you do it? Because it's not practical. I have such experience with Gentoo, I prefer do something useful instead of watching on "emerge world" progress. Super-build doesn't scale, what if you have two super-build projects how will you merge them? > I'm lazy, I don't want to have to configure everything separately and > maintain them. > You seem to have a lot of issues with Hunter anyway such as this one: > https://github.com/ruslo/hunter/issues/454 I don't understand how is this issue specific to Hunter? You will have same issues with super-build, Python-based build, brew, whatever... > Just so you know, I shared the CMake file for Boost with some > employees who wanted to use it for a personal project running on both > iOS and Android: they had no configuration to do and it actually worked. > It's one anecdote and doesn't mean much. but it's an approach that works. I like approach of CMakefying Boost but without dependency manager it will not work smooth. So you have CMakeLists.txt for all Boost libraries or you have CMakeLists.txt for each component. I don't see the link to the code. > It's not about saying which solution if better or worse. Each have > benefits and cons. If you want a traditional dependency management, go > for it. > If you want to use your software Hunter, go for it. > > I'm merely explaining that with the solution we have in place, > everything is working great for us and we don't have any issue now > managing builds for many libraries. > Robert asked about feedback and options, I'm just giving one more to him. That's the problem with C++ community - everybody use tool that "works for me!". So package A use one build tool, package B decide that tool for A is not powerful enough and use custom tool. Package C want to use A and B so it have to ignore A/B system or create "integrator". Package D use C but want to use custom A so I have to sneak into C build process and patch it. Building Tower of Babel, it will not end well... Real world example: Boost user b2, Boost.iostreams depends on ZLIB, ZLIB use CMake, I have to run CMake to install ZLIB then run ./b2 with custom flags to show where ZLIB is located. Now I want to add OpenCV to my project, and OpenCV has an internal copy of ZLIB, so I have to sneak into OpenCV build and teach it to use my version of ZLIB. Ruslo From nicholas11braden at gmail.com Wed Aug 17 07:09:26 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Wed, 17 Aug 2016 06:09:26 -0500 Subject: [CMake] dependencies between external projects (not DEPENDS) In-Reply-To: References: Message-ID: Usually there would be variables like A_ROOT which allow the FindA.cmake module being used by B to correctly find everything. If there isn't, you'd have to write your own FindA.cmake module in either case. If you can't modify B, you could use the patch step of the external project to replace the broken FindA.cmake with your modern FindA.cmake with minimal effort while you wait for B to accept your pull request. The takeaway is, if B doesn't have a way for you to say "Look for A here first/only", that's a bug in B's FindA module. As for recursive dependencies, there is the CMakeFindDependencyMacro module, but you have to be careful about the can of worms you are opening - you'd want to only find versions which are binary compatible and also deal with cases of the wrong version of the package having already been found. Sometimes it's easier to just tell the client to find the dependencies for you, rather than trying to do it for them and potentially getting it wrong. I honestly don't know what the best approach is here. On Mon, Aug 15, 2016 at 10:56 AM, Neil Carlson wrote: > I'm struggling with how to handle dependencies between external projects in > a > superbuild. The issue is different than simply ensuring that one gets built > before > another using the DEPENDS keyword -- that's trivial. > > Suppose I have two external libraries A and B, where B depends on A. It is > not > always possible to correctly define variables like A_LIBRARIES that feed > into the > externalproject_add for B that anticipate what will come out of the A > configure/build. > There are sometimes additional link libraries that only come to light after > A is > actually configured. > > How do people handle these situations? I'm thinking of a multi-pass > approach > where one runs cmake/make twice. The first installs A skipping the > dependent B. > The second builds B (skipping a found A) using correctly set variables from > a > FindA module. > > Incidentally, is it kosher to have a Find module invoke a find_package? > There are > examples in of this in standard Find modules. This creates problems in the > superbuild context, where say A is found, but rejected by the superbuild > because > of missing features, for example, but FindB finds A and uses it. > > Thanks for your advice. > > -Neil > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 intelfx at intelfx.name Wed Aug 17 08:55:08 2016 From: intelfx at intelfx.name (Ivan Shapovalov) Date: Wed, 17 Aug 2016 15:55:08 +0300 Subject: [CMake] Private dependencies of static libraries exported as targets In-Reply-To: References: <1471311153.20784.29.camel@intelfx.name> <1471314145.20784.33.camel@intelfx.name> <1471394666.4604.2.camel@intelfx.name> <1471425100.4604.7.camel@intelfx.name> Message-ID: <1471438508.32113.4.camel@intelfx.name> On 2016-08-17 at 05:19 -0500, Nicholas Braden wrote: > Huh, this is weird. It seems to be an issue with the export/import > mechanism. If you make a project where everything is in the same > CMakeLists.txt and there is no install step, there is no include > directory pollution. See my attached project for example. On my > system > I run this to build: > > mkdir build && cd build && cmake -G "MinGW Makefiles" .. && cmake > --build . -- VERBOSE=1 > > When it builds main: > > C:\MinGW\bin\g++.exe????@CMakeFiles/main.dir/includes_CXX.rsp > -std=gnu++14 -o CMakeFiles\main.dir\main.cpp.obj -c > C:\Users\LB\Code\cmake-private-static-dependencies\main.cpp > > The entirety of the includes_CXX.rsp file: > > -IC:/Users/LB/Code/cmake-private-static-dependencies/c > > The project you provided definitely has the include directory > pollution problem - the client includes_CXX.rsp file contains an > -isystem directive for bar. It looks like the generated > FooTargets-noconfig.cmake contains this line (setting properties on > foo): > > IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG "bar" > > I'm not fully sure but I think this is wrong because it is saying > that > bar is a public dependency. This seems to be an oversight in CMake, > as > there is no 'private' alternative of the above variable for imported > targets - that is, there is no IMPORTED_LINK_LIBRARIES_NOCONFIG, thus > there is no way for CMake to provide special treatment as in my > example. It seems CMake literally converts private dependencies of > static libraries to public dependencies only when using the export > functionality. > > ...and that's as much as I can figure right now. Can you confirm that > my attached example doesn't exhibit the problem? If it doesn't have > the include directory pollution problem, I'd be inclined to say it's > a > bug with the export/import functionality. Indeed, your sample project does not exhibit include path bloat. So this really looks like a limitation of CMake import/export mechanism (I say limitation, not bug, because there are simply no target properties detailed enough to allow this behavior). There is a property IMPORTED_LINK_DEPENDENT_LIBRARIES_ which is _almost_ what we want, but just for shared libraries. --? Ivan Shapovalov / intelfx / -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mike.jackson at bluequartz.net Wed Aug 17 20:31:52 2016 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Wed, 17 Aug 2016 20:31:52 -0400 Subject: [CMake] Example of using Visual Studio for Nightly Dashboard Message-ID: <57B501F8.70100@bluequartz.net> Can anyone point my to a project, including scripts etc, that shows how to use Visual Studio as the build mechanism for a Visual Fortran project? My Problem is the following: I am generating a Visual Studio with Intel Fortran compiler (v16.x) from CMake but when I load the resulting sln file into Visual Studio and compile the only thing that gets compiled are a few *.c files in the project and NOT the 100 actual *.f90 files. If I use NMake from the command line then I can actually invoke "nmake" and have my project properly compile. I am not sure what is going on or where the issue is. I also tried to use NMake from the command line but I am have no idea which environment and/or cmake variables I need to set in order for my batch file and .cmake file combination to actually get the Intel Fortran compiler set properly. I tried using "call ... " with the proper path to the Intel Fortran .bat file that lays out all the variables but it seems to just prematurely exit the command prompt and nothing gets configured or compiled. I can successfully configure a .sln file for my project during a "nightly" build but then the .sln does not actually compile any of the fortran source files. If anyone has any insight into these issues I would greatly appreciate the help. Thanks -- Michael A. Jackson BlueQuartz Software, LLC [e]: mike.jackson at bluequartz.net From tonka3100 at gmail.com Thu Aug 18 07:12:10 2016 From: tonka3100 at gmail.com (tonka tonka) Date: Thu, 18 Aug 2016 13:12:10 +0200 Subject: [CMake] CPack: Combine Debug and Release build In-Reply-To: References: Message-ID: Hey, I want to switch to cpack to build my zip, installer etc.. Everything works fine, but I am not able to get my debug build into my cpack end file. It will always use the release build, which is fine for end-user deployment but not for and sdk installer, because on windows I have to provide both build-configurations. Can anybody give me some advice what I can do to get such result? Thanks in advance Tonka -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamas.kenez at gmail.com Thu Aug 18 09:29:32 2016 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Thu, 18 Aug 2016 15:29:32 +0200 Subject: [CMake] Private dependencies of static libraries exported as targets In-Reply-To: <1471438508.32113.4.camel@intelfx.name> References: <1471311153.20784.29.camel@intelfx.name> <1471314145.20784.33.camel@intelfx.name> <1471394666.4604.2.camel@intelfx.name> <1471425100.4604.7.camel@intelfx.name> <1471438508.32113.4.camel@intelfx.name> Message-ID: Ivan, > But, if library `foo` is built as static, then its clients suddenly > become required to link to `bar` as well, and this information is not > recorded anywhere! I changed the cmake_minimum_required version in your projects from 2.8 to 3.0 which fixed the issue. (I tried it with cmake 3.6.1) Tamas On Wed, Aug 17, 2016 at 2:55 PM, Ivan Shapovalov wrote: > On 2016-08-17 at 05:19 -0500, Nicholas Braden wrote: > > Huh, this is weird. It seems to be an issue with the export/import > > mechanism. If you make a project where everything is in the same > > CMakeLists.txt and there is no install step, there is no include > > directory pollution. See my attached project for example. On my > > system > > I run this to build: > > > > mkdir build && cd build && cmake -G "MinGW Makefiles" .. && cmake > > --build . -- VERBOSE=1 > > > > When it builds main: > > > > C:\MinGW\bin\g++.exe @CMakeFiles/main.dir/includes_CXX.rsp > > -std=gnu++14 -o CMakeFiles\main.dir\main.cpp.obj -c > > C:\Users\LB\Code\cmake-private-static-dependencies\main.cpp > > > > The entirety of the includes_CXX.rsp file: > > > > -IC:/Users/LB/Code/cmake-private-static-dependencies/c > > > > The project you provided definitely has the include directory > > pollution problem - the client includes_CXX.rsp file contains an > > -isystem directive for bar. It looks like the generated > > FooTargets-noconfig.cmake contains this line (setting properties on > > foo): > > > > IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG "bar" > > > > I'm not fully sure but I think this is wrong because it is saying > > that > > bar is a public dependency. This seems to be an oversight in CMake, > > as > > there is no 'private' alternative of the above variable for imported > > targets - that is, there is no IMPORTED_LINK_LIBRARIES_NOCONFIG, thus > > there is no way for CMake to provide special treatment as in my > > example. It seems CMake literally converts private dependencies of > > static libraries to public dependencies only when using the export > > functionality. > > > > ...and that's as much as I can figure right now. Can you confirm that > > my attached example doesn't exhibit the problem? If it doesn't have > > the include directory pollution problem, I'd be inclined to say it's > > a > > bug with the export/import functionality. > > Indeed, your sample project does not exhibit include path bloat. So > this really looks like a limitation of CMake import/export mechanism > (I say limitation, not bug, because there are simply no target > properties detailed enough to allow this behavior). > > There is a property IMPORTED_LINK_DEPENDENT_LIBRARIES_ which is > _almost_ what we want, but just for shared libraries. > > -- > Ivan Shapovalov / intelfx / > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 tom.edwards at thefoundry.co.uk Thu Aug 18 11:26:01 2016 From: tom.edwards at thefoundry.co.uk (tom.edwards at thefoundry.co.uk) Date: Thu, 18 Aug 2016 16:26:01 +0100 Subject: [CMake] Installing a list of components Message-ID: <57b5d388.a719c20a.a5ed7.f102@mx.google.com> I?m working on an application which consists of many different components surrounding a common core. We ship multiple products from the same source tree by adding and/or removing components from the output application directory. Using CMake?s install system in this environment is proving difficult. I?ve managed to set things up so that all components are installed to the same place, which is fine for development but not suitable for testing or shipping. A proper solution would install only the components needed for an individual application. The new EXCLUDE_FROM_ALL option for the install command overcomes one of the biggest hurdles to reaching that goal. I can now add that option to every install command, generate a list of component names, and add a custom target for each application which invokes CMake and has it install only the relevant components. The problem now is that I can only install one component at a time, and that invoking CMake 200+ times to install them all individually is unacceptably slow. Looking at the install scripts CMake generates I see lines like this: > if("${CMAKE_INSTALL_COMPONENT}" STREQUAL "foobar" OR NOT CMAKE_INSTALL_COMPONENT) The install process would become much more flexible if STREQUAL were changed to IN_LIST. As far as I can see this change: a) has no performance penalty when the component value isn?t a list and b) would be backwards compatible unless an individual component name contained a semicolon (which seems an unlikely scenario). What do the developers think? -------------- next part -------------- An HTML attachment was scrubbed... URL: From laura at ucar.edu Thu Aug 18 11:27:43 2016 From: laura at ucar.edu (Laura Fowler) Date: Thu, 18 Aug 2016 09:27:43 -0600 Subject: [CMake] SecTrustEvaluateAsync != NULL Message-ID: Hello: This is my first post on the mailing list, so please bare with me. I would like to compile cmake on my machine, but I get the following error during the "make" step. /Users/LauraLaptop/InstalledSoftwares/sourcecode/cmake-3.6.1/Utilities/cmcurl/lib/vtls/darwinssl.c: In function ?darwinssl_connect_step3?: /Users/LauraLaptop/InstalledSoftwares/sourcecode/cmake-3.6.1/Utilities/cmcurl/lib/vtls/darwinssl.c:1999:6: error: ?SecTrustEvaluateAsync? undeclared (first use in this function) if(SecTrustEvaluateAsync != NULL) { ^ /Users/LauraLaptop/InstalledSoftwares/sourcecode/cmake-3.6.1/Utilities/cmcurl/lib/vtls/darwinssl.c:1999:6: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [Utilities/cmcurl/lib/CMakeFiles/cmcurl.dir/vtls/darwinssl.c.o] Error 1 make[1]: *** [Utilities/cmcurl/lib/CMakeFiles/cmcurl.dir/all] Error 2 make: *** [all] Error 2 I assume that ./bootstrap worked fine since it asked me to run "make" as the next step. My operating system is OS X El Capitan Version 10.11.6 and I am using gcc version 5.3. I apologize if that kind of error has been reported before. I am not sure as how to browse through previous posts. I will be glad to provide any additional files that you may need from my bootstrap step. Many thanks for our help. Cheers, Laura -- !------------------------------------------------------------------------------------------------------------- Laura D. Fowler Mesoscale and Microscale Meteorology Division (MMM) National Center for Atmospheric Research P.O. Box 3000, Boulder CO 80307-3000 e-mail: laura at ucar.edu phone: 303-497-1628 !------------------------------------------------------------------------------------------------------------- From mjklaim at gmail.com Thu Aug 18 11:32:13 2016 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Thu, 18 Aug 2016 17:32:13 +0200 Subject: [CMake] Installing a list of components In-Reply-To: <57b5d388.a719c20a.a5ed7.f102@mx.google.com> References: <57b5d388.a719c20a.a5ed7.f102@mx.google.com> Message-ID: On 18 August 2016 at 17:26, wrote: > I?m working on an application which consists of many different components > surrounding a common core. We ship multiple products from the same source > tree by adding and/or removing components from the output application > directory. > > > > Using CMake?s install system in this environment is proving difficult. > I?ve managed to set things up so that all components are installed to the > same place, which is fine for development but not suitable for testing or > shipping. A proper solution would install only the components needed for an > individual application. > > > > The new EXCLUDE_FROM_ALL option for the install command overcomes one of > the biggest hurdles to reaching that goal. I can now add that option to > every install command, generate a list of component names, and add a custom > target for each application which invokes CMake and has it install only the > relevant components. > > > > The problem now is that I can only install one component at a time, and > that invoking CMake 200+ times to install them all individually is > unacceptably slow. > > > > Looking at the install scripts CMake generates I see lines like this: > > > > > if("${CMAKE_INSTALL_COMPONENT}" STREQUAL "foobar" OR NOT > CMAKE_INSTALL_COMPONENT) > > > > The install process would become much more flexible if STREQUAL were > changed to IN_LIST. As far as I can see this change: a) has no performance > penalty when the component value isn?t a list and b) would be backwards > compatible unless an individual component name contained a semicolon (which > seems an unlikely scenario). > > > > What do the developers think? > > As a side note, I have pointed problems with similar setup, in particular when you want to be able to debug too just after a build, in a context which look like an installed app, with only the files necessary for the app. The discussion led to a ticket for a potential feature: https://gitlab.kitware.com/cmake/cmake/issues/15450 Discussion ended there: http://public.kitware.com/pipermail/cmake/2015-March/060120.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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Thu Aug 18 11:33:20 2016 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Thu, 18 Aug 2016 17:33:20 +0200 Subject: [CMake] Installing a list of components In-Reply-To: References: <57b5d388.a719c20a.a5ed7.f102@mx.google.com> Message-ID: On 18 August 2016 at 17:32, Klaim - Jo?l Lamotte wrote: > The discussion led to a ticket for a potential feature: https://gitlab. > kitware.com/cmake/cmake/issues/15450 > Discussion ended there: http://public.kitware.com/pipermail/cmake/2015- > March/060120.html > http://cmake.3232098.n2.nabble.com/List-all-binaries-associated-with-a-target-td7590021.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.edwards at thefoundry.co.uk Thu Aug 18 11:52:02 2016 From: tom.edwards at thefoundry.co.uk (tom.edwards at thefoundry.co.uk) Date: Thu, 18 Aug 2016 16:52:02 +0100 Subject: [CMake] Installing a list of components In-Reply-To: References: <57b5d388.a719c20a.a5ed7.f102@mx.google.com> Message-ID: <57b5d9a2.88cb1c0a.1eea1.10a2@mx.google.com> That was one of the other problems I encountered during the initial conversion to CMake. I fixed it by wrapping all the ADD_* commands with my own functions which override the target?s output directory. Now we only need to install if a script or static resource changes. From: Klaim - Jo?l Lamotte -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Aug 18 12:45:08 2016 From: sean at rogue-research.com (Sean McBride) Date: Thu, 18 Aug 2016 12:45:08 -0400 Subject: [CMake] SecTrustEvaluateAsync != NULL In-Reply-To: References: Message-ID: <20160818164508.217002013@mail.rogue-research.com> On Thu, 18 Aug 2016 09:27:43 -0600, Laura Fowler said: > >/Users/LauraLaptop/InstalledSoftwares/sourcecode/cmake-3.6.1/Utilities/ >cmcurl/lib/vtls/darwinssl.c:1999:6: >error: ?SecTrustEvaluateAsync? undeclared (first use in this function) > > if(SecTrustEvaluateAsync != NULL) { > > ^ If you look in SecTrust.h (where the SecTrustEvaluateAsync() API is declared), you'll see it's wrapped in #ifdef __BLOCKS__ Likely your complier (gcc 5.3) does not support blocks. Is there a reason you want to use gcc instead of the system complier (clang)? Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From clinton at elemtech.com Thu Aug 18 11:09:52 2016 From: clinton at elemtech.com (clinton at elemtech.com) Date: Thu, 18 Aug 2016 09:09:52 -0600 (MDT) Subject: [CMake] CPack: Combine Debug and Release build In-Reply-To: References: Message-ID: <1827798146.7924530.1471532992420.JavaMail.zimbra@elemtech.com> One thing I've done before is to tell cpack to bundle up 2 projects in one cpack session. One project is a debug build, and the other a release build. if ( CREATE_MULTI_CONFIG_PACKAGE ) set (CPACK_INSTALL_CMAKE_PROJECTS # self project " ${CMAKE_CURRENT_BINARY_DIR} ; ${CMAKE_PROJECT_NAME} ;ALL;/" # other project " ${DIR_TO_OTHER_PROJECT} ; ${CMAKE_PROJECT_NAME} ;ALL;/" ) endif () ----- On Aug 18, 2016, at 5:12 AM, tonka tonka wrote: > Hey, > I want to switch to cpack to build my zip, installer etc.. Everything works > fine, but I am not able to get my debug build into my cpack end file. It will > always use the release build, which is fine for end-user deployment but not for > and sdk installer, because on windows I have to provide both > build-configurations. > Can anybody give me some advice what I can do to get such result? > Thanks in advance > Tonka > -- > Powered by www.kitware.com > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > Visit other Kitware 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 laura at ucar.edu Thu Aug 18 14:44:37 2016 From: laura at ucar.edu (Laura Fowler) Date: Thu, 18 Aug 2016 12:44:37 -0600 Subject: [CMake] SecTrustEvaluateAsync != NULL In-Reply-To: <20160818164508.217002013@mail.rogue-research.com> References: <20160818164508.217002013@mail.rogue-research.com> Message-ID: Hi Sean: Many thanks for suggesting to use clang++. I was able to successfully compile cmake. Cheers, Laura On Thu, Aug 18, 2016 at 10:45 AM, Sean McBride wrote: > On Thu, 18 Aug 2016 09:27:43 -0600, Laura Fowler said: > >> >>/Users/LauraLaptop/InstalledSoftwares/sourcecode/cmake-3.6.1/Utilities/ >>cmcurl/lib/vtls/darwinssl.c:1999:6: >>error: ?SecTrustEvaluateAsync? undeclared (first use in this function) >> >> if(SecTrustEvaluateAsync != NULL) { >> >> ^ > > If you look in SecTrust.h (where the SecTrustEvaluateAsync() API is declared), you'll see it's wrapped in > > #ifdef __BLOCKS__ > > Likely your complier (gcc 5.3) does not support blocks. Is there a reason you want to use gcc instead of the system complier (clang)? > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada -- !------------------------------------------------------------------------------------------------------------- Laura D. Fowler Mesoscale and Microscale Meteorology Division (MMM) National Center for Atmospheric Research P.O. Box 3000, Boulder CO 80307-3000 e-mail: laura at ucar.edu phone: 303-497-1628 !------------------------------------------------------------------------------------------------------------- From d3ck0r at gmail.com Thu Aug 18 14:50:57 2016 From: d3ck0r at gmail.com (J Decker) Date: Thu, 18 Aug 2016 11:50:57 -0700 Subject: [CMake] howto retrigger check_function_exists Message-ID: I was trying to add some libraries for CMAKE_REQUIRED_LIBRARIES to be able to find more symbols, but changing that didn't cause the check_function-0exists to re-run; is there a shorter way to get it to re-run without deleting CMakeCache.txt? I'm not abject to manually editing files; I had tried to remove just the cached variable reference, but that didn't help. Same for check_type_size() I guess -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Thu Aug 18 15:24:25 2016 From: d3ck0r at gmail.com (J Decker) Date: Thu, 18 Aug 2016 12:24:25 -0700 Subject: [CMake] howto retrigger check_function_exists In-Reply-To: References: Message-ID: I don't understand how this works.... info_size[1] will return 'N' how will it know it has to pass like 14 arguments to get the right character? And even then the character '4' is not the value 4. - this is the code generated for check_type_size #include #include #include #include "time.h" #undef KEY #if defined(__i386) # define KEY '_','_','i','3','8','6' #elif defined(__x86_64) # define KEY '_','_','x','8','6','_','6','4' #elif defined(__ppc__) # define KEY '_','_','p','p','c','_','_' #elif defined(__ppc64__) # define KEY '_','_','p','p','c','6','4','_','_' #endif #define SIZE (sizeof(time_t)) char info_size[] = {'I', 'N', 'F', 'O', ':', 's','i','z','e','[', ('0' + ((SIZE / 10000)%10)), ('0' + ((SIZE / 1000)%10)), ('0' + ((SIZE / 100)%10)), ('0' + ((SIZE / 10)%10)), ('0' + (SIZE % 10)), ']', #ifdef KEY ' ','k','e','y','[', KEY, ']', #endif '\0'}; #ifdef __CLASSIC_C__ int main(argc, argv) int argc; char *argv[]; #else int main(int argc, char *argv[]) #endif { int require = 0; require += info_size[argc]; (void)argv; return require; } On Thu, Aug 18, 2016 at 11:50 AM, J Decker wrote: > I was trying to add some libraries for CMAKE_REQUIRED_LIBRARIES to be able > to find more symbols, but changing that didn't cause the > check_function-0exists to re-run; is there a shorter way to get it to > re-run without deleting CMakeCache.txt? > I'm not abject to manually editing files; I had tried to remove just the > cached variable reference, but that didn't help. > > Same for check_type_size() I guess > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Aug 18 15:48:12 2016 From: DLRdave at aol.com (David Cole) Date: Thu, 18 Aug 2016 15:48:12 -0400 Subject: [CMake] howto retrigger check_function_exists In-Reply-To: References: Message-ID: The code is not meant to be called. The "require += info_size" line is to keep compiler optimizations from stripping out the info_size string variable from the final executable. This code is simply built, and then the resulting binary is scanned for the string "INFO:size[xxxx],key[xxxx]" and then the string analyzed to pull out the size.... Does that make sense? D On Thu, Aug 18, 2016 at 3:24 PM, J Decker wrote: > I don't understand how this works.... > > info_size[1] will return 'N' > how will it know it has to pass like 14 arguments to get the right > character? And even then the character '4' is not the value 4. > > > > - this is the code generated for check_type_size > > #include > #include > #include > #include "time.h" > > > #undef KEY > #if defined(__i386) > # define KEY '_','_','i','3','8','6' > #elif defined(__x86_64) > # define KEY '_','_','x','8','6','_','6','4' > #elif defined(__ppc__) > # define KEY '_','_','p','p','c','_','_' > #elif defined(__ppc64__) > # define KEY '_','_','p','p','c','6','4','_','_' > #endif > > #define SIZE (sizeof(time_t)) > char info_size[] = {'I', 'N', 'F', 'O', ':', 's','i','z','e','[', > ('0' + ((SIZE / 10000)%10)), > ('0' + ((SIZE / 1000)%10)), > ('0' + ((SIZE / 100)%10)), > ('0' + ((SIZE / 10)%10)), > ('0' + (SIZE % 10)), > ']', > #ifdef KEY > ' ','k','e','y','[', KEY, ']', > #endif > '\0'}; > > #ifdef __CLASSIC_C__ > int main(argc, argv) int argc; char *argv[]; > #else > int main(int argc, char *argv[]) > #endif > { > int require = 0; > require += info_size[argc]; > (void)argv; > return require; > } > > > > > > > On Thu, Aug 18, 2016 at 11:50 AM, J Decker wrote: >> >> I was trying to add some libraries for CMAKE_REQUIRED_LIBRARIES to be able >> to find more symbols, but changing that didn't cause the >> check_function-0exists to re-run; is there a shorter way to get it to re-run >> without deleting CMakeCache.txt? >> I'm not abject to manually editing files; I had tried to remove just the >> cached variable reference, but that didn't help. >> >> Same for check_type_size() I guess > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 nicholas11braden at gmail.com Thu Aug 18 19:38:51 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Thu, 18 Aug 2016 18:38:51 -0500 Subject: [CMake] Private dependencies of static libraries exported as targets In-Reply-To: References: <1471311153.20784.29.camel@intelfx.name> <1471314145.20784.33.camel@intelfx.name> <1471394666.4604.2.camel@intelfx.name> <1471425100.4604.7.camel@intelfx.name> <1471438508.32113.4.camel@intelfx.name> Message-ID: Ah! When I do that, it also solves the include path bloat issue. No longer does `client` know about the include directory of `bar`. Seems it was a difference in minimum CMake version respecting old behavior. In FooTargets.cmake, I see this line: INTERFACE_LINK_LIBRARIES "\$" Awesome. Of course, this only helps Ivan if they can use CMake >= 3.0 - still good to know that the solution is simple. On Thu, Aug 18, 2016 at 8:29 AM, Tam?s Ken?z wrote: > Ivan, > >> But, if library `foo` is built as static, then its clients suddenly >> become required to link to `bar` as well, and this information is not >> recorded anywhere! > > I changed the cmake_minimum_required version in your projects from 2.8 to > 3.0 which fixed the issue. > (I tried it with cmake 3.6.1) > > Tamas > > On Wed, Aug 17, 2016 at 2:55 PM, Ivan Shapovalov > wrote: >> >> On 2016-08-17 at 05:19 -0500, Nicholas Braden wrote: >> > Huh, this is weird. It seems to be an issue with the export/import >> > mechanism. If you make a project where everything is in the same >> > CMakeLists.txt and there is no install step, there is no include >> > directory pollution. See my attached project for example. On my >> > system >> > I run this to build: >> > >> > mkdir build && cd build && cmake -G "MinGW Makefiles" .. && cmake >> > --build . -- VERBOSE=1 >> > >> > When it builds main: >> > >> > C:\MinGW\bin\g++.exe @CMakeFiles/main.dir/includes_CXX.rsp >> > -std=gnu++14 -o CMakeFiles\main.dir\main.cpp.obj -c >> > C:\Users\LB\Code\cmake-private-static-dependencies\main.cpp >> > >> > The entirety of the includes_CXX.rsp file: >> > >> > -IC:/Users/LB/Code/cmake-private-static-dependencies/c >> > >> > The project you provided definitely has the include directory >> > pollution problem - the client includes_CXX.rsp file contains an >> > -isystem directive for bar. It looks like the generated >> > FooTargets-noconfig.cmake contains this line (setting properties on >> > foo): >> > >> > IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG "bar" >> > >> > I'm not fully sure but I think this is wrong because it is saying >> > that >> > bar is a public dependency. This seems to be an oversight in CMake, >> > as >> > there is no 'private' alternative of the above variable for imported >> > targets - that is, there is no IMPORTED_LINK_LIBRARIES_NOCONFIG, thus >> > there is no way for CMake to provide special treatment as in my >> > example. It seems CMake literally converts private dependencies of >> > static libraries to public dependencies only when using the export >> > functionality. >> > >> > ...and that's as much as I can figure right now. Can you confirm that >> > my attached example doesn't exhibit the problem? If it doesn't have >> > the include directory pollution problem, I'd be inclined to say it's >> > a >> > bug with the export/import functionality. >> >> Indeed, your sample project does not exhibit include path bloat. So >> this really looks like a limitation of CMake import/export mechanism >> (I say limitation, not bug, because there are simply no target >> properties detailed enough to allow this behavior). >> >> There is a property IMPORTED_LINK_DEPENDENT_LIBRARIES_ which is >> _almost_ what we want, but just for shared libraries. >> >> -- >> Ivan Shapovalov / intelfx / >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 westion717 at gmail.com Fri Aug 19 05:14:22 2016 From: westion717 at gmail.com (Zeson Wu) Date: Fri, 19 Aug 2016 17:14:22 +0800 Subject: [CMake] latest cmake 3.6.1 building in AIX can not find symbol `.w32attrset` Message-ID: > > /usr/bin/g++ -Wl,-bnoipath -Wl,-brtl CMakeFiles/ccmake.dir/ > CursesDialog/cmCursesOptionsWidget.cxx.o CMakeFiles/ccmake.dir/ > CursesDialog/cmCursesBoolWidget.cxx.o CMakeFiles/ccmake.dir/CursesDialog/ > cmCursesCacheEntryComposite.cxx.o CMakeFiles/ccmake.dir/CursesDialog/cmCursesDummyWidget.cxx.o > CMakeFiles/ccmake.dir/CursesDialog/cmCursesFilePathWidget.cxx.o > CMakeFiles/ccmake.dir/CursesDialog/cmCursesForm.cxx.o > CMakeFiles/ccmake.dir/CursesDialog/cmCursesLabelWidget.cxx.o > CMakeFiles/ccmake.dir/CursesDialog/cmCursesLongMessageForm.cxx.o > CMakeFiles/ccmake.dir/CursesDialog/cmCursesMainForm.cxx.o > CMakeFiles/ccmake.dir/CursesDialog/cmCursesPathWidget.cxx.o > CMakeFiles/ccmake.dir/CursesDialog/cmCursesStringWidget.cxx.o > CMakeFiles/ccmake.dir/CursesDialog/cmCursesWidget.cxx.o > CMakeFiles/ccmake.dir/CursesDialog/ccmake.cxx.o -o ../bin/ccmake > -Wl,-bexpall libCMakeLib.a CursesDialog/form/libcmForm.a kwsys/libcmsys.a > ../Utilities/cmexpat/libcmexpat.a ../Utilities/cmlibarchive/libarchive/libcmlibarchive.a > ../Utilities/cmliblzma/libcmliblzma.a ../Utilities/cmbzip2/libcmbzip2.a > ../Utilities/cmcompress/libcmcompress.a ../Utilities/cmcurl/lib/libcmcurl.a > ../Utilities/cmzlib/libcmzlib.a -lld ../Utilities/cmjsoncpp/libcmjsoncpp.a > */usr/lib/libncurses.a* /opt/freeware/lib/gcc/powerpc- > ibm-aix7.1.0.0/4.9.2/libgcc_eh.a /opt/freeware/lib/gcc/powerpc- > ibm-aix7.1.0.0/4.9.2/libgcc_eh.a -Wl,-blibpath:/opt/freeware/ > lib/gcc/powerpc-ibm-aix7.1.0.0/4.9.2:/opt/freeware/lib:/usr/lib:/lib > ld: 0711-317 ERROR: Undefined symbol: .w32attrset > ld: 0711-317 ERROR: Undefined symbol: .w32insch > ld: 0711-317 ERROR: Undefined symbol: .w32addch > ld: 0711-317 ERROR: Undefined symbol: .w32attron > ld: 0711-317 ERROR: Undefined symbol: .w32attroff > ld: 0711-317 ERROR: Undefined symbol: .initscr32 > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more > information. > collect2: error: ld returned 8 exit status > > In AIX, it links with */usr/lib/libncurses.a* library which does not have such symbol. It should be */usr/lib/libcurses.a*. In AIX, it uses */usr/include/curses.h *and can not find ncurses.h in /usr/include. It must be something wrong with* Modules/FindCurses.cmake*. -- Zeson -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Bielik at dirac.com Fri Aug 19 05:18:14 2016 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Fri, 19 Aug 2016 09:18:14 +0000 Subject: [CMake] Suppressing policy warnings Message-ID: <2cdd84f6d04442b8ac082d63d7b440e1@hosted3-mb01.itm.host> Hi, I'm currently using CMake 3.5.0 and I get TONS of CMP0054 policy warnings. So I set the policy: cmake_policy(SET CMP0054 OLD) in top level CMakeLists.txt file. Nothing happens. I STILL get TONS of warnings. Help ? Regards /Robert From nilsgladitz at gmail.com Fri Aug 19 05:50:23 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 19 Aug 2016 11:50:23 +0200 Subject: [CMake] Suppressing policy warnings In-Reply-To: <2cdd84f6d04442b8ac082d63d7b440e1@hosted3-mb01.itm.host> References: <2cdd84f6d04442b8ac082d63d7b440e1@hosted3-mb01.itm.host> Message-ID: <6a7b21e8-fe1d-9f01-4f3e-5265969e04d3@gmail.com> On 08/19/2016 11:18 AM, Robert Bielik wrote: > Hi, > > I'm currently using CMake 3.5.0 and I get TONS of CMP0054 policy warnings. So I set the policy: > > cmake_policy(SET CMP0054 OLD) > > in top level CMakeLists.txt file. Nothing happens. I STILL get TONS of warnings. > > Help ? cmake_minimum_required(VERSION) resets all policies to match the given version. So either set the policy after any cmake_minimum_required(VERSION) call, or don't set this specific policy at all and increase your minimum required version to at least 3.1 (will implicitly set the policy to NEW), or fix (work around) the ambiguities that the policy warnings point to. Nils From intelfx at intelfx.name Fri Aug 19 08:06:32 2016 From: intelfx at intelfx.name (Ivan Shapovalov) Date: Fri, 19 Aug 2016 15:06:32 +0300 Subject: [CMake] Private dependencies of static libraries exported as targets In-Reply-To: References: <1471311153.20784.29.camel@intelfx.name> <1471314145.20784.33.camel@intelfx.name> <1471394666.4604.2.camel@intelfx.name> <1471425100.4604.7.camel@intelfx.name> <1471438508.32113.4.camel@intelfx.name> Message-ID: <1471608392.15556.0.camel@intelfx.name> That's very nice; thanks! --? Ivan Shapovalov / intelfx / On 2016-08-18 at 15:29 +0200, Tam?s Ken?z wrote: > Ivan, > > > > > But, if library `foo` is built as static, then its clients suddenly > > become required to link to `bar` as well, and this information is > > not > > recorded anywhere! > > I changed the cmake_minimum_required version in your projects from > 2.8 to > 3.0 which fixed the issue. > (I tried it with cmake 3.6.1) > > Tamas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From blowekamp at mail.nih.gov Fri Aug 19 08:06:21 2016 From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C]) Date: Fri, 19 Aug 2016 12:06:21 +0000 Subject: [CMake] test dependencies and CTest -I Message-ID: Hello, I am trying to get ctest working on CircleCI with multiple concurrent containers. The following command works for many cases: ctest -j 2 -I ${CIRCLE_NODE_INDEX},,${CIRCLE_NODE_TOTAL} unless there are dependencies specified between tests via something like: set_property(TEST B APPEND PROPERTY DEPENDS A) Then test B will still run even if test A has been run on the same node. Are there any suggestions to solve this problem? It would be nice to just split up the tests which have no dependencies, or always run the dependence of the test. Thanks, Brad From chuck.atkins at kitware.com Fri Aug 19 09:38:10 2016 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Fri, 19 Aug 2016 09:38:10 -0400 Subject: [CMake] latest cmake 3.6.1 building in AIX can not find symbol `.w32attrset` In-Reply-To: References: Message-ID: Hi Zeson, We do have a nightly build on AIX with both GCC and IBM XL. It does build correctly using curses instead ncurses, as you mention, but the machine we use doesn't have ncurses on it, only curses, so it doesn't have this problem of accidentally finding the wrong curses library. When configuring your build, try adding -DCURSES_NCURSES_LIBRARY=IGNORE to prevent FindCurses from picking the wrong one. ---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. On Fri, Aug 19, 2016 at 5:14 AM, Zeson Wu wrote: > /usr/bin/g++ -Wl,-bnoipath -Wl,-brtl CMakeFiles/ccmake.dir/CursesDi >> alog/cmCursesOptionsWidget.cxx.o CMakeFiles/ccmake.dir/CursesDialog/cmCursesBoolWidget.cxx.o >> CMakeFiles/ccmake.dir/CursesDialog/cmCursesCacheEntryComposite.cxx.o >> CMakeFiles/ccmake.dir/CursesDialog/cmCursesDummyWidget.cxx.o >> CMakeFiles/ccmake.dir/CursesDialog/cmCursesFilePathWidget.cxx.o >> CMakeFiles/ccmake.dir/CursesDialog/cmCursesForm.cxx.o >> CMakeFiles/ccmake.dir/CursesDialog/cmCursesLabelWidget.cxx.o >> CMakeFiles/ccmake.dir/CursesDialog/cmCursesLongMessageForm.cxx.o >> CMakeFiles/ccmake.dir/CursesDialog/cmCursesMainForm.cxx.o >> CMakeFiles/ccmake.dir/CursesDialog/cmCursesPathWidget.cxx.o >> CMakeFiles/ccmake.dir/CursesDialog/cmCursesStringWidget.cxx.o >> CMakeFiles/ccmake.dir/CursesDialog/cmCursesWidget.cxx.o >> CMakeFiles/ccmake.dir/CursesDialog/ccmake.cxx.o -o ../bin/ccmake >> -Wl,-bexpall libCMakeLib.a CursesDialog/form/libcmForm.a kwsys/libcmsys.a >> ../Utilities/cmexpat/libcmexpat.a ../Utilities/cmlibarchive/libarchive/libcmlibarchive.a >> ../Utilities/cmliblzma/libcmliblzma.a ../Utilities/cmbzip2/libcmbzip2.a >> ../Utilities/cmcompress/libcmcompress.a ../Utilities/cmcurl/lib/libcmcurl.a >> ../Utilities/cmzlib/libcmzlib.a -lld ../Utilities/cmjsoncpp/libcmjsoncpp.a >> */usr/lib/libncurses.a* /opt/freeware/lib/gcc/powerpc- >> ibm-aix7.1.0.0/4.9.2/libgcc_eh.a /opt/freeware/lib/gcc/powerpc- >> ibm-aix7.1.0.0/4.9.2/libgcc_eh.a -Wl,-blibpath:/opt/freeware/li >> b/gcc/powerpc-ibm-aix7.1.0.0/4.9.2:/opt/freeware/lib:/usr/lib:/lib >> ld: 0711-317 ERROR: Undefined symbol: .w32attrset >> ld: 0711-317 ERROR: Undefined symbol: .w32insch >> ld: 0711-317 ERROR: Undefined symbol: .w32addch >> ld: 0711-317 ERROR: Undefined symbol: .w32attron >> ld: 0711-317 ERROR: Undefined symbol: .w32attroff >> ld: 0711-317 ERROR: Undefined symbol: .initscr32 >> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more >> information. >> collect2: error: ld returned 8 exit status >> >> > In AIX, it links with */usr/lib/libncurses.a* library which does not have > such symbol. It should be */usr/lib/libcurses.a*. In AIX, it uses */usr/include/curses.h > *and can not find ncurses.h in /usr/include. It must be something wrong > with* Modules/FindCurses.cmake*. > > -- > Zeson > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dendy.ua at gmail.com Sat Aug 20 02:44:13 2016 From: dendy.ua at gmail.com (Daniel Levin) Date: Sat, 20 Aug 2016 02:44:13 -0400 Subject: [CMake] Adding dependencies for configuration stage Message-ID: CMake can automatically invoke configuration at build time when any dependency has been modified. For instance, after you edited CMakeLists.txt. Of when you used add_subdirectory() and edited nested CMakeLists.txt. Or if you have include("myscript.cmake") and modified myscript.cmake. I am curious which command in CMake can be used to add arbitrary dependency. For instance, I have python script which is executed at configuration stage with execute_process(). Obviously I want to trigger reconfiguration when this script was edited, since it is an essential part of the CMake script (just written in different language). -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sat Aug 20 07:15:58 2016 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 20 Aug 2016 21:15:58 +1000 Subject: [CMake] Adding dependencies for configuration stage In-Reply-To: References: Message-ID: Check out CMAKE_CONFIGURE_DEPENDS, I think it should do what you want: https://cmake.org/cmake/help/latest/prop_dir/CMAKE_CONFIGURE_DEPENDS.html On Saturday, 20 August 2016, Daniel Levin wrote: > CMake can automatically invoke configuration at build time when any > dependency has been modified. For instance, after you edited > CMakeLists.txt. Of when you used add_subdirectory() and edited nested > CMakeLists.txt. Or if you have include("myscript.cmake") and modified > myscript.cmake. > > I am curious which command in CMake can be used to add arbitrary > dependency. For instance, I have python script which is executed at > configuration stage with execute_process(). Obviously I want to trigger > reconfiguration when this script was edited, since it is an essential part > of the CMake script (just written in different language). > -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sat Aug 20 20:32:54 2016 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 21 Aug 2016 10:32:54 +1000 Subject: [CMake] Setup/tear down steps for CTest Message-ID: Let's say a project defines a bunch of tests which require setup and tear down steps before/after all the tests are run (not each individual test, I'm talking here about one setup before all tests are run and one tear down after all tests have finished). While this could be done by a script driving CTest itself, it is less desirable since different platforms may need different driver scripts and this seems like something CTest should be able to handle itself (if the setup/tear down steps use parts of the build, that only strengthens the case to have them handled by CMake/CTest directly). It is possible to abuse the DEPENDS test property and define setup and tear down "tests" which are not really tests but which perform the necessary steps. While this mostly works, it is not ideal and in particular it doesn't work with CTest's --rerun-failed option. I'm wondering if there's currently a better way of telling CMake/CTest about a setup step which must be run before some particular set of test cases and a tear down step after they are all done. The tear down step needs to be performed regardless of whether any of the real test cases pass or fail. The motivating case is to start up and shutdown a service which a (subset of) test cases need running. That service is expensive to set up and hence it isn't feasible to start it up and shut it down for every test case individually. Any ideas? -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From yaronct at gmail.com Sun Aug 21 03:24:10 2016 From: yaronct at gmail.com (Yaron Cohen-Tal) Date: Sun, 21 Aug 2016 10:24:10 +0300 Subject: [CMake] Creating dependencies between static imported targets. Message-ID: Hi, Using ""target_link_libraries" between static libraries is allowed, however doing it with static imported targets fails with: "Cannot specify link libraries for target "" which is not built by this project. However, this is necessary in order to define dependencies between the targets, which is necessary when solving dependencies (when those targets are eventually linked into e.g. an executable built by the project). How, then, can I create dependencies between imported targets? Thanx, Yaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ch.Ehrlicher at gmx.de Sun Aug 21 05:37:11 2016 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Sun, 21 Aug 2016 11:37:11 +0200 Subject: [CMake] Creating dependencies between static imported targets. In-Reply-To: References: Message-ID: Am 21.08.2016 um 09:24 schrieb Yaron Cohen-Tal: > Hi, > > Using ""target_link_libraries" between static libraries is allowed, > however doing it with static imported targets fails with: > > "Cannot specify link libraries for target "" which is not > built by this project. > > However, this is necessary in order to define dependencies between the > targets, which is necessary when solving dependencies (when those > targets are eventually linked into e.g. an executable built by the > project). How, then, can I create dependencies between imported targets? INTERFACE_LINK_LIBRARIES is what you're looking for. See also https://cmake.org/cmake/help/v3.5/manual/cmake-buildsystem.7.html#imported-targets for more information. HTH, Christian From DLRdave at aol.com Sun Aug 21 09:41:44 2016 From: DLRdave at aol.com (David Cole) Date: Sun, 21 Aug 2016 09:41:44 -0400 Subject: [CMake] Setup/tear down steps for CTest In-Reply-To: References: Message-ID: The best thing to do would be to add the feature to ctest, and contribute to the CMake community. I, too, use the "run this test first" and "that test last" technique, and set up DEPENDS property values to ensure ordering when all tests are run in parallel. However, as you noted, this does not work to run subsets of tests reliably. For me, I am able to live with the partial solution because the vast majority of my tests can be run independently anyhow and we usually do run all the tests, but a setup / teardown step for the whole suite would be a welcome addition to ctest. Looking forward to your patch... :-) David C. On Sat, Aug 20, 2016 at 8:32 PM, Craig Scott wrote: > Let's say a project defines a bunch of tests which require setup and tear > down steps before/after all the tests are run (not each individual test, I'm > talking here about one setup before all tests are run and one tear down > after all tests have finished). While this could be done by a script driving > CTest itself, it is less desirable since different platforms may need > different driver scripts and this seems like something CTest should be able > to handle itself (if the setup/tear down steps use parts of the build, that > only strengthens the case to have them handled by CMake/CTest directly). > > It is possible to abuse the DEPENDS test property and define setup and tear > down "tests" which are not really tests but which perform the necessary > steps. While this mostly works, it is not ideal and in particular it doesn't > work with CTest's --rerun-failed option. I'm wondering if there's currently > a better way of telling CMake/CTest about a setup step which must be run > before some particular set of test cases and a tear down step after they are > all done. The tear down step needs to be performed regardless of whether any > of the real test cases pass or fail. > > The motivating case is to start up and shutdown a service which a (subset > of) test cases need running. That service is expensive to set up and hence > it isn't feasible to start it up and shut it down for every test case > individually. > > Any ideas? > > -- > 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 From yaronct at gmail.com Sun Aug 21 10:23:25 2016 From: yaronct at gmail.com (Yaron Cohen-Tal) Date: Sun, 21 Aug 2016 17:23:25 +0300 Subject: [CMake] Creating dependencies between static imported targets. In-Reply-To: References: Message-ID: Thanx! I think it would b nice though if the "target_XXX" commands would also work for imported targets, e.g.. by adding the dependency to "INTERFACE_LINK_LIBRARIES'. That way I sometimes can use the same command without checking if the depentent is imported. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgolubev.public at gmail.com Sun Aug 21 11:14:05 2016 From: dgolubev.public at gmail.com (Denis G.) Date: Sun, 21 Aug 2016 15:14:05 +0000 Subject: [CMake] Error message of `cmake --verbose -E copy` is misleading Message-ID: Hello, While working with `cmake -E copy` (in a custom command for copying Qt's qml files to the output directory) and diagnosing a problem in my CMakeLists.txt with it, I discovered some misleading error messages. The following examples are used outside of any CMake project for simplification. $ cmake -E copy_if_different non_existant_source.txt target.txt Error copying file (if different) from "non_existant_source.txt" to "target.txt". In the original error message without any additional flags, there was not enough information for me to determine which location was missing (without looking into the directories manually). The easiest was to use some kind of verbose output: $ cmake --verbose -E copy non_existant_source.txt target.txt CMake Error: The source directory "/tmp/target.txt" does not exist. Specify --help for usage, or press the help button on the CMake GUI. The error message references the target location instead of the source location. It is the same for `copy` and `copy_directory`. Furthermore "source directory" is only correct for `copy_directory`. The usage output for `copy` when using `cmake -E` indicates that the first parameter is the source. If the source file exists, copying fails, when the `--verbose` flag is given: $ touch source.txt $ cmake --verbose -E copy_if_different source.txt target.txt CMake Error: The source directory "/tmp/target.txt" is a file, not a directory. Specify --help for usage, or press the help button on the CMake GUI. I could not find anything about `--verbose` in the man page of CMake, is this an official flag? If not, are there any flags I can use for diagnosing such problems in the future? Does it interfere with the `cmake -E` invocation or should I file an issue? I am using CMake 3.6.1 on Arch Linux (package version is "3.6.1-1"). A project as a SSCCE: $ tree . ??? CMakeLists.txt ??? main.cc $ cat main.cc # empty source file $ cat CMakeLists.txt cmake_minimum_required(VERSION 3.6) project(cmake-copy-issue) set(OUT_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/out.txt) # In the custom command I intentionally used the wrong source file and not the file which is given in DEPENDS. # This is the issue I was previously having and how I discovered this error messages. I already added `--verbose` here. add_custom_command( OUTPUT ${OUT_LOCATION} COMMAND ${CMAKE_COMMAND} --verbose -E copy non_existant_file.txt ${OUT_LOCATION} DEPENDS main.cc COMMENT "Copying..." VERBATIM ) add_executable(test_target main.cc ${OUT_LOCATION}) $ cd .. $ mkdir cmake-copy-issue-build $ cd cmake-copy-issue-build $ cmake ../cmake-copy-issue [...] $ make [ 33%] Copying... CMake Error: The source directory "/path/to/project/parent/directory/cmake-copy-issue-build/out.txt" does not exist. Specify --help for usage, or press the help button on the CMake GUI. make[2]: *** [CMakeFiles/test_target.dir/build.make:62: out.txt] Error 1 make[1]: *** [CMakeFiles/Makefile2:67: CMakeFiles/test_target.dir/all] Error 2 make: *** [Makefile:84: all] Error 2 Regards, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamas.kenez at gmail.com Sun Aug 21 14:52:52 2016 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Sun, 21 Aug 2016 20:52:52 +0200 Subject: [CMake] Creating dependencies between static imported targets. In-Reply-To: References: Message-ID: Defining the dependencies of an imported target should be done by the target's config-module (or a file invoked by the config-module, usually generated with install(EXPORT...) ) On Sun, Aug 21, 2016 at 4:23 PM, Yaron Cohen-Tal wrote: > Thanx! > > I think it would b nice though if the "target_XXX" commands would also > work for imported targets, e.g.. by adding the dependency to > "INTERFACE_LINK_LIBRARIES'. That way I sometimes can use the same command > without checking if the depentent is imported. > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yaronct at gmail.com Sun Aug 21 14:56:12 2016 From: yaronct at gmail.com (Yaron Cohen-Tal) Date: Sun, 21 Aug 2016 21:56:12 +0300 Subject: [CMake] Creating dependencies between static imported targets. In-Reply-To: References: Message-ID: That would have been ideal, however it seems to me not many packages ship with cmake config module files.. On Sun, Aug 21, 2016 at 9:52 PM, Tam?s Ken?z wrote: > Defining the dependencies of an imported target should be done by the > target's config-module (or a file invoked by the config-module, usually > generated with install(EXPORT...) ) > > On Sun, Aug 21, 2016 at 4:23 PM, Yaron Cohen-Tal > wrote: > >> Thanx! >> >> I think it would b nice though if the "target_XXX" commands would also >> work for imported targets, e.g.. by adding the dependency to >> "INTERFACE_LINK_LIBRARIES'. That way I sometimes can use the same command >> without checking if the depentent is imported. >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 tamas.kenez at gmail.com Sun Aug 21 17:59:37 2016 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Sun, 21 Aug 2016 23:59:37 +0200 Subject: [CMake] Creating dependencies between static imported targets. In-Reply-To: References: Message-ID: In my company we're doing this all the time: cmakefying thirdparty packages. Which means one of these things: (1) fixing existing cmake support (2) converting autotools build to cmake (3) adding cmake driver to autotools build. On Sun, Aug 21, 2016 at 8:56 PM, Yaron Cohen-Tal wrote: > That would have been ideal, however it seems to me not many packages ship > with cmake config module files.. > > On Sun, Aug 21, 2016 at 9:52 PM, Tam?s Ken?z > wrote: > >> Defining the dependencies of an imported target should be done by the >> target's config-module (or a file invoked by the config-module, usually >> generated with install(EXPORT...) ) >> >> On Sun, Aug 21, 2016 at 4:23 PM, Yaron Cohen-Tal >> wrote: >> >>> Thanx! >>> >>> I think it would b nice though if the "target_XXX" commands would also >>> work for imported targets, e.g.. by adding the dependency to >>> "INTERFACE_LINK_LIBRARIES'. That way I sometimes can use the same command >>> without checking if the depentent is imported. >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware 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 tonka3100 at gmail.com Mon Aug 22 03:27:13 2016 From: tonka3100 at gmail.com (tonka tonka) Date: Mon, 22 Aug 2016 09:27:13 +0200 Subject: [CMake] Wrong version of cl.exe for x64 Message-ID: Hey, I have recently switched to cmake (instead of plain visual studio). Now i discovered a problem.cmake choose the wrong cl.exe for my x64 project. Cmake choose bin/x86_amd64/cl.exe which is the ?x64 Cross Tools?. This create x64 binaries, but with my big project I reach a out of memory linker error, because the cl.exe is wrong (this cl.exe is an 32bit compiler which can create x64 binaries). Cmake should choose bin/amd64/cl.exe to use a ?real? x64 compiler. Does anybody know how I can tell cmake to do that? Compiler: visual studio 2010 sp1 OS: win 7 x64 Cmake: 3.4.3 Greetings Tonka -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristianonline28 at gmail.com Mon Aug 22 03:50:22 2016 From: kristianonline28 at gmail.com (Kristian) Date: Mon, 22 Aug 2016 09:50:22 +0200 Subject: [CMake] Wrong version of cl.exe for x64 In-Reply-To: References: Message-ID: Did you already tried to use the "Visual Studio 10 2010 Win64" generator? * https://cmake.org/cmake/help/v3.6/generator/Visual%20Studio%2010%202010.html * https://cmake.org/cmake/help/v3.6/manual/cmake-generators.7.html 2016-08-22 9:27 GMT+02:00 tonka tonka : > Hey, > > I have recently switched to cmake (instead of plain visual studio). > Now i discovered a problem.cmake choose the wrong cl.exe for my x64 > project. > Cmake choose bin/x86_amd64/cl.exe which is the ?x64 Cross Tools?. This > create x64 binaries, but with my big project I reach a out of memory linker > error, because the cl.exe is wrong (this cl.exe is an 32bit compiler which > can create x64 binaries). > Cmake should choose bin/amd64/cl.exe to use a ?real? x64 compiler. > > Does anybody know how I can tell cmake to do that? > > Compiler: visual studio 2010 sp1 > OS: win 7 x64 > Cmake: 3.4.3 > > Greetings > Tonka > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 tonka3100 at gmail.com Mon Aug 22 03:54:21 2016 From: tonka3100 at gmail.com (tonka tonka) Date: Mon, 22 Aug 2016 09:54:21 +0200 Subject: [CMake] Wrong version of cl.exe for x64 In-Reply-To: References: Message-ID: Yes, i definitely choose the Win64 version. Am 22.08.2016 09:50 schrieb "Kristian" : > Did you already tried to use the "Visual Studio 10 2010 Win64" generator? > > * https://cmake.org/cmake/help/v3.6/generator/Visual% > 20Studio%2010%202010.html > * https://cmake.org/cmake/help/v3.6/manual/cmake-generators.7.html > > 2016-08-22 9:27 GMT+02:00 tonka tonka : > >> Hey, >> >> I have recently switched to cmake (instead of plain visual studio). >> Now i discovered a problem.cmake choose the wrong cl.exe for my x64 >> project. >> Cmake choose bin/x86_amd64/cl.exe which is the ?x64 Cross Tools?. This >> create x64 binaries, but with my big project I reach a out of memory linker >> error, because the cl.exe is wrong (this cl.exe is an 32bit compiler which >> can create x64 binaries). >> Cmake should choose bin/amd64/cl.exe to use a ?real? x64 compiler. >> >> Does anybody know how I can tell cmake to do that? >> >> Compiler: visual studio 2010 sp1 >> OS: win 7 x64 >> Cmake: 3.4.3 >> >> Greetings >> Tonka >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 nilsgladitz at gmail.com Mon Aug 22 04:01:24 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 22 Aug 2016 10:01:24 +0200 Subject: [CMake] Wrong version of cl.exe for x64 In-Reply-To: References: Message-ID: <3ba5ce3d-dcd1-e170-4e1a-cdfe52c3d5ad@gmail.com> On 08/22/2016 09:27 AM, tonka tonka wrote: > Hey, > > I have recently switched to cmake (instead of plain visual studio). > Now i discovered a problem.cmake choose the wrong cl.exe for my x64 > project. > I don't think CMake chooses the compiler when using the visual studio generators. Visual Studio chooses and CMake just records that choice in CMAKE__COMPILER. Nils From lp.cordier at dynamixyz.com Mon Aug 22 04:28:03 2016 From: lp.cordier at dynamixyz.com (Louis-Paul CORDIER) Date: Mon, 22 Aug 2016 10:28:03 +0200 Subject: [CMake] target_link_libraries and flags issue with Visual Studio In-Reply-To: References: <7747c153-4986-12a7-01dd-d49c8ef0cb31@dynamixyz.com> Message-ID: <03364b5d-214d-9c06-1a85-49e1dd7d7d82@dynamixyz.com> Dear Guillaume, Thank you for the suggestion. Unfortunately, it seems this option does not fill the linker property of the linking project. Otherwise, it seems that STATIC_LIBRARY_FLAGS is adding the link properties to the 'librarian': set_target_properties(lib_project PROPERTIES STATIC_LIBRARY_FLAGS "-level='requireAdministrator' -uiAccess='false'") Any other suggestions? Thanks! LP Le 08/08/2016 ? 02:45, Guillaume Dumont a ?crit : > Hi, > > You can use the LINK_FLAGS or LINK_FLAGS_ for this: > > https://cmake.org/cmake/help/v3.6/prop_tgt/LINK_FLAGS.html > > Have you tried that? > > Guillaume > > On Wed, Aug 3, 2016 at 7:02 AM, Louis-Paul CORDIER > > wrote: > > ase not t > > > > > > -- > Guillaume Dumont > ========================= > dumont.guillaume at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Mon Aug 22 04:28:40 2016 From: d3ck0r at gmail.com (J Decker) Date: Mon, 22 Aug 2016 01:28:40 -0700 Subject: [CMake] Wrong version of cl.exe for x64 In-Reply-To: <3ba5ce3d-dcd1-e170-4e1a-cdfe52c3d5ad@gmail.com> References: <3ba5ce3d-dcd1-e170-4e1a-cdfe52c3d5ad@gmail.com> Message-ID: Maybe you need a diferent parameter to vcvarsall before running cmake https://msdn.microsoft.com/en-us/library/x4d2c09s.aspx On Mon, Aug 22, 2016 at 1:01 AM, Nils Gladitz wrote: > On 08/22/2016 09:27 AM, tonka tonka wrote: > > Hey, >> >> I have recently switched to cmake (instead of plain visual studio). >> Now i discovered a problem.cmake choose the wrong cl.exe for my x64 >> project. >> >> > I don't think CMake chooses the compiler when using the visual studio > generators. > Visual Studio chooses and CMake just records that choice in > CMAKE__COMPILER. > > Nils > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Aug 22 04:33:46 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 22 Aug 2016 10:33:46 +0200 Subject: [CMake] Wrong version of cl.exe for x64 In-Reply-To: References: <3ba5ce3d-dcd1-e170-4e1a-cdfe52c3d5ad@gmail.com> Message-ID: On 08/22/2016 10:28 AM, J Decker wrote: > Maybe you need a diferent parameter to vcvarsall before running cmake > > https://msdn.microsoft.com/en-us/library/x4d2c09s.aspx > The visual studio command line environments should have no effect when using the visual studio generators. They should only be relevant when you use one of the command line generators (e.g. makefiles or ninja). Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Mon Aug 22 04:36:27 2016 From: d3ck0r at gmail.com (J Decker) Date: Mon, 22 Aug 2016 01:36:27 -0700 Subject: [CMake] Wrong version of cl.exe for x64 In-Reply-To: References: <3ba5ce3d-dcd1-e170-4e1a-cdfe52c3d5ad@gmail.com> Message-ID: On Mon, Aug 22, 2016 at 1:33 AM, Nils Gladitz wrote: > On 08/22/2016 10:28 AM, J Decker wrote: > > Maybe you need a diferent parameter to vcvarsall before running cmake > > https://msdn.microsoft.com/en-us/library/x4d2c09s.aspx > > > > How to: Enable a 64-Bit Visual C++ Toolset on the Command Line > > > To run vcvarsall.bat to use a 64-bit toolset > > 1. > > At the command prompt, change to the Visual C++ installation > directory. (The location depends on the system and the Visual Studio > installation, but a typical location is C:\Program Files (x86)\Microsoft > Visual Studio *version*\VC\.) For example, enter: > > To configure this Command Prompt window for 64-bit command-line builds that target x86 platforms, at the command prompt, enter: *vcvarsall amd64_x86* *shjrug* the article spells it out. > > The visual studio command line environments should have no effect when > using the visual studio generators. > They should only be relevant when you use one of the command line > generators (e.g. makefiles or ninja). > > Nils > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonka3100 at gmail.com Mon Aug 22 05:22:01 2016 From: tonka3100 at gmail.com (tonka tonka) Date: Mon, 22 Aug 2016 11:22:01 +0200 Subject: [CMake] Wrong version of cl.exe for x64 In-Reply-To: References: <3ba5ce3d-dcd1-e170-4e1a-cdfe52c3d5ad@gmail.com> Message-ID: Does cmake call vcvarall.bat itself? Always call vcvarall.bat before cmake itself is not really a nice solution. Setting/override CMAKE_CXX_COMPILER to the x64 toolchain could work, but it depends on the question ?does cmake call vcvarall.bat internally? Am 22.08.2016 10:36 schrieb "J Decker" : > > > On Mon, Aug 22, 2016 at 1:33 AM, Nils Gladitz > wrote: > >> On 08/22/2016 10:28 AM, J Decker wrote: >> >> Maybe you need a diferent parameter to vcvarsall before running cmake >> >> https://msdn.microsoft.com/en-us/library/x4d2c09s.aspx >> >> > >> How to: Enable a 64-Bit Visual C++ Toolset on the Command Line >> >> >> To run vcvarsall.bat to use a 64-bit toolset >> >> 1. >> >> At the command prompt, change to the Visual C++ installation >> directory. (The location depends on the system and the Visual Studio >> installation, but a typical location is C:\Program Files (x86)\Microsoft >> Visual Studio *version*\VC\.) For example, enter: >> >> To configure this Command Prompt window for 64-bit command-line builds > that target x86 platforms, at the command prompt, enter: > *vcvarsall amd64_x86* > > *shjrug* the article spells it out. > >> >> The visual studio command line environments should have no effect when >> using the visual studio generators. >> They should only be relevant when you use one of the command line >> generators (e.g. makefiles or ninja). >> >> Nils >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From AlbrechtS.fltk at online.de Mon Aug 22 06:18:15 2016 From: AlbrechtS.fltk at online.de (Albrecht Schlosser) Date: Mon, 22 Aug 2016 12:18:15 +0200 Subject: [CMake] Wrong version of cl.exe for x64 In-Reply-To: References: <3ba5ce3d-dcd1-e170-4e1a-cdfe52c3d5ad@gmail.com> Message-ID: <66e4994f-e998-8498-5330-c1f99c245006@online.de> On 22.08.2016 10:33 Nils Gladitz wrote: > The visual studio command line environments should have no effect when > using the visual studio generators. Are you sure? Or what does "should" mean here? ;-) I know of a case where running CMake (3.2.1) from the installed desktop link does not find some headers that are found if I run CMake from within a "Developer Command Prompt for VS2015". Note: I did not use vcvarsall.bat explicitly. Shall I post an example CMake file? From nilsgladitz at gmail.com Mon Aug 22 06:54:20 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 22 Aug 2016 12:54:20 +0200 Subject: [CMake] Wrong version of cl.exe for x64 In-Reply-To: <66e4994f-e998-8498-5330-c1f99c245006@online.de> References: <3ba5ce3d-dcd1-e170-4e1a-cdfe52c3d5ad@gmail.com> <66e4994f-e998-8498-5330-c1f99c245006@online.de> Message-ID: <15a23535-2d4f-fc6f-c243-c35ed3213398@gmail.com> On 08/22/2016 12:18 PM, Albrecht Schlosser wrote: > On 22.08.2016 10:33 Nils Gladitz wrote: > >> The visual studio command line environments should have no effect when >> using the visual studio generators. > > Are you sure? Or what does "should" mean here? ;-) Yes. The Visual Studio generators are meant to work outside of the visual studio command line environments while the command line generators (makefiles, ninja) are meant to work from within the visual studio command line environment. What that means is that the Visual Studio generators must work without it. You can of course create manual dependencies from your project e.g. when you manually run "cl" from a custom command but such use should obviously be avoided since it is non-obvious and there is nothing that prevents you from running e.g. the x86 environment while your visual studio solution (which will ignore that environment) is targeting amd64. Nils From AlbrechtS.fltk at online.de Mon Aug 22 07:30:02 2016 From: AlbrechtS.fltk at online.de (Albrecht Schlosser) Date: Mon, 22 Aug 2016 13:30:02 +0200 Subject: [CMake] Wrong version of cl.exe for x64 In-Reply-To: <15a23535-2d4f-fc6f-c243-c35ed3213398@gmail.com> References: <3ba5ce3d-dcd1-e170-4e1a-cdfe52c3d5ad@gmail.com> <66e4994f-e998-8498-5330-c1f99c245006@online.de> <15a23535-2d4f-fc6f-c243-c35ed3213398@gmail.com> Message-ID: <988c5670-28e1-59d6-8cf9-8bfeab3001ed@online.de> On 22.08.2016 12:54 Nils Gladitz wrote: > On 08/22/2016 12:18 PM, Albrecht Schlosser wrote: > >> On 22.08.2016 10:33 Nils Gladitz wrote: >> >>> The visual studio command line environments should have no effect when >>> using the visual studio generators. >> >> Are you sure? Or what does "should" mean here? ;-) > > Yes. The Visual Studio generators are meant to work outside of the > visual studio command line environments while the command line > generators (makefiles, ninja) are meant to work from within the visual > studio command line environment. > > What that means is that the Visual Studio generators must work without it. Okay, I posted a simple example CMake file to show what happens in my case. See new thread: "Visual Studio generator does not find some header files" Basically some special (SDK?) header files are not found when executing CMake w/o the Visual Studio environment. From AlbrechtS.fltk at online.de Mon Aug 22 07:29:24 2016 From: AlbrechtS.fltk at online.de (Albrecht Schlosser) Date: Mon, 22 Aug 2016 13:29:24 +0200 Subject: [CMake] Visual Studio generator does not find some header files Message-ID: I found an inconsistency when executing CMake directly from a desktop link vs. running it for instance from a "Developer Command Prompt for VS2015" _or_ executing CMake's (re)configure stage from within the Visual Studio environment after modifying one of the CMake files. This seems to indicate that "something" is not set up correctly if I execute CMake directly (clicking the desktop link or running it from the Windows Explorer). On 22.08.2016 12:54 Nils Gladitz wrote in another thread: > The Visual Studio generators are meant to work outside of the > visual studio command line environments while the command line > generators (makefiles, ninja) are meant to work from within the visual > studio command line environment. > > What that means is that the Visual Studio generators must work > without it. The following example CMakeLists.txt file seems to indicate that this is not true, at least for CMake 3.2.1. I'm currently not keen on installing another (newer) CMake version, but if this is fixed in a newer version I can do this. System: Windows 10 Visual Studio 2015 Community 2015, Update 3 CMake 3.2.1 Here is my minimal CMakeLists.txt that is needed to run the configure step and show the results. Note that "other" header files are found w/o issues. I can provide more (with a configure_file) if requested. #------------------------------------- # CMakeLists.txt #------------------------------------- cmake_minimum_required(VERSION 2.8) project (find_headers) find_file (HAVE_GL_GL_H GL/gl.h) find_file (HAVE_GL_GLU_H GL/glu.h) find_file (HAVE_LOCALE_H locale.h) if (MSVC) message(STATUS "Note: The following three headers should all be found!") message(STATUS "HAVE_GL_GL_H = '${HAVE_GL_GL_H}'") message(STATUS "HAVE_GL_GLU_H = '${HAVE_GL_GLU_H}'") message(STATUS "HAVE_LOCALE_H = '${HAVE_LOCALE_H}'") message(STATUS "If one of these headers was not found, run cmake-gui ...") message(STATUS "... again from a Visual Studio developer command prompt!") endif (MSVC) #------------------------------------- # End of CMakeLists.txt #------------------------------------- # Run cmake-gui directly by clicking the installed desktop link # to the cmake-gui executable # Click 'configure' The C compiler identification is MSVC 19.0.24213.1 The CXX compiler identification is MSVC 19.0.24213.1 Check for working C compiler using: Visual Studio 14 2015 Win64 Check for working C compiler using: Visual Studio 14 2015 Win64 -- works Detecting C compiler ABI info Detecting C compiler ABI info - done Check for working CXX compiler using: Visual Studio 14 2015 Win64 Check for working CXX compiler using: Visual Studio 14 2015 Win64 -- works Detecting CXX compiler ABI info Detecting CXX compiler ABI info - done Detecting CXX compile features Detecting CXX compile features - done Note: The following three headers should all be found! HAVE_GL_GL_H = 'HAVE_GL_GL_H-NOTFOUND' HAVE_GL_GLU_H = 'HAVE_GL_GLU_H-NOTFOUND' HAVE_LOCALE_H = 'HAVE_LOCALE_H-NOTFOUND' If one of these headers was not found, run cmake-gui ... ... again from a Visual Studio developer command prompt! Configuring done # Repeating configure ... Note: The following three headers should all be found! HAVE_GL_GL_H = 'HAVE_GL_GL_H-NOTFOUND' HAVE_GL_GLU_H = 'HAVE_GL_GLU_H-NOTFOUND' HAVE_LOCALE_H = 'HAVE_LOCALE_H-NOTFOUND' If one of these headers was not found, run cmake-gui ... ... again from a Visual Studio developer command prompt! Configuring done # Now executing "Developer Command Prompt for VS2015" C:\Program Files (x86)\Microsoft Visual Studio 14.0>c:\CMake\bin\cmake.exe --version cmake version 3.2.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). C:\Program Files (x86)\Microsoft Visual Studio 14.0>c:\CMake\bin\cmake-gui.exe # Clicking 'configure' in the same build directory configured before: Note: The following three headers should all be found! HAVE_GL_GL_H = 'C:/Program Files (x86)/Windows Kits/8.1/Include/um/GL/gl.h' HAVE_GL_GLU_H = 'C:/Program Files (x86)/Windows Kits/8.1/Include/um/GL/glu.h' HAVE_LOCALE_H = 'C:/Program Files (x86)/Windows Kits/10/Include/10.0.10240.0/ucrt/locale.h' If one of these headers was not found, run cmake-gui ... ... again from a Visual Studio developer command prompt! Configuring done # End of log As you can see, CMake finds the above mentioned headers when executed from a "Developer Command Prompt for VS2015", but not when executed directly by clicking the CMake desktop link or clicking cmake-gui in the windows explorer. Further tests show that CMake also finds the headers when it needs to reconfigure something within the VS IDE because a CMake file was changed. Wild guess: given the paths of the header files in question I assume that it has something to do with the SDK files ('Windows Kits/8.1/Include/um/GL/...' and 'Windows Kits/10/Include/10.0.10240.0/ucrt/...' From nilsgladitz at gmail.com Mon Aug 22 08:12:24 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 22 Aug 2016 14:12:24 +0200 Subject: [CMake] Wrong version of cl.exe for x64 In-Reply-To: <988c5670-28e1-59d6-8cf9-8bfeab3001ed@online.de> References: <3ba5ce3d-dcd1-e170-4e1a-cdfe52c3d5ad@gmail.com> <66e4994f-e998-8498-5330-c1f99c245006@online.de> <15a23535-2d4f-fc6f-c243-c35ed3213398@gmail.com> <988c5670-28e1-59d6-8cf9-8bfeab3001ed@online.de> Message-ID: <75c5ad4e-9f9e-eff9-53c8-c4b91a35dcef@gmail.com> On 08/22/2016 01:30 PM, Albrecht Schlosser wrote: > On 22.08.2016 12:54 Nils Gladitz wrote: >> On 08/22/2016 12:18 PM, Albrecht Schlosser wrote: >> >>> On 22.08.2016 10:33 Nils Gladitz wrote: >>> >>>> The visual studio command line environments should have no effect when >>>> using the visual studio generators. >>> >>> Are you sure? Or what does "should" mean here? ;-) >> >> Yes. The Visual Studio generators are meant to work outside of the >> visual studio command line environments while the command line >> generators (makefiles, ninja) are meant to work from within the visual >> studio command line environment. >> >> What that means is that the Visual Studio generators must work >> without it. > > Okay, I posted a simple example CMake file to show what happens in my > case. See new thread: > > "Visual Studio generator does not find some header files" > > Basically some special (SDK?) header files are not found when > executing CMake w/o the Visual Studio environment. > E.g. CMake find_path() uses the INCLUDE environment variable (which is provided by the visual studio command line environment) if set. So yes this can influence CMake itself but not Visual Studio. Since the paths in the INCLUDE environment variable are not used by Visual Studio this can result in obvious conflicts. Since CMake does not (I don't know if it (easily) could) know the implicit include directories Visual Studio uses it can not use them in find_*() calls either. In case of the OpenGL library (which on windows is part of the windows/platform SDK) cmake e.g. assumes (within the FindOpenGL.cmake module) that the header is in an implicit include directory and does not try to locate it. Assuming this matches your use case I would suggest you do the same. Nils From AlbrechtS.fltk at online.de Mon Aug 22 13:34:22 2016 From: AlbrechtS.fltk at online.de (Albrecht Schlosser) Date: Mon, 22 Aug 2016 19:34:22 +0200 Subject: [CMake] Wrong version of cl.exe for x64 In-Reply-To: <75c5ad4e-9f9e-eff9-53c8-c4b91a35dcef@gmail.com> References: <3ba5ce3d-dcd1-e170-4e1a-cdfe52c3d5ad@gmail.com> <66e4994f-e998-8498-5330-c1f99c245006@online.de> <15a23535-2d4f-fc6f-c243-c35ed3213398@gmail.com> <988c5670-28e1-59d6-8cf9-8bfeab3001ed@online.de> <75c5ad4e-9f9e-eff9-53c8-c4b91a35dcef@gmail.com> Message-ID: <38c7d3ad-3f1a-0417-8628-5aca83f1ed72@online.de> On 22.08.2016 14:12 Nils Gladitz wrote: > On 08/22/2016 01:30 PM, Albrecht Schlosser wrote: > >> On 22.08.2016 12:54 Nils Gladitz wrote: >>> On 08/22/2016 12:18 PM, Albrecht Schlosser wrote: >>> >>>> On 22.08.2016 10:33 Nils Gladitz wrote: >>>> >>>>> The visual studio command line environments should have no effect when >>>>> using the visual studio generators. >>>> >>>> Are you sure? Or what does "should" mean here? ;-) >>> >>> Yes. The Visual Studio generators are meant to work outside of the >>> visual studio command line environments while the command line >>> generators (makefiles, ninja) are meant to work from within the visual >>> studio command line environment. >>> >>> What that means is that the Visual Studio generators must work >>> without it. >> >> Okay, I posted a simple example CMake file to show what happens in my >> case. See new thread: >> >> "Visual Studio generator does not find some header files" >> >> Basically some special (SDK?) header files are not found when >> executing CMake w/o the Visual Studio environment. >> > > E.g. CMake find_path() uses the INCLUDE environment variable (which is > provided by the visual studio command line environment) if set. > > So yes this can influence CMake itself but not Visual Studio. > Since the paths in the INCLUDE environment variable are not used by > Visual Studio this can result in obvious conflicts. Okay, I see. > Since CMake does not (I don't know if it (easily) could) know the > implicit include directories Visual Studio uses it can not use them in > find_*() calls either. Understood. Thanks for the information. > In case of the OpenGL library (which on windows is part of the > windows/platform SDK) cmake e.g. assumes (within the FindOpenGL.cmake > module) that the header is in an implicit include directory and does not > try to locate it. Well, that's a pity. This makes it necessary to use platform specific code in CMake files unless you can completely rely on modules that do already include such platform specify code. > Assuming this matches your use case I would suggest you do the same. Indeed our case in FLTK (www.fltk.org), a cross platform GUI library (for those that don't know it) is related to OpenGL (GL/gl.h and GL/glu.h), but also locale.h. We need to know if we can #include these (and other) header files in the library code. I took a look into our old bundled IDE files and found that we _assumed_ that these headers existed even in our oldest supported Visual C++ IDE (the provided config.h file was edited accordingly). So, the conclusion is: since CMake can't figure it out we have to _assume_ that the header files can be #included in MSVC projects (MinGW works well), hence we should set the corresponding CMake variable to true, maybe something like: if (MSVC) set (HAVE_GL_GL_H 1) endif (MSVC) Is this what you suggest? This would work, but it's very unfortunate to have to do this. It would be much better if find_file() or find_path() would be able to work really cross platform w/o special assumptions. But I see your point. I'll take another look in our CMake files to see if find_package(OpenGL) would get us to a better solution. Thanks for your support. From nilsgladitz at gmail.com Mon Aug 22 13:55:12 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 22 Aug 2016 19:55:12 +0200 Subject: [CMake] Wrong version of cl.exe for x64 In-Reply-To: <38c7d3ad-3f1a-0417-8628-5aca83f1ed72@online.de> References: <3ba5ce3d-dcd1-e170-4e1a-cdfe52c3d5ad@gmail.com> <66e4994f-e998-8498-5330-c1f99c245006@online.de> <15a23535-2d4f-fc6f-c243-c35ed3213398@gmail.com> <988c5670-28e1-59d6-8cf9-8bfeab3001ed@online.de> <75c5ad4e-9f9e-eff9-53c8-c4b91a35dcef@gmail.com> <38c7d3ad-3f1a-0417-8628-5aca83f1ed72@online.de> Message-ID: <9783fdf9-78f1-0a2a-bf54-1978318dbf50@gmail.com> On 22.08.2016 19:34, Albrecht Schlosser wrote: > > So, the conclusion is: since CMake can't figure it out we have to > _assume_ that the header files can be #included in MSVC projects > (MinGW works well), hence we should set the corresponding CMake > variable to true, maybe something like: > > if (MSVC) > set (HAVE_GL_GL_H 1) > endif (MSVC) > > Is this what you suggest? I suppose I'd go with if(WIN32). Nils From gilles.khouzam at microsoft.com Mon Aug 22 15:37:59 2016 From: gilles.khouzam at microsoft.com (Gilles Khouzam) Date: Mon, 22 Aug 2016 19:37:59 +0000 Subject: [CMake] Bash on ubuntu on windows as target References: <20160811062317.C32BAF5211@public.kitware.com> Message-ID: I?ve looked more in depth at the issue, and while this doesn?t work yet, we?re looking to enable this in a future Windows Insider Flight for better windows/linux interop. From: Gilles Khouzam Sent: Monday, August 15, 2016 13:24 To: 'Tiago Macarios' ; csiga.biga at aol.com Cc: CMake ML Subject: RE: [CMake] Bash on ubuntu on windows as target That?s an interesting idea, I?m not sure why cmd is failing to invoke bash properly, but I will try and figure it out. Also, for addressing invoking bash.exe without copying it to SysWow64, you can reference it by C:\Windows\Sysnative\bash.exe from a 32-bit process. It still doesn?t make the target succeed, but at least it removes the need to copy the file around. Thanks ~Gilles From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Tiago Macarios Sent: Thursday, August 11, 2016 10:12 To: csiga.biga at aol.com Cc: CMake ML > Subject: Re: [CMake] Bash on ubuntu on windows as target Well what I was trying to do was to actually have a target inside the windows build that would trigger the linux build so to build both at the same time. imagine you have a VS project one of the "projects" would be the linux build. So as long as the build folder is different I could have both building in sync everytime. Get the idea? If I just do a full build inside bash everything works great =) On Wed, Aug 10, 2016 at 11:23 PM, <"M?t? Ferenc Nagy-Egri via CMake > wrote: +1 for the initiative. Wouldn?t it make more sense however to make it a CMAKE_SYSTEM_NAME? If I remember correctly that?s how MinGW works, and this should be something very similar. Felad?: Tiago Macarios Elk?ldve: 2016. augusztus 11., cs?t?rt?k 1:51 C?mzett: CMake ML T?rgy: [CMake] Bash on ubuntu on windows as target Hi All, Windows 10 anniversary edition comes with support to execute Linux binaries. I have been trying to use it with one of our projects, but I have been getting a weird error. Maybe someone can help me? The target is pretty simple: set(BASH "C:\\Windows\\System32\\bash.exe") set(ARGS "--help") add_custom_target(linux ${BASH} ${ARGS}) If I then build that project in visual studio (with some extra verbosity) I get: Target "CustomBuild" in file "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets" from project "C:\_Working\delegate\build\linux.vcxproj" (target "_BuildGenerateSourcesAction" depends on it): Using "CustomBuild" task from assembly "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Build.CppTasks.Common.dll". Task "CustomBuild" Write Tracking Logs: x64\Debug\linux\linux.tlog\custombuild.write.1.tlog Read Tracking Logs: x64\Debug\linux\linux.tlog\custombuild.read.1.tlog No output for C:\_WORKING\DELEGATE\BUILD\CMAKEFILES\3FA5525E877A7559336C7D412E1B43B0\LINUX.RULE|C:\_WORKING\DELEGATE\CMAKELISTS.TXT was found in the tracking log; source compilation required. C:\_Working\delegate\CMakeLists.txt will be compiled as it was not found in the tracking log. C:\_Working\delegate\build\CMakeFiles\3fa5525e877a7559336c7d412e1b43b0\linux.rule will be compiled as it was not found in the tracking log. setlocal "C:\Program Files (x86)\CMake\bin\cmake.exe" -HC:/_Working/delegate -BC:/_Working/delegate/build --check-stamp-file C:\_Working\delegate\build\CMakeFiles\generate.stamp if %errorlevel% neq 0 goto :cmEnd :cmEnd endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone :cmErrorLevel exit /b %1 :cmDone if %errorlevel% neq 0 goto :VCEnd setlocal C:\Windows\System32\bash.exe --help if %errorlevel% neq 0 goto :cmEnd :cmEnd endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone :cmErrorLevel exit /b %1 :cmDone if %errorlevel% neq 0 goto :VCEnd Building Custom Rule C:/_Working/delegate/CMakeLists.txt CMake does not need to re-run because C:\_Working\delegate\build\CMakeFiles\generate.stamp is up-to-date. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code -1073740791. Done executing task "CustomBuild" -- FAILED. Done building target "CustomBuild" in project "linux.vcxproj" -- FAILED. The command line seems correct. If I just copy it to the windows prompt it works fine: C:\Users\tmc> C:\Windows\System32\bash.exe --help GNU bash, version 4.3.11(1)-release-(x86_64-pc-linux-gnu) Usage: /bin/bash [GNU long option] [option] ... /bin/bash [GNU long option] [option] script-file ... GNU long options: --debug --debugger --dump-po-strings --dump-strings --help --init-file --login --noediting --noprofile --norc --posix --rcfile --restricted --verbose --version Shell options: -ilrsD or -c command or -O shopt_option (invocation only) -abefhkmnptuvxBCHP or -o option Type `/bin/bash -c "help set"' for more information about shell options. Type `/bin/bash -c help' for more information about shell builtin commands. Use the `bashbug' command to report bugs. I also tried to use it from the visual studio "external tools" and it seems to work. So I am not sure what is going on. Is there a way to debug custom_targets? In case anyone tries the example above on a 64 bit machine: You will need to copy bash.exe from system32 to syswow64 since VS is 32 bits. 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 craig.scott at crascit.com Mon Aug 22 23:47:45 2016 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 23 Aug 2016 13:47:45 +1000 Subject: [CMake] MACOSX_PACKAGE_LOCATION and iOS Message-ID: Just wondering if this is expected behaviour (it's not documented if it is). When building for iOS with the Xcode generator, if a source file has its MACOSX_PACKAGE_LOCATION property set, the generated Xcode project shows that "../" is prepended to the path given. I'm wondering if the assumption here is that for OSX, files will likely be getting put in "Resources/...", but for iOS it is a flat structure with no Resources folder, so CMake silently pulls the destination dir up one level. This seems like trying to do too much on behalf of the developer, but let's first confirm whether this is intended and debate the merits later. ;) -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Bielik at dirac.com Tue Aug 23 02:26:00 2016 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Tue, 23 Aug 2016 06:26:00 +0000 Subject: [CMake] Xcode generator problems Message-ID: Hi all, I just opened https://gitlab.kitware.com/cmake/cmake/issues/16260, anyone have ideas how to work around it ? Or if it is fixed in latest & greatest CMake ? Regards /Robert From Robert.Bielik at dirac.com Tue Aug 23 03:30:24 2016 From: Robert.Bielik at dirac.com (Robert Bielik) Date: Tue, 23 Aug 2016 07:30:24 +0000 Subject: [CMake] Xcode generator problems In-Reply-To: References: Message-ID: <53c7fcf9aafd430692d2c171fd5c4fba@hosted3-mb01.itm.host> I just realized this is in error, issue is closed. But I still have the need to combine several static libraries into ONE static library. There seems to be descriptions of solutions to this, but they are rather convoluted, so is there an "easy" way of doing: add_library(foo STATIC ) add_library(bar STATIC ) add_library(baz STATIC ) target_link_libraries(baz foo bar) with baz containing ALL libraries ? Regards /Robert >-----Original Message----- >From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert Bielik >Sent: den 23 augusti 2016 08:26 >To: cmake at cmake.org >Subject: [CMake] Xcode generator problems > >Hi all, > >I just opened https://gitlab.kitware.com/cmake/cmake/issues/16260, anyone >have ideas how to work around it ? Or if it is fixed in latest & greatest CMake ? > >Regards >/Robert >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: >http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For more >information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware 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 steve.lorimer at gmail.com Tue Aug 23 11:20:13 2016 From: steve.lorimer at gmail.com (Steve Lorimer) Date: Tue, 23 Aug 2016 10:20:13 -0500 Subject: [CMake] Custom target for running tests as part of the build Message-ID: We have several unit tests which we would like to be run as part of our build process. To achieve this I have a helper script which creates a custom command that runs the test, and if successful, creates a file "test_name.passed". I then add a custom target "test_name.run" which depends on "test_name.passed". The idea is that if "test_name.passed" doesn't exist or is older than "test_name", the custom command will be run. Builds will continue to run the custom command until the test passes. Subsequent builds won't call the custom command, so the test won't be run if it doesn't need to. Here is the script: # create test.passed command which runs the test and creates a sentinel file if it passes add_custom_command( OUTPUT ${TEST_NAME}.passed COMMAND $ COMMAND ${CMAKE_COMMAND} -E touch ${TEST_NAME}.passed DEPENDS ${TEST_NAME} ) # create test.run module which depends on test.passed add_custom_target(${TEST_NAME}.run ALL DEPENDS ${TEST_NAME}.passed ) The problem is that our tests often log a tonne of information to stdout, and it makes for a very noisy build. I'm trying to now capture stdout to a file, and only in the event of a failure, display the test output. My first attempt was to try a Bash shell scripting syntax - capture stdout into a file and when the exit status is an error, cat the file. add_custom_command( OUTPUT ${TEST_NAME}.passed COMMAND $ > ${TEST_NAME}.output || cat ${TEST_NAME}.output COMMAND ${CMAKE_COMMAND} -E touch ${TEST_NAME}.passed DEPENDS ${TEST_NAME} ) This doesn't work, as even if the test fails I am getting the sentinal "test_name.passed" file created, which means the next time I try to build it thinks the test passed. Is there a way to achieve what I want? Bonus points for a cross-platform method, but if it has to be Linux only, then so be it. Thanks in advance Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From kimberly.kryger at gmail.com Tue Aug 23 12:21:57 2016 From: kimberly.kryger at gmail.com (Kim Kryger) Date: Tue, 23 Aug 2016 12:21:57 -0400 Subject: [CMake] [CTest] Set BuildName through command line Message-ID: I'm trying to simply set the name of the build to be sent to CDash to something on the command line. I've tried a few different avenues, but no options seem to affect the build name, other than reconfiguring CMake. I am using Visual Studio, which of course is multi-configuration, which means that a single CTest file is used when building, but when I build Debug and Release tests, the CDash output treats them as the same build, and it considers the results to be similar, when I want them to be separated by build name. Can I use generator expressions somehow? I shouldn't have to reconfigure cmake to change a simple name for the CTest build name. Here are some of my attempts: "C:\Program Files (x86)\CMake 3.3\bin\ctest.exe" -D BuildName:String=MyBuild -C Debug -D ExperimentalBuild "C:\Program Files (x86)\CMake 3.3\bin\ctest.exe" -D CTEST_BUILD_NAME:String=MyBuild -C Debug -D Experimental "C:\Program Files (x86)\CMake 3.3\bin\ctest.exe" --overwrite BUILDNAME=MyBuild -C Debug -D Experimental "C:\Program Files (x86)\CMake 3.3\bin\ctest.exe" --overwrite CTEST_BUILD_NAME=MyBuild -C Debug -D Experimental I was hoping -S was a supplement to the already created configuration file, but nope, it's meant to be a complete replacement for the default. I found this thread but it's not the solution I was hoping to use. http://public.kitware.com/pipermail/cmake/2010-June/037706.html Is there a command line option I'm missing or using incorrectly, or is this seriously not something that is supported? Thanks, Kim -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkeeler at tenable.com Tue Aug 23 13:14:05 2016 From: mkeeler at tenable.com (Matthew Keeler) Date: Tue, 23 Aug 2016 13:14:05 -0400 Subject: [CMake] Custom target for running tests as part of the build In-Reply-To: References: Message-ID: One thing I see immediately is this line: $ > ${TEST_NAME}.output || cat ${TEST_NAME}.output Unless ${TEST_NAME}.output doesn?t exist cat is going to have a successful exit status and cause the whole COMMAND to be successful. Something like ?|| (cat ${TEST_NAME}.output && false)? should work in bash. When the test passes everything in the parens won?t be executed but when it does it will still force a bad exit status. For a cross platform solution I would create a cmake script to do the grunt work of executing the test. COMMAND ${CMAKE_COMMAND} -DTEST_EXEC= -DTEST_NAME=${TEST_NAME} -P test-runner.cmake Then in the script it could do something like the following: execute_process(COMMAND ${TEST_EXEC} OUTPUT_FILE ${TEST_NAME}.out ERROR_FILE ${TEST_NAME}.out RESULT_VARIABLE TEST_SUCCESS) if (NOT TEST_SUCCESS EQUAL 0) execute_process(COMMAND cat ${TEST_NAME}.out) message(FATAL_ERROR ?Execution of ${TEST_EXEC} exited with a failure status?) endif() execute_process(COMMAND ${CMAKE_COMMAND} -E touch ${TEST_NAME}.passed) Depending on how much you need the cross platform solution the ugliness of the extra indirection may not be desirable for you. -- Matt Keeler On August 23, 2016 at 11:20:48, Steve Lorimer (steve.lorimer at gmail.com) wrote: We have several unit tests which we would like to be run as part of our build process. To achieve this I have a helper script which creates a custom command that runs the test, and if successful, creates a file "test_name.passed". I then add a custom target "test_name.run" which depends on "test_name.passed". The idea is that if "test_name.passed" doesn't exist or is older than "test_name", the custom command will be run. Builds will continue to run the custom command until the test passes. Subsequent builds won't call the custom command, so the test won't be run if it doesn't need to. Here is the script: # create test.passed command which runs the test and creates a sentinel file if it passes add_custom_command( OUTPUT ${TEST_NAME}.passed COMMAND $ COMMAND ${CMAKE_COMMAND} -E touch ${TEST_NAME}.passed DEPENDS ${TEST_NAME} ) # create test.run module which depends on test.passed add_custom_target(${TEST_NAME}.run ALL DEPENDS ${TEST_NAME}.passed ) The problem is that our tests often log a tonne of information to stdout, and it makes for a very noisy build. I'm trying to now capture stdout to a file, and only in the event of a failure, display the test output. My first attempt was to try a Bash shell scripting syntax - capture stdout into a file and when the exit status is an error, cat the file. add_custom_command( OUTPUT ${TEST_NAME}.passed COMMAND $ > ${TEST_NAME}.output || cat ${TEST_NAME}.output COMMAND ${CMAKE_COMMAND} -E touch ${TEST_NAME}.passed DEPENDS ${TEST_NAME} ) This doesn't work, as even if the test fails I am getting the sentinal "test_name.passed" file created, which means the next time I try to build it thinks the test passed. Is there a way to achieve what I want? Bonus points for a cross-platform method, but if it has to be Linux only, then so be it. Thanks in advance Steve -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.lorimer at gmail.com Tue Aug 23 13:34:13 2016 From: steve.lorimer at gmail.com (Steve Lorimer) Date: Tue, 23 Aug 2016 12:34:13 -0500 Subject: [CMake] Custom target for running tests as part of the build In-Reply-To: References: Message-ID: Thanks Matt, that works great! As a note for if someone wants to repeat this in the future... One of the things I initially tried was bash stdout and stderr redirection (using &>) &>${TEST_NAME}.output This doesn't work. I guess it causes the test to run in the background? It also results in the test.passed sentinel always being created. To get both stdout and stderr I had to redirect stdout to file and stderr to stdout >${TEST_NAME}.output 2>&1 On 23 August 2016 at 12:14, Matthew Keeler wrote: > One thing I see immediately is this line: > > $ > ${TEST_NAME}.output || cat > ${TEST_NAME}.output > > Unless ${TEST_NAME}.output doesn?t exist cat is going to have a successful > exit status and cause the whole COMMAND to be successful. Something like > ?|| (cat ${TEST_NAME}.output && false)? should work in bash. When the test > passes everything in the parens won?t be executed but when it does it will > still force a bad exit status. > For a cross platform solution I would create a cmake script to do the > grunt work of executing the test. > > COMMAND ${CMAKE_COMMAND} -DTEST_EXEC= > -DTEST_NAME=${TEST_NAME} -P test-runner.cmake > > Then in the script it could do something like the following: > > execute_process(COMMAND ${TEST_EXEC} OUTPUT_FILE ${TEST_NAME}.out > ERROR_FILE ${TEST_NAME}.out RESULT_VARIABLE TEST_SUCCESS) > if (NOT TEST_SUCCESS EQUAL 0) > execute_process(COMMAND cat ${TEST_NAME}.out) > message(FATAL_ERROR ?Execution of ${TEST_EXEC} exited with a failure > status?) > endif() > > execute_process(COMMAND ${CMAKE_COMMAND} -E touch ${TEST_NAME}.passed) > > > Depending on how much you need the cross platform solution the ugliness of > the extra indirection may not be desirable for you. > > -- > Matt Keeler > > > On August 23, 2016 at 11:20:48, Steve Lorimer (steve.lorimer at gmail.com) > wrote: > > We have several unit tests which we would like to be run as part of our > build process. > > To achieve this I have a helper script which creates a custom command that > runs the test, and if successful, creates a file "test_name.passed". > > I then add a custom target "test_name.run" which depends on > "test_name.passed". > > The idea is that if "test_name.passed" doesn't exist or is older than > "test_name", the custom command will be run. > > Builds will continue to run the custom command until the test passes. > Subsequent builds won't call the custom command, so the test won't be run > if it doesn't need to. > > Here is the script: > > # create test.passed command which runs the test and creates a > sentinel file if it passes > add_custom_command( > OUTPUT ${TEST_NAME}.passed > COMMAND $ > COMMAND ${CMAKE_COMMAND} -E touch ${TEST_NAME}.passed > DEPENDS ${TEST_NAME} > ) > > # create test.run module which depends on test.passed > add_custom_target(${TEST_NAME}.run > ALL > DEPENDS ${TEST_NAME}.passed > ) > > The problem is that our tests often log a tonne of information to stdout, > and it makes for a very noisy build. > > I'm trying to now capture stdout to a file, and only in the event of a > failure, display the test output. > > My first attempt was to try a Bash shell scripting syntax - capture stdout > into a file and when the exit status is an error, cat the file. > > add_custom_command( > OUTPUT ${TEST_NAME}.passed > COMMAND $ > ${TEST_NAME}.output || cat > ${TEST_NAME}.output > COMMAND ${CMAKE_COMMAND} -E touch ${TEST_NAME}.passed > DEPENDS ${TEST_NAME} > ) > > This doesn't work, as even if the test fails I am getting the sentinal > "test_name.passed" file created, which means the next time I try to build > it thinks the test passed. > > Is there a way to achieve what I want? Bonus points for a cross-platform > method, but if it has to be Linux only, then so be it. > > Thanks in advance > Steve > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Tue Aug 23 10:45:38 2016 From: parag at ionicsecurity.com (Parag Chandra) Date: Tue, 23 Aug 2016 14:45:38 +0000 Subject: [CMake] [EXTERNAL]: Re: Xcode generator problems In-Reply-To: <53c7fcf9aafd430692d2c171fd5c4fba@hosted3-mb01.itm.host> References: <53c7fcf9aafd430692d2c171fd5c4fba@hosted3-mb01.itm.host> Message-ID: Hi Robert, We have a similar requirement, so I basically run ?ar -x? to explode all of the static libraries into their constituent pieces, and then run ?ar cr" to recombine them into one monolithic static library. This is done via Gradle, after it runs CMake to build the static libraries in the first place. Probably not the answer you?re looking for, but I?m sure you can write a custom post-build step in CMake to do the same. Parag Chandra Technical Lead, Mobile Team Mobile: +1.919.824.1410 Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 On 8/23/16, 3:30 AM, "CMake on behalf of Robert Bielik" wrote: I just realized this is in error, issue is closed. But I still have the need to combine several static libraries into ONE static library. There seems to be descriptions of solutions to this, but they are rather convoluted, so is there an "easy" way of doing: add_library(foo STATIC ) add_library(bar STATIC ) add_library(baz STATIC ) target_link_libraries(baz foo bar) with baz containing ALL libraries ? Regards /Robert >-----Original Message----- >From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert Bielik >Sent: den 23 augusti 2016 08:26 >To: cmake at cmake.org >Subject: [CMake] Xcode generator problems > >Hi all, > >I just opened https://gitlab.kitware.com/cmake/cmake/issues/16260, anyone >have ideas how to work around it ? Or if it is fixed in latest & greatest CMake ? > >Regards >/Robert >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: >http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For more >information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware 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 jack.stalnaker at gmail.com Tue Aug 23 15:36:23 2016 From: jack.stalnaker at gmail.com (Jack Stalnaker) Date: Tue, 23 Aug 2016 14:36:23 -0500 Subject: [CMake] visual studio tries to link to non-existent static version of lib Message-ID: The following works on Linux, for both GNU and Intel compilers: add_library(mylib SHARED ${mylib_sources}) target_link_libraries(mylib ${mylib_libraries}) ... add_executable(test_mylib test_mylib.c) target_link_libraries(test_mylib mylib ${test_mylib_libraries}) add_test (TestMylib test_mylib) However on windows, using Visual Studio, building test_mylib fails with the message "cannot open file Debug\mylib.lib". But I have not asked for a static library, and I'm not sure why VS is trying to link to it. Is there some extra step I need to take to make this work on Windows? --Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Aug 23 15:44:29 2016 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 23 Aug 2016 21:44:29 +0200 Subject: [CMake] visual studio tries to link to non-existent static version of lib In-Reply-To: References: Message-ID: <3740e1cf-fd08-590d-1470-80f450456d98@gmail.com> On 23.08.2016 21:36, Jack Stalnaker wrote: > The following works on Linux, for both GNU and Intel compilers: > > add_library(mylib SHARED ${mylib_sources}) > target_link_libraries(mylib ${mylib_libraries}) > ... > add_executable(test_mylib test_mylib.c) > target_link_libraries(test_mylib mylib ${test_mylib_libraries}) > add_test (TestMylib test_mylib) > > > However on windows, using Visual Studio, building test_mylib fails > with the message "cannot open file Debug\mylib.lib". But I have not > asked for a static library, and I'm not sure why VS is trying to link > to it. Is there some extra step I need to take to make this work on > Windows? mylib.lib is the import library [1] for your DLL. The linker is (probably) not creating it because you aren't exporting any symbols [2]. Nils [1] https://en.wikipedia.org/wiki/Dynamic-link_library#Import_libraries [2] https://msdn.microsoft.com/en-us/library/z4zxe9k8.aspx From oliver.zabel at egoproducts.com Wed Aug 24 07:34:07 2016 From: oliver.zabel at egoproducts.com (oliver.zabel at egoproducts.com) Date: Wed, 24 Aug 2016 13:34:07 +0200 Subject: [CMake] surround add_executable with flags Message-ID: Hi, i trying to migrate a cross-compiler project (ARM on Windows) from an IDE (Cypress PSoC Creator) to cmake. The toolchain is a standard gcc for arm. The IDE compiles the binary with arm-none-eabi-gcc.exe -Wl,--start-group ..... -Wl,--end-group. I'm trying to reach the same in cmake, but since add_executable(target main.c) together with target_link_libraries() at least the main-file is outside the start / end-group. Is there a way to achive this? The problem is, that the code-size differs between the IDE build and cmake build and i need to know at least why. And since the group issue is the last thing, i need to get around it. Thanks for help! Best regards, Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.zabel at egoproducts.com Wed Aug 24 07:31:56 2016 From: oliver.zabel at egoproducts.com (oliver.zabel at egoproducts.com) Date: Wed, 24 Aug 2016 13:31:56 +0200 Subject: [CMake] surround executable with flags Message-ID: Hi, i trying to migrate a cross-compiler project (ARM on Windows) from an IDE (Cypress PSoC Creator) to cmake. The toolchain is a standard gcc for arm. The IDE compiles the binary with arm-none-eabi-gcc.exe -Wl,--start-group ..... -Wl,--end-group. I'm trying to reach the same in cmake, but since add_executable(target main.c) together with target_link_libraries() at least the main-file is outside the start / end-group. Is there a way to achive this? The problem is, that the code-size differs between the IDE build and cmake build and i need to know at least why. And since the group issue is the last thing, i need to get around it. Thanks for help! Best regards, Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From cottoncandycoder at gmail.com Wed Aug 24 11:09:29 2016 From: cottoncandycoder at gmail.com (Cotton Candy) Date: Wed, 24 Aug 2016 17:09:29 +0200 Subject: [CMake] trouble with find_package Message-ID: Hi, Cmake was having trouble finding the MySQL libraries on my machine so I tried using find_package with a package finder that I downloaded ( https://gist.github.com/RenatoUtsch/1623340) called FindMySQL.cmake. In my CMakeLists.txt file I added: ------------------------ set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ?/Users/jones/Dropbox/Skedmo/skedmo-solver-lean/cmake/?) find_package(MySQL) ------------------------ And I made sure that FindMySQL.cmake was in the directory that I added to the CMAKE_MODULE_PATH. Every time I press "Configure" on the GUI, I get the same warning message: CMake Warning at CMakeLists.txt:38 (find_package): By not providing "FindMySQL.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "MySQL", but CMake did not find one. Could not find a package configuration file provided by "MySQL" with any of the following names: MySQLConfig.cmake mysql-config.cmake Add the installation prefix of "MySQL" to CMAKE_PREFIX_PATH or set "MySQL_DIR" to a directory containing one of the above files. If "MySQL" provides a separate development package or SDK, be sure it has been installed. If I continue with "Generate", ultimately the resulting makefile does not work. I get errors at the linker stage. A few details about my environment: I am working on a MacBook Pro running OS X 10.9.5. I am using MAMP to run MySQL. The project builds just fine using Xcode, but I am trying to switch to CMake. Thanks for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Wed Aug 24 11:21:00 2016 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 24 Aug 2016 17:21:00 +0200 Subject: [CMake] trouble with find_package In-Reply-To: References: Message-ID: Hi. In your e-mail, there are curly quotes in the set() command. Is that an artifact of e-mailing, or are they actually present in your code? The latter could indeed cause the error you're seeing. Petr On 24 August 2016 at 17:09, Cotton Candy wrote: > Hi, > Cmake was having trouble finding the MySQL libraries on my machine so I > tried using find_package with a package finder that I downloaded ( > https://gist.github.com/RenatoUtsch/1623340) called FindMySQL.cmake. > > In my CMakeLists.txt file I added: > > ------------------------ > set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ?/Users/jones/Dropbox/Skedmo/ > skedmo-solver-lean/cmake/?) > > find_package(MySQL) > ------------------------ > > And I made sure that FindMySQL.cmake was in the directory that I added to > the CMAKE_MODULE_PATH. > > Every time I press "Configure" on the GUI, I get the same warning message: > > CMake Warning at CMakeLists.txt:38 (find_package): > By not providing "FindMySQL.cmake" in CMAKE_MODULE_PATH this project has > asked CMake to find a package configuration file provided by "MySQL", but > CMake did not find one. > > Could not find a package configuration file provided by "MySQL" with any of > the following names: > > MySQLConfig.cmake > mysql-config.cmake > > Add the installation prefix of "MySQL" to CMAKE_PREFIX_PATH or set > "MySQL_DIR" to a directory containing one of the above files. If "MySQL" > provides a separate development package or SDK, be sure it has been > installed. > > If I continue with "Generate", ultimately the resulting makefile does not > work. I get errors at the linker stage. > > > A few details about my environment: > > I am working on a MacBook Pro running OS X 10.9.5. > I am using MAMP to run MySQL. > The project builds just fine using Xcode, but I am trying to switch to > CMake. > > Thanks for your help. > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 steve.lorimer at gmail.com Wed Aug 24 12:35:29 2016 From: steve.lorimer at gmail.com (Steve Lorimer) Date: Wed, 24 Aug 2016 11:35:29 -0500 Subject: [CMake] set_directory_properties ADDITIONAL_MAKE_CLEAN_FILES globbing pattern? Message-ID: As part of our build process we tag certain binary files with version information such as git branch, number of commits, build variant etc. Eg, for a binary called "app" we could install a file in the local source directory with the name "app.branch_foo.91.debug" The shell globbing pattern that matches is "app.*[0-9]*" I need a globbing pattern because the tag can change without the makefiles changing, so the tag can't be hardcoded into the makefile. If I specify a globbing pattern for ADDITIONAL_MAKE_CLEAN_FILES it specifies this as an actual file set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES app.*[0-9]*) This results in file(REMOVE_RECURSE "../../../app/app.*[0-9]*" ... ) I've tried adding a nested file(GLOB ...) into the set_directory_properties but that doesn't work either. Is it possible to specify a globbing pattern in set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES ...)? Is it possible to specify a globbing pattern in file(REMOVE_RECURSE ...)? TIA Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.fedorov at gmail.com Wed Aug 24 13:10:36 2016 From: andrey.fedorov at gmail.com (Andrey Fedorov) Date: Wed, 24 Aug 2016 13:10:36 -0400 Subject: [CMake] Problems running npm-based tests on Windows Message-ID: Hi, we are running ctest's on appveyor using npm-installed packages. Specifically, we run jsonlint and ajv on json files to validate the content. Packages are installed in this line: https://github.com/QIICR/dcmqi/blob/master/appveyor.yml#L12-L13 of the appveyor configuration. The installed packages can be run wihtout problems when invoked directly from command line on appveyor. These lines https://github.com/QIICR/dcmqi/blob/master/appveyor.yml#L35-L36 both work fine on appveyor: https://ci.appveyor.com/project/fedorov/dcmqi/build/0.0.251#L1203. The path to the ajv package used by ctest is identical to the one that works when invoked directly from the cmd shell; here is the location where ctest is invoked:https://github.com/QIICR/dcmqi/blob/master/appveyor.yml#L37, and this is the where it is being run by appveyor: https://ci.appveyor.com/project/fedorov/dcmqi/build/0.0.251#L1662. Bottom line: ajv works when invoked directly from the appveyor windows cmd shell, but not when called by ctest. Why is ctest failing to run the test with "Not Run/BAD_COMMAND" status? AF From tonka3100 at gmail.com Wed Aug 24 15:53:37 2016 From: tonka3100 at gmail.com (tonka3100 at gmail.com) Date: Wed, 24 Aug 2016 21:53:37 +0200 Subject: [CMake] CPack change file extension Message-ID: <5B3A03DF-B95C-4B3E-8CDA-7DF893C21CF1@gmail.com> Hey everybody, I try to rename the fileextension of my cpack zip file. So i use cpack -G ZIP to create the package and get my zip file. Now i need to rename these fileextension to another name, like microsoft did it with with docx word format, where the file is a zip file, but has the docx extension. Does anybody know how i can do that? Greetings Tonka From petr.kmoch at gmail.com Thu Aug 25 02:42:13 2016 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Thu, 25 Aug 2016 08:42:13 +0200 Subject: [CMake] trouble with find_package In-Reply-To: References: Message-ID: I've never even used a Mac, so I am afraid I can't help you there. But I would assume there's a setting somewhere in the editor to enable/disable replacing straight quotes with curly ones. Petr On 24 August 2016 at 18:22, Cotton Candy wrote: > Hi Petr, > Indeed those curly quotes were in the code. I am using TextEdit on a Mac > and when I type the double-quote key I automatically get those curly > quotes. Fortunately I had some straight quotes elsewhere in my code and I > copied and pasted those and, voila - that seemed to fix the problem! > Now the question is, how do I get my keyboard to give me straight quotes > when I am typing. Any ideas? > Many thanks for your help. > Aaron > > On Wed, Aug 24, 2016 at 5:21 PM, Petr Kmoch wrote: > >> Hi. >> >> In your e-mail, there are curly quotes in the set() command. Is that an >> artifact of e-mailing, or are they actually present in your code? The >> latter could indeed cause the error you're seeing. >> >> Petr >> >> On 24 August 2016 at 17:09, Cotton Candy >> wrote: >> >>> Hi, >>> Cmake was having trouble finding the MySQL libraries on my machine so I >>> tried using find_package with a package finder that I downloaded ( >>> https://gist.github.com/RenatoUtsch/1623340) called FindMySQL.cmake. >>> >>> In my CMakeLists.txt file I added: >>> >>> ------------------------ >>> set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ?/Users/jones/Dropbox/Skedmo/s >>> kedmo-solver-lean/cmake/?) >>> >>> find_package(MySQL) >>> ------------------------ >>> >>> And I made sure that FindMySQL.cmake was in the directory that I added >>> to the CMAKE_MODULE_PATH. >>> >>> Every time I press "Configure" on the GUI, I get the same warning >>> message: >>> >>> CMake Warning at CMakeLists.txt:38 (find_package): >>> By not providing "FindMySQL.cmake" in CMAKE_MODULE_PATH this project has >>> asked CMake to find a package configuration file provided by "MySQL", but >>> CMake did not find one. >>> >>> Could not find a package configuration file provided by "MySQL" with any >>> of >>> the following names: >>> >>> MySQLConfig.cmake >>> mysql-config.cmake >>> >>> Add the installation prefix of "MySQL" to CMAKE_PREFIX_PATH or set >>> "MySQL_DIR" to a directory containing one of the above files. If "MySQL" >>> provides a separate development package or SDK, be sure it has been >>> installed. >>> >>> If I continue with "Generate", ultimately the resulting makefile does >>> not work. I get errors at the linker stage. >>> >>> >>> A few details about my environment: >>> >>> I am working on a MacBook Pro running OS X 10.9.5. >>> I am using MAMP to run MySQL. >>> The project builds just fine using Xcode, but I am trying to switch to >>> CMake. >>> >>> Thanks for your help. >>> >>> >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware 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 andrey.fedorov at gmail.com Thu Aug 25 07:12:41 2016 From: andrey.fedorov at gmail.com (Andrey Fedorov) Date: Thu, 25 Aug 2016 07:12:41 -0400 Subject: [CMake] Problems running npm-based tests on Windows In-Reply-To: References: Message-ID: As demonstrated here https://github.com/QIICR/dcmqi/pull/79, the problem is resolved when .cmd versions of the commands are used. On Wed, Aug 24, 2016 at 1:10 PM, Andrey Fedorov wrote: > Hi, > > we are running ctest's on appveyor using npm-installed packages. > Specifically, we run jsonlint and ajv on json files to validate the > content. > > Packages are installed in this line: > https://github.com/QIICR/dcmqi/blob/master/appveyor.yml#L12-L13 of the > appveyor configuration. > > The installed packages can be run wihtout problems when invoked > directly from command line on appveyor. These lines > https://github.com/QIICR/dcmqi/blob/master/appveyor.yml#L35-L36 both > work fine on appveyor: > https://ci.appveyor.com/project/fedorov/dcmqi/build/0.0.251#L1203. > > The path to the ajv package used by ctest is identical to the one that > works when invoked directly from the cmd shell; here is the location > where ctest is invoked:https://github.com/QIICR/dcmqi/blob/master/appveyor.yml#L37, > and this is the where it is being run by appveyor: > https://ci.appveyor.com/project/fedorov/dcmqi/build/0.0.251#L1662. > > Bottom line: ajv works when invoked directly from the appveyor windows > cmd shell, but not when called by ctest. > > Why is ctest failing to run the test with "Not Run/BAD_COMMAND" status? > > AF From tonka3100 at gmail.com Thu Aug 25 07:45:07 2016 From: tonka3100 at gmail.com (tonka tonka) Date: Thu, 25 Aug 2016 13:45:07 +0200 Subject: [CMake] Only install one component in cpack In-Reply-To: References: Message-ID: Hey, I want to create a zip file with only one component in it. Installers like nsis respect the CPACK_COMPONENTS_ALL settings, but the zip generator ignores it. Can I do that? Alternatively I would like to split every component into a single zip file, I know that it is possible but I forgot how to do that. Greetings Tonka -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Thu Aug 25 07:56:57 2016 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 25 Aug 2016 13:56:57 +0200 Subject: [CMake] Only install one component in cpack In-Reply-To: References: Message-ID: Hi Tonka, You should read the doc here: https://cmake.org/cmake/help/v3.5/module/CPackComponent.html for the ZIP generator you should set(CPACK_ARCHIVE_COMPONENT_INSTALL ON) this is necessary because archive generator are "MONOLITHIC" by default. set(CPACK_COMPONENTS_GROUPING IGNORE) with this grouping you get on package per component (the default is to have one package per component **group**) This should produce one zip file per component. Other grouping variant are possible, read the previous doc. 2016-08-25 13:45 GMT+02:00 tonka tonka : > Hey, > > I want to create a zip file with only one component in it. Installers like > nsis respect the CPACK_COMPONENTS_ALL settings, but the zip generator > ignores it. > > Can I do that? > > Alternatively I would like to split every component into a single zip > file, I know that it is possible but I forgot how to do that. > > Greetings > Tonka > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl.ljungkvist at it.uu.se Thu Aug 25 08:35:56 2016 From: karl.ljungkvist at it.uu.se (Karl Ljungkvist) Date: Thu, 25 Aug 2016 14:35:56 +0200 Subject: [CMake] CUDA: COMPILE_DEFINITIONS not picked up Message-ID: <57BEE62C.50603@it.uu.se> Hi all, if I do something like this, ADD_EXECUTABLE(myprog myprog.cpp) SET_PROPERTY(TARGET myprog APPEND PROPERTY COMPILE_DEFINITIONS "DEF1;DEF2" ) then the two macros DEF1 and DEF2 will be defined at compilation. However, if I switch to the corresponding CUDA setup, CUDA_ADD_EXECUTABLE(myprog myprog.cu) SET_PROPERTY(TARGET myprog APPEND PROPERTY COMPILE_DEFINITIONS "DEF1;DEF2" ) then they are not defined. Is this the intended behavior, and if so, how can I make the cuda version pick up the COMPILE_DEFINITIONS Best regards, Karl -- Karl Ljungkvist PhD student Uppsala University Dept. of Information Technology Div. of Scientific Computing Box 337 SE-751 05 Uppsala, Sweden Email: karl.ljungkvist at it.uu.se Phone: +46 18 471 2967 Mobile: +46 70 200356 From Daniel.Lueken at bmw-carit.de Thu Aug 25 12:06:51 2016 From: Daniel.Lueken at bmw-carit.de (Daniel Lueken) Date: Thu, 25 Aug 2016 16:06:51 +0000 Subject: [CMake] Erroneous CMP0022 warning for transitive conditional link dependencies? Message-ID: <3cdd17902c1249449330ca6acd40331b@CIT-HM8-EX01.bmw-carit.intra> Hi all, As it seems you get an erroneous CMP0022 warning in the following scenario, due to a generator expression not being resolved before string comparison. Confirmed with versions 3.5.1 and rev 00a583ac6833 . (2016-08-24 06:01:04) on Ubuntu Xenial using the Unix Makefile generator. - Create a library - Create a shared library and publicly conditionally (optimized | debug) link it to that library - Create an executable - Link the executable to the shared library, thus creating a transitive conditional dependency on the first library Running CMake on this setup yields the following warning during generation: -------------------------------------------------------------------------------------------------------- > ./cmake . . CMake Warning (dev) in CMakeLists.txt: Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link interface. Run "cmake --help-policy CMP0022" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Target "testso" has an INTERFACE_LINK_LIBRARIES property which differs from its LINK_INTERFACE_LIBRARIES properties. INTERFACE_LINK_LIBRARIES: $<$>:testlib> LINK_INTERFACE_LIBRARIES: testlib -------------------------------------------------------------------------------------------------------- CMakeLists.txt: cmake_minimum_required(VERSION 2.8) project(libtest_project) set(CMAKE_POSITION_INDEPENDENT_CODE ON) add_library(testlib STATIC testlib.cpp) add_library(testso SHARED sharedlib.cpp) target_link_libraries(testso PUBLIC optimized testlib) add_executable(testexe exe.cpp) target_link_libraries(testexe testso) -------------------------------------------------------------------------------------------------------- Simplified stack trace: cmGeneratorTarget (Target: testso)::GetLinkInterfaceLibraries("", target testexe, usage requirements only) TargetPropertyNode::Evaluate(testso, INTERFACE_SOURCES) GeneratorExpressionContent ($)::Evaluate() cmCompiledGeneratorExpression ($)::EvaluateWithContext() cmCompiledGeneratorExpression ($)::Evaluate() processSources() cmGeneratorTarget (Target: testexe)::GetSourceFiles(config: "") cmGeneratorTarget (Target: testexe)::GetSourceFiles(config: "") cmTargetTraceDependencies (Target: textexe)::ctor() cmGeneratorTarget (Target: testexe)::TraceDependencies() cmLocalGenerator (/src)::TraceDependencies() cmGlobalGenerator::Compute() cmake::Generate() cmake::Run() main() -------------------------------------------------------------------------------------------------------- .or is this intended behavior? Best regards -- BMW Car IT GmbH Daniel L?ken Spezialist Entwicklung Moosacher Stra?e 86 80809 M?nchen Tel.:? +49 89 189311-35 Fax:? +49 89 189311-20 Mail: daniel.lueken at bmw-carit.de Web: http://www.bmw-carit.de ------------------------------------------------------------------------- BMW Car IT GmbH Gesch?ftsf?hrer: Michael W?rtenberger und Alexis Trolin Sitz und Registergericht: M?nchen HRB 134810 ------------------------------------------------------------------------- From kmorel at sandia.gov Thu Aug 25 12:58:34 2016 From: kmorel at sandia.gov (Moreland, Kenneth) Date: Thu, 25 Aug 2016 16:58:34 +0000 Subject: [CMake] Time each target Message-ID: <5691b6650f5045ee8bebc6916a9786a0@ES08AMSNLNT.srn.sandia.gov> Does anyone know of a simple way to get CMake to time how long it takes to compile each target? As it stands now, when compiling a CMake-managed project a status is printed before each target is built. What I am looking for is a way to get CMake to print a second status message after the target finishes building with a note on what the wall time of the build was. -Ken **** Kenneth Moreland *** Sandia National Laboratories *********** *** *** *** email: kmorel at sandia.gov ** *** ** phone: (505) 844-8919 *** web: http://kennethmoreland.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonka3100 at gmail.com Thu Aug 25 13:02:15 2016 From: tonka3100 at gmail.com (tonka tonka) Date: Thu, 25 Aug 2016 19:02:15 +0200 Subject: [CMake] Only install one component in cpack In-Reply-To: References: Message-ID: Thx. Works perfectly :-D Am 25.08.2016 13:56 schrieb "Eric Noulard" : > Hi Tonka, > > You should read the doc here: > https://cmake.org/cmake/help/v3.5/module/CPackComponent.html > > for the ZIP generator you should > > set(CPACK_ARCHIVE_COMPONENT_INSTALL ON) > this is necessary because archive generator are "MONOLITHIC" by default. > > set(CPACK_COMPONENTS_GROUPING IGNORE) > with this grouping you get on package per component > (the default is to have one package per component **group**) > > This should produce one zip file per component. > Other grouping variant are possible, read the previous doc. > > 2016-08-25 13:45 GMT+02:00 tonka tonka : > >> Hey, >> >> I want to create a zip file with only one component in it. Installers >> like nsis respect the CPACK_COMPONENTS_ALL settings, but the zip generator >> ignores it. >> >> Can I do that? >> >> Alternatively I would like to split every component into a single zip >> file, I know that it is possible but I forgot how to do that. >> >> Greetings >> Tonka >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > > > -- > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mellery451 at gmail.com Thu Aug 25 13:57:31 2016 From: mellery451 at gmail.com (Michael Ellery) Date: Thu, 25 Aug 2016 10:57:31 -0700 Subject: [CMake] Time each target In-Reply-To: <5691b6650f5045ee8bebc6916a9786a0@ES08AMSNLNT.srn.sandia.gov> References: <5691b6650f5045ee8bebc6916a9786a0@ES08AMSNLNT.srn.sandia.gov> Message-ID: <3CDC0B4E-55F5-4064-BFA1-65B0D8FECAF4@gmail.com> > On Aug 25, 2016, at 9:58 AM, Moreland, Kenneth wrote: > > Does anyone know of a simple way to get CMake to time how long it takes to compile each target? As it stands now, when compiling a CMake-managed project a status is printed before each target is built. What I am looking for is a way to get CMake to print a second status message after the target finishes building with a note on what the wall time of the build was. > > -Ken > I don?t know of any built-in support for this. I think Visual Studio projects might have a setting to generate timing info, but I suspect you are not using Visual Studio/MSbuild. Here is an example of some build timing: https://github.com/PointCloudLibrary/pcl/blob/master/CMakeLists.txt#L98 https://github.com/PointCloudLibrary/pcl/blob/master/cmake/custom_output.sh ..but I think it is providing timing for each compile command, not at the target level. In any event, this technique of using RULE_LAUNCH_COMPILE seems interesting - perhaps you can adopt it somehow. The only other thing I can think of is to add custom targets around your real targets where POST depends on REAL which DEPENDS on PRE and the PRE and POST targets just print some timing info. Kludgy to be sure. HTH. -Mike From steinbach at scionics.de Fri Aug 26 03:15:58 2016 From: steinbach at scionics.de (Peter Steinbach) Date: Fri, 26 Aug 2016 09:15:58 +0200 Subject: [CMake] CUDA: COMPILE_DEFINITIONS not picked up In-Reply-To: <57BEE62C.50603@it.uu.se> References: <57BEE62C.50603@it.uu.se> Message-ID: Hi Karl, just a quick question, why not use add_definitions? Did you look into it or is directory-wide preprocessor defines a nogo in your use case? Best, Peter From steinbach at scionics.de Fri Aug 26 03:41:12 2016 From: steinbach at scionics.de (Peter Steinbach) Date: Fri, 26 Aug 2016 09:41:12 +0200 Subject: [CMake] CUDA: COMPILE_DEFINITIONS not picked up In-Reply-To: References: <57BEE62C.50603@it.uu.se> Message-ID: Hey Karl, just gave it another shot ... so I can confirm what you saw with cmake 3.3 (btw, what cmake version did you use?). I should try a more recent one to make sure as well. anyhow, there 2 global workarounds that you have at your disposal: 1) set(CUDA_NVCC_FLAGS "-Dfoo") needs to be called *BEFORE* any cuda_add_xxx according to `cmake --help-module FindCUDA` 2) add_definitions(-Dfoo), I called it before cuda_add_xxx too and it worked as well Hope that get's you going - P From kristianonline28 at gmail.com Fri Aug 26 13:05:48 2016 From: kristianonline28 at gmail.com (Kristian) Date: Fri, 26 Aug 2016 19:05:48 +0200 Subject: [CMake] CPack change file extension In-Reply-To: <5B3A03DF-B95C-4B3E-8CDA-7DF893C21CF1@gmail.com> References: <5B3A03DF-B95C-4B3E-8CDA-7DF893C21CF1@gmail.com> Message-ID: Hey, you're working on Windows, right? I think you can do that if you create an additional target and call that target. So let's say, you have this 'hello.cpp', and you generate with CMake a solution. This is an example of a CMakeLists.txt > cmake_minimum_required(VERSION 3.4) > project(cpack_zip_test) > set(SOURCES hello.cpp) > add_executable(${PROJECT_NAME} ${SOURCES}) > set(CPACK_GENERATOR "ZIP") > set(CPACK_PACKAGE_EXECUTABLE ${PROJECT_NAME}) > set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-package) > add_custom_target(rename_zip > COMMAND rename ${CPACK_PACKAGE_FILE_NAME}.zip ${CPACK_PACKAGE_FILE_NAME}.docx > WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}) > include(CPack) When I call now something like this on the command line (Visual Studio 12 2013) > devenv cpack_zip_test.sln /Rebuild Debug /project PACKAGE.vcxproj and afterwards some like this > devenv cpack_zip_test.sln /Rebuild Debug /project rename_zip.vcxproj then this is some way of renaming your zip into a docx file. But I do not know, if there is a more automatic way to do this. I tried it with an additional parameter in the 'add_custom_target'-command (see at the DEPENDS part): > add_custom_target(rename_zip > COMMAND rename ${CPACK_PACKAGE_FILE_NAME}.zip ${CPACK_PACKAGE_FILE_NAME}.docx > DEPENDS PACKAGE > WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}) But when I call 'devenv cpack_zip_test.sln /Rebuild Debug /project rename_zip.vcxproj', I would assume, that first the PACKAGE target is called, and afterwards the 'rename_zip' target is called. But that's not the case. Maybe some other person can tell me, if this is a bug or this is intention... 2016-08-24 21:53 GMT+02:00 tonka3100 at gmail.com : > Hey everybody, > > I try to rename the fileextension of my cpack zip file. So i use cpack -G > ZIP to create the package and get my zip file. Now i need to rename these > fileextension to another name, like microsoft did it with with docx word > format, where the file is a zip file, but has the docx extension. > > Does anybody know how i can do that? > > Greetings > Tonka > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 tonka3100 at gmail.com Fri Aug 26 14:01:41 2016 From: tonka3100 at gmail.com (tonka3100 at gmail.com) Date: Fri, 26 Aug 2016 20:01:41 +0200 Subject: [CMake] CPack change file extension In-Reply-To: References: <5B3A03DF-B95C-4B3E-8CDA-7DF893C21CF1@gmail.com> Message-ID: <45217079-2F0B-42EA-B5B6-B7F5DD6FD789@gmail.com> Hey Kristian, Thx for your answer. Iv've already done this like in your solution. I have a seperated target which depends on my create zip target and use ${CMAKE_COMMAND} -e copy to copy the file to my target directory (so the solution is platform independent), and leaf the original zip in the binary directory. Do you have any special reason why your rename target depends on PACKAGE, is this the target which cpack is using? > Am 26.08.2016 um 19:05 schrieb Kristian : > > Hey, > > you're working on Windows, right? > > I think you can do that if you create an additional target and call that target. So let's say, you have this 'hello.cpp', and you generate with CMake a solution. This is an example of a CMakeLists.txt > > > cmake_minimum_required(VERSION 3.4) > > project(cpack_zip_test) > > > set(SOURCES hello.cpp) > > > add_executable(${PROJECT_NAME} ${SOURCES}) > > > set(CPACK_GENERATOR "ZIP") > > set(CPACK_PACKAGE_EXECUTABLE ${PROJECT_NAME}) > > set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-package) > > > add_custom_target(rename_zip > > COMMAND rename ${CPACK_PACKAGE_FILE_NAME}.zip ${CPACK_PACKAGE_FILE_NAME}.docx > > WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}) > > > include(CPack) > > When I call now something like this on the command line (Visual Studio 12 2013) > > > devenv cpack_zip_test.sln /Rebuild Debug /project PACKAGE.vcxproj > > and afterwards some like this > > > devenv cpack_zip_test.sln /Rebuild Debug /project rename_zip.vcxproj > > then this is some way of renaming your zip into a docx file. But I do not know, if there is a more automatic way to do this. I tried it with an additional parameter in the 'add_custom_target'-command (see at the DEPENDS part): > > > add_custom_target(rename_zip > > COMMAND rename ${CPACK_PACKAGE_FILE_NAME}.zip ${CPACK_PACKAGE_FILE_NAME}.docx > > DEPENDS PACKAGE > > WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}) > > But when I call 'devenv cpack_zip_test.sln /Rebuild Debug /project rename_zip.vcxproj', I would assume, that first the PACKAGE target is called, and afterwards the 'rename_zip' target is called. But that's not the case. Maybe some other person can tell me, if this is a bug or this is intention... > > 2016-08-24 21:53 GMT+02:00 tonka3100 at gmail.com : >> Hey everybody, >> >> I try to rename the fileextension of my cpack zip file. So i use cpack -G ZIP to create the package and get my zip file. Now i need to rename these fileextension to another name, like microsoft did it with with docx word format, where the file is a zip file, but has the docx extension. >> >> Does anybody know how i can do that? >> >> Greetings >> Tonka >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 kristianonline28 at gmail.com Fri Aug 26 14:22:22 2016 From: kristianonline28 at gmail.com (Kristian) Date: Fri, 26 Aug 2016 20:22:22 +0200 Subject: [CMake] CPack change file extension In-Reply-To: <45217079-2F0B-42EA-B5B6-B7F5DD6FD789@gmail.com> References: <5B3A03DF-B95C-4B3E-8CDA-7DF893C21CF1@gmail.com> <45217079-2F0B-42EA-B5B6-B7F5DD6FD789@gmail.com> Message-ID: > Do you have any special reason why your rename target depends on PACKAGE, is this the target which cpack is using? I think so ... 2016-08-26 20:01 GMT+02:00 tonka3100 at gmail.com : > Hey Kristian, > > Thx for your answer. Iv've already done this like in your solution. I have > a seperated target which depends on my create zip target and use > ${CMAKE_COMMAND} -e copy to copy the file to my target directory (so the > solution is platform independent), and leaf the original zip in the binary > directory. > > Do you have any special reason why your rename target depends on PACKAGE, > is this the target which cpack is using? > > Am 26.08.2016 um 19:05 schrieb Kristian : > > Hey, > > you're working on Windows, right? > > I think you can do that if you create an additional target and call that > target. So let's say, you have this 'hello.cpp', and you generate with > CMake a solution. This is an example of a CMakeLists.txt > > > cmake_minimum_required(VERSION 3.4) > > project(cpack_zip_test) > > > set(SOURCES hello.cpp) > > > add_executable(${PROJECT_NAME} ${SOURCES}) > > > set(CPACK_GENERATOR "ZIP") > > set(CPACK_PACKAGE_EXECUTABLE ${PROJECT_NAME}) > > set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-package) > > > add_custom_target(rename_zip > > COMMAND rename ${CPACK_PACKAGE_FILE_NAME}.zip > ${CPACK_PACKAGE_FILE_NAME}.docx > > WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}) > > > include(CPack) > > When I call now something like this on the command line (Visual Studio 12 > 2013) > > > devenv cpack_zip_test.sln /Rebuild Debug /project PACKAGE.vcxproj > > and afterwards some like this > > > devenv cpack_zip_test.sln /Rebuild Debug /project rename_zip.vcxproj > > then this is some way of renaming your zip into a docx file. But I do not > know, if there is a more automatic way to do this. I tried it with an > additional parameter in the 'add_custom_target'-command (see at the DEPENDS > part): > > > add_custom_target(rename_zip > > COMMAND rename ${CPACK_PACKAGE_FILE_NAME}.zip > ${CPACK_PACKAGE_FILE_NAME}.docx > > DEPENDS PACKAGE > > WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}) > > But when I call 'devenv cpack_zip_test.sln /Rebuild Debug /project > rename_zip.vcxproj', I would assume, that first the PACKAGE target is > called, and afterwards the 'rename_zip' target is called. But that's not > the case. Maybe some other person can tell me, if this is a bug or this is > intention... > > 2016-08-24 21:53 GMT+02:00 tonka3100 at gmail.com : > >> Hey everybody, >> >> I try to rename the fileextension of my cpack zip file. So i use cpack -G >> ZIP to create the package and get my zip file. Now i need to rename these >> fileextension to another name, like microsoft did it with with docx word >> format, where the file is a zip file, but has the docx extension. >> >> Does anybody know how i can do that? >> >> Greetings >> Tonka >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 eric.noulard at gmail.com Fri Aug 26 14:55:59 2016 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 26 Aug 2016 20:55:59 +0200 Subject: [CMake] CPack change file extension In-Reply-To: References: <5B3A03DF-B95C-4B3E-8CDA-7DF893C21CF1@gmail.com> <45217079-2F0B-42EA-B5B6-B7F5DD6FD789@gmail.com> Message-ID: HI all, package is a builtin target unless things have changed you cannot depend on a builtin target. https://gitlab.kitware.com/cmake/cmake/issues/8438 https://cmake.org/Bug/view.php?id=8438 Personnally I would explicitely call CPack in my custom target in order to be sure that the zip is up-to-date. e.g.: # find a way to get path to cpack command in a portable way get_filename_component(CPACK_COMMAND ${CMAKE_COMMAND} PATH) set(CPACK_COMMAND ${CPACK_COMMAND}/cpack) add_custom_target(package_docx COMMAND $(CPACK_COMMAND} -G ZIP COMMAND ${CMAKE_COMMAND} -E rename ${CPACK_PACKAGE_FILE_NAME}.zip ${CPACK_PACKAGE_FILE_NAME}.docx WORKING_DIRECTORY ${CMAKE_BUILD_DIR}) cmake -E rename will work on the same volume, copy will work accross volume. note that your custom target should run in build dir in order to make cpack work as expected. 2016-08-26 20:22 GMT+02:00 Kristian : > > Do you have any special reason why your rename target depends on > PACKAGE, is this the target which cpack is using? > > I think so ... > > 2016-08-26 20:01 GMT+02:00 tonka3100 at gmail.com : > >> Hey Kristian, >> >> Thx for your answer. Iv've already done this like in your solution. I >> have a seperated target which depends on my create zip target and use >> ${CMAKE_COMMAND} -e copy to copy the file to my target directory (so the >> solution is platform independent), and leaf the original zip in the binary >> directory. >> >> Do you have any special reason why your rename target depends on PACKAGE, >> is this the target which cpack is using? >> >> Am 26.08.2016 um 19:05 schrieb Kristian : >> >> Hey, >> >> you're working on Windows, right? >> >> I think you can do that if you create an additional target and call that >> target. So let's say, you have this 'hello.cpp', and you generate with >> CMake a solution. This is an example of a CMakeLists.txt >> >> > cmake_minimum_required(VERSION 3.4) >> > project(cpack_zip_test) >> >> > set(SOURCES hello.cpp) >> >> > add_executable(${PROJECT_NAME} ${SOURCES}) >> >> > set(CPACK_GENERATOR "ZIP") >> > set(CPACK_PACKAGE_EXECUTABLE ${PROJECT_NAME}) >> > set(CPACK_PACKAGE_FILE_NAME ${PROJECT_NAME}-package) >> >> > add_custom_target(rename_zip >> > COMMAND rename ${CPACK_PACKAGE_FILE_NAME}.zip >> ${CPACK_PACKAGE_FILE_NAME}.docx >> > WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}) >> >> > include(CPack) >> >> When I call now something like this on the command line (Visual Studio 12 >> 2013) >> >> > devenv cpack_zip_test.sln /Rebuild Debug /project PACKAGE.vcxproj >> >> and afterwards some like this >> >> > devenv cpack_zip_test.sln /Rebuild Debug /project rename_zip.vcxproj >> >> then this is some way of renaming your zip into a docx file. But I do not >> know, if there is a more automatic way to do this. I tried it with an >> additional parameter in the 'add_custom_target'-command (see at the DEPENDS >> part): >> >> > add_custom_target(rename_zip >> > COMMAND rename ${CPACK_PACKAGE_FILE_NAME}.zip >> ${CPACK_PACKAGE_FILE_NAME}.docx >> > DEPENDS PACKAGE >> > WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}) >> >> But when I call 'devenv cpack_zip_test.sln /Rebuild Debug /project >> rename_zip.vcxproj', I would assume, that first the PACKAGE target is >> called, and afterwards the 'rename_zip' target is called. But that's not >> the case. Maybe some other person can tell me, if this is a bug or this is >> intention... >> >> 2016-08-24 21:53 GMT+02:00 tonka3100 at gmail.com : >> >>> Hey everybody, >>> >>> I try to rename the fileextension of my cpack zip file. So i use cpack >>> -G ZIP to create the package and get my zip file. Now i need to rename >>> these fileextension to another name, like microsoft did it with with docx >>> word format, where the file is a zip file, but has the docx extension. >>> >>> Does anybody know how i can do that? >>> >>> Greetings >>> Tonka >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware 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 > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From yaronct at gmail.com Sat Aug 27 15:39:07 2016 From: yaronct at gmail.com (Yaron Cohen-Tal) Date: Sat, 27 Aug 2016 22:39:07 +0300 Subject: [CMake] Using a pathless library in an imported target. Message-ID: Hi, I try to make an imported target out of OpenGL, and I have some difficulty. Usually "OPENGL_gl_LIBRARY" is a full path (found with "find_library"), but sometimes (on Windows) it's a pathless library (e.g. "opengl32", set with the cmake command "set"). However an imported library requires the full path to the library. Any idea how to tackle it? Thanx, Yaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.lorimer at gmail.com Sun Aug 28 17:17:58 2016 From: steve.lorimer at gmail.com (Steve Lorimer) Date: Sun, 28 Aug 2016 16:17:58 -0500 Subject: [CMake] How to link against PIC version of a library's dependency in CMake? Message-ID: *CMake:* We have a dependency on cpp-netlib . We build it from source as part of our build system. cpp-netlib/CMakeLists.txt: add_library(cpp-netlib STATIC ${SRCS}) For one particular use case, we have to use it in a shared library, so I've created a second library with -fPIC enabled: add_library(cpp-netlib_pic STATIC ${SRCS}) set_property(TARGET cpp-netlib_pic PROPERTY POSITION_INDEPENDENT_CODE) In my shared library target, I then link against libcpp-netlib_pic.a foo/CMakeLists.txt: add_library(foo SHARED ${SRCS}) target_link_libraries(foo cpp-netlib_pic) I'm getting a linker error back because cpp-netlib is trying to link against the non-pic version of boost_network /usr/bin/ld: ../third_party/cpp-netlib/libcpp-netlib_pic.a(client.cpp.o): \ relocation R_X86_64_32 against `_ZTVN5boost7network4http4impl15normal_delegateE' \ can not be used when making a shared object; recompile with -fPIC Demangled name: $ c++filt _ZTVN5boost7network4http4impl15normal_delegateE vtable for boost::network::http::impl::normal_delegate ------------------------------ *Boost Build:* This is all part of migrating our existing build system from boost-build to CMake. The boost-build Jamfiles work fine. Jamroot: variant pic : release : -fPIC ; cpp-netlib/Jamfile: lib cpp-netlib : [ glob src/*.cpp ] ; foo/Jamfile: shared-lib foo: [ glob *.cpp ] /ext/cpp-netlib//cpp-netlib/pic: shared -fPIC; This works. Note there is no mention of boost::network anywhere, although there is a subfolder in cpp-netlib/boost/library, but it contains headers only. ------------------------------ *Question:* How do I tell CMake that cpp-netlib_pic needs to use the pic version of boost_network? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bballet at ivsweb.com Sun Aug 28 17:28:20 2016 From: bballet at ivsweb.com (Benjamin Ballet) Date: Sun, 28 Aug 2016 23:28:20 +0200 Subject: [CMake] Using a pathless library in an imported target. In-Reply-To: References: Message-ID: Create an imported interface instead of a static library. Then you can set either INTERFACE_COMPILE_OPTIONS or INTERFACE_LINK_LIBRARIES properties. 2016-08-27 21:39 GMT+02:00 Yaron Cohen-Tal : > Hi, > > I try to make an imported target out of OpenGL, and I have some > difficulty. Usually "OPENGL_gl_LIBRARY" is a full path (found with > "find_library"), but sometimes (on Windows) it's a pathless library (e.g. > "opengl32", set with the cmake command "set"). However an imported library > requires the full path to the library. Any idea how to tackle it? > > Thanx, > Yaron > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- *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 steve.lorimer at gmail.com Sun Aug 28 17:28:39 2016 From: steve.lorimer at gmail.com (Steve Lorimer) Date: Sun, 28 Aug 2016 16:28:39 -0500 Subject: [CMake] How to add -fPIC to a static library? Message-ID: I'm trying to create a static library with -fPIC specified. add_library(cpp-netlib_pic STATIC ${SRCS}) set_property(TARGET cpp-netlib_pic PROPERTY POSITION_INDEPENDENT_CODE) This doesn't work. The library (cpp-netlib_pic) is built without the -fPIC flags. Other targets which link against cpp-netlib_pic have -fPIC added to their compiler flags, but the linking fails because cpp-netlib_pic didn't. Here foo will have -fPIC added: add_library(foo SHARED ${SRCS}) target_link_libraries(foo cpp-netlib_pic) I've proved this to myself with make VERBOSE=1 [ 87%] Building CXX object third_party/cpp-netlib/CMakeFiles/cpp-netlib_pic.dir/src/server_request_parsers_impl.cpp.o /usr/bin/c++ ... -std=c++14 -Werror -Wall -Wextra ... -o CMakeFiles/cpp-netlib_pic.dir/src/server_request_parsers_impl.cpp.o -c .../third_party/cpp-netlib/src/server_request_parsers_impl.cpp Note no -fPIC here. When building a target which uses cpp-netlib_pic -fPIC appears: [ 93%] Building CXX object foo.cc.o /usr/bin/c++ ... -std=c++14 -Werror -Wall -Wextra ... *-fPIC* ... -o CMakeFiles/foo_shared_lib.dir/foo.cc.o -c .../foo/foo.cc How can I configure CMake to build the 1st library (cpp-netlib_pic) with -fPIC? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas11braden at gmail.com Sun Aug 28 18:35:45 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Sun, 28 Aug 2016 17:35:45 -0500 Subject: [CMake] How to add -fPIC to a static library? In-Reply-To: References: Message-ID: Have you tried set_property(TARGET cpp-netlib_pic PROPERTY POSITION_INDEPENDENT_CODE ON)? I think you must specify the value ON for it to work. On Sun, Aug 28, 2016 at 4:28 PM, Steve Lorimer wrote: > I'm trying to create a static library with -fPIC specified. > > add_library(cpp-netlib_pic > STATIC > ${SRCS}) > set_property(TARGET cpp-netlib_pic PROPERTY POSITION_INDEPENDENT_CODE) > > This doesn't work. > > The library (cpp-netlib_pic) is built without the -fPIC flags. > > Other targets which link against cpp-netlib_pic have -fPIC added to their > compiler flags, but the linking fails because cpp-netlib_pic didn't. > > Here foo will have -fPIC added: > > add_library(foo > SHARED > ${SRCS}) > target_link_libraries(foo cpp-netlib_pic) > > > I've proved this to myself with make VERBOSE=1 > > [ 87%] Building CXX object > third_party/cpp-netlib/CMakeFiles/cpp-netlib_pic.dir/src/server_request_parsers_impl.cpp.o > > /usr/bin/c++ ... -std=c++14 -Werror -Wall -Wextra ... -o > CMakeFiles/cpp-netlib_pic.dir/src/server_request_parsers_impl.cpp.o -c > .../third_party/cpp-netlib/src/server_request_parsers_impl.cpp > > Note no -fPIC here. > > When building a target which uses cpp-netlib_pic -fPIC appears: > > [ 93%] Building CXX object foo.cc.o > /usr/bin/c++ ... -std=c++14 -Werror -Wall -Wextra ... -fPIC ... -o > CMakeFiles/foo_shared_lib.dir/foo.cc.o -c .../foo/foo.cc > > How can I configure CMake to build the 1st library (cpp-netlib_pic) with > -fPIC? > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 steve.lorimer at gmail.com Sun Aug 28 19:00:05 2016 From: steve.lorimer at gmail.com (Steve Lorimer) Date: Sun, 28 Aug 2016 18:00:05 -0500 Subject: [CMake] How to add -fPIC to a static library? In-Reply-To: References: Message-ID: Thanks Nicholas, you are indeed correct! On 28 August 2016 at 17:35, Nicholas Braden wrote: > Have you tried set_property(TARGET cpp-netlib_pic PROPERTY > POSITION_INDEPENDENT_CODE ON)? I think you must specify the value ON > for it to work. > > On Sun, Aug 28, 2016 at 4:28 PM, Steve Lorimer > wrote: > > I'm trying to create a static library with -fPIC specified. > > > > add_library(cpp-netlib_pic > > STATIC > > ${SRCS}) > > set_property(TARGET cpp-netlib_pic PROPERTY POSITION_INDEPENDENT_CODE) > > > > This doesn't work. > > > > The library (cpp-netlib_pic) is built without the -fPIC flags. > > > > Other targets which link against cpp-netlib_pic have -fPIC added to their > > compiler flags, but the linking fails because cpp-netlib_pic didn't. > > > > Here foo will have -fPIC added: > > > > add_library(foo > > SHARED > > ${SRCS}) > > target_link_libraries(foo cpp-netlib_pic) > > > > > > I've proved this to myself with make VERBOSE=1 > > > > [ 87%] Building CXX object > > third_party/cpp-netlib/CMakeFiles/cpp-netlib_pic.dir/ > src/server_request_parsers_impl.cpp.o > > > > /usr/bin/c++ ... -std=c++14 -Werror -Wall -Wextra ... -o > > CMakeFiles/cpp-netlib_pic.dir/src/server_request_parsers_impl.cpp.o -c > > .../third_party/cpp-netlib/src/server_request_parsers_impl.cpp > > > > Note no -fPIC here. > > > > When building a target which uses cpp-netlib_pic -fPIC appears: > > > > [ 93%] Building CXX object foo.cc.o > > /usr/bin/c++ ... -std=c++14 -Werror -Wall -Wextra ... -fPIC ... -o > > CMakeFiles/foo_shared_lib.dir/foo.cc.o -c .../foo/foo.cc > > > > How can I configure CMake to build the 1st library (cpp-netlib_pic) with > > -fPIC? > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware 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 steinbach at scionics.de Mon Aug 29 03:33:20 2016 From: steinbach at scionics.de (Peter Steinbach) Date: Mon, 29 Aug 2016 09:33:20 +0200 Subject: [CMake] How to add -fPIC to a static library? In-Reply-To: References: Message-ID: <01d36e8e-3d77-d69f-3f9c-be9c70aeecc7@scionics.de> AFAIK, there is also a global CMAKE_POSITION_INDEPENDENT_CODE that is used to derive the target-specific value of POSITION_INDEPENDENT_CODE. If you wanna use fPIC for all your targets, you may wanna consider set(CMAKE_POSITION_INDEPENDENT_CODE ON). Best, P From tonka3100 at gmail.com Mon Aug 29 03:43:37 2016 From: tonka3100 at gmail.com (tonka tonka) Date: Mon, 29 Aug 2016 09:43:37 +0200 Subject: [CMake] Convert UTF8 to UTF16 (Windows) In-Reply-To: References: Message-ID: Hey, I have a little problem with files which has to be UTF 16 instead of UTF 8, f.e. Visual studios .rc files. They must be utf16 and git detect it as bin files. So my question is: how do you handle these files? My rc files has to be generated with configure_file, so my hope was that configure_file will read utf8 and write utf16 if I want, but that seems not possible. Is there and other way in cake to convert to utf16? Greetings Tonka -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas11braden at gmail.com Mon Aug 29 03:47:22 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Mon, 29 Aug 2016 02:47:22 -0500 Subject: [CMake] Convert UTF8 to UTF16 (Windows) In-Reply-To: References: Message-ID: Are you sure about this UTF16 requirement? I have many projects ranging from Visual Studio 2008 to 2015 that use .rc files and all of them are ANSI/UTF8. On Mon, Aug 29, 2016 at 2:43 AM, tonka tonka wrote: > Hey, > > I have a little problem with files which has to be UTF 16 instead of UTF 8, > f.e. Visual studios .rc files. They must be utf16 and git detect it as bin > files. > So my question is: how do you handle these files? > My rc files has to be generated with configure_file, so my hope was that > configure_file will read utf8 and write utf16 if I want, but that seems not > possible. > Is there and other way in cake to convert to utf16? > > Greetings > Tonka > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 wolf at wolfsden.cz Mon Aug 29 04:01:29 2016 From: wolf at wolfsden.cz (Wolf) Date: Mon, 29 Aug 2016 10:01:29 +0200 Subject: [CMake] Convert UTF8 to UTF16 (Windows) In-Reply-To: References: Message-ID: <20160829080129.cpjpiu4qmtcwl36x@wolfsden.cz> On , tonka tonka wrote: > I have a little problem with files which has to be UTF 16 instead of UTF 8, > f.e. Visual studios .rc files. They must be utf16 and git detect it as bin > files. > So my question is: how do you handle these files? > My rc files has to be generated with configure_file, so my hope was that > configure_file will read utf8 and write utf16 if I want, but that seems not > possible. > Is there and other way in cake to convert to utf16? I would just use iconv for this. Call it as external program to do the conversion. W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From tonka3100 at gmail.com Mon Aug 29 05:01:04 2016 From: tonka3100 at gmail.com (tonka tonka) Date: Mon, 29 Aug 2016 11:01:04 +0200 Subject: [CMake] Convert UTF8 to UTF16 (Windows) In-Reply-To: References: Message-ID: Nicholas, you are right. My mistake was that i've used utf8 with BOM, but visual studio only likes without BOM. Thx Am 29.08.2016 09:47 schrieb "Nicholas Braden" : > Are you sure about this UTF16 requirement? I have many projects > ranging from Visual Studio 2008 to 2015 that use .rc files and all of > them are ANSI/UTF8. > > On Mon, Aug 29, 2016 at 2:43 AM, tonka tonka wrote: > > Hey, > > > > I have a little problem with files which has to be UTF 16 instead of UTF > 8, > > f.e. Visual studios .rc files. They must be utf16 and git detect it as > bin > > files. > > So my question is: how do you handle these files? > > My rc files has to be generated with configure_file, so my hope was that > > configure_file will read utf8 and write utf16 if I want, but that seems > not > > possible. > > Is there and other way in cake to convert to utf16? > > > > Greetings > > Tonka > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware 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 tonka3100 at gmail.com Mon Aug 29 09:02:45 2016 From: tonka3100 at gmail.com (tonka tonka) Date: Mon, 29 Aug 2016 15:02:45 +0200 Subject: [CMake] CMake/CTest no RUN_TESTS target Message-ID: Hey, I?ve try to get ctest running with my existing gtest-tests. I have my own findGTest, but should make no difference. My Problem is that I can?t see the RUN_TESTS target (I?m using Visual Studio). I follow the following tutorialhttps:// cmake.org/Wiki/CMake/Testing_With_CTest I?m start using enable_testing() I create my executable in my target-CMakeLists.txt file and add the test to CTest via add_test(MyTestName ThePathToMyExe) CMake should now create a RUN_TESTS target for me, but it does not happen. I?ve I use include(CTest) at the end I get many new targets f.e. continuous, nightly, etc. but no RUN_TESTS What I?m doing wrong? I use CMake 3.4.3 Greetings Tonka -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Mon Aug 29 11:52:38 2016 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Mon, 29 Aug 2016 11:52:38 -0400 Subject: [CMake] ExternalProject_Add not honoring the INSTALL_DIR argument. Message-ID: <57C45A46.3020400@bluequartz.net> I have the following CMake file: set(QHull_GIT_REPO "git://github.com/qhull/qhull") set(QHull_GIT_TAG "") set(QHull_INSTALL_NAME "qhull") set(QHull_INSTALL_NAME "qhull-2015.2") ExternalProject_Add(${QHull_INSTALL_NAME} PREFIX ${Fusion_SDK_ROOT} URL "http://www.qhull.org/download/qhull-2015-src-7.2.0.tgz" INSTALL_DIR=/tmp/Fusion/qhull-2015.2 LOG_DOWNLOAD 1 LOG_UPDATE 1 LOG_CONFIGURE 1 LOG_BUILD 1 LOG_INSTALL 1 ) and when I invoke the initial cmake with this: cmake -G Ninja -DBUILD_SHARED_LIBS=ON -DCMAKE_BUILD_TYPE=Release -DFusion_SDK_ROOT=/tmp/Fusion_SDK ../ I get a valid "configure" step. Then I run "ninja" and I get errors on installation. The errors are because CMake is attempting to install QHull in /usr/local/lib. Why is that? I am not sure what I am doing wrong as this seems like a pretty trivial case. I have cmake 3.5.1 and read the docs at https://cmake.org/cmake/help/v3.5/module/ExternalProject.html but somehow cmake is messing up. Thoughts? -- Michael A. Jackson BlueQuartz Software, LLC [e]: mike.jackson at bluequartz.net From nicholas11braden at gmail.com Mon Aug 29 11:54:48 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Mon, 29 Aug 2016 10:54:48 -0500 Subject: [CMake] ExternalProject_Add not honoring the INSTALL_DIR argument. In-Reply-To: <57C45A46.3020400@bluequartz.net> References: <57C45A46.3020400@bluequartz.net> Message-ID: Have you tried changing the = to a space, as with the other parameters? On Mon, Aug 29, 2016 at 10:52 AM, Michael Jackson wrote: > I have the following CMake file: > > set(QHull_GIT_REPO "git://github.com/qhull/qhull") > set(QHull_GIT_TAG "") > set(QHull_INSTALL_NAME "qhull") > set(QHull_INSTALL_NAME "qhull-2015.2") > > > ExternalProject_Add(${QHull_INSTALL_NAME} > PREFIX ${Fusion_SDK_ROOT} > URL "http://www.qhull.org/download/qhull-2015-src-7.2.0.tgz" > INSTALL_DIR=/tmp/Fusion/qhull-2015.2 > LOG_DOWNLOAD 1 > LOG_UPDATE 1 > LOG_CONFIGURE 1 > LOG_BUILD 1 > LOG_INSTALL 1 > > ) > > and when I invoke the initial cmake with this: > > cmake -G Ninja -DBUILD_SHARED_LIBS=ON -DCMAKE_BUILD_TYPE=Release > -DFusion_SDK_ROOT=/tmp/Fusion_SDK ../ > > I get a valid "configure" step. Then I run "ninja" and I get errors on > installation. The errors are because CMake is attempting to install QHull in > /usr/local/lib. > > Why is that? I am not sure what I am doing wrong as this seems like a pretty > trivial case. I have cmake 3.5.1 and read the docs at > https://cmake.org/cmake/help/v3.5/module/ExternalProject.html but somehow > cmake is messing up. > > Thoughts? > > > -- > Michael A. Jackson > BlueQuartz Software, LLC > [e]: mike.jackson at bluequartz.net > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From mike.jackson at bluequartz.net Mon Aug 29 12:00:03 2016 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Mon, 29 Aug 2016 12:00:03 -0400 Subject: [CMake] ExternalProject_Add not honoring the INSTALL_DIR argument. In-Reply-To: References: <57C45A46.3020400@bluequartz.net> Message-ID: <57C45C03.5020408@bluequartz.net> So that was a typo on my part but changing it had no effect after deleting every build/download/tmp/stamp directory and trying again. -- Michael A. Jackson BlueQuartz Software, LLC [e]: mike.jackson at bluequartz.net Nicholas Braden wrote: > Have you tried changing the = to a space, as with the other parameters? > > On Mon, Aug 29, 2016 at 10:52 AM, Michael Jackson > wrote: >> I have the following CMake file: >> >> set(QHull_GIT_REPO "git://github.com/qhull/qhull") >> set(QHull_GIT_TAG "") >> set(QHull_INSTALL_NAME "qhull") >> set(QHull_INSTALL_NAME "qhull-2015.2") >> >> >> ExternalProject_Add(${QHull_INSTALL_NAME} >> PREFIX ${Fusion_SDK_ROOT} >> URL "http://www.qhull.org/download/qhull-2015-src-7.2.0.tgz" >> INSTALL_DIR=/tmp/Fusion/qhull-2015.2 >> LOG_DOWNLOAD 1 >> LOG_UPDATE 1 >> LOG_CONFIGURE 1 >> LOG_BUILD 1 >> LOG_INSTALL 1 >> >> ) >> >> and when I invoke the initial cmake with this: >> >> cmake -G Ninja -DBUILD_SHARED_LIBS=ON -DCMAKE_BUILD_TYPE=Release >> -DFusion_SDK_ROOT=/tmp/Fusion_SDK ../ >> >> I get a valid "configure" step. Then I run "ninja" and I get errors on >> installation. The errors are because CMake is attempting to install QHull in >> /usr/local/lib. >> >> Why is that? I am not sure what I am doing wrong as this seems like a pretty >> trivial case. I have cmake 3.5.1 and read the docs at >> https://cmake.org/cmake/help/v3.5/module/ExternalProject.html but somehow >> cmake is messing up. >> >> Thoughts? >> >> >> -- >> Michael A. Jackson >> BlueQuartz Software, LLC >> [e]: mike.jackson at bluequartz.net >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 nicholas11braden at gmail.com Mon Aug 29 12:08:33 2016 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Mon, 29 Aug 2016 11:08:33 -0500 Subject: [CMake] ExternalProject_Add not honoring the INSTALL_DIR argument. In-Reply-To: <57C45C03.5020408@bluequartz.net> References: <57C45A46.3020400@bluequartz.net> <57C45C03.5020408@bluequartz.net> Message-ID: Hmm, you're right, I just tested and it seems the INSTALL_DIR is ignored or not handled properly, I'm not sure why. But if you use the CMAKE_ARGS option to manually set "-DCMAKE_INSTALL_PREFIX=/tmp/Fusion/qhull-2015.2" it works, so at least there's an easy workaround. Maybe someone else knows how the INSTALL_DIR option is meant to be used? On Mon, Aug 29, 2016 at 11:00 AM, Michael Jackson wrote: > So that was a typo on my part but changing it had no effect after deleting > every build/download/tmp/stamp directory and trying again. > > -- > Michael A. Jackson > BlueQuartz Software, LLC > [e]: mike.jackson at bluequartz.net > > > Nicholas Braden wrote: >> >> Have you tried changing the = to a space, as with the other parameters? >> >> On Mon, Aug 29, 2016 at 10:52 AM, Michael Jackson >> wrote: >>> >>> I have the following CMake file: >>> >>> set(QHull_GIT_REPO "git://github.com/qhull/qhull") >>> set(QHull_GIT_TAG "") >>> set(QHull_INSTALL_NAME "qhull") >>> set(QHull_INSTALL_NAME "qhull-2015.2") >>> >>> >>> ExternalProject_Add(${QHull_INSTALL_NAME} >>> PREFIX ${Fusion_SDK_ROOT} >>> URL "http://www.qhull.org/download/qhull-2015-src-7.2.0.tgz" >>> INSTALL_DIR=/tmp/Fusion/qhull-2015.2 >>> LOG_DOWNLOAD 1 >>> LOG_UPDATE 1 >>> LOG_CONFIGURE 1 >>> LOG_BUILD 1 >>> LOG_INSTALL 1 >>> >>> ) >>> >>> and when I invoke the initial cmake with this: >>> >>> cmake -G Ninja -DBUILD_SHARED_LIBS=ON -DCMAKE_BUILD_TYPE=Release >>> -DFusion_SDK_ROOT=/tmp/Fusion_SDK ../ >>> >>> I get a valid "configure" step. Then I run "ninja" and I get errors on >>> installation. The errors are because CMake is attempting to install QHull >>> in >>> /usr/local/lib. >>> >>> Why is that? I am not sure what I am doing wrong as this seems like a >>> pretty >>> trivial case. I have cmake 3.5.1 and read the docs at >>> https://cmake.org/cmake/help/v3.5/module/ExternalProject.html but somehow >>> cmake is messing up. >>> >>> Thoughts? >>> >>> >>> -- >>> Michael A. Jackson >>> BlueQuartz Software, LLC >>> [e]: mike.jackson at bluequartz.net >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware 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 yaronct at gmail.com Mon Aug 29 16:07:50 2016 From: yaronct at gmail.com (Yaron Cohen-Tal) Date: Mon, 29 Aug 2016 23:07:50 +0300 Subject: [CMake] Using a pathless library in an imported target. In-Reply-To: References: Message-ID: That did the trick, thanx! On Mon, Aug 29, 2016 at 12:28 AM, Benjamin Ballet wrote: > Create an imported interface instead of a static library. Then you can set > either INTERFACE_COMPILE_OPTIONS or INTERFACE_LINK_LIBRARIES properties. > > 2016-08-27 21:39 GMT+02:00 Yaron Cohen-Tal : > >> Hi, >> >> I try to make an imported target out of OpenGL, and I have some >> difficulty. Usually "OPENGL_gl_LIBRARY" is a full path (found with >> "find_library"), but sometimes (on Windows) it's a pathless library (e.g. >> "opengl32", set with the cmake command "set"). However an imported library >> requires the full path to the library. Any idea how to tackle it? >> >> Thanx, >> Yaron >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > > > -- > *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 reavertm at gmail.com Mon Aug 29 17:31:59 2016 From: reavertm at gmail.com (Maciej Mrozowski) Date: Mon, 29 Aug 2016 23:31:59 +0200 Subject: [CMake] add_custom_command and re-running command when target in DEPENDS was updated Message-ID: <1940401.Je6uuN5uvQ@liwardyna> Hello, I have a project that goes something along the lines of: (...) add_jar(generator src/javafile.java) (...) get_target_property(GENERATOR_PATH generator JAR_FILE) (...) add_custom_command ${CMAKE_CURRENT_BINARY_DIR}/generated.cpp COMMAND ${Java_JAVA_EXECUTABLE -jar ${GENERATOR_PATH} --output $ {CMAKE_CURRENT_BINARY_DIR}/generated.cpp DEPENDS generator some other static input files ) (...) add_executable(foo ${CMAKE_CURRENT_BINARY_DIR}/generated.cpp) The problem is: whenever I change javafile.java, target 'generator' is rebuilt, however, above command is NOT re-run, even though 'generator' is in DEPENDS, as a result, '${CMAKE_CURRENT_BINARY_DIR}/generated.cpp' is not regenerated and executable 'foo' is not recompiled. add_custom_command documentation says: The DEPENDS option specifies files on which the command depends. If any dependency is an OUTPUT of another custom command in the same directory (CMakeLists.txt file) CMake automatically brings the other custom command into the target in which this command is built. If DEPENDS is not specified the command will run whenever the OUTPUT is missing; if the command does not actually create the OUTPUT then the rule will always run. If DEPENDS specifies any target (created by an ADD_* command) a target-level dependency is created to make sure the target is built before any target using this custom command. Additionally, if the target is an executable or library a file-level dependency is created to cause the custom command to re-run whenever the target is recompiled. In my case, the target in DEPENDS is neither executable nor library (it's a jar created with add_jar). Is it possible to still make add_custom_command re-run in this case? I tried: set_source_file_properties( ${CMAKE_CURRENT_BINARY_DIR}/generated.cpp PROPERTIES OBJECT_DEPENDS ${GENERATOR_PATH} ) and it helps a bit (even though it doesn't make a sense, that target does not exist on first CMake run after all), but requires always two CMake runs to work. Searching ML, I found this: https://www.mail-archive.com/cmake%40cmake.org/msg24644.html I'm not including external files for parsing in CMake so I find myself reluctant to use suggested hack and invalidate CMake file by including some dummy file... -- regards MM From reavertm at gmail.com Mon Aug 29 17:44:30 2016 From: reavertm at gmail.com (Maciej Mrozowski) Date: Mon, 29 Aug 2016 23:44:30 +0200 Subject: [CMake] add_custom_command and re-running command when target in DEPENDS was updated In-Reply-To: <1940401.Je6uuN5uvQ@liwardyna> References: <1940401.Je6uuN5uvQ@liwardyna> Message-ID: <4244379.SUtfHYaurZ@liwardyna> On poniedzia?ek, 29 sierpnia 2016 23:31:59 CEST you wrote: > add_custom_command documentation says: > > > The DEPENDS option specifies files on which the command depends. If any > dependency is an OUTPUT of another custom command in the same directory > (CMakeLists.txt file) CMake automatically brings the other custom command > into the target in which this command is built. One possibly important note I forgot. Mentioned add_jar and add_custom_command in my case are NOT in the same directory, but I guess it should not matter since I have explicit 'DEPENDS generator'? -- regards MM From karl.ljungkvist at it.uu.se Tue Aug 30 05:02:29 2016 From: karl.ljungkvist at it.uu.se (Karl Ljungkvist) Date: Tue, 30 Aug 2016 11:02:29 +0200 Subject: [CMake] CUDA: COMPILE_DEFINITIONS not picked up In-Reply-To: References: <57BEE62C.50603@it.uu.se> Message-ID: <57C54BA5.7040706@it.uu.se> Peter, I use CMake 3.5.1 and 3.0.2, and this works the same with both. Thanks for your suggestions. It does indeed work if I define them explicitly like that, but the reason why I want to use something like COMPILE_DEFINITIONS is that we have a large library that has several targets with different setups (release and debug mode, for instance). Most of the library is regular C++ and there the COMPILE_DEFINITIONS propagates to all source files. Now I want it to propagate to any CUDA .cu files too. What would it take to FindCUDA respect COMPILE_DEFINITIONS too? Best, Karl On 2016-08-26 09:41, Peter Steinbach wrote: > Hey Karl, > > just gave it another shot ... so I can confirm what you saw with cmake > 3.3 (btw, what cmake version did you use?). I should try a more recent > one to make sure as well. > > anyhow, there 2 global workarounds that you have at your disposal: > 1) set(CUDA_NVCC_FLAGS "-Dfoo") needs to be called *BEFORE* any > cuda_add_xxx according to `cmake --help-module FindCUDA` > > 2) add_definitions(-Dfoo), I called it before cuda_add_xxx too and it > worked as well > > Hope that get's you going - > P -- Karl Ljungkvist PhD student Uppsala University Dept. of Information Technology Div. of Scientific Computing Box 337 SE-751 05 Uppsala, Sweden Email: karl.ljungkvist at it.uu.se Phone: +46 18 471 2967 Mobile: +46 70 2003565 From steinbach at scionics.de Tue Aug 30 10:09:57 2016 From: steinbach at scionics.de (Peter Steinbach) Date: Tue, 30 Aug 2016 16:09:57 +0200 Subject: [CMake] CUDA: COMPILE_DEFINITIONS not picked up In-Reply-To: <57C54BA5.7040706@it.uu.se> References: <57BEE62C.50603@it.uu.se> <57C54BA5.7040706@it.uu.se> Message-ID: <6e9301d3-2fef-3ce1-a03b-9406dfed18af@scionics.de> Karl, good question. The docs say that you supply OPTIONS to cuda_add_library, which are in turn handed over to cuda_wrap_srcs. the only chance I see is digging there. internally, both cuda_add_xxx create regular cmake targets. I am not sure why cmake doesn't accept subsequent set_target_properties calls on them. I cannot spare the time resources to dive into this further. Sorry! Maybe it's worthwhile to file a bug report and bring that to the attention of the FindCUDA.cmake author? Best, peter On 08/30/2016 11:02 AM, Karl Ljungkvist wrote: > Peter, > > I use CMake 3.5.1 and 3.0.2, and this works the same with both. > > Thanks for your suggestions. It does indeed work if I define them > explicitly like that, but the reason why I want to use something like > COMPILE_DEFINITIONS is that we have a large library that has several > targets with different setups (release and debug mode, for instance). > > Most of the library is regular C++ and there the COMPILE_DEFINITIONS > propagates to all source files. Now I want it to propagate to any CUDA > .cu files too. > > What would it take to FindCUDA respect COMPILE_DEFINITIONS too? > > Best, > Karl > > On 2016-08-26 09:41, Peter Steinbach wrote: >> Hey Karl, >> >> just gave it another shot ... so I can confirm what you saw with cmake >> 3.3 (btw, what cmake version did you use?). I should try a more recent >> one to make sure as well. >> >> anyhow, there 2 global workarounds that you have at your disposal: >> 1) set(CUDA_NVCC_FLAGS "-Dfoo") needs to be called *BEFORE* any >> cuda_add_xxx according to `cmake --help-module FindCUDA` >> >> 2) add_definitions(-Dfoo), I called it before cuda_add_xxx too and it >> worked as well >> >> Hope that get's you going - >> P > From reavertm at gmail.com Tue Aug 30 19:17:07 2016 From: reavertm at gmail.com (Maciej Mrozowski) Date: Wed, 31 Aug 2016 01:17:07 +0200 Subject: [CMake] [solved sort of] Re: add_custom_command and re-running command when target in DEPENDS was updated In-Reply-To: <4244379.SUtfHYaurZ@liwardyna> References: <1940401.Je6uuN5uvQ@liwardyna> <4244379.SUtfHYaurZ@liwardyna> Message-ID: <2455459.flHvJjIzLy@liwardyna> On poniedzia?ek, 29 sierpnia 2016 23:44:30 CEST you wrote: > On poniedzia?ek, 29 sierpnia 2016 23:31:59 CEST you wrote: > > add_custom_command documentation says: > > > > > > The DEPENDS option specifies files on which the command depends. If any > > dependency is an OUTPUT of another custom command in the same directory > > (CMakeLists.txt file) CMake automatically brings the other custom command > > into the target in which this command is built. > > One possibly important note I forgot. > Mentioned add_jar and add_custom_command in my case are NOT in the same > directory, but I guess it should not matter since I have explicit 'DEPENDS > generator'? Strangely enough, it is now sort of solved/worked around, though I still don't fully understand why. I think I placed: set_source_file_properties( ${CMAKE_CURRENT_BINARY_DIR}/generated.cpp PROPERTIES OBJECT_DEPENDS ${GENERATOR_PATH} ) after custom command definition and not before like previously I tried that (like it mattered whether it's before or after?) and touching file under $ {GENERATOR_PATH} actually triggers command to be re-run. Still I would like to know how to make command re-run in better way. -- regards MM From intelfx at intelfx.name Wed Aug 31 07:57:34 2016 From: intelfx at intelfx.name (Ivan Shapovalov) Date: Wed, 31 Aug 2016 14:57:34 +0300 Subject: [CMake] User-overriding IMPORTED targets (overlaying libraries, ...) Message-ID: <1472644654.10750.42.camel@intelfx.name> Hello, Let's suppose I have a project Foo which generates a shared library `libfoo.so`, and a project Bar which links to `foo` and builds an executable `bar`. Let's also suppose that as a maintainer, I wrote a library `libfoo_overlay.so` which links to `libfoo.so` and redefines certain symbols in that library (e. g. for hardware-specific optimizations which cannot be upstreamed). If the projects use the traditional find_package() module mode approach to find `foo`, then the FindFoo.cmake module will most likely define a CACHED variable Foo_LIBRARY, which I can then edit with ccmake, pointing it to `libfoo_overlay.so` instead of `libfoo.so`. This way, I do not need to patch either project's buildsystem, which is nice. However, if the two projects use a more-modern approach with config mode find_package() and IMPORTED targets, then I have no way to edit the definition of `foo` imported target to alter its LOCATION, because the target definition itself is not cached. Of course, I can always edit the FooConfig.cmake file manually, but I'd better avoid patching anything (installing new files or running any cmake commands is OK). Is there any nice way to solve this? -- Ivan Shapovalov / intelfx / -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From nick at appletonaudio.com Wed Aug 31 08:51:22 2016 From: nick at appletonaudio.com (Nick Appleton) Date: Wed, 31 Aug 2016 22:51:22 +1000 Subject: [CMake] CMake library installations and pkg-config Message-ID: <6BE05649-B850-412A-BEAC-CF485D91EDF0@appletonaudio.com> Hi, I?ve been recently doing a bit of work for an open source project trying to extend it?s support for CMake. I?ve been trying to get CMake to be able to replicate most of the functionality which can be achieved with the existing autoconf-based infrastructure (and have had pretty good success) but am struggling to figure out how to get CMake to generate pkg-config files on unix-ey systems. I?ve done quite a lot of searching, but have not found anything which provides a good solution for our use case. The project is called portaudio (a cross-platform, C, real-time audio library) and at present there is one CMakeLists.txt file which does everything (I?ve tried to keep it clean), you can see it here: https://app.assembla.com/spaces/portaudio/git/source/cmake_updates/CMakeLists.txt It looks for various audio libraries which may be present on the system using find_package() and associates them with the library which it defines using target_link_libraries(). This is all great when my CMake project includes portaudio (via add_subdirectory() and target_link_libraries() with one of the portaudio library targets), but if I want ?make install?-like functionality so that others can use a portaudio installation without requiring CMake, I would like to be able to generate a pkg-config file which contains the necessary linker arguments to pass when linking against the library. The generation of the pkg-config file is straight-forward using the configure_file() function, but I am struggling to find a way to: given a CMake target, create a variable containing the set of linker paths and library names to use in the pkg-config file. Can anyone give me some hints as to whether this is possible? Cheers, Nick From annulen at yandex.ru Wed Aug 31 09:32:23 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 31 Aug 2016 16:32:23 +0300 Subject: [CMake] CMake library installations and pkg-config In-Reply-To: <6BE05649-B850-412A-BEAC-CF485D91EDF0@appletonaudio.com> References: <6BE05649-B850-412A-BEAC-CF485D91EDF0@appletonaudio.com> Message-ID: <1241801472650343@web16o.yandex.ru> 31.08.2016, 16:22, "Nick Appleton" : > Hi, > > I?ve been recently doing a bit of work for an open source project trying to extend it?s support for CMake. I?ve been trying to get CMake to be able to replicate most of the functionality which can be achieved with the existing autoconf-based infrastructure (and have had pretty good success) but am struggling to figure out how to get CMake to generate pkg-config files on unix-ey systems. I?ve done quite a lot of searching, but have not found anything which provides a good solution for our use case. Do you consider contributing to https://api.kde.org/ecm/module/ECMGeneratePkgConfigFile.html ? > > The project is called portaudio (a cross-platform, C, real-time audio library) and at present there is one CMakeLists.txt file which does everything (I?ve tried to keep it clean), you can see it here: https://app.assembla.com/spaces/portaudio/git/source/cmake_updates/CMakeLists.txt > > It looks for various audio libraries which may be present on the system using find_package() and associates them with the library which it defines using target_link_libraries(). This is all great when my CMake project includes portaudio (via add_subdirectory() and target_link_libraries() with one of the portaudio library targets), but if I want ?make install?-like functionality so that others can use a portaudio installation without requiring CMake, I would like to be able to generate a pkg-config file which contains the necessary linker arguments to pass when linking against the library. The generation of the pkg-config file is straight-forward using the configure_file() function, but I am struggling to find a way to: given a CMake target, create a variable containing the set of linker paths and library names to use in the pkg-config file. > > Can anyone give me some hints as to whether this is possible? > > Cheers, > > Nick > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin