From elfring at users.sourceforge.net Tue Sep 1 04:38:36 2015 From: elfring at users.sourceforge.net (SF Markus Elfring) Date: Tue, 1 Sep 2015 10:38:36 +0200 Subject: [CMake] Enhanced version management for the command "project" Message-ID: <55E5640C.7060401@users.sourceforge.net> Hello, CMake provides an interface for the specification of version information by the command "project". http://www.cmake.org/cmake/help/v3.3/command/project.html I find that there is a growing need to extend it. 1. How do you think about to preserve a software release tag there? 2. Software packages can often evolve and deviate from the specified version numbers after the moment they were copied to an useful location. Would you like to distinguish the extensions to a base version by any additional data (like a commit hash or revision identifier) from a content management system? Regards, Markus From ralf.habacker at freenet.de Tue Sep 1 08:47:25 2015 From: ralf.habacker at freenet.de (Ralf Habacker) Date: Tue, 1 Sep 2015 14:47:25 +0200 Subject: [CMake] How to exclude top level directory from install(DIRECTORY) Message-ID: <55E59E5D.3080204@freenet.de> Hi, in a cmake project I have a directory structure like shown below: source/ subdir1/ subdir2/ file subdir2/ file which should be installed partially. In one install call I need to exclude subdir1/subdir2 which could be performed with the following install command. install(DIRECTORY source DESTINATION . REGEX subdir1/subdir2 EXCLUDE) but it looks impossible to exclude the top level subdir2. I tried several variations. install(DIRECTORY source DESTINATION . REGEX subdir2 EXCLUDE) -> excludes all directory named 'subdir2' install(DIRECTORY source DESTINATION . REGEX /subdir2 EXCLUDE) - does not match any subdir install(DIRECTORY source DESTINATION . REGEX ./subdir2 EXCLUDE) - does not match any subdir install(DIRECTORY source DESTINATION . REGEX ^subdir2 EXCLUDE) - does not match any subdir install(DIRECTORY source DESTINATION . REGEX ^/subdir2 EXCLUDE) - does not match any subdir install(DIRECTORY source DESTINATION . REGEX ^./subdir2 EXCLUDE) - does not match any subdir How to proceed ? Regards Ralf From csiga.biga at aol.com Tue Sep 1 09:03:54 2015 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Tue, 1 Sep 2015 15:03:54 +0200 Subject: [CMake] packageConfig mishap Message-ID: Hi! I'm trying to use the package config file of clFFT (big congrats on providing one), but it seems I'm doing something wrong. Without using FindclFFT.cmake, CMake fails to find the config files, both on Windows and Ubuntu. On Windows I have a registry entry such as: PS C:\Users\Matty> Get-ItemProperty -Path HKCU:\SOFTWARE\Kitware\CMake\Packages\ clFFT_2.6.1 : C:\Kellekek\AMD\clFFT\2.6.1\CMake PSPath : Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\SOFTWARE\Kitware\CMake\Packages\ PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\SOFTWARE\Kitware\CMake PSChildName : Packages PSDrive : HKCU PSProvider : Microsoft.PowerShell.Core\Registry and also on Linux: mnagy at opteron:~/Build/clFFT_Test/opteron$ cat ~/.cmake/packages/clFFT_2.6.1.package /opt/AMD/clFFT/2.6.1/lib64/cmake/clFFT but every time I configure a project, I get the following error: mnagy at opteron:~/Build/clFFT_Test/opteron$ cmake -D CMAKE_BUILD_TYPE=Release ~/Develop/clFFT_Test/ -- The C compiler identification is GNU 4.8.2 -- The CXX compiler identification is GNU 4.8.2 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Warning at CMakeLists.txt:39 (find_package): By not providing "FindclFFT.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "clFFT", but CMake did not find one. Could not find a package configuration file provided by "clFFT" with any of the following names: clFFTConfig.cmake clfft-config.cmake Add the installation prefix of "clFFT" to CMAKE_PREFIX_PATH or set "clFFT_DIR" to a directory containing one of the above files. If "clFFT" provides a separate development package or SDK, be sure it has been installed. CMake Warning at CMakeLists.txt:40 (find_package): By not providing "FindOpenCL.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "OpenCL", but CMake did not find one. Could not find a package configuration file provided by "OpenCL" with any of the following names: OpenCLConfig.cmake opencl-config.cmake Add the installation prefix of "OpenCL" to CMAKE_PREFIX_PATH or set "OpenCL_DIR" to a directory containing one of the above files. If "OpenCL" provides a separate development package or SDK, be sure it has been installed. -- Configuring done -- Generating done -- Build files have been written to: /home/mnagy/Build/clFFT_Test/opteron Without providing CMAKE_PREFIX_PATH on the command-line, the paclage config files do not work. What exactly am I doing wrong? According to the CMake wiki http://www.cmake.org/Wiki/CMake/Tutorials/Package_Registry it should be working automatically (as is the whole purpose of packages). -------------- next part -------------- An HTML attachment was scrubbed... URL: From bmorgan.warwick at gmail.com Tue Sep 1 10:02:01 2015 From: bmorgan.warwick at gmail.com (Ben Morgan) Date: Tue, 1 Sep 2015 15:02:01 +0100 Subject: [CMake] Adding Compile Features/Flags for Intel and other Compilers Message-ID: Hi, I've been using the new compile features functionality for working with C++11 and beyond (very useful!!). However, I've run into issues (probably misunderstandings) trying to extend it to compilers for which CMake doesn't currently provide a -CXX-FeatureTests.cmake file. Of course long term, these will be added (and I'm happy to contribute here), but on shorter timescales and to potentially support older CMake 3 series I wanted to see if I could provide files/settings in my own project to do this. Initially I thought about providing the file as a module in my project (e.g. for Intel) and then prepending the directory holding it to CMAKE_MODULE_PATH. However, all the files using the feature testing system appear to use absolute paths (via CMAKE_ROOT) to load the relevant file, so this appears to be a no-go. I then looked at setting the CMAKE_CXX11_COMPILE_FEATURES and CMAKE_CXX11_{STANDARD,EXTENSION}_COMPILE_OPTION variables directly after the initial project call. This appears to work for compile features, but not for compile options. Here's my simple test case (NB no version checking of Intel yet...) cmake_minimum_required(VERSION 3.1) project(IntelCompileFeatures CXX) if(CMAKE_CXX_COMPILER_ID MATCHES "Intel") message(STATUS "CMAKE_COMPILER_ID matches 'Intel'") set(CMAKE_CXX11_COMPILE_FEATURES cxx_auto_type cxx_range_for) set(CMAKE_CXX_COMPILE_FEATURES ${CMAKE_CXX11_COMPILE_FEATURES}) set(CMAKE_CXX11_STANDARD_COMPILE_OPTION "-std=c++11") set(CMAKE_CXX11_EXTENSION_COMPILE_OPTION "-std=c++11") endif() file(WRITE "testIntel.cpp" " #include int main() { std::string foo(\"helloworld\"); for (auto& i : foo) { std::cout << i << std::endl; } } ") add_executable(testIntel testIntel.cpp) target_compile_features(testIntel PRIVATE cxx_auto_type cxx_range_for ) This will pass the configure/generate stage fine, as CMake configures and generates recognising the features set on `testIntel`, but the compile option -std=c++11 isn't added to the compile flags. I've cross-checked on the usage of CMAKE_CXX11_{STANDARD,EXTENSION}_COMPILE_OPTION and here I've been able to modify it after project has been called and see the modified version appear in the build time flags. I'm therefore not sure if I've misunderstood how CMAKE_CXX11_{STANDARD,EXTENSION}_COMPILE_OPTION is supposed to work, or if there's some other setting I'm missing. Any help or suggestions gratefully received!! Thanks, Ben Morgan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergiu.dotenco at gmail.com Tue Sep 1 11:03:30 2015 From: sergiu.dotenco at gmail.com (Sergiu Dotenco) Date: Tue, 1 Sep 2015 17:03:30 +0200 Subject: [CMake] Per build configuration variables In-Reply-To: <55E38D8A.7060405@gmail.com> References: <55E38D8A.7060405@gmail.com> Message-ID: <55E5BE42.2030109@gmail.com> On 8/31/2015 1:11 AM, Sergiu Dotenco wrote: > I would like to pass different library directories to fixup_bundle, > depending what configuration is currently active. Right now, I define a > cache variable consisting of DLL directories: > > set (RUNTIME_LIBRARY_DIRS "C:/Foo/Release/bin;..." CACHE STRING "") > > This is problematic, since for a different build configuration (for > instance RelWithDebInfo or even Debug) this set of directories would > probably be different as well. For Makefile generators I can use > CMAKE_BUILD_TYPE to decide which variables to select. However, this does > not work in an environment that supports multiconfiguration, such as > Visual Studio or Xcode, because the selection must be done at build time. > > Any ideas how can one achieve this? > Got it. One can use CMAKE_INSTALL_CONFIG_NAME in install (CODE "..."). From Daniel.Macumber at nrel.gov Tue Sep 1 11:51:11 2015 From: Daniel.Macumber at nrel.gov (Macumber, Daniel) Date: Tue, 1 Sep 2015 15:51:11 +0000 Subject: [CMake] Patch on Windows? Message-ID: There was a thread back in January of 2014 about "It would be great if CMake implemented a "cmake -E patch".". This feature would really help us out, especially since the patch tool was removed from the Git for Windows distribution (I have no idea why). Did anything ever happen with this request? Thanks a lot, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Tue Sep 1 12:30:51 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue, 1 Sep 2015 12:30:51 -0400 Subject: [CMake] Patch on Windows? In-Reply-To: References: Message-ID: <55E5D2BB.4050908@kitware.com> On 9/1/2015 11:51 AM, Macumber, Daniel wrote: > There was a thread back in January of 2014 about ?It would be great if > CMake implemented a "cmake -E patch".?. This feature would really help > us out, especially since the patch tool was removed from the Git for > Windows distribution (I have no idea why). Did anything ever happen > with this request? > > Would be a great contribution but I don't think there is a compatible license patch library that is around. I have looked in the past. This one requires Qt: https://github.com/arrbee/google-diff-match-patch/blob/master/cpp/diff_match_patch.h -Bill From fotosentido at gmail.com Tue Sep 1 16:02:30 2015 From: fotosentido at gmail.com (Marcos) Date: Tue, 1 Sep 2015 22:02:30 +0200 Subject: [CMake] Subclass of external library: unresolved external symbol Message-ID: Hi, I can use and include VTK libraries in my project, but I did a vtkInteractorStyleImage subclass, just overriding a method: #ifndef dcmInteractorStyleImage_h #define dcmInteractorStyleImage_h #include "vtkInteractionStyleModule.h" // For export macro #include "vtkInteractorStyleImage.h" class VTKINTERACTIONSTYLE_EXPORT dcmInteractorStyle : public vtkInteractorStyleImage { public: static dcmInteractorStyle *New(); vtkTypeMacro(dcmInteractorStyle, vtkInteractorStyleImage); virtual void OnLeftButtonDown(); void PrintSelf(ostream& os, vtkIndent indent); }; #endif ---------------------------------------------------------------- The thing is I use it in a Qt class. So I include this in my CMakeLists.txt: set(GENERIC_VIEW_CPP View/UI/dcminteractorstyle.cpp ) SET(GENERIC_VIEW_H View/UI/dcminteractorstyle.h ) add_library(generic ${GENERIC_VIEW_CPP} ${GENERIC_VIEW_H}) ... add_library(ui_qt ${UI_QT_CXX} ${UI_FORM_HEADERS} ${UI_RESOURCES_RCC} ${MODEL_WRAPPED_HEADERS} ${GENERIC_VIEW_CPP} ${GENERIC_VIEW_H} #necesary here? ) qt5_use_modules(ui_qt Core Gui Widgets) ... set_source_files_properties(${UI_RESOURCES_RCC} PROPERTIES GENERATED ON) add_executable(UtilidadDICOM WIN32 main.cpp ${UI_RESOURCES_RCC}) target_link_libraries(UtilidadDICOM model ui_qt generic ${Glue} ${VTK_LIBRARIES} ${ITK_LIBRARIES} ) ------------------------------------------------------------------ The error trying to compile: ui_qt.lib(viewerwidget.cpp.obj):-1: error: LNK2019: unresolved external symbol "public: static class dcmInteractorStyle * __cdecl dcmInteractorStyle::New(void)" (?New at dcmInteractorStyle@@SAPAV1 at XZ) referenced in function "public: static class vtkSmartPointer __cdecl vtkSmartPointer::New(void)" (?New@?$vtkSmartPointer at VdcmInteractorStyle@@@@SA?AV1 at XZ) ui_qt is a library declared in CMake, as you can see above. Any ideas? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsvanbethlehem at gmail.com Wed Sep 2 02:36:31 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Wed, 2 Sep 2015 08:36:31 +0200 Subject: [CMake] Subclass of external library: unresolved external symbol In-Reply-To: References: Message-ID: <79F3A768-FDB4-46EC-8F99-B9CF2910C8AF@gmail.com> Hej, Seems to me at first sight you didn?t implement the New() function Greetsz, Jakob > On 01 Sep 2015, at 22:02, Marcos wrote: > > Hi, > > I can use and include VTK libraries in my project, but I did a vtkInteractorStyleImage subclass, just overriding a method: > > > #ifndef dcmInteractorStyleImage_h > #define dcmInteractorStyleImage_h > > #include "vtkInteractionStyleModule.h" // For export macro > #include "vtkInteractorStyleImage.h" > > class VTKINTERACTIONSTYLE_EXPORT dcmInteractorStyle : public vtkInteractorStyleImage > { > public: > static dcmInteractorStyle *New(); > vtkTypeMacro(dcmInteractorStyle, vtkInteractorStyleImage); > > virtual void OnLeftButtonDown(); > > void PrintSelf(ostream& os, vtkIndent indent); > }; > > > #endif > ---------------------------------------------------------------- > > The thing is I use it in a Qt class. So I include this in my CMakeLists.txt: > > set(GENERIC_VIEW_CPP > View/UI/dcminteractorstyle.cpp > ) > > SET(GENERIC_VIEW_H > View/UI/dcminteractorstyle.h > ) > > add_library(generic ${GENERIC_VIEW_CPP} ${GENERIC_VIEW_H}) > ... > add_library(ui_qt ${UI_QT_CXX} > ${UI_FORM_HEADERS} ${UI_RESOURCES_RCC} > ${MODEL_WRAPPED_HEADERS} > ${GENERIC_VIEW_CPP} ${GENERIC_VIEW_H} #necesary here? > ) > qt5_use_modules(ui_qt Core Gui Widgets) > ... > set_source_files_properties(${UI_RESOURCES_RCC} PROPERTIES GENERATED ON) > add_executable(UtilidadDICOM WIN32 main.cpp ${UI_RESOURCES_RCC}) > target_link_libraries(UtilidadDICOM > model > ui_qt > generic > ${Glue} > ${VTK_LIBRARIES} > ${ITK_LIBRARIES} > ) > ------------------------------------------------------------------ > The error trying to compile: > ui_qt.lib(viewerwidget.cpp.obj):-1: error: LNK2019: unresolved external symbol "public: static class dcmInteractorStyle * __cdecl dcmInteractorStyle::New(void)" (?New at dcmInteractorStyle@@SAPAV1 at XZ) referenced in function "public: static class vtkSmartPointer __cdecl vtkSmartPointer::New(void)" (?New@?$vtkSmartPointer at VdcmInteractorStyle@@@@SA?AV1 at XZ) > > ui_qt is a library declared in CMake, as you can see above. > > Any ideas? Thank you. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at sap.com Wed Sep 2 02:56:55 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Wed, 2 Sep 2015 06:56:55 +0000 Subject: [CMake] Patch on Windows? Message-ID: <34C188D9-E2B9-482A-814D-157A10FEAAC3@sap.com> FYI, the latest version (2.5.1) of git for Windows (available https://github.com/git-for-windows/git/releases and http://git-scm.com/) includes again the patch tool. Marc From: CMake on behalf of "Macumber, Daniel" Date: Tuesday 1 September 2015 17:51 To: "cmake at cmake.org" Subject: [CMake] Patch on Windows? There was a thread back in January of 2014 about ?It would be great if CMake implemented a "cmake -E patch".?. This feature would really help us out, especially since the patch tool was removed from the Git for Windows distribution (I have no idea why). Did anything ever happen with this request? Thanks a lot, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ngeorghiou at iprimus.com.au Wed Sep 2 03:21:11 2015 From: ngeorghiou at iprimus.com.au (Nick Georghiou) Date: Wed, 2 Sep 2015 17:21:11 +1000 Subject: [CMake] How to link the output of a custom command (VS2013) when the output is an obj file, since LinkObjects is hardcoded to false? Message-ID: <01bc01d0e54f$f295b920$d7c12b60$@iprimus.com.au> Hi, I have the custom command provided below which successfully creates mydll.obj in the correct intermediate directory. However the LinkObjects property of the custom command within Visual Studio 2013 is set to false and therefore the object file is not linked. Upon inspection of the CMake code, it seems that the LinkObjects property is hardcoded to false and there is no cmake option to specify otherwise. Is there another way to get the object file to link that I am missing. Any help on this would be greatly appreciated. --- My custom command: add_custom_command( OUTPUT "$(IntDir)mydll.obj" COMMAND ml64.exe /c /nologo /Fo"$(IntDir)mydll.obj" /Zi "%(FullPath)" MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/mydll.asm) --- CMake code in file cmVisualStudio10TargetGenerator.cxx: if(this->LocalGenerator->GetVersion() > cmGlobalVisualStudioGenerator::VS10) { // VS >= 11 let us turn off linking of custom command outputs. this->WritePlatformConfigTag("LinkObjects", i->c_str(), 3); (*this->BuildFileStream ) << "false\n"; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From yaronct at gmail.com Wed Sep 2 03:40:49 2015 From: yaronct at gmail.com (Yaron Cohen-Tal) Date: Wed, 2 Sep 2015 10:40:49 +0300 Subject: [CMake] Unable to locate the project's shared library when running the tests Message-ID: Hi, My project is a shared library, and my tests are linked to that shared library. When I try to run the tests, they fail because they can't find the DLL of the project. The "CMakeLists.txt" of the tests is in a different folder ("test/") than that of the shared lib ("src/"), and therefore they're built in different directories. Currently I'm using Visual Studio, and the DLL of the project is built in "src\Debug\", and the executables of the tests are built in "test\Debug\"; That is, for a debug build of course. What would be the best solution to b able to run the tests? I'm currently with Visual Studio but I guess the same problem would arise on Linux and OS X, and it should work there too. Thanx, Yaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleigh at codelibre.net Wed Sep 2 04:15:46 2015 From: rleigh at codelibre.net (Roger Leigh) Date: Wed, 2 Sep 2015 09:15:46 +0100 Subject: [CMake] Unable to locate the project's shared library when running the tests In-Reply-To: References: Message-ID: <55E6B032.2010400@codelibre.net> On 02/09/2015 08:40, Yaron Cohen-Tal wrote: > Hi, > > My project is a shared library, and my tests are linked to that shared > library. When I try to run the tests, they fail because they can't find > the DLL of the project. The "CMakeLists.txt" of the tests is in a > different folder ("test/") than that of the shared lib ("src/"), and > therefore they're built in different directories. Currently I'm using > Visual Studio, and the DLL of the project is built in "src\Debug\", and > the executables of the tests are built in "test\Debug\"; That is, for a > debug build of course. What would be the best solution to b able to run > the tests? I'm currently with Visual Studio but I guess the same problem > would arise on Linux and OS X, and it should work there too. On Linux/BSD/MacOS it's using rpath so it works without any special effort on your part. On Windows, you do need to set the test environment so it can find all the DLLs. To do this, I did this for libtiff: macro(tiff_test_reader name command infile) add_test(NAME "${name}" COMMAND "${CMAKE_COMMAND}" [... other options...] "-DTIFFINFO=$" "-DLIBTIFF=$" -P "${CMAKE_CURRENT_SOURCE_DIR}/TiffTest.cmake") endmacro() where TIFFINFO is an executable run by the test and LIBTIFF is the library used by this executable. Note we pass these options as generator expressions so you can run "ctest -C Debug|Release" and have it use the executable and library from the debug or release build. TiffTest.cmake is a wrapper to run the test. It's doing this: # Add the directory containing libtiff to the PATH (Windows only) if(WIN32) get_filename_component(LIBTIFF_DIR "${LIBTIFF}" DIRECTORY) file(TO_NATIVE_PATH "${LIBTIFF_DIR}" LIBTIFF_DIR) set(ENV{PATH} "${LIBTIFF_DIR};$ENV{PATH}") endif() and then it runs the test command and specified options via execute_process(). i.e. we've added a level of indirection when running the tests via a standalone cmake script. There may be better ways of doing this. I'd certainly be keen to simplify things! Regards, Roger From nico.schloemer at gmail.com Wed Sep 2 04:22:08 2015 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Wed, 02 Sep 2015 08:22:08 +0000 Subject: [CMake] linking: absolute path vs -l In-Reply-To: <4451129.mAJvdXgu70@tuxedo.neundorf.net> References: <4451129.mAJvdXgu70@tuxedo.neundorf.net> Message-ID: > it uses -l if the full path is not know or if the full path is one of the system library dirs Hm, that sound a little weird. Using `-l` appears to delegate the library finding to the linker although CMake has already done that job. If one was overly cautious, one could ask questions like: What if there are two libraries by the same name in different system library dirs? What if there's only one library in a system dir at configure time, but two at link time? Moreover, in the example I gave above it seems that both libraries are in the system path, yet still they are represented differently on the link line. --Nico On Mon, Aug 31, 2015 at 10:33 PM Alexander Neundorf wrote: > On Friday, August 28, 2015 08:23:47 Nico Schl?mer wrote: > > Hi everyone, > > > > I'm curious about when CMake decides to link a library by its absolute > path > > and when it links using the `-l*` syntax. I came across this for the very > > simple test problem > > ``` > > cmake_minimum_required(VERSION 3.0) > > > > project(mytest) > > > > find_package(ZLIB REQUIRED) > > find_package(netCDF REQUIRED) > > > > add_executable(mytest main.cpp) > > target_link_libraries( > > mytest > > ${ZLIB_LIBRARIES} > > ${netCDF_LIBRARIES} > > ) > > ``` > > The resulting link line is > > ``` > > /usr/bin/c++ CMakeFiles/mytest.dir/main.cpp.o -o mytest -rdynamic > > -lz /usr/lib/x86_64-linux-gnu/libnetcdf.so.7.3.0 > > ``` > > so ZLIB is linked with `-lz`, netCDF with the full absolute path. > > > > Seems inconsistent? (ZLIB by the way is found through CMake's > > FindZLIB.cmake, netCDF by their own export files.) > > > > So far, I had been under the impression that `-l*` defeats the purpose of > > CMake a little bit as it asks the linker to search in the system's paths > > for a libz.so, something CMake has already done. > > > > A little clarification here would be great. > > it uses -l if the full path is not know or if the full path is one of the > system library dirs (like e.g. /usr/lib/ or the, IIRC, $LIBRARY_PATH > env.var) > > Alex > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Wed Sep 2 06:13:18 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Wed, 02 Sep 2015 12:13:18 +0200 Subject: [CMake] How to link the output of a custom command (VS2013) when the output is an obj file, since LinkObjects is hardcoded to false? In-Reply-To: <01bc01d0e54f$f295b920$d7c12b60$@iprimus.com.au> References: <01bc01d0e54f$f295b920$d7c12b60$@iprimus.com.au> Message-ID: <5996052E-FEE5-46E8-A1A5-E2F844C42B06@hendrik-sattler.de> Hi, why don't you just add the asm file to your add_library() call and enable the ASM language? HS Am 2. September 2015 09:21:11 MESZ, schrieb Nick Georghiou : >Hi, > > > >I have the custom command provided below which successfully creates >mydll.obj in the correct intermediate directory. However the >LinkObjects >property of the custom command within Visual Studio 2013 is set to >false and >therefore the object file is not linked. Upon inspection of the CMake >code, >it seems that the LinkObjects property is hardcoded to false and there >is no >cmake option to specify otherwise. > > > >Is there another way to get the object file to link that I am missing. >Any >help on this would be greatly appreciated. > > > >--- > > > >My custom command: > > > >add_custom_command( > > OUTPUT "$(IntDir)mydll.obj" > > COMMAND ml64.exe /c /nologo /Fo"$(IntDir)mydll.obj" /Zi "%(FullPath)" > > MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/mydll.asm) > > > >--- > > > >CMake code in file cmVisualStudio10TargetGenerator.cxx: > > > > if(this->LocalGenerator->GetVersion() > > > >cmGlobalVisualStudioGenerator::VS10) > > { > > // VS >= 11 let us turn off linking of custom command outputs. > > this->WritePlatformConfigTag("LinkObjects", i->c_str(), 3); > > (*this->BuildFileStream ) << "false\n"; > > } > > } > > > > > > > >------------------------------------------------------------------------ > >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: >http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For >more information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware open-source projects at >http://www.kitware.com/opensource/opensource.html > >Follow this link to subscribe/unsubscribe: >http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Wed Sep 2 06:11:24 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Wed, 02 Sep 2015 12:11:24 +0200 Subject: [CMake] linking: absolute path vs -l In-Reply-To: References: Message-ID: <50AC801A-A583-498A-8735-C6C0BA516FAD@hendrik-sattler.de> Hi, is the netcdf find module defining an imported target? AFAIK, imported targets are always linked by full path. Else the rules already mentioned apply. HS Am 28. August 2015 10:23:47 MESZ, schrieb "Nico Schl?mer" : >Hi everyone, > >I'm curious about when CMake decides to link a library by its absolute >path >and when it links using the `-l*` syntax. I came across this for the >very >simple test problem >``` >cmake_minimum_required(VERSION 3.0) > >project(mytest) > >find_package(ZLIB REQUIRED) >find_package(netCDF REQUIRED) > >add_executable(mytest main.cpp) >target_link_libraries( > mytest > ${ZLIB_LIBRARIES} > ${netCDF_LIBRARIES} > ) >``` >The resulting link line is >``` >/usr/bin/c++ CMakeFiles/mytest.dir/main.cpp.o -o mytest >-rdynamic >-lz /usr/lib/x86_64-linux-gnu/libnetcdf.so.7.3.0 >``` >so ZLIB is linked with `-lz`, netCDF with the full absolute path. > >Seems inconsistent? (ZLIB by the way is found through CMake's >FindZLIB.cmake, netCDF by their own export files.) > >So far, I had been under the impression that `-l*` defeats the purpose >of >CMake a little bit as it asks the linker to search in the system's >paths >for a libz.so, something CMake has already done. > >A little clarification here would be great. > >Cheers, >Nico > > >------------------------------------------------------------------------ > >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: >http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For >more information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware 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 ngeorghiou at iprimus.com.au Wed Sep 2 10:08:21 2015 From: ngeorghiou at iprimus.com.au (Nick Georghiou) Date: Thu, 3 Sep 2015 00:08:21 +1000 Subject: [CMake] How to link the output of a custom command (VS2013) when the output is an obj file, since LinkObjects is hardcoded to false? In-Reply-To: <5996052E-FEE5-46E8-A1A5-E2F844C42B06@hendrik-sattler.de> References: <01bc01d0e54f$f295b920$d7c12b60$@iprimus.com.au> <5996052E-FEE5-46E8-A1A5-E2F844C42B06@hendrik-sattler.de> Message-ID: <01e701d0e588$d3b9da70$7b2d8f50$@iprimus.com.au> Hi, Thanks for the quick reply. I enabled asm language and it now links. Apologies for the noob question; Thanks Nick From: Hendrik Sattler [mailto:post at hendrik-sattler.de] Sent: Wednesday, 2 September 2015 8:13 PM To: ngeorghiou at iprimus.com.au; cmake at cmake.org Subject: Re: [CMake] How to link the output of a custom command (VS2013) when the output is an obj file, since LinkObjects is hardcoded to false? Hi, why don't you just add the asm file to your add_library() call and enable the ASM language? HS Am 2. September 2015 09:21:11 MESZ, schrieb Nick Georghiou : Hi, I have the custom command provided below which successfully creates mydll.obj in the correct intermediate directory. However the LinkObjects property of the custom command within Visual Studio 2013 is set to false and therefore the object file is not linked. Upon inspection of the CMake code, it seems that the LinkObjects property is hardcoded to false and there is no cmake option to specify otherwise. Is there another way to get the object file to link that I am missing. Any help on this would be greatly appreciated. --- My custom command: add_custom_command( OUTPUT "$(IntDir)mydll.obj" COMMAND ml64.exe /c /nologo /Fo"$(IntDir)mydll.obj" /Zi "%(FullPath)" MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/mydll.asm) --- CMake code in file cmVisualStudio10TargetGenerator.cxx: if(this->LocalGenerator->GetVersion() > cmGlobalVisualStudioGenerator::VS10) { // VS >= 11 let us turn off linking of custom command outputs. this->WritePlatformConfigTag("LinkObjects", i->c_str(), 3); (*this->BuildFileStream ) << "false\n"; } } -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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 Wed Sep 2 11:40:57 2015 From: yaronct at gmail.com (Yaron Cohen-Tal) Date: Wed, 2 Sep 2015 18:40:57 +0300 Subject: [CMake] Unable to locate the project's shared library when running the tests In-Reply-To: <55E6B032.2010400@codelibre.net> References: <55E6B032.2010400@codelibre.net> Message-ID: Thanx, it worked! You might even be surprised that it worked without the "TO_NATIVE_PATH" - my Windows (8.1) seems to know how to handle "/" in the "PATH"! Nevertheless I'll use it, to be on the safe side. On Wed, Sep 2, 2015 at 11:15 AM, Roger Leigh wrote: > On 02/09/2015 08:40, Yaron Cohen-Tal wrote: > >> Hi, >> >> My project is a shared library, and my tests are linked to that shared >> library. When I try to run the tests, they fail because they can't find >> the DLL of the project. The "CMakeLists.txt" of the tests is in a >> different folder ("test/") than that of the shared lib ("src/"), and >> therefore they're built in different directories. Currently I'm using >> Visual Studio, and the DLL of the project is built in "src\Debug\", and >> the executables of the tests are built in "test\Debug\"; That is, for a >> debug build of course. What would be the best solution to b able to run >> the tests? I'm currently with Visual Studio but I guess the same problem >> would arise on Linux and OS X, and it should work there too. >> > > On Linux/BSD/MacOS it's using rpath so it works without any special effort > on your part. > > On Windows, you do need to set the test environment so it can find all the > DLLs. To do this, I did this for libtiff: > > > macro(tiff_test_reader name command infile) > add_test(NAME "${name}" > COMMAND "${CMAKE_COMMAND}" > [... other options...] > "-DTIFFINFO=$" > "-DLIBTIFF=$" > -P "${CMAKE_CURRENT_SOURCE_DIR}/TiffTest.cmake") > endmacro() > > where TIFFINFO is an executable run by the test and LIBTIFF is the library > used by this executable. Note we pass these options as generator > expressions so you can run "ctest -C Debug|Release" and have it use the > executable and library from the debug or release build. > > TiffTest.cmake is a wrapper to run the test. It's doing this: > > # Add the directory containing libtiff to the PATH (Windows only) > if(WIN32) > get_filename_component(LIBTIFF_DIR "${LIBTIFF}" DIRECTORY) > file(TO_NATIVE_PATH "${LIBTIFF_DIR}" LIBTIFF_DIR) > set(ENV{PATH} "${LIBTIFF_DIR};$ENV{PATH}") > endif() > > and then it runs the test command and specified options via > execute_process(). > > i.e. we've added a level of indirection when running the tests via a > standalone cmake script. > > There may be better ways of doing this. I'd certainly be keen to simplify > things! > > > Regards, > Roger > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Wed Sep 2 13:20:05 2015 From: d3ck0r at gmail.com (J Decker) Date: Wed, 2 Sep 2015 10:20:05 -0700 Subject: [CMake] Unable to locate the project's shared library when running the tests In-Reply-To: References: <55E6B032.2010400@codelibre.net> Message-ID: On Wed, Sep 2, 2015 at 8:40 AM, Yaron Cohen-Tal wrote: > Thanx, it worked! > > You might even be surprised that it worked without the "TO_NATIVE_PATH" - my > Windows (8.1) seems to know how to handle "/" in the "PATH"! Nevertheless > I'll use it, to be on the safe side. > I'm not surprised. It would work on NT 3.51. Windows never cared about the direction of slashes in file paths. It's only applications that do. (command line arguments often used '/' so they use it as a flag that it should be an argument) > On Wed, Sep 2, 2015 at 11:15 AM, Roger Leigh wrote: >> >> On 02/09/2015 08:40, Yaron Cohen-Tal wrote: >>> >>> Hi, >>> >>> My project is a shared library, and my tests are linked to that shared >>> library. When I try to run the tests, they fail because they can't find >>> the DLL of the project. The "CMakeLists.txt" of the tests is in a >>> different folder ("test/") than that of the shared lib ("src/"), and >>> therefore they're built in different directories. Currently I'm using >>> Visual Studio, and the DLL of the project is built in "src\Debug\", and >>> the executables of the tests are built in "test\Debug\"; That is, for a >>> debug build of course. What would be the best solution to b able to run >>> the tests? I'm currently with Visual Studio but I guess the same problem >>> would arise on Linux and OS X, and it should work there too. >> >> >> On Linux/BSD/MacOS it's using rpath so it works without any special effort >> on your part. >> >> On Windows, you do need to set the test environment so it can find all the >> DLLs. To do this, I did this for libtiff: >> >> >> macro(tiff_test_reader name command infile) >> add_test(NAME "${name}" >> COMMAND "${CMAKE_COMMAND}" >> [... other options...] >> "-DTIFFINFO=$" >> "-DLIBTIFF=$" >> -P "${CMAKE_CURRENT_SOURCE_DIR}/TiffTest.cmake") >> endmacro() >> >> where TIFFINFO is an executable run by the test and LIBTIFF is the library >> used by this executable. Note we pass these options as generator >> expressions so you can run "ctest -C Debug|Release" and have it use the >> executable and library from the debug or release build. >> >> TiffTest.cmake is a wrapper to run the test. It's doing this: >> >> # Add the directory containing libtiff to the PATH (Windows only) >> if(WIN32) >> get_filename_component(LIBTIFF_DIR "${LIBTIFF}" DIRECTORY) >> file(TO_NATIVE_PATH "${LIBTIFF_DIR}" LIBTIFF_DIR) >> set(ENV{PATH} "${LIBTIFF_DIR};$ENV{PATH}") >> endif() >> >> and then it runs the test command and specified options via >> execute_process(). >> >> i.e. we've added a level of indirection when running the tests via a >> standalone cmake script. >> >> There may be better ways of doing this. I'd certainly be keen to simplify >> things! >> >> >> Regards, >> Roger >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 JamesJ at motionview3d.com Wed Sep 2 14:38:37 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Wed, 2 Sep 2015 18:38:37 -0000 Subject: [CMake] Visual Studio - Ninja Generator In-Reply-To: <2B4322E3-BF6B-4180-9B1D-D4B5C569B78C@hendrik-sattler.de> References: <2B4322E3-BF6B-4180-9B1D-D4B5C569B78C@hendrik-sattler.de> Message-ID: <052601d0e5ae$954f0b40$bfed21c0$@motionview3d.com> Hi, The problem with /MP in cl.exe, /CGTHREADS in link.exe, and /MAXCPUCOUNT in msbuild.exe is they don't communicate with each other, potentially leading to massive over/undersubscription of the system. I would love it if Microsoft could get this mishmash cleaned up somehow so they can all communicate and not oversubscribe the system. (Out-of-the-box, Visual C++ ought to have this straightened out). In theory it would be faster than Ninja because the /MP switch reduces forking overhead and fixed overhead initialization cl.exe by batch building. In the meantime, Ninja seems faster in practice, because it can properly avoid oversubscription with building individual C++ files and entire projects in parallel (whereas cl.exe and msbuild.exe cannot). (One problem with link.exe /CGTHREADS though is that Ninja needs to be told how many threads link.exe will actually use, so that Ninja doesn't oversubscribe. I'm not aware of a way to make Ninja do that though. You can use pools to restrict to one link at a time, but moderate oversubscription will still happen with the concurrent cl.exe instances.) Best regards, James Johnston From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Hendrik Sattler Sent: Monday, August 31, 2015 15:49 To: Guillaume Dumont; cmake at cmake.org Subject: Re: [CMake] Visual Studio - Ninja Generator Hi, did you really enable parallel compiling in VS with /MP24 or the like? Note that using devenv to build uses the number from the IDE user settings but using msbuild needs a command line option. Else just create a custom target that calls cmake for ninja and afterwards ninja itself in yet another build tree. you can limit the creation of that target to if(MSVC_IDE). HS Am 31. August 2015 16:35:01 MESZ, schrieb Guillaume Dumont : Hi all, I would like to know what kind of effort would it take to generate a Visual Studio generator that bypasses the normal MSBuild build and uses Ninja instead. I have been working on different projects which build much faster with ninja than MSBuild (several orders of magnitude on a machine with 24 cores). Still I like to use the Visual Studio environment to use the debugger. Using ninja is especially useful for projects with a lot of CUDA files which are built sequentially for every target using MSVS. I would like to contribute but I don't really know where to start and if such an effort already exists. From ond at semanchuk.com Wed Sep 2 15:12:46 2015 From: ond at semanchuk.com (Philip Semanchuk) Date: Wed, 2 Sep 2015 15:12:46 -0400 Subject: [CMake] No-op command? Message-ID: <55E74A2E.2070105@semanchuk.com> Hi there, Does CMake have a no-op command, like 'pass' in Python or ';' in C? I sometimes want to create a construct like this: IF(CMAKE_SYSTEM_NAME STREQUAL "Windows") # Under Windows we do nothing because blah blah blah ...no-op... ELSE() ...do something... ENDIF(CMAKE_SYSTEM_NAME STREQUAL "Windows") Thanks Philip From JamesJ at motionview3d.com Wed Sep 2 15:34:44 2015 From: JamesJ at motionview3d.com (James Johnston) Date: Wed, 2 Sep 2015 19:34:44 -0000 Subject: [CMake] Visual Studio - Ninja Generator In-Reply-To: References: <55E48101.2010502@gmail.com> Message-ID: <053901d0e5b6$6c47ae70$44d70b50$@motionview3d.com> Recently I have wondered if it would be useful if the Visual Studio generators in CMake were refactored somewhat (to what degree, I am not sure). Not that I have time to work on it right now, and I have not studied this section of CMake code in detail, so I may be a little off base with some of this - please bear with me... Example: instead of Visual C++ 2008 generator, we have a back-end generator for VC++2005/2008 projects. Then instead of Visual C++ 2010 generator, we have back-end MSBuild generator. (Perhaps the back-end generators could be tools reused by existing normal "Visual Studio 2008" CMake generators and so on). If a VC++ 2008 project is needed, the back-end VC2008 generator is used. If a C# 2008 project is needed, the back-end MSBuild generator is used. There are some use cases: * The example given by Guillaume Dumont. In this case, it would be useful to have Visual Studio available as an "Extra" CMake generator. For example, specification of "Visual Studio 2015 - Ninja" (much like how you can do "CodeBlocks - Ninja" today, etc.). This would run Ninja in background to do the building, while retaining the IDE. Presumably this generator will have to share a lot of code with the regular VS2015 generator. I would be very happy if this feature existed and would use it tomorrow. The MSBuild system has serious concurrency issues resulting in serious over/undersubscription. * Recently there have been mailings from Michael Stuermer about adding C# as a language CMake. Another feature I would use tomorrow if it worked well. I skimmed through some of the commits to see how he is doing it; while helpful, I think there are some shortcomings that may not be easy to fix without some preliminary work related to Visual Studio project generation. IIRC the author's code works for generating Visual C# 2013 projects using the Visual C++ 2013 generator, but that's it. Ideally you really want to be able to: (1) build C# 2005/2008 projects, (2) use more efficient tools like Ninja. And to do that I think requires decoupling the language from the project file generator. Right now, CMake makes the assumption that the language project file format of each VS version is basically identical (e.g. all MSBuild, or not), and this is not true. To elaborate on the C# example some more, suppose the user wants to generate a Visual Studio 2008 solution. So they pick the normal VS2008 generator. In this situation: (1) C++ projects need to be generated using the C++ project generation code in the existing VS2008 generator, (2) C# projects need to be generated using an MSBuild generator, which is very different from the VS2008 C++ project format - i.e. these projects will need to use code from the current VC++ 2010 generator. Summary: to do this right for VS2005/2008 requires using significant code from two different existing CMake generators: some code from existing VS2005/2008 generator, and some code from VS2010 generator. The Ninja C# example is also tricky to get right. It may not be practical to invoke csc.exe directly; there might be other tools involved and a lot of how things "should" work is currently largely undocumented and hidden away inside of the system MSBuild .targets files. An example is resolving assembly references. If you pass in an unqualified assembly reference directly to csc.exe, the compiler searches for the assembly in various directories using rules defined here: https://msdn.microsoft.com/en-us/library/s5bac5fx.aspx - however, these rules do not match what actually happens when you add an assembly reference to a Visual C# project and compile it with MSBuild.exe. In that situation, MSBuild.exe resolves assemblies using a COMPLETELY DIFFERENT set of rules than csc.exe, and then passes absolute paths to csc.exe. The correct rules to use are probably the ones inside of Microsoft.Common.targets file, which doesn't seem to be documented in MSDN, and only documented by a comment in the XML: For example, I found when building with MSBuild, absolute paths to assemblies in "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5" were used, and this location is not used if I pass an unqualified path directly to csc.exe and use csc's rules. This blog post suggests that these new assembly resolution rules are very important: http://blogs.msdn.com/b/msbuild/archive/2007/04/12/new-reference-assemblies-location.aspx --- Therefore, I have to conclude that there are only two valid ways of compiling a C# project from CMake: a. Reverse engineer the MSBuild files for each Visual Studio project and teach CMake largely undocumented rules for things like assembly resolution and whatever else we run into. If it's just assembly resolution it might be manageable, but I fear it's a rabbit hole... b. Have CMake generate a C# project file for each C# project - even when using non-VS generators like Ninja. The Ninja build rule for a C# project would just be to invoke MSBuild.exe and build that one project. (Only generate projects, not solutions.) But this requires the ability for a CMake language to invoke the MSBuild-generating code inside CMake to spit out a Visual Studio project for each C# target. Benefit: now CMake doesn't reimplement undocumented behavior of Microsoft's MSBuild targets; we just use them directly as a black box. Best regards, James Johnston From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Guillaume Dumont Sent: Monday, August 31, 2015 16:49 To: Gonzalo Cc: cmake at cmake.org Subject: Re: [CMake] Visual Studio - Ninja Generator @Hendrik Sattler I have not experimented with the /MP flag that much, but this won't solve my problem when the project contains a lot of CUDA files. The /MP flag as not effect there. Yes I could indeed create a custom build target and create additional build trees to build using ninja in there but this is suboptimal in my opinion. @Gonzalo Yes this is precisely what I do but then you only get the ninja build files. No solution for debugging etc. My question is more about the difficulty of creating a new generator that makes the use of ninja as transparent as possible to the user instead of writing custom CMake code to do this in my own projects. On Mon, Aug 31, 2015 at 12:29 PM, Gonzalo wrote: s it has changed names a couple of times). That shoul -- Guillaume Dumont ========================= dumont.guillaume at gmail.com From hectorb at utexas.edu Wed Sep 2 16:13:08 2015 From: hectorb at utexas.edu (Hector E Barrios Molano) Date: Wed, 2 Sep 2015 15:13:08 -0500 Subject: [CMake] Colored output CTest, make test Message-ID: Hi CMake Experts! Does CTest support colored output? I'm using CMake version 3.3.1. I got colored output for the build part (compilation) while using make. However, when I do "make test" or "ctest" I don't get colored output. Does the colored output for the tests have to be activated somewhere? Thank you very much for your help, Best regards, Hector -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Wed Sep 2 16:18:30 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Wed, 02 Sep 2015 22:18:30 +0200 Subject: [CMake] linking: absolute path vs -l In-Reply-To: References: <4451129.mAJvdXgu70@tuxedo.neundorf.net> Message-ID: <16196974.EVcJYbhyED@tuxedo.neundorf.net> On Wednesday, September 02, 2015 08:22:08 Nico Schl?mer wrote: > > it uses -l if the full path is not know or if the full path is one of the > > system > library dirs > > Hm, that sound a little weird. Using `-l` appears to delegate the library > finding to the linker although CMake has already done that job. If one was > overly cautious, one could ask questions like: What if there are two > libraries by the same name in different system library dirs? What if > there's only one library in a system dir at configure time, but two at link > time? > > Moreover, in the example I gave above it seems that both libraries are in > the system path, yet still they are represented differently on the link > line. what values do ${ZLIB_LIBRARIES} and ${netCDF_LIBRARIES} have in your case ? Alex From nico.schloemer at gmail.com Wed Sep 2 16:28:35 2015 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Wed, 02 Sep 2015 20:28:35 +0000 Subject: [CMake] linking: absolute path vs -l In-Reply-To: <16196974.EVcJYbhyED@tuxedo.neundorf.net> References: <4451129.mAJvdXgu70@tuxedo.neundorf.net> <16196974.EVcJYbhyED@tuxedo.neundorf.net> Message-ID: Curiously, ``` message(${ZLIB_LIBRARIES}) message(${netCDF_LIBRARIES}) ``` yields ``` /usr/lib/x86_64-linux-gnu/libz.so netcdf ``` Hm, I would have expected it the other way around. :) --Nico On Wed, Sep 2, 2015 at 10:17 PM Alexander Neundorf wrote: > On Wednesday, September 02, 2015 08:22:08 Nico Schl?mer wrote: > > > it uses -l if the full path is not know or if the full path is one of > the > > > system > > library dirs > > > > Hm, that sound a little weird. Using `-l` appears to delegate the library > > finding to the linker although CMake has already done that job. If one > was > > overly cautious, one could ask questions like: What if there are two > > libraries by the same name in different system library dirs? What if > > there's only one library in a system dir at configure time, but two at > link > > time? > > > > Moreover, in the example I gave above it seems that both libraries are in > > the system path, yet still they are represented differently on the link > > line. > > what values do ${ZLIB_LIBRARIES} and ${netCDF_LIBRARIES} have in your case > ? > > Alex > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Wed Sep 2 16:47:18 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Wed, 02 Sep 2015 22:47:18 +0200 Subject: [CMake] linking: absolute path vs -l In-Reply-To: References: <16196974.EVcJYbhyED@tuxedo.neundorf.net> Message-ID: <2343087.bvSSRjt86D@tuxedo.neundorf.net> On Wednesday, September 02, 2015 20:28:35 Nico Schl?mer wrote: > Curiously, > ``` > message(${ZLIB_LIBRARIES}) > message(${netCDF_LIBRARIES}) > ``` > yields > ``` > /usr/lib/x86_64-linux-gnu/libz.so > netcdf > ``` > Hm, I would have expected it the other way around. :) maybe "netcdf" is the name of an imported target. Can you check that (e.g. by trying to get a target property from it and if so , figure out the attached location ? Alex From nico.schloemer at gmail.com Wed Sep 2 18:12:39 2015 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Wed, 02 Sep 2015 22:12:39 +0000 Subject: [CMake] linking: absolute path vs -l In-Reply-To: <2343087.bvSSRjt86D@tuxedo.neundorf.net> References: <16196974.EVcJYbhyED@tuxedo.neundorf.net> <2343087.bvSSRjt86D@tuxedo.neundorf.net> Message-ID: Indeed, ``` get_target_property(out ${netCDF_LIBRARIES} LOCATION) message(${out}) ``` gives ``` /usr/lib/x86_64-linux-gnu/libnetcdf.so.7.3.0 ``` This value appears to be set in the CMake export file ``` /usr/lib/x86_64-linux-gnu/cmake/netCDF/netCDFTargets-none.cmake ``` What does this mean? --Nico On Wed, Sep 2, 2015 at 10:46 PM Alexander Neundorf wrote: > On Wednesday, September 02, 2015 20:28:35 Nico Schl?mer wrote: > > Curiously, > > ``` > > message(${ZLIB_LIBRARIES}) > > message(${netCDF_LIBRARIES}) > > ``` > > yields > > ``` > > /usr/lib/x86_64-linux-gnu/libz.so > > netcdf > > ``` > > Hm, I would have expected it the other way around. :) > > > maybe "netcdf" is the name of an imported target. > Can you check that (e.g. by trying to get a target property from it and if > so > , figure out the attached location ? > > Alex > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Thu Sep 3 01:59:39 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Thu, 3 Sep 2015 07:59:39 +0200 Subject: [CMake] No-op command? In-Reply-To: <55E74A2E.2070105@semanchuk.com> References: <55E74A2E.2070105@semanchuk.com> Message-ID: Hi Philip. You don't need one. This is a perfectly valid piece of CMake code: if(CMAKE_SYSTEM_NAME STREQUAL "Windows") else() ... do something ... endif() Of course, the comment can be put in there, but you don't need any commands between an if() and else() (or between any other pair of start-end style commands, for that matter). Petr On Wed, Sep 2, 2015 at 9:12 PM, Philip Semanchuk wrote: > Hi there, > Does CMake have a no-op command, like 'pass' in Python or ';' in C? I > sometimes want to create a construct like this: > > IF(CMAKE_SYSTEM_NAME STREQUAL "Windows") > # Under Windows we do nothing because blah blah blah > ...no-op... > ELSE() > ...do something... > ENDIF(CMAKE_SYSTEM_NAME STREQUAL "Windows") > > > Thanks > Philip > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 ond at semanchuk.com Thu Sep 3 11:22:57 2015 From: ond at semanchuk.com (Philip Semanchuk) Date: Thu, 3 Sep 2015 11:22:57 -0400 Subject: [CMake] No-op command? In-Reply-To: References: <55E74A2E.2070105@semanchuk.com> Message-ID: <55E865D1.2070102@semanchuk.com> On 9/3/2015 1:59 AM, Petr Kmoch wrote: > Hi Philip. > > You don't need one. This is a perfectly valid piece of CMake code: > > if(CMAKE_SYSTEM_NAME STREQUAL "Windows") > else() > ... do something ... > endif() Thanks, Petr, that never occurred to me! No wonder I couldn't find it in the documentation -- I was looking for something that wasn't there. Cheers Philip > > Of course, the comment can be put in there, but you don't need any > commands between an if() and else() (or between any other pair of > start-end style commands, for that matter). > > Petr > > On Wed, Sep 2, 2015 at 9:12 PM, Philip Semanchuk > wrote: > > Hi there, > Does CMake have a no-op command, like 'pass' in Python or ';' in C? > I sometimes want to create a construct like this: > > IF(CMAKE_SYSTEM_NAME STREQUAL "Windows") > # Under Windows we do nothing because blah blah blah > ...no-op... > ELSE() > ...do something... > ENDIF(CMAKE_SYSTEM_NAME STREQUAL "Windows") > > > Thanks > Philip > -- From mike.jackson at bluequartz.net Thu Sep 3 13:48:50 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Thu, 3 Sep 2015 13:48:50 -0400 Subject: [CMake] Protobuf Libraries not found on OS X Message-ID: <3A0ED8D0-BCEB-4E4D-9F90-F5CC83C7653F@bluequartz.net> I have compiled the Protocol Buffer library on OS X and I am using the following CMake code to try and find the compiled libraries: find_package(Protobuf REQUIRED) but when configuring I get the usual CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: PROTOBUF_LIBRARY (ADVANCED) Looking at the FindProtobuf.cmake file that came with CMake 3.3.0 it looks like the module would ONLY work with MSVC built Protobuf libraries as the specific paths that are searched for are Visual Studio specific. Is this the correct behavior? Does anyone else use Protobuffers on OS X? I am thinking of rolling my on FindProtobuf.cmake file to have cmake look in more places. --- Mike Jackson From a.neundorf-work at gmx.net Thu Sep 3 15:19:33 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Thu, 03 Sep 2015 21:19:33 +0200 Subject: [CMake] linking: absolute path vs -l In-Reply-To: References: <2343087.bvSSRjt86D@tuxedo.neundorf.net> Message-ID: <4760225.6s3L1JrNIh@tuxedo.neundorf.net> On Wednesday, September 02, 2015 22:12:39 Nico Schl?mer wrote: > Indeed, > ``` > get_target_property(out ${netCDF_LIBRARIES} LOCATION) > message(${out}) > ``` > gives > ``` > /usr/lib/x86_64-linux-gnu/libnetcdf.so.7.3.0 > ``` > This value appears to be set in the CMake export file > ``` > /usr/lib/x86_64-linux-gnu/cmake/netCDF/netCDFTargets-none.cmake > ``` > What does this mean? this means that netcdf is a so-called "imported target". I.e. for cmake, it is a library target, as those which are created when doing add_library(foo foo.c bar.c blub.b), but hass not been built by the project, but has been built and installed before, and then during find_package() an "imported" target has been set up, which has all necessary target properties set so it can be used the same way a target which has been built inside cmake. Maybe absolute paths of imported targets are handled differently, I'm not sure. Alex From rcdailey.lists at gmail.com Thu Sep 3 17:15:20 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 3 Sep 2015 16:15:20 -0500 Subject: [CMake] Writing find packages Message-ID: How recent is this documentation? http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries#Writing_find_modules It seems rather old. What is the modern way of doing this? Below is my find module, I'm not sure if I'm doing it "the right way": # Try to find the vsvars32.bat file if( MSVC_VERSION EQUAL 1900 ) set( ENV_VAR_NUM 140 ) endif() set( vscomntools $ENV{} ) find_file( VSVARS_FILE vsvars32.bat HINTS ENV "VS${ENV_VAR_NUM}COMNTOOLS" ) include( FindPackageHandleStandardArgs ) find_package_handle_standard_args( FindVSVars DEFAULT_MSG VSVARS_FILE ) mark_as_advanced( VSVARS_FILE ) From gerhard.gappmeier at ascolab.com Fri Sep 4 03:56:08 2015 From: gerhard.gappmeier at ascolab.com (Gerhard Gappmeier) Date: Fri, 4 Sep 2015 09:56:08 +0200 Subject: [CMake] Idea: CMake IRC Bot Message-ID: <55E94E98.7090206@ascolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi CMake Devs, maybe this idea is not new or you even have something like that, so please let me know. Wouldn't it be cool to have an IRC bot for cmake which we could use to control builds and get build notifications? What I'm thinking of is this: * for each project on CDash you can configure an IRC channel, by default # or #-ci. * you can trigger a build manually or periodically on a given branch. - build []: one shot build if no inteval is given, periodic otherwise where type is: Continuous, Nightly, Experimental - list: lists all registered build configurations - remove : for removing a configured build config * getting notifications posted in the project channel: FAILED (w=50) ...., similar to emails a link for the CDash website can also be posted to view the results in detail. Of course many more commands would be possible. The possibilities of using IRC are endless: E.g. you could integrate a build-status script in TMUX statusbar to show a nice icon for your project status. I think the main things that are missing at the moment, except for the obvious IRC code are: * a communication channels between CDash and the build machines, so that CDash can trigger the builds (I can remember a discussion that something like that was planned, but I don't know the current status of this) Why not use also IRC commands between CDash (build-master) and the build-slaves? * a framework which does the initial cloning of configured projects, checkout the right branch, submodule init/sync/update, and call cmake. This needs to be done before "make Continuous" works. We created some BASH scripts for this in our company, but I feel this is something that needs a more generic solution and almost everybody needs that. This should also be able to report some Git checkout errors, e.g. if a Git submodule reference is invalid. What do you think? - -- mit freundlichen Gr??en / best regards *Gerhard Gappmeier* ascolab GmbH - automation systems communication laboratory Tel.: +49 9131 691 123 Fax: +49 9131 691 128 Web: http://www.ascolab.com GPG-KeyId: 5AAC50C4 GPG-Fingerprint: 967A 15F1 2788 164D CCA3 6C46 07CD 6F82 5AAC 50C4 - -- *ascolab GmbH* Gesch?ftsf?hrer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrau? Sitz der Gesellschaft: Am Weichselgarten 7 ? 91058 Erlangen ? Germany Registernummer: HRB 9360 Registergericht: Amtsgericht F?rth -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlXpTpgACgkQB81vglqsUMRDLgCfco6/hYYm/dYZYIoOBHN3asHr sX8AmwdpCSk+sjrWd91n/h0+2tpqv3UY =eYO/ -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.custin at hp.com Fri Sep 4 09:29:18 2015 From: jay.custin at hp.com (Custin, Jay (CSC Sw Middleware)) Date: Fri, 4 Sep 2015 13:29:18 +0000 Subject: [CMake] CMake on OpenVMS Message-ID: Has ANYONE actually gotten CMake working on OpenVMS? I see numerous traces of OpenVMS riddled throughout the configuration/bootstrap code, but after spending almost two solid days trying to get past the "Configure" phase I have decided I needed to formally inquire. SenseiC -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.custin at hp.com Fri Sep 4 09:42:41 2015 From: jay.custin at hp.com (Custin, Jay (CSC Sw Middleware)) Date: Fri, 4 Sep 2015 13:42:41 +0000 Subject: [CMake] CMake on OpenVMS (some clarification) Message-ID: While I specifically want this on OpenVMS/Integrity (V8.3 or higher), I have not tried this on an Alpha yet (vast majority of the coding/builds I do involve the Integrity platform). It took some manual editing of files, etc. to get this far: <> CXX has ios::binary openmode --------------------------------------------- CXX -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -I/PRJ_ROOT/CMAKE-3_3_1/Source -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -c /PRJ_ROOT/CMAKE -3_3_1/Source/cmake.cxx -o cmake.o #ifndef cmIML_ABI_H .^ %CXX-E-MISSINGENDIF, the #endif for this directive is missing at line number 33 in file LCL_ROOT:[cmake-3_3_1.Bootstrap_cmk.cmIML]ABI.h;4 cmIML_INT__VERIFY_TYPE(cmIML_INT_intptr_t, sizeof(void*)); ^ %CXX-E-NOTCOMPREDEC, declaration is incompatible with "int (*cmIML_INT_intptr_t__VERIFY__)[4U]" (declared at line 839) at line number 839 in file LCL_ROOT:[cmake-3_3_1.Bootstrap_cmk.cmIML]INT.h;23 < I have the GNU Not VMS (GNV) Bash environment with the latest code base for GNV (including Perl 5.22) and CMake (3.3.1). -------------- next part -------------- An HTML attachment was scrubbed... URL: From netbandit at gmx.de Fri Sep 4 10:17:17 2015 From: netbandit at gmx.de (=?UTF-8?Q?Andr=c3=a9_Netzeband?=) Date: Fri, 4 Sep 2015 16:17:17 +0200 Subject: [CMake] CMake [nmake target] is adding backslash at end of cd command In-Reply-To: <55E9A578.9010609@netzeband.eu> References: <55E9A578.9010609@netzeband.eu> Message-ID: <55E9A7ED.1010101@gmx.de> Hi I have a very strange issue with generated nmake makefiles from cmake 3.3.1 In a very complex project with many sub-cmake files (Ogre3D) the generated nmake makefiles (build.make) contain backslashes at the end of some cd commands. Like this: lib\OgreSamplesCommon_d.lib: Samples\2.0\Common\CMakeFiles\OgreSamplesCommon.dir\src\BaseSystem.cpp.obj lib\OgreSamplesCommon_d.lib: Samples\2.0\Common\CMakeFiles\OgreSamplesCommon.dir\src\CameraController.cpp.obj lib\OgreSamplesCommon_d.lib: Samples\2.0\Common\CMakeFiles\OgreSamplesCommon.dir\src\GameEntityManager.cpp.obj lib\OgreSamplesCommon_d.lib: Samples\2.0\Common\CMakeFiles\OgreSamplesCommon.dir\src\GraphicsSystem.cpp.obj lib\OgreSamplesCommon_d.lib: Samples\2.0\Common\CMakeFiles\OgreSamplesCommon.dir\src\LogicSystem.cpp.obj lib\OgreSamplesCommon_d.lib: Samples\2.0\Common\CMakeFiles\OgreSamplesCommon.dir\src\SdlInputHandler.cpp.obj lib\OgreSamplesCommon_d.lib: Samples\2.0\Common\CMakeFiles\OgreSamplesCommon.dir\src\Threading\MessageQueueSystem.cpp.obj lib\OgreSamplesCommon_d.lib: Samples\2.0\Common\CMakeFiles\OgreSamplesCommon.dir\src\TutorialGameState.cpp.obj lib\OgreSamplesCommon_d.lib: Samples\2.0\Common\CMakeFiles\OgreSamplesCommon.dir\src\Utils\HdrUtils.cpp.obj lib\OgreSamplesCommon_d.lib: Samples\2.0\Common\CMakeFiles\OgreSamplesCommon.dir\build.make lib\OgreSamplesCommon_d.lib: Samples\2.0\Common\CMakeFiles\OgreSamplesCommon.dir\objects1.rsp @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --bold --progress-dir=D:\Projects\CPP\Libraries\Ogre3D\ogre\build-vc64\CMakeFiles --progress-num=$(CMAKE_PROGRESS_10) "Linking CXX static library ..\..\..\lib\OgreSamplesCommon_d.lib" cd Samples\2.0\Common $(CMAKE_COMMAND) -P CMakeFiles\OgreSamplesCommon.dir\cmake_clean_target.cmake cd ..\..\..\ cd Samples\2.0\Common D:\Compiler\MVS14.0\VC\bin\amd64\link.exe /lib /out:..\..\..\lib\OgreSamplesCommon_d.lib @CMakeFiles\OgreSamplesCommon.dir\objects1.rsp cd ..\..\..\ Unfortunately these backslashes at the end of cd ..\..\..\ are interpreted as multi-line backslashes. Thus the makefile will not do this: cd ..\..\.. cd Samples\2.0\Common But it will do this: cd ..\..\.. cd Samples\2.0\Common And of course this is not a correct command. I searched a lot in the internet to find a hint, how to prevent such a behaviour, but I was not able to find any answer. Also all the other projects I have compiled that uses cmake do not have a single cd in the build.make file. So I was not able to check if this is a general issue of cmake. Is this an error of cmake or is something wrong configured in the project? What forces cmake in this project to change the directory so often and why does cmake not add any cd commands to other project using cmake? Is there an option to prevent cd-command generation and using absolute paths for all files? Best regards, Andr? From mike.jackson at bluequartz.net Fri Sep 4 13:33:49 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Fri, 4 Sep 2015 13:33:49 -0400 Subject: [CMake] Protobuf Libraries not found on OS X In-Reply-To: References: <3A0ED8D0-BCEB-4E4D-9F90-F5CC83C7653F@bluequartz.net> Message-ID: Odd, I built from source and there does not seem to be any way to add a custom search path (akin to QtDir or something like that) for the searching. I added a few lines to the FindProtobuf.cmake file to make it look for "Protobuf_DIR" as an environment variable. If I installed it into /usr/local I bit the default paths would find it. I guess I could submit the patch as a bug report for the next version of CMake. Thanks Mike Jackson On Sep 4, 2015, at 11:53 AM, Nils Guillermin wrote: > I'm on Mac OS X 10.10.4 and I use protobuf installed through homebrew. > > Nils > > On Thu, Sep 3, 2015 at 1:48 PM, Michael Jackson wrote: > I have compiled the Protocol Buffer library on OS X and I am using the following CMake code to try and find the compiled libraries: > > find_package(Protobuf REQUIRED) > > > but when configuring I get the usual > > CMake Error: The following variables are used in this project, but they are set to NOTFOUND. > Please set them or make sure they are set and tested correctly in the CMake files: > PROTOBUF_LIBRARY (ADVANCED) > > Looking at the FindProtobuf.cmake file that came with CMake 3.3.0 it looks like the module would ONLY work with MSVC built Protobuf libraries as the specific paths that are searched for are Visual Studio specific. Is this the correct behavior? Does anyone else use Protobuffers on OS X? I am thinking of rolling my on FindProtobuf.cmake file to have cmake look in more places. > > --- > Mike Jackson > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 lbmgmusic at gmail.com Fri Sep 4 14:37:35 2015 From: lbmgmusic at gmail.com (Jay Cotton) Date: Fri, 4 Sep 2015 11:37:35 -0700 Subject: [CMake] New to cmake and I have a problem. Message-ID: Hi: I need to add an 'S' to the ar flags. Now, I have found that I can edit the link.txt file but, this is not a real solution. I am certain there is a way to do this with the CMakeCache.txt file. I just don't see how. Any help would be appreciated. tnx JC -------------- next part -------------- An HTML attachment was scrubbed... URL: From dschepler at scalable-networks.com Fri Sep 4 14:59:30 2015 From: dschepler at scalable-networks.com (Daniel Schepler) Date: Fri, 4 Sep 2015 18:59:30 +0000 Subject: [CMake] Protobuf Libraries not found on OS X In-Reply-To: References: <3A0ED8D0-BCEB-4E4D-9F90-F5CC83C7653F@bluequartz.net> , Message-ID: Doesn't CMAKE_PREFIX_PATH work for you? -- Daniel Schepler ________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of Michael Jackson [mike.jackson at bluequartz.net] Sent: Friday, September 04, 2015 10:33 AM To: CMake list Subject: Re: [CMake] Protobuf Libraries not found on OS X Odd, I built from source and there does not seem to be any way to add a custom search path (akin to QtDir or something like that) for the searching. I added a few lines to the FindProtobuf.cmake file to make it look for "Protobuf_DIR" as an environment variable. If I installed it into /usr/local I bit the default paths would find it. I guess I could submit the patch as a bug report for the next version of CMake. Thanks Mike Jackson On Sep 4, 2015, at 11:53 AM, Nils Guillermin > wrote: I'm on Mac OS X 10.10.4 and I use protobuf installed through homebrew. Nils On Thu, Sep 3, 2015 at 1:48 PM, Michael Jackson > wrote: I have compiled the Protocol Buffer library on OS X and I am using the following CMake code to try and find the compiled libraries: find_package(Protobuf REQUIRED) but when configuring I get the usual CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: PROTOBUF_LIBRARY (ADVANCED) Looking at the FindProtobuf.cmake file that came with CMake 3.3.0 it looks like the module would ONLY work with MSVC built Protobuf libraries as the specific paths that are searched for are Visual Studio specific. Is this the correct behavior? Does anyone else use Protobuffers on OS X? I am thinking of rolling my on FindProtobuf.cmake file to have cmake look in more places. --- Mike Jackson -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Fri Sep 4 15:01:25 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Fri, 4 Sep 2015 15:01:25 -0400 Subject: [CMake] Protobuf Libraries not found on OS X In-Reply-To: References: <3A0ED8D0-BCEB-4E4D-9F90-F5CC83C7653F@bluequartz.net> , Message-ID: It _should_. I think this was a case of "operator" error. Not sure I defined CMAKE_PREFIX_PATH properly with the path to the protobuf libraries. I'll give that a try and I am sure that it will work properly. Thanks for the sanity check Mike J. On Sep 4, 2015, at 2:59 PM, Daniel Schepler wrote: > Doesn't CMAKE_PREFIX_PATH work for you? > -- > Daniel Schepler > From: CMake [cmake-bounces at cmake.org] on behalf of Michael Jackson [mike.jackson at bluequartz.net] > Sent: Friday, September 04, 2015 10:33 AM > To: CMake list > Subject: Re: [CMake] Protobuf Libraries not found on OS X > > Odd, I built from source and there does not seem to be any way to add a custom search path (akin to QtDir or something like that) for the searching. I added a few lines to the FindProtobuf.cmake file to make it look for "Protobuf_DIR" as an environment variable. If I installed it into /usr/local I bit the default paths would find it. > > I guess I could submit the patch as a bug report for the next version of CMake. > > Thanks > Mike Jackson > On Sep 4, 2015, at 11:53 AM, Nils Guillermin wrote: > >> I'm on Mac OS X 10.10.4 and I use protobuf installed through homebrew. >> >> Nils >> >> On Thu, Sep 3, 2015 at 1:48 PM, Michael Jackson wrote: >> I have compiled the Protocol Buffer library on OS X and I am using the following CMake code to try and find the compiled libraries: >> >> find_package(Protobuf REQUIRED) >> >> >> but when configuring I get the usual >> >> CMake Error: The following variables are used in this project, but they are set to NOTFOUND. >> Please set them or make sure they are set and tested correctly in the CMake files: >> PROTOBUF_LIBRARY (ADVANCED) >> >> Looking at the FindProtobuf.cmake file that came with CMake 3.3.0 it looks like the module would ONLY work with MSVC built Protobuf libraries as the specific paths that are searched for are Visual Studio specific. Is this the correct behavior? Does anyone else use Protobuffers on OS X? I am thinking of rolling my on FindProtobuf.cmake file to have cmake look in more places. >> >> --- >> Mike Jackson >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Fri Sep 4 15:30:47 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri, 4 Sep 2015 15:30:47 -0400 Subject: [CMake] CMake on OpenVMS (some clarification) In-Reply-To: References: Message-ID: <55E9F167.2090000@kitware.com> On 9/4/2015 9:42 AM, Custin, Jay (CSC Sw Middleware) wrote: > While I specifically want this on OpenVMS/Integrity (V8.3 or higher), I > have not tried this on an Alpha yet (vast majority of the coding/builds > I do involve the Integrity platform). It took some manual editing of > files, etc. to get this far: > > <> > > CXX has ios::binary openmode > > --------------------------------------------- > > CXX -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -I/PRJ_ROOT/CMAKE-3_3_1/Source > -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -c /PRJ_ROOT/CMAKE > > -3_3_1/Source/cmake.cxx -o cmake.o > > #ifndef cmIML_ABI_H > > .^ > > %CXX-E-MISSINGENDIF, the #endif for this directive is missing > > at line number 33 in file LCL_ROOT:[cmake-3_3_1.Bootstrap_cmk.cmIML]ABI.h;4 > > cmIML_INT__VERIFY_TYPE(cmIML_INT_intptr_t, sizeof(void*)); > > ^ > > %CXX-E-NOTCOMPREDEC, declaration is incompatible with > > "int (*cmIML_INT_intptr_t__VERIFY__)[4U]" (declared at line 839) > > at line number 839 in file > LCL_ROOT:[cmake-3_3_1.Bootstrap_cmk.cmIML]INT.h;23 > > < > > I have the GNU Not VMS (GNV) Bash environment with the latest code base > for GNV (including Perl 5.22) and CMake (3.3.1). > I worked on this years ago. I did manage to get most of it working, but no one ever setup a dashboard for it, so I am sure it fails now. If you do manage to get it working it would be great if you could run a nightly dashboard... :) -Bill From Ch.Ehrlicher at gmx.de Fri Sep 4 15:43:03 2015 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Fri, 4 Sep 2015 21:43:03 +0200 Subject: [CMake] cmake uses -I instead -isystem when linking private against a library Message-ID: <55E9F447.6020001@gmx.de> Hi, It looks like '-isystem' is replaced by '-i' from the compile line as soon as the library which defined the path as system include path is linked as 'PRIVATE'. See this testcase: project(isystem) cmake_minimum_required(VERSION 3.0) add_library(lib1 SHARED foo.cpp) set_property(TARGET lib1 PROPERTY INTERFACE_INCLUDE_DIRECTORIES ${CMAKE_SOURCE_DIR}/include) set_property(TARGET lib1 PROPERTY INTERFACE_SYSTEM_INCLUDE_DIRECTORIES ${CMAKE_SOURCE_DIR}/include) add_library(lib2 SHARED foo.cpp) target_link_libraries(lib2 PUBLIC lib1 ) add_library(lib3 SHARED foo.cpp) target_link_libraries(lib3 PRIVATE lib1 PUBLIC lib2 ) add_library(lib4 SHARED foo.cpp) target_link_libraries(lib4 PUBLIC lib3 ) now lib4.cpp is compiled with -I ${CMAKE_SOURCE_DIR}/include ... I'm not quite sure if the dependency chain is valid here and it can be easily fixed by moving lib1 from PRIVATE to PUBLIC in target_link_libraries(lib3) but since lib3 links public to lib2 and lib2 public to lib1 I expected that lib4 should also use '-isystem' Should I file a bug report on this? Christian From i.zaufi at gmail.com Sat Sep 5 02:22:17 2015 From: i.zaufi at gmail.com (Alex Turbov) Date: Sat, 5 Sep 2015 09:22:17 +0300 Subject: [CMake] How to do that w/o LOCATION property of a target... Message-ID: Hi, in my project I have `add_executable()`. after that, in a current binary dir I need to render a `*.cmake` script (via `configure_file()`) to be running from `add_test()` (as `cmake -P`) which should start just the compiled executable via `execute_process()` and capture its output (to be processed by followed commands)... the problem is: how to render an absolute path to the compiled executable inside the generated `*.cmake` script ?? 0) access to LOCATION target property is prohibited from CMakeLists.txt, so I can't set it into a generated script 1) generator expressions don't work w/ `configure_file()` any other idea? -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Sat Sep 5 04:38:04 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Sat, 5 Sep 2015 10:38:04 +0200 Subject: [CMake] How to do that w/o LOCATION property of a target... In-Reply-To: References: Message-ID: Hi Alex. I don't know if there is a better solution, but the following workaround should work for you: In your normal CMakeList, do `file(GENERATE OUTPUT location.cmake CONTENT "set(TheLocation \"$\")\n")`. Then, in the configured *.cmake script, do `include(location.cmake)`. The location of the target will then be stored in the variable `TheLocation`. Alternatively, generate just the location and use `file(READ)` instead of `include()`, whichever suits you better. Petr On Sat, Sep 5, 2015 at 8:22 AM, Alex Turbov wrote: > Hi, > > in my project I have `add_executable()`. after that, in a current binary > dir I need to render a `*.cmake` script (via `configure_file()`) to be > running from `add_test()` (as `cmake -P`) which should start just the > compiled executable via `execute_process()` and capture its output (to be > processed by followed commands)... > > the problem is: how to render an absolute path to the compiled executable > inside the generated `*.cmake` script ?? > 0) access to LOCATION target property is prohibited from CMakeLists.txt, > so I can't set it into a generated script > 1) generator expressions don't work w/ `configure_file()` > > any other idea? > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 gjasny at googlemail.com Sat Sep 5 15:16:29 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 5 Sep 2015 21:16:29 +0200 Subject: [CMake] How to do that w/o LOCATION property of a target... In-Reply-To: References: Message-ID: <55EB3F8D.3090907@googlemail.com> On 05/09/15 08:22, Alex Turbov wrote: > Hi, > > in my project I have `add_executable()`. after that, in a current binary > dir I need to render a `*.cmake` script (via `configure_file()`) to be > running from `add_test()` (as `cmake -P`) which should start just the > compiled executable via `execute_process()` and capture its output (to be > processed by followed commands)... > > the problem is: how to render an absolute path to the compiled executable > inside the generated `*.cmake` script ?? > 0) access to LOCATION target property is prohibited from CMakeLists.txt, so > I can't set it into a generated script > 1) generator expressions don't work w/ `configure_file()` If you use the add_test(NAME COMMAND ) signature you can use generator expressions. You could pass the executable directory as a parameter to the script: add_test(NAME myTest COMMAND ${CMAKE_COMMAND} -DMY_EXECUATABLE=$ -P my_script.cmake) In the script use ${MY_EXECUATABLE}. Hope this helps, Gregor From gjasny at googlemail.com Sat Sep 5 15:29:56 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Sat, 5 Sep 2015 21:29:56 +0200 Subject: [CMake] Writing find packages In-Reply-To: References: Message-ID: <55EB42B4.6020108@googlemail.com> Hello, On 03/09/15 23:15, Robert Dailey wrote: > How recent is this documentation? > http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries#Writing_find_modules > > It seems rather old. What is the modern way of doing this? The cmake-developer help page has a section about modules: http://www.cmake.org/cmake/help/latest/manual/cmake-developer.7.html#find-modules Or you use an existing module as boilerplate code. Maybe you could look at FindZLIB.cmake or any other module which uses add_library(... IMPORTED ...) Thanks, Gregor From mjklaim at gmail.com Sat Sep 5 21:03:42 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Sun, 6 Sep 2015 03:03:42 +0200 Subject: [CMake] Protobuf Libraries not found on OS X In-Reply-To: <3A0ED8D0-BCEB-4E4D-9F90-F5CC83C7653F@bluequartz.net> References: <3A0ED8D0-BCEB-4E4D-9F90-F5CC83C7653F@bluequartz.net> Message-ID: On 3 September 2015 at 19:48, Michael Jackson wrote: > I have compiled the Protocol Buffer library on OS X and I am using the > following CMake code to try and find the compiled libraries: > > find_package(Protobuf REQUIRED) > > > but when configuring I get the usual > > CMake Error: The following variables are used in this project, but they > are set to NOTFOUND. > Please set them or make sure they are set and tested correctly in the > CMake files: > PROTOBUF_LIBRARY (ADVANCED) > > Looking at the FindProtobuf.cmake file that came with CMake 3.3.0 it looks > like the module would ONLY work with MSVC built Protobuf libraries as the > specific paths that are searched for are Visual Studio specific. Is this > the correct behavior? Does anyone else use Protobuffers on OS X? I am > thinking of rolling my on FindProtobuf.cmake file to have cmake look in > more places. > > --- > Mike Jackson > > -- Which version of Protobuf did you compile? if it's the last version (3.x alpha or beta) then it is not compatible with the currently provided findprotobuf module. See comments in this issue: http://public.kitware.com/Bug/view.php?id=14833 And the related ticket: https://github.com/google/protobuf/issues/578 -------------- next part -------------- An HTML attachment was scrubbed... URL: From roolebo at gmail.com Mon Sep 7 06:19:08 2015 From: roolebo at gmail.com (Roman Bolshakov) Date: Mon, 07 Sep 2015 03:19:08 -0700 (PDT) Subject: [CMake] New to cmake and I have a problem. In-Reply-To: References: Message-ID: <1441621147894.4c586743@Nodemailer> Hi Jay,? Have you tried something like this (http://www.cmake.org/pipermail/cmake/2010-July/038312.html)? ? ?????????? ?? Mailbox On Fri, Sep 4, 2015 at 9:37 PM, Jay Cotton wrote: > Hi: > I need to add an 'S' to the ar flags. Now, I have found that I can edit > the link.txt file but, > this is not a real solution. I am certain there is a way to do this with > the CMakeCache.txt file. > I just don't see how. Any help would be appreciated. > tnx > JC -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Mon Sep 7 07:08:41 2015 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Mon, 7 Sep 2015 11:08:41 +0000 Subject: [CMake] Generated .rc files silently ignored Message-ID: <8D981219EEA621479C112DA9BDC39A8E348BAE05@EXMBS1.ad.igd.fraunhofer.de> While adding versioning info to a .dll I noticed that .rc files that are generated (via configure_file) are silently being ignored. Adding them via an absolute path works, but using a relative leads to it being ignored. Is this a bug or is this by design? At the very least just silently ignoring it seems wrong. -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Mon Sep 7 12:31:54 2015 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 7 Sep 2015 12:31:54 -0400 Subject: [CMake] No-op command? In-Reply-To: <55E865D1.2070102@semanchuk.com> References: <55E74A2E.2070105@semanchuk.com> <55E865D1.2070102@semanchuk.com> Message-ID: > > if(CMAKE_SYSTEM_NAME STREQUAL "Windows") >> else() >> ... do something ... >> endif() >> > While you may need the empty if condition for something else, in this use case specifically you could just as easily avoid the empty conditional block and negate the expression with: if(NOT CMAKE_SYSTEM_NAME MATCHES "Windows") ... do something ... endif() - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaronngray.lists at gmail.com Mon Sep 7 18:47:35 2015 From: aaronngray.lists at gmail.com (Aaron Gray) Date: Mon, 7 Sep 2015 23:47:35 +0100 Subject: [CMake] General cross platform stating place Message-ID: Hi, Am new to this mailing list. And have looked at CMake as a tool in a number of other projects including LLVM, but still consider myself a CMake newbie. I am looking at using CMake for a group of meta language based projects I am developing. Basically I need to be able to develop for all three major C++ compilers, MSVC, GCC, and Clang, on all major platforms, Windows, Linux and on the Mac. What I am wondering is if there is a good starting point / set of scripts for CMake that will allow me to build :- a) On Windows for MSVC, Clang and GCC b) For Linux with Clang/LLVm tool chain and GCC And at some point c) XCode on the Mac Support for using Googles gtest. Basically I don't want to get too bogged down with CMake scripts if it is possible to avoid getting bogged down with them as much as it is possible. Heres where I am now, I have pinched gtests script and have Windows MSVC, MSYS GCC and Linux GCC and Clang. I have used gtest's script as a staring place :- https://github.com/google/googletest/blob/master/googletest/cmake/internal_utils.cmake And the following script :- ~~~ cmake_minimum_required(VERSION 2.6) set(CMAKE_AR /usr/bin/ar CACHE FILEPATH "Archiver") project(gtest-test CXX C) find_package (Threads) # Define helper functions and macros. include(cmake/internal_utils.cmake) config_compiler_and_linker() # Defined in internal_utils.cmake. #message("prefix: ${CMAKE_FIND_LIBRARY_PREFIXES}") #message("suffix: ${CMAKE_FIND_LIBRARY_SUFFIXES}") find_package(BISON) find_package(FLEX) # Locate GTest find_package(GTest REQUIRED) include_directories(${GTEST_INCLUDE_DIRS}) # Link runTests with what we want to test and the GTest and pthread library add_executable(runTests tests.cpp) target_link_libraries(runTests ${GTEST_LIBRARIES} ${CMAKE_THREAD_LIBS_INIT}) ~~~ It runs fine on Windows with MSVC, seems to be failing on MSYS :- ~~~ $ cmake -G "MSYS Makefiles" . CMake Error: CMAKE_AR was not found, please set to archive program. CMake Error: CMAKE_AR was not found, please set to archive program. CMake Error: CMAKE_AR was not found, please set to archive program. CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:148 (message): Could NOT find GTest (missing: GTEST_LIBRARY GTEST_INCLUDE_DIR GTEST_MAIN_LIBRARY) Call Stack (most recent call first): C:/Program Files (x86)/CMake/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE) C:/Program Files (x86)/CMake/share/cmake-3.3/Modules/FindGTest.cmake:204 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:20 (find_package) -- Configuring incomplete, errors occurred! See also "C:/Users/Aaron/GitHub/GTest/CMakeFiles/CMakeOutput.log". See also "C:/Users/Aaron/GitHub/GTest/CMakeFiles/CMakeError.log". ~~~ CMakeOutput.txt and CMakeError.txt Files attached. So if theres either a better starting point or better/proper way of doing this then please put me on the right path. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CMakeError.log Type: application/octet-stream Size: 5167 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CMakeOutput.log Type: application/octet-stream Size: 30642 bytes Desc: not available URL: From johannes.zarl-zierl at jku.at Tue Sep 8 05:29:32 2015 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Tue, 08 Sep 2015 11:29:32 +0200 Subject: [CMake] General cross platform stating place In-Reply-To: References: Message-ID: <1683971.Gq2OOCZJRF@ersa> Hi, On Monday 07 September 2015 23:47:35 Aaron Gray wrote: > cmake_minimum_required(VERSION 2.6) Just as a side note: if you need to support cmake 2.6, that's fine. However, if you are starting a new project and do not *need* to limit yourself to cmake 2.6, develop for a cmake version that as new as can be supported by your target platforms. (Even if you chose the newest cmake it will get kind of old within the lifetime of your project *g*) > set(CMAKE_AR /usr/bin/ar CACHE FILEPATH "Archiver") Why do you set CMAKE_AR? > It runs fine on Windows with MSVC, seems to be failing on MSYS :- MSVC doesn't use CMAKE_AR, so there should be no problems here. MSYS obviously tries to use CMAKE_AR, which you set to the unlikely (on windows) path of /usr/bin/ar. Johannes From nico.schloemer at gmail.com Tue Sep 8 07:01:31 2015 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Tue, 08 Sep 2015 11:01:31 +0000 Subject: [CMake] CMake + MPI Message-ID: Hi everyone, When it comes to compiling and linking, the MPI world is quite a mess. Sometimes, vendors make you link and include certain libraries/directories, sometimes you are supposed to simply use a compiler wrapper, often both. What's the recommended way of dealing with MPI in CMake? Do you `find_package(MPI REQUIRED)` and set LINK_LIBRARIES and INCLUDE_DIRS? Do you select a compiler wrapper from within the CMake file? From outside? Cheers, Nico -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas-Naumann at gmx.net Tue Sep 8 08:07:38 2015 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Tue, 08 Sep 2015 14:07:38 +0200 Subject: [CMake] CMake + MPI In-Reply-To: References: Message-ID: <55EECF8A.5090200@gmx.net> Hi Nico, I just use find_package(MPI REQUIRED) and use the given MPI_CXX_LIBRARIES and MPI_CXX_INCLUDE_PATH. Recent mpi wrappers should support support interspection. Regards, Andreas Am 08.09.2015 um 13:01 schrieb Nico Schl?mer: > Hi everyone, > > When it comes to compiling and linking, the MPI world is quite a mess. > Sometimes, vendors make you link and include certain > libraries/directories, sometimes you are supposed to simply use a > compiler wrapper, often both. > > What's the recommended way of dealing with MPI in CMake? Do you > `find_package(MPI REQUIRED)` and set LINK_LIBRARIES and INCLUDE_DIRS? > Do you select a compiler wrapper from within the CMake file? From outside? > > Cheers, > Nico > > From brad.king at kitware.com Tue Sep 8 11:31:18 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 08 Sep 2015 11:31:18 -0400 Subject: [CMake] CMake [nmake target] is adding backslash at end of cd command In-Reply-To: <55E9A7ED.1010101@gmx.de> References: <55E9A578.9010609@netzeband.eu> <55E9A7ED.1010101@gmx.de> Message-ID: <55EEFF46.8080000@kitware.com> On 9/4/2015 10:17 AM, Andr? Netzeband wrote: > I have a very strange issue with generated nmake makefiles from cmake 3.3.1 Is this problem new in 3.3 or are you just reporting this as the version you are using? > In a very complex project with many sub-cmake files (Ogre3D) the > generated nmake makefiles (build.make) contain backslashes at the end of > some cd commands. That project turns on the CMAKE_USE_RELATIVE_PATHS option which is documented as not fully implemented and unsupported: http://www.cmake.org/cmake/help/v3.3/variable/CMAKE_USE_RELATIVE_PATHS.html That option should not be used. -Brad From tim.gallagher at gatech.edu Tue Sep 8 11:41:08 2015 From: tim.gallagher at gatech.edu (Tim Gallagher) Date: Tue, 8 Sep 2015 11:41:08 -0400 (EDT) Subject: [CMake] CMake + MPI In-Reply-To: <55EECF8A.5090200@gmx.net> Message-ID: <1099353100.5624202.1441726868102.JavaMail.root@mail.gatech.edu> The only exception to that (which I am aware of) is if you are on a CRAY system where the MPI (and BLAS and LAPACK) are baked into the compiler wrappers (cc, ftn, etc). In those situations, you actually do not want to run find_package(MPI) or it will throw errors. Tim ----- Original Message ----- From: "Andreas Naumann" To: cmake at cmake.org Sent: Tuesday, September 8, 2015 8:07:38 AM Subject: Re: [CMake] CMake + MPI Hi Nico, I just use find_package(MPI REQUIRED) and use the given MPI_CXX_LIBRARIES and MPI_CXX_INCLUDE_PATH. Recent mpi wrappers should support support interspection. Regards, Andreas Am 08.09.2015 um 13:01 schrieb Nico Schl?mer: > Hi everyone, > > When it comes to compiling and linking, the MPI world is quite a mess. > Sometimes, vendors make you link and include certain > libraries/directories, sometimes you are supposed to simply use a > compiler wrapper, often both. > > What's the recommended way of dealing with MPI in CMake? Do you > `find_package(MPI REQUIRED)` and set LINK_LIBRARIES and INCLUDE_DIRS? > Do you select a compiler wrapper from within the CMake file? From outside? > > Cheers, > Nico > > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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 amdmi3 at amdmi3.ru Tue Sep 8 22:57:10 2015 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Wed, 9 Sep 2015 05:57:10 +0300 Subject: [CMake] Tweaking/disabling timeout for "Check for working CXX compiler" Message-ID: <20150909025710.GU1245@hades.panopticon> Hi! FreeBSD project use userspace qemu emulation to cross-build packages for some architectures, namely arm. This worked great for most packages, however ones using cmake tend to fail randomly. I couldn't reproduce these failures, but after we've updated cmake to 3.3.1 which is more verbose, the cause became apparent. Example failure log: http://beefy8.nyi.freebsd.org/data/head-armv6-default/p396164_s287479/logs/flare-game-0.19_1.log Relevant excerpt: --- -- Check for working CXX compiler: /nxb-bin/usr/bin/c++ CMake Error: Generator: execution of make failed. Make command was: "/usr/bin/make" "cmTryCompileExec920170445/fast" -- Check for working CXX compiler: /nxb-bin/usr/bin/c++ -- broken CMake Error at /usr/local/share/cmake/Modules/CMakeTestCXXCompiler.cmake:54 (message): The C++ compiler "/nxb-bin/usr/bin/c++" is not able to compile a simple test program. It fails with the following output: ... Linking CXX executable cmTryCompileExec920170445 /usr/local/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec920170445.dir/link.txt --verbose=1 /nxb-bin/usr/bin/c++ -O2 -pipe -mfloat-abi=softfp -fno-strict-aliasing CMakeFiles/cmTryCompileExec920170445.dir/testCXXCompiler.cxx.o -o cmTryCompileExec920170445 Process terminated due to timeout Generator: execution of make failed. Make command was: "/usr/bin/make" ... --- As expected, emulated build is much slower than native one (even though we try to use native (amd64) cross(arm)-compiler (and some tools) instead of using fully emulated build). Package builds are also highly concurrent. It seems like cmake timeout for these compiler tests is too small for this environment and it fires frequently. The question is obvious: where is this timeout defined, what value is it set to exactly and is it tunable? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3 at amdmi3.ru ..: jabber: amdmi3 at jabber.ru http://amdmi3.ru From gheaeckkseqrz at gmail.com Wed Sep 9 03:49:08 2015 From: gheaeckkseqrz at gmail.com (Pierre Wilmot) Date: Wed, 9 Sep 2015 10:49:08 +0300 Subject: [CMake] Fwd: Expected behaviour for Tests/VSWinStorePhone References: Message-ID: <96EC67AD-B4C0-4A94-A1B0-F7BCCCC75243@gmail.com> Hi everyone, I?m trying to generate a Windows Phone 8.1 project from CMake, I was expecting the Tests/VSWinStorePhone folder to be a good template to start with, but I?m a bit confused with the result I get. I was expecting to get pretty much the same result as a project created with the Visual studio ?DirectX and XAML App (Windows Phone)?. That means a project displaying cubes that I could just run on my Windows Phone device by pressing run on device. Instead I?m getting a project with no ARM configuration, only Win32 which is surprising, because as far as I know, there only ARM device available on the market. If I build the project, I get an exe throwing an error on launch ?This application can only run in the context of an app container?. (started from exe) OR ?In order to debug this project, you must consume it from an application project that creates a package and is marked as the Startup Project? (started from Visual Studio) As the Project name is ?VSWinStorePhone?, I was expecting the created solution to be ready for Windows Phone deployment, but it?s not. Is that the expected behaviour ? If so, where can I find a good CMakeList template to create a Windows Phone 8.1 app ? Setup Info: Running on Windows 8 x64 With Visual Studio Professional 2013 Version 12.0.31101.00 Update 4 Used cmake 3.3.1-win32-x86 With the file of Tests/VSWinStorePhone from the current github master branch Ran command from Desktop/CMAKEOUT : ..\cmake-3.3.1-win32-x86\bin\cmake.exe ..\Cmake-master\Test\VSWinStrorePhone Best regards, Pierre > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.wirtz at simtech.uni-stuttgart.de Wed Sep 9 09:02:11 2015 From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz) Date: Wed, 9 Sep 2015 15:02:11 +0200 Subject: [CMake] Object targets and link libraries Message-ID: <55F02DD3.9050104@simtech.uni-stuttgart.de> Hey all, i've been wondering why CMake (3.3.+) yells at me if i want to add link libraries to an OBJECT target. Consider the scenario find_package(package_with_bar_target) add_library(foo OBJECT ${foo_src}) # Would like to write # target_link_libraries(foo bar) # But have to use target_include_directories(foo PRIVATE $) I know that intuitively "link library" is something different than "include directory". but one of the nice things of cmake is that it automatically sorts out everything for you when you specify link libraries. if there are more bar-dependent properties that need to be set in order to successfully compile foo (e.g. compile flags), i have to literally re-write all the nice internal cmake logic to establish the compile environment of bar for foo. what's the plan with that? or are there any other (less involved) solutions? i need the objects of foo inside a larger target and want to avoid having a separate library being build that needs extra linking. cheers! -- Dr. Daniel Wirtz Dipl. Math. Dipl. Inf. SRC SimTech Pfaffenwaldring 5a +49 711 685 60044 From tino.mettler at alcnetworx.de Wed Sep 9 08:58:21 2015 From: tino.mettler at alcnetworx.de (Tino Mettler) Date: Wed, 9 Sep 2015 14:58:21 +0200 Subject: [CMake] Shared library from ExternalProject Message-ID: <1441803501.13183.17.camel@alcnetworx.de> Hi, I'm thinking about a solution to use separate projects as source archives and include it into the main cmake build. I looks like ExternalProject_Add() can handle this. However, there seems to be no standard way to use shared C/C++ libraries in an external project. Is there a basic example how to handle things like compiler and linker flags, dependencies etc. for let's say, an external project called foo and a library libbar.so? My understanding is that I need to define a shared library using "add_library(bar SHARED IMPORTED)" and use set_target_properties() to adjust the location. What else do I need to do? My guess is that I need to build a config.cmake in the external project and use find_package(), but I'm not sure about that. Regards, Tino From parag at ionicsecurity.com Wed Sep 9 09:31:43 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Wed, 9 Sep 2015 13:31:43 +0000 Subject: [CMake] Fwd: Expected behaviour for Tests/VSWinStorePhone In-Reply-To: <96EC67AD-B4C0-4A94-A1B0-F7BCCCC75243@gmail.com> References: <96EC67AD-B4C0-4A94-A1B0-F7BCCCC75243@gmail.com> Message-ID: Hi Pierre, For the ARM version, I believe you will need to specify the CPU architecture explicitly, because CMake is not going to generate a ?fat?/multi-arch solution in the manner that it does for Xcode. What I do for WinPhone is to pass arguments like this: -DCMAKE_SYSTEM_NAME=WindowsPhone -DCMAKE_SYSTEM_VERSION=8.1 ?G?Visual Studio 12 2013? -DCMAKE_GENERATOR_PLATFORM=ARM Hope this helps. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: CMake on behalf of Pierre Wilmot Date: Wednesday, September 9, 2015 at 3:49 AM To: "cmake at cmake.org" Subject: [CMake] Fwd: Expected behaviour for Tests/VSWinStorePhone Hi everyone, I?m trying to generate a Windows Phone 8.1 project from CMake, I was expecting the Tests/VSWinStorePhone folder to be a good template to start with, but I?m a bit confused with the result I get. I was expecting to get pretty much the same result as a project created with the Visual studio ?DirectX and XAML App (Windows Phone)?. That means a project displaying cubes that I could just run on my Windows Phone device by pressing run on device. Instead I?m getting a project with no ARM configuration, only Win32 which is surprising, because as far as I know, there only ARM device available on the market. If I build the project, I get an exe throwing an error on launch ?This application can only run in the context of an app container?. (started from exe) OR ?In order to debug this project, you must consume it from an application project that creates a package and is marked as the Startup Project? (started from Visual Studio) As the Project name is ?VSWinStorePhone?, I was expecting the created solution to be ready for Windows Phone deployment, but it?s not. Is that the expected behaviour ? If so, where can I find a good CMakeList template to create a Windows Phone 8.1 app ? Setup Info: Running on Windows 8 x64 With Visual Studio Professional 2013 Version 12.0.31101.00 Update 4 Used cmake 3.3.1-win32-x86 With the file of Tests/VSWinStorePhone from the current github master branch Ran command from Desktop/CMAKEOUT : ..\cmake-3.3.1-win32-x86\bin\cmake.exe ..\Cmake-master\Test\VSWinStrorePhone Best regards, Pierre -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.wirtz at simtech.uni-stuttgart.de Wed Sep 9 10:37:10 2015 From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz) Date: Wed, 9 Sep 2015 16:37:10 +0200 Subject: [CMake] Missing -lgfortran with FortranCInterface verify calls In-Reply-To: <55E07B10.30809@kitware.com> References: <55DEBB29.1050904@simtech.uni-stuttgart.de> <55E07B10.30809@kitware.com> Message-ID: <55F04416.9010803@simtech.uni-stuttgart.de> Hey all, sorry for the late reply but that indeed fixes the issue! thanks Brad. On 28.08.2015 17:15, Brad King wrote: > On 08/27/2015 03:24 AM, Daniel Wirtz wrote: >> CMake 3.3.0. > [snip] >> after checking, the @CMakeFiles/VerifyFortranC.dir/linklibs.rsp does not >> contain the "-lgfortran" library include, hence the fuss. > I managed to reproduce this and track down the problem. Here > is a fix based on 3.3.1: > > Makefile: Print color escapes only when necessary > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=371fe92e > > Please try out that version. > > Thanks, > -Brad -- Dr. Daniel Wirtz Dipl. Math. Dipl. Inf. SRC SimTech Pfaffenwaldring 5a, D-70569 Stuttgart +49 (711) 685-60044 From chuck.atkins at kitware.com Wed Sep 9 11:11:27 2015 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 9 Sep 2015 11:11:27 -0400 Subject: [CMake] CMake + MPI In-Reply-To: <1099353100.5624202.1441726868102.JavaMail.root@mail.gatech.edu> References: <55EECF8A.5090200@gmx.net> <1099353100.5624202.1441726868102.JavaMail.root@mail.gatech.edu> Message-ID: > > The only exception to that (which I am aware of) is if you are on a CRAY > system where the MPI (and BLAS and LAPACK) are baked into the compiler > wrappers (cc, ftn, etc). In those situations, you actually do not want to > run find_package(MPI) or it will throw errors. > Not true. The FindMPI.cmake module performs the appropriate introspection to check if your primary compiler wraps accordingly. For example, on a Cray XC30, with the PrgEnv-pgi and cray-mpich modules loaded: p02064 at swan:~/Code/tmp/build> cat ../source/CMakeLists.txt cmake_minimum_required(VERSION 3.3) project(TestMPI C CXX) find_package(MPI REQUIRED) add_executable(test-mpi-c test-mpi.c) target_include_directories(test-mpi-c PRIVATE ${MPI_C_INCLUDE_PATH}) target_link_libraries(test-mpi-c ${MPI_C_LIBRARIES}) add_executable(test-mpi-cxx test-mpi.cxx) target_include_directories(test-mpi-cxx PRIVATE ${MPI_CXX_INCLUDE_PATH}) target_link_libraries(test-mpi-cxx ${MPI_CXX_LIBRARIES}) p02064 at swan:~/Code/tmp/build> p02064 at swan:~/Code/tmp/build> cmake ../source -- The C compiler identification is PGI 15.7.0 -- The CXX compiler identification is PGI 15.7.0 -- Check for working C compiler: /opt/cray/craype/2.4.1/bin/cc -- Check for working C compiler: /opt/cray/craype/2.4.1/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /opt/cray/craype/2.4.1/bin/CC -- Check for working CXX compiler: /opt/cray/craype/2.4.1/bin/CC -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Found MPI_C: /opt/cray/craype/2.4.1/bin/cc -- Found MPI_CXX: /opt/cray/craype/2.4.1/bin/CC -- Configuring done -- Generating done -- Build files have been written to: /home/users/p02064/Code/tmp/build p02064 at swan:~/Code/tmp/build> p02064 at swan:~/Code/tmp/build> grep '^MPI_.*' CMakeCache.txt | grep -v INTERNAL MPI_CXX_COMPILER:STRING=/opt/cray/craype/2.4.1/bin/CC MPI_CXX_COMPILE_FLAGS:STRING= MPI_CXX_INCLUDE_PATH:STRING= MPI_CXX_LIBRARIES:STRING= MPI_CXX_LINK_FLAGS:STRING= MPI_CXX_NO_INTERROGATE:STRING=/opt/cray/craype/2.4.1/bin/CC MPI_C_COMPILER:STRING=/opt/cray/craype/2.4.1/bin/cc MPI_C_COMPILE_FLAGS:STRING= MPI_C_INCLUDE_PATH:STRING= MPI_C_LIBRARIES:STRING= MPI_C_LINK_FLAGS:STRING= MPI_C_NO_INTERROGATE:STRING=/opt/cray/craype/2.4.1/bin/cc MPI_EXTRA_LIBRARY:STRING=MPI_EXTRA_LIBRARY-NOTFOUND MPI_LIBRARY:FILEPATH=MPI_LIBRARY-NOTFOUND p02064 at swan:~/Code/tmp/build> p02064 at swan:~/Code/tmp/build> make [ 25%] Building C object CMakeFiles/test-mpi-c.dir/test-mpi.c.o [ 50%] Linking C executable test-mpi-c [ 50%] Built target test-mpi-c [ 75%] Building CXX object CMakeFiles/test-mpi-cxx.dir/test-mpi.cxx.o [100%] Linking CXX executable test-mpi-cxx [100%] Built target test-mpi-cxx p02064 at swan:~/Code/tmp/build> As you can see from the resulting cache, the FindMPI module knows how to act accordingly even when mpi libraries are folded into the regular compiler. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.gallagher at gatech.edu Wed Sep 9 13:24:11 2015 From: tim.gallagher at gatech.edu (Tim Gallagher) Date: Wed, 9 Sep 2015 13:24:11 -0400 (EDT) Subject: [CMake] CMake + MPI In-Reply-To: Message-ID: <998140380.6124165.1441819451180.JavaMail.root@mail.gatech.edu> That's good to know -- it looks like that capability was added 3 months after we wrote our CMakeLists.txt and we had to skip the find_package if we used a cray. That was 2011 and we never looked back at it because it worked. I guess I can go ahead and update that! Tim ----- Original Message ----- From: "Chuck Atkins" To: "tim gallagher" Cc: "Andreas Naumann" , cmake at cmake.org Sent: Wednesday, September 9, 2015 11:11:27 AM Subject: Re: [CMake] CMake + MPI The only exception to that (which I am aware of) is if you are on a CRAY system where the MPI (and BLAS and LAPACK) are baked into the compiler wrappers (cc, ftn, etc). In those situations, you actually do not want to run find_package(MPI) or it will throw errors. Not true. The FindMPI.cmake module performs the appropriate introspection to check if your primary compiler wraps accordingly. For example, on a Cray XC30, with the PrgEnv-pgi and cray-mpich modules loaded: p02064 at swan:~/Code/tmp/build> cat ../source/CMakeLists.txt cmake_minimum_required(VERSION 3.3) project(TestMPI C CXX) find_package(MPI REQUIRED) add_executable(test-mpi-c test-mpi.c) target_include_directories(test-mpi-c PRIVATE ${MPI_C_INCLUDE_PATH}) target_link_libraries(test-mpi-c ${MPI_C_LIBRARIES}) add_executable(test-mpi-cxx test-mpi.cxx) target_include_directories(test-mpi-cxx PRIVATE ${MPI_CXX_INCLUDE_PATH}) target_link_libraries(test-mpi-cxx ${MPI_CXX_LIBRARIES}) p02064 at swan:~/Code/tmp/build> p02064 at swan:~/Code/tmp/build> cmake ../source -- The C compiler identification is PGI 15.7.0 -- The CXX compiler identification is PGI 15.7.0 -- Check for working C compiler: /opt/cray/craype/2.4.1/bin/cc -- Check for working C compiler: /opt/cray/craype/2.4.1/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /opt/cray/craype/2.4.1/bin/CC -- Check for working CXX compiler: /opt/cray/craype/2.4.1/bin/CC -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Found MPI_C: /opt/cray/craype/2.4.1/bin/cc -- Found MPI_CXX: /opt/cray/craype/2.4.1/bin/CC -- Configuring done -- Generating done -- Build files have been written to: /home/users/p02064/Code/tmp/build p02064 at swan:~/Code/tmp/build> p02064 at swan:~/Code/tmp/build> grep '^MPI_.*' CMakeCache.txt | grep -v INTERNAL MPI_CXX_COMPILER:STRING=/opt/cray/craype/2.4.1/bin/CC MPI_CXX_COMPILE_FLAGS:STRING= MPI_CXX_INCLUDE_PATH:STRING= MPI_CXX_LIBRARIES:STRING= MPI_CXX_LINK_FLAGS:STRING= MPI_CXX_NO_INTERROGATE:STRING=/opt/cray/craype/2.4.1/bin/CC MPI_C_COMPILER:STRING=/opt/cray/craype/2.4.1/bin/cc MPI_C_COMPILE_FLAGS:STRING= MPI_C_INCLUDE_PATH:STRING= MPI_C_LIBRARIES:STRING= MPI_C_LINK_FLAGS:STRING= MPI_C_NO_INTERROGATE:STRING=/opt/cray/craype/2.4.1/bin/cc MPI_EXTRA_LIBRARY:STRING=MPI_EXTRA_LIBRARY-NOTFOUND MPI_LIBRARY:FILEPATH=MPI_LIBRARY-NOTFOUND p02064 at swan:~/Code/tmp/build> p02064 at swan:~/Code/tmp/build> make [ 25%] Building C object CMakeFiles/test-mpi-c.dir/test-mpi.c.o [ 50%] Linking C executable test-mpi-c [ 50%] Built target test-mpi-c [ 75%] Building CXX object CMakeFiles/test-mpi-cxx.dir/test-mpi.cxx.o [100%] Linking CXX executable test-mpi-cxx [100%] Built target test-mpi-cxx p02064 at swan:~/Code/tmp/build> As you can see from the resulting cache, the FindMPI module knows how to act accordingly even when mpi libraries are folded into the regular compiler. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.enright at gmail.com Wed Sep 9 15:10:10 2015 From: michael.enright at gmail.com (Michael Enright) Date: Wed, 9 Sep 2015 12:10:10 -0700 Subject: [CMake] Tweaking/disabling timeout for "Check for working CXX compiler" In-Reply-To: <20150909025710.GU1245@hades.panopticon> References: <20150909025710.GU1245@hades.panopticon> Message-ID: On Tue, Sep 8, 2015 at 7:57 PM, Dmitry Marakasov wrote: > > Hi! > > FreeBSD project use userspace qemu emulation to cross-build packages > for some architectures, namely arm. This worked great for most > packages, however ones using cmake tend to fail randomly. > Relevant excerpt: > > --- > > > Process terminated due to timeout > > > > The question is obvious: where is this timeout defined, what value > is it set to exactly and is it tunable? > When you build manually in this setup, does the build actually complete? How long does it take for the compile to complete? It seems to me that if the compile is actually completing then worrying about CMake's timeout is worth the trouble. From amdmi3 at amdmi3.ru Wed Sep 9 15:52:22 2015 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Wed, 9 Sep 2015 22:52:22 +0300 Subject: [CMake] Tweaking/disabling timeout for "Check for working CXX compiler" In-Reply-To: References: <20150909025710.GU1245@hades.panopticon> Message-ID: <20150909195222.GA55590@hades.panopticon> * Michael Enright (michael.enright at gmail.com) wrote: > > Relevant excerpt: > > > > --- > > > > > > Process terminated due to timeout > > > > > > > > The question is obvious: where is this timeout defined, what value > > is it set to exactly and is it tunable? > > > > When you build manually in this setup, does the build actually > complete? Of course. > How long does it take for the compile to complete? It's still hard to reproduce, however I've emulated it by writing a Makefile which compiles, then links the test file taken from cmake with the same compiler and flags as used in the build - essentially the same thing which cmake does judging from the output. I've ran this in a loop with package build runing in a parallel to somehow simulate what's actually hapenning on our build cluster and measured some times. Host hardware is Core i7-2600K @ 3.40GHz (4 cores x 2 HT threads) ( min / avg / max ) Build on host: 0.00 / 0.00 / 0.43 (fully native) ARMv6 jail, host toolchain: 0.03 / 0.27 / 3.76 (what we actually use for cross-builds) ARMv6 jail, armv6 toolchain: 0.91 / 1.23 / 4.82 (fully emulated) As you can see, it's not uncommon for the build to take several seconds, and the timeout as I suspect is somewhere around this value. I'd suggest to bump it to some arbitrary high value like 60 seconds, which, on one hand, ensures that the build doesn't hand, on the other tolerates slow hardware and environments. However, I doubt this solution (enforcing any timeouts by default) in general, as there's no limit on how slow compilation could be (slow hardware, emulation, CPU starvation due other tasks and/or low priority, SIGSTOP etc.). > It seems to me that if the compile is actually completing then > worrying about CMake's timeout is worth the trouble. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3 at amdmi3.ru ..: jabber: amdmi3 at jabber.ru http://amdmi3.ru From gheaeckkseqrz at gmail.com Thu Sep 10 03:21:23 2015 From: gheaeckkseqrz at gmail.com (Pierre Wilmot) Date: Thu, 10 Sep 2015 10:21:23 +0300 Subject: [CMake] Fwd: Fwd: Expected behaviour for Tests/VSWinStorePhone In-Reply-To: References: <96EC67AD-B4C0-4A94-A1B0-F7BCCCC75243@gmail.com> Message-ID: Hi Parag, Thanks for the reply, it does help, I'm getting a working solution that let me build and run the "cube app" on my phone. But what I'm trying to achieve here is a fully automation Generate Build and Run system for continuous integration. I'm using the cmake --build command to compile, but the resulting appx wont deploy to the device because of "Error: Deployment optimization failed due to an assembly that's not valid. Try rebuilding the project, and then try again." Here is the script I'm using : https://gist.github.com/anonymous/6d72e8833833ea313e7b And the output : https://gist.github.com/anonymous/adafc15d4fb4ab7ca04c I've been trying to set the startup project with https://github.com/michaKFromParis/slnStartupProject, but it keeps giving the same result. I've also tried to sign the appx, but it doesn't work any better. If I build it using Visual studio, I need to right click the Direct3DApp1 and "Set it as startup project", but is there any way to the same result from command line ? Thanks for the help :) Best regards, Pierre 2015-09-09 16:31 GMT+03:00 Parag Chandra : > Hi Pierre, > > For the ARM version, I believe you will need to specify the CPU > architecture explicitly, because CMake is not going to generate a > ?fat?/multi-arch solution in the manner that it does for Xcode. What I do > for WinPhone is to pass arguments like this: > > -DCMAKE_SYSTEM_NAME=WindowsPhone -DCMAKE_SYSTEM_VERSION=8.1 ?G?Visual > Studio 12 2013? -DCMAKE_GENERATOR_PLATFORM=ARM > > Hope this helps. > > > > *Parag Chandra *Senior Software Engineer, Mobile Team > Mobile: +1.919.824.1410 > > > > Ionic Security Inc. > 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 > > > > > > > > > From: CMake on behalf of Pierre Wilmot > Date: Wednesday, September 9, 2015 at 3:49 AM > To: "cmake at cmake.org" > Subject: [CMake] Fwd: Expected behaviour for Tests/VSWinStorePhone > > > > Hi everyone, > > I?m trying to generate a Windows Phone 8.1 project from CMake, I was > expecting the Tests/VSWinStorePhone folder to be a good template to start > with, but I?m a bit confused with the result I get. > > I was expecting to get pretty much the same result as a project created > with the Visual studio ?DirectX and XAML App (Windows Phone)?. That means a > project displaying cubes that I could just run on my Windows Phone device > by pressing run on device. > > Instead I?m getting a project with no ARM configuration, only Win32 which > is surprising, because as far as I know, there only ARM device available on > the market. > If I build the project, I get an exe throwing an error on launch > > ?This application can only run in the context of an app container?. > (started from exe) > OR > ?In order to debug this project, you must consume it from an application > project that creates a package and is marked as the Startup Project? > (started from Visual Studio) > > As the Project name is ?VSWinStorePhone?, I was expecting the created > solution to be ready for Windows Phone deployment, but it?s not. > > Is that the expected behaviour ? > If so, where can I find a good CMakeList template to create a Windows > Phone 8.1 app ? > > Setup Info: > > Running on Windows 8 x64 > With Visual Studio Professional 2013 Version 12.0.31101.00 Update 4 > Used cmake 3.3.1-win32-x86 > With the file of Tests/VSWinStorePhone from the current github master > branch > > Ran command from Desktop/CMAKEOUT : > ..\cmake-3.3.1-win32-x86\bin\cmake.exe > ..\Cmake-master\Test\VSWinStrorePhone > > Best regards, > Pierre > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.wirtz at simtech.uni-stuttgart.de Thu Sep 10 10:34:13 2015 From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz) Date: Thu, 10 Sep 2015 16:34:13 +0200 Subject: [CMake] FindGit.cmake proposal Message-ID: <55F194E5.4030300@simtech.uni-stuttgart.de> Dear all, i've now quite often encountered the need to access basic git information about the source tree from within cmake. i've attached the current FindGit.cmake module shipped with CMake enhanced by two functions: getGitRevision and getGitBranch. if you fancy the idea of having this included, feel free to include any part of it in future releases. if this is not the "right way" of proposing such things, where to go to? cheers Daniel -- Dr. Daniel Wirtz Dipl. Math. Dipl. Inf. SRC SimTech Pfaffenwaldring 5a +49 711 685 60044 -------------- next part -------------- A non-text attachment was scrubbed... Name: FindGit.cmake Type: text/x-cmake Size: 3914 bytes Desc: not available URL: From dayan.sivalingam at yahoo.com Thu Sep 10 15:24:31 2015 From: dayan.sivalingam at yahoo.com (dayan.s) Date: Thu, 10 Sep 2015 12:24:31 -0700 (MST) Subject: [CMake] PackageMaker Generator and Developer Identification. Message-ID: <1441913071894-7591492.post@n2.nabble.com> I am using PackageMaker Generator to create .dmg and .pkg of a MAC application that we intend distribute outside of the App Store - So far so good. I am looking into the next step of signing this application, so as to ensure that the GateKeeper does not flag it as quarantined. Questions: 1) Does the PackageMaker Generator have this capability ? what are the variables that need to be configured to make this happen ? In my limited experience, the closest thing i could find is CPACK_BUNDLE_APPLE_CERT_APP. But I guess that pertains to the Bundle Generator. Any help is very much appreciated. Thanks, -- View this message in context: http://cmake.3232098.n2.nabble.com/PackageMaker-Generator-and-Developer-Identification-tp7591492.html Sent from the CMake mailing list archive at Nabble.com. From nico.schloemer at gmail.com Fri Sep 11 04:53:59 2015 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Fri, 11 Sep 2015 08:53:59 +0000 Subject: [CMake] FindMPI Message-ID: Hi everyone, I see from the CMake docs [1] that the recommended way for using MPI is to call `find_package(MPI)` and set the linker and include flags appropriately. On the other hand, I see from the OpenMPI specs [2] that > The Open MPI team *strongly* recommends that you simply use Open MPI's > "wrapper" compilers to compile your MPI applications. Is there a way to reconcile these two approaches? Cheers, Nico [1] http://www.cmake.org/cmake/help/v3.0/module/FindMPI.html [2] https://www.open-mpi.org/faq/?category=mpi-apps#general-build -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwan.work at gmail.com Fri Sep 11 05:10:37 2015 From: rwan.work at gmail.com (Raymond Wan) Date: Fri, 11 Sep 2015 17:10:37 +0800 Subject: [CMake] FindMPI In-Reply-To: References: Message-ID: Hi Nico, On Fri, Sep 11, 2015 at 4:53 PM, Nico Schl?mer wrote: > I see from the CMake docs [1] that the recommended way for using MPI is to > call `find_package(MPI)` and set the linker and include flags appropriately. > On the other hand, I see from the OpenMPI specs [2] that > >> > > The Open MPI team strongly recommends that you simply use Open MPI's > >> "wrapper" compilers to compile your MPI applications. > > > Is there a way to reconcile these two approaches? I'm not sure what is the "right" way to do things, but FindMPI and the Open MPI's doc doesn't really contradict with each other. If you look at the source for FindMPI.cmake, the variable for MPI__COMPILER gets set to the path of the wrapper. So, the wrapper is found. Honestly, I've never tried replacing the compiler in my CMake with this wrapper, without setting any libraries...it might work? CMake is suppose to be for cross-platform development. Some other system might have MPI but no wrapper compiler. So, perhaps for this reason, it's a good idea not to rely on the wrapper? Maybe you could use the wrapper and if MPI__COMPILER is not set, then set the library, etc. the CMake way? As for the Open MPI's suggestion, I don't think that paragraph means that they suggest it over CMake's method. I think what it is suggesting is to use the wrapper over trying to worry about the libraries and options "manually" -- which is a pain. Ray From alain.miniussi at oca.eu Fri Sep 11 05:32:17 2015 From: alain.miniussi at oca.eu (Alain Miniussi) Date: Fri, 11 Sep 2015 11:32:17 +0200 Subject: [CMake] FindMPI In-Reply-To: References: Message-ID: <55F29FA1.8050008@oca.eu> On 11/09/2015 10:53, Nico Schl?mer wrote: > Hi everyone, > > I see from the CMake docs [1] that the recommended way for using MPI is to call `find_package(MPI)` and set the linker and include flags appropriately. On the other hand, I see from the OpenMPI specs [2] that > > > > > The Open MPI team *strongly* recommends that you simply use Open MPI's > > > "wrapper" compilers to compile your MPI applications. > > > Is there a way to reconcile these two approaches? I'm still not sure why those wrappers are provided, except that MPI is mostly used in HPC, where code is often written by people with little engineering background who can't always be trusted for setting compilation and link flags. I guess it saves them a lot of support ? The two approaches have theirs draw back, including: Using the wrappers: -Not all MPI implementations have wrappers. - Some implementations do not call the underlying compiler you would expect, meaning you might have to set a sub standard env var to select it. (Intel's mpicc calls gcc by default, not icc, you need to use mpiicc (not a standard name) or set some var or ..) - You might need to mix with another tool which also provides its own "helpful" wrapper. Using CMake to detect the MPI stuff: - depending on the cmake version and implementations, can be a PITA. MPI relies on the presence of some flags in the (sometime non-existing) wrapper (-show...) which are not always present, or are present but won't behave as expected, or maybe are not present but won't dare reporting it properly in order not to hurt the feeling of pre-existing build system too harshly (provided I understood Intel's explanation). Most of the time, I use FindMPI which I feed explicitly with compile and link flags... which feel weird. Cheers Alain > > Cheers, > Nico > > > [1] http://www.cmake.org/cmake/help/v3.0/module/FindMPI.html > [2] https://www.open-mpi.org/faq/?category=mpi-apps#general-build > > From Emmanuel.HOUITTE at ingenico.com Fri Sep 11 09:26:47 2015 From: Emmanuel.HOUITTE at ingenico.com (Emmanuel HOUITTE) Date: Fri, 11 Sep 2015 13:26:47 +0000 Subject: [CMake] CMAKE_CXX_COMPILE_OBJECT not set with ADD_SUBDIRECTORY Message-ID: <83644FD2E7AE5440A6494BC3949F1C2B82850483@COSNADEXC23.usr.ingenico.loc> I'm working with cmake version 2.8.12.2 on CentOS6. I've got a very simple project with one subdirectory. Each directory has a CMakeLists.txt file. The ADD_SUBDIRECTORY seems to remove the default generated CMAKE rule variables in the generation step. Is it normal? How to get an example without generation errors? If I replace the ADD_SUBDIRECTORY by the code of the second CMakeLists.txt, there is no problem. This is the content of my project: -- lib CMakeLists.txt { CMAKE_MINIMUM_REQUIRED (VERSION 2.8.8) ADD_SUBDIRECTORY(libtest) PROJECT(lib) } -- libtest CMakeLists.txt { FILE(WRITE "empty.cpp" "") ADD_LIBRARY(test STATIC empty.cpp ) } And the results: $ cmake -DCMAKE_BUILD_TYPE=Release -- Configuring done CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_CXX_COMPILE_OBJECT CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_CXX_CREATE_STATIC_LIBRARY -- Generating done -- Build files have been written to: /home/test/lib -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at sap.com Fri Sep 11 10:12:29 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Fri, 11 Sep 2015 14:12:29 +0000 Subject: [CMake] CMAKE_CXX_COMPILE_OBJECT not set with ADD_SUBDIRECTORY Message-ID: PROJECT instruction MUST BE the first one after CMAKE_MINIMUM_REQUIRED: -- lib CMakeLists.txt { CMAKE_MINIMUM_REQUIRED (VERSION 2.8.8) PROJECT(lib) ADD_SUBDIRECTORY(libtest) } From: CMake on behalf of Emmanuel HOUITTE Date: Friday 11 September 2015 15:26 To: "cmake at cmake.org" Subject: [CMake] CMAKE_CXX_COMPILE_OBJECT not set with ADD_SUBDIRECTORY I?m working with cmake version 2.8.12.2 on CentOS6. I?ve got a very simple project with one subdirectory. Each directory has a CMakeLists.txt file. The ADD_SUBDIRECTORY seems to remove the default generated CMAKE rule variables in the generation step. Is it normal? How to get an example without generation errors? If I replace the ADD_SUBDIRECTORY by the code of the second CMakeLists.txt, there is no problem. This is the content of my project: -- lib CMakeLists.txt { CMAKE_MINIMUM_REQUIRED (VERSION 2.8.8) ADD_SUBDIRECTORY(libtest) PROJECT(lib) } -- libtest CMakeLists.txt { FILE(WRITE "empty.cpp" "") ADD_LIBRARY(test STATIC empty.cpp ) } And the results: $ cmake -DCMAKE_BUILD_TYPE=Release -- Configuring done CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_CXX_COMPILE_OBJECT CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_CXX_CREATE_STATIC_LIBRARY -- Generating done -- Build files have been written to: /home/test/lib -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamieh at xmos.com Fri Sep 11 13:02:24 2015 From: jamieh at xmos.com (Jamie Hanlon) Date: Fri, 11 Sep 2015 17:02:24 +0000 Subject: [CMake] Force rebuild of external project with Ninja Message-ID: <6CBAD7B29A160A46BCB08426862D870B167B2538@EXMAILBOX2.vo.spidergroup.co.uk> Dear all, I thought I would post this here before filing a bug, to see if anyone else has encountered this problem. The 'BUILD_ALWAYS 1' option for 'ExternalProject_Add' does not run the install command when used with Ninja. This behaviour can be demonstrated with the following project: CMakeLists.txt (1) foo/ CMakeLists.txt (2) Where CMakeLists.txt (1) contains: cmake_minimum_required(VERSION 3.2) include(ExternalProject) ExternalProject_Add(foo SOURCE_DIR foo CONFIGURE_COMMAND "" BUILD_COMMAND echo "building foo" INSTALL_COMMAND "installing foo" BUILD_ALWAYS 1) And CMakeLists.txt (2) is empty. In the top level directory, initialising CMake, then running 'ninja': $ cmake . -DCMAKE_GENERATOR=Ninja ... $ ninja [6/8] Performing build step for 'foo' building foo [7/8] Performing install step for 'foo' installing foo [8/8] Completed 'foo' $ ninja [1/3] Performing build step for 'foo' building foo $ ninja [1/3] Performing build step for 'foo' building foo $ ninja [1/3] Performing build step for 'foo' building foo Causes the build and install step to run the first time, but only the build step to run after. With Make, the build and install steps are always run, as I would expect: $ cmake . -DCMAKE_GENERATOR='Unix Makefiles' ... $ make Scanning dependencies of target foo [ 12%] Creating directories for 'foo' [ 25%] No download step for 'foo' [ 37%] No patch step for 'foo' [ 50%] No update step for 'foo' [ 62%] No configure step for 'foo' [ 75%] Performing build step for 'foo' building foo [ 87%] Performing install step for 'foo' installing foo [100%] Completed 'foo' [100%] Built target foo $ make [ 12%] Performing build step for 'foo' building foo [ 25%] Performing install step for 'foo' installing foo [ 37%] Completed 'foo' [100%] Built target foo $ make [ 12%] Performing build step for 'foo' building foo [ 25%] Performing install step for 'foo' installing foo [ 37%] Completed 'foo' [100%] Built target foo Similarly, with CMakeLists.txt (1) this time containing an 'ExternalProject_Add_Step' and 'ALWAYS 1': cmake_minimum_required(VERSION 3.2) include(ExternalProject) ExternalProject_Add(foo SOURCE_DIR foo CONFIGURE_COMMAND "" BUILD_COMMAND echo "building foo" INSTALL_COMMAND echo "installing foo" ) ExternalProject_Add_Step(foo force_rebuild DEPENDERS build ALWAYS 1) Make works as above, but this time, Ninja does not run the build or install steps after the first run: $ cmake . -DCMAKE_GENERATOR=Ninja ... $ ninja [7/9] Performing build step for 'foo' building foo [8/9] Performing install step for 'foo' installing foo [9/9] Completed 'foo' $ ninja [1/4] No force_rebuild step for 'foo' $ ninja [1/4] No force_rebuild step for 'foo' In these examples, I'm using CMake 3.3.1, Ninja 1.3.4 and Make 3.81. Cheers, Jamie From vladimir.yelnikov at gmail.com Fri Sep 11 13:14:29 2015 From: vladimir.yelnikov at gmail.com (Vladimir Yelnikov) Date: Fri, 11 Sep 2015 20:14:29 +0300 Subject: [CMake] Ninja target aliases generation - mixing absolute target path with relative Message-ID: Dear all, Project has following structure (and I can't change it) -project -module1 -CMakeLists.txt (module1 build rules, depends on module2 using add_subdirectory("../module2" "${binarypath}") -lib1 -CMakeLists.txt (depends on lib3) -lib2 -CMakeLists.txt -module2 -lib3 -CMakeLists.txt -lib4 -CMakeLists.txt But ninja generator generates build rule with absolute paths: build d$:\project\module2\lib3:.... But depends it as ..\module2\lib3 as a result I got following error: ninja: error: '../module2/lib3.lib', needed by 'lib1', missing and no known rule to make it I added additional phony to build.ninja and it worked: build ../module2/lib3.lib: phony d$:\project\module2\lib3 How should I fix CMake files to generate same names/aliases for targets? -- Best Wishes, Vladimir Yelnikov -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaronngray.lists at gmail.com Fri Sep 11 19:13:34 2015 From: aaronngray.lists at gmail.com (Aaron Gray) Date: Sat, 12 Sep 2015 00:13:34 +0100 Subject: [CMake] Anyone got Clang/LLVM working natively on Windows Message-ID: Hi Has anyone got Clang/LLVM working natively on Windows, and got CMake scripts for it ? Many thanks in advance, Aaron From wmamrak at gmail.com Sat Sep 12 09:04:12 2015 From: wmamrak at gmail.com (Wojciech Mamrak) Date: Sat, 12 Sep 2015 15:04:12 +0200 Subject: [CMake] install EXPORT uses absolute paths on Windows, making libraries not relocatable Message-ID: Hello, based on both wiki and this presentation: https://archive.fosdem.org/2013/schedule/event/moderncmake/attachments/slides/258/export/events/attachments/moderncmake/slides/258/cmake_fosdem_2013.pdf I have made this simple example. Its purpose is to test installing projects and importing them by other projects. CMakeLists.txt: cmake_minimum_required(VERSION 3.3) add_library(foo main.cpp) if (NOT DEFINED INSTALL_LIBDIR) set(INSTALL_LIBDIR "" CACHE PATH "Output directory for libraries") endif() set(CMAKECONFIG_INSTALL_DIR "${INSTALL_LIBDIR}/CMake") include(CMakePackageConfigHelpers) configure_package_config_file(FooConfig.cmake.in FooConfig.cmake INSTALL_DESTINATION "${CMAKECONFIG_INSTALL_DIR}") install(FILES "${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake" DESTINATION "${CMAKECONFIG_INSTALL_DIR}") install(TARGETS foo EXPORT FooTargets ARCHIVE DESTINATION "${INSTALL_LIBDIR}") install(EXPORT FooTargets DESTINATION "${CMAKECONFIG_INSTALL_DIR}") FooConfig.cmake.in: @PACKAGE_INIT@ include("${CMAKE_CURRENT_LIST_DIR}/FooTargets.cmake") Assume sources are located at "G:/workspace/Foo". I am setting INSTALL_LIBDIR to "G:/Install". Installation output: > -- Install configuration: "Debug" > -- Installing: G:/Install/CMake/FooConfig.cmake > -- Installing: G:/Install/foo.lib > -- Installing: G:/Install/CMake/FooTargets.cmake > -- Installing: G:/Install/CMake/FooTargets-debug.cmake The contents of FooTargets-debug.cmake seems to be problematic: #---------------------------------------------------------------- # Generated CMake target import file for configuration "Debug". #---------------------------------------------------------------- # Commands may need to know the format version. set(CMAKE_IMPORT_FILE_VERSION 1) # Import target "foo" for configuration "Debug" set_property(TARGET foo APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG) set_target_properties(foo PROPERTIES IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX" IMPORTED_LOCATION_DEBUG "G:/Install/foo.lib" ) list(APPEND _IMPORT_CHECK_TARGETS foo ) list(APPEND _IMPORT_CHECK_FILES_FOR_foo "G:/Install/foo.lib" ) # Commands beyond this point should not need to know the version. set(CMAKE_IMPORT_FILE_VERSION) Notice the absolute paths, which make this code not relocatable. I would like to be able to copy the install tree to some other machine and point CMAKE_PREFIX_PATH to that new location. How can I achieve this? regards From nilsgladitz at gmail.com Sat Sep 12 09:30:58 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sat, 12 Sep 2015 15:30:58 +0200 Subject: [CMake] install EXPORT uses absolute paths on Windows, making libraries not relocatable In-Reply-To: References: Message-ID: <55F42912.9050100@gmail.com> On 12.09.2015 15:04, Wojciech Mamrak wrote: > install(TARGETS foo > EXPORT FooTargets > ARCHIVE DESTINATION "${INSTALL_LIBDIR}") Your target's install DESTINATION is absolute which is why the exported location is absolute as well. e.g. using "DESTINATION lib" instead of "DESTINATION /foo/bar/lib" should make both your install and export relative (relocatable). For the regular "install" target install destinations are appended to CMAKE_INSTALL_PREFIX[1]. Nils [1] http://www.cmake.org/cmake/help/v3.3/variable/CMAKE_INSTALL_PREFIX.html From seth.cantrell at gmail.com Sat Sep 12 16:52:34 2015 From: seth.cantrell at gmail.com (Seth Cantrell) Date: Sat, 12 Sep 2015 16:52:34 -0400 Subject: [CMake] fixup_bundles on macosx for non-.app target Message-ID: <1038F7E4-9919-4287-A331-7E44AAD7A619@gmail.com> I have a project which uses fixup_bundle on Windows to package up the exe with the third-party dlls it requires. On Mac OS X this same packaging process fails. It looks like on Mac OS X this utility is assuming I want to producing a .app bundle. I realize this utility originated on Mac OS X specifically for dealing with .app bundles, but it's also been expanded to handle simply producing relocatable executable directories on other platforms. Can fixup_bundle be used for that purpose on Mac OS X as well? I simply want to have CPack zip up a command line executable with the automatically detected third party .dylibs and to fix up the install names so that the executable uses included dylibs on Mac OS X. Thanks, Seth From dank at kegel.com Sat Sep 12 17:28:54 2015 From: dank at kegel.com (Dan Kegel) Date: Sat, 12 Sep 2015 14:28:54 -0700 Subject: [CMake] fixup_bundles on macosx for non-.app target In-Reply-To: <1038F7E4-9919-4287-A331-7E44AAD7A619@gmail.com> References: <1038F7E4-9919-4287-A331-7E44AAD7A619@gmail.com> Message-ID: On Sat, Sep 12, 2015 at 1:52 PM, Seth Cantrell wrote: > I have a project which uses fixup_bundle on Windows to package up the exe with the third-party dlls it requires. On Mac OS X this same packaging process fails. It looks like on Mac OS X this utility is assuming I want to producing a .app bundle. Given that a .app bundle is just a directory containing the executable and the things it depends on, what's wrong with what fixup_bundle does? Do you have a special reason to not want to follow the .app convention? - Dan From wmamrak at gmail.com Sat Sep 12 18:25:17 2015 From: wmamrak at gmail.com (Wojtek Mamrak) Date: Sun, 13 Sep 2015 00:25:17 +0200 Subject: [CMake] install EXPORT uses absolute paths on Windows, making libraries not relocatable In-Reply-To: <55F42912.9050100@gmail.com> References: <55F42912.9050100@gmail.com> Message-ID: I must have missed that, thanks! 2015-09-12 15:30 GMT+02:00 Nils Gladitz : > On 12.09.2015 15:04, Wojciech Mamrak wrote: >> >> install(TARGETS foo >> EXPORT FooTargets >> ARCHIVE DESTINATION "${INSTALL_LIBDIR}") > > > Your target's install DESTINATION is absolute which is why the exported > location is absolute as well. > > e.g. using "DESTINATION lib" instead of "DESTINATION /foo/bar/lib" should > make both your install and export relative (relocatable). > For the regular "install" target install destinations are appended to > CMAKE_INSTALL_PREFIX[1]. > > Nils > > [1] http://www.cmake.org/cmake/help/v3.3/variable/CMAKE_INSTALL_PREFIX.html From seth.cantrell at gmail.com Sat Sep 12 19:54:02 2015 From: seth.cantrell at gmail.com (Seth Cantrell) Date: Sat, 12 Sep 2015 19:54:02 -0400 Subject: [CMake] fixup_bundles on macosx for non-.app target In-Reply-To: References: <1038F7E4-9919-4287-A331-7E44AAD7A619@gmail.com> Message-ID: <43A20A83-1405-44A5-9ABF-7160BAC2AE2D@gmail.com> > > On Sep 12, 2015, at 5:28 PM, Dan Kegel wrote: > > On Sat, Sep 12, 2015 at 1:52 PM, Seth Cantrell wrote: >> I have a project which uses fixup_bundle on Windows to package up the exe with the third-party dlls it requires. On Mac OS X this same packaging process fails. It looks like on Mac OS X this utility is assuming I want to producing a .app bundle. > > Given that a .app bundle is just a directory containing the executable and > the things it depends on, what's wrong with what fixup_bundle does? > Do you have a special reason to not want to follow the .app convention? > - Dan The primary problem is simply that install and CPack processes fail on Mac OS X. If I can get the process to succeed, even if that means producing a .app directory structure for this non-.app, command line executable that would be a fine first step. But ultimately I'd rather not have to fake the .app structure either. On Windows installing and packaging succeed. For example on windows I get a .zip file named myproj-0.1.1-win64.zip that contains: myproj-0.1.1-win64.zip\ myproj-0.1.1-win64\ main.exe somelib.dll someotherlib.dll And of course the _CPack_Packages structure used to generate this is _CPack_Packages\ win64\ ZIP\ myproj-0.1.1-win64\ main.exe somelib.dll someotherlib.dll This is the same structure I'd like to produce on OS X. On Mac OS X the packaging process fails: > [1/1] Run CPack packaging tool... > CPack: Create package using ZIP > CPack: Install projects > CPack: - Install project: scratch > exe_dotapp_dir/='/Volumes/D/Builds/scratch/_CPack_Packages/Darwin/ZIP/scratch-0.1.1-Darwin/' > item_substring='/Volumes/D/Builds/scratch/_CPack_Packages/Darwin/ZIP/MacOS/somelib' > resolved_embedded_item='/Volumes/D/Builds/scratch/_CPack_Packages/Darwin/ZIP/MacOS/somelib.dylib' > > Install or copy the item into the bundle before calling fixup_bundle. > Or maybe there's a typo or incorrect path in one of the args to fixup_bundle? > > CMake Error at /Applications/CMake.app/Contents/share/cmake-3.3/Modules/BundleUtilities.cmake:737 (message): > cannot fixup an item that is not in the bundle... > Call Stack (most recent call first): > /Applications/CMake.app/Contents/share/cmake-3.3/Modules/BundleUtilities.cmake:848 (fixup_bundle_item) > /Volumes/D/Builds/scratch/FixBundle.cmake:11 (fixup_bundle) > /Volumes/D/Builds/scratch/cmake_install.cmake:41 (include) > > > CPack Error: Error when generating package: scratch > FAILED: cd /Volumes/D/Builds/scratch && /Applications/CMake.app/Contents/bin/cpack --config ./CPackConfig.cmake > ninja: build stopped: subcommand failed. On Mac OS X after the packaging failure I can see that _CPack_Packages contains a directory structure _CPack_Packages\ Darwin\ ZIP\ MacOS\ somelib.dylib someotherlib.dylib myproj-0.1.1-Darwin\ main and the process has stopped before generating the zip file. The initial error is due to the fact that I'm putting the executable in the root of the install tree: install(TARGETS main DESTINATION "."). This causes fixup_bundle's behavior on Mac OS to put the libraries outside the directory that CPack is preparing to zip, causing an error where fixup (quite correctly) refuses to work when the dylibs aren't in the directory that's going to be zipped up Even so, the packaging process has clearly gone as far as correctly identifying the dylibs and copying them into the _CPack_Packages directory. Using otool I can see that the executable's rpath's for finding the dylibs have been updated: @executable_path/../MacOS/somelib.dylib. Using DYLD_PRINT_LIBRARIES I can see that running the executable does indeed load the intended .dylibs the the program runs correctly. Trying to fix the issue of the dylibs being put outside the zip directory, I changed the install command to not put the executable at the root of the install location: install(TARGET main DESTINATION "bin"). This still does not succeed because fixup_bundle is explicitly verifying whether the directory structure is a valid bundle, which this is not. > CMake Error at /Applications/CMake.app/Contents/share/cmake-3.3/Modules/BundleUtilities.cmake:860 (message): > error: fixup_bundle: not a valid bundle And of course just trying to ape the .app directory structure still does not produce a valid .app bundle: install(TARGETS main DESTINATION "foo.app/Contents/MacOS") I would prefer to not be required to use the .app bundle directory structure at all. I'm not producing a .app. The program is a command line program intended to be run directly from Terminal.app, not a GUI program intended to be launched from Mac OS's Finder. I just want to automatically detect the necessary .dylibs, copy them into the folder that gets zipped up, fix up the dyld paths to make the executable relocatable, and zip up the whole thing. --- Here's the scripts I've got on Windows and which produce the desired products, but which fail on Mac OS. CMakeLists.txt: ... > 7 add_executable(main main.cpp) ... > 10 target_include_directories(main PRIVATE ${somelib_INCLUDE_DIRS}) > 11 target_link_libraries(main PRIVATE ${somelib_LIBRARIES}) ... > 14 install(TARGETS main DESTINATION ".") > 15 > 16 configure_file( > 17 ${CMAKE_CURRENT_SOURCE_DIR}/FixBundle.cmake.in > 18 ${CMAKE_CURRENT_BINARY_DIR}/FixBundle.cmake > 19 @ONLY) > 20 > 21 install(SCRIPT ${CMAKE_CURRENT_BINARY_DIR}/FixBundle.cmake) > 22 > 23 set(CPACK_GENERATOR ZIP 7Z TBZ2) > 24 include(CPack) FixBundle.cmake.in > 1 include(BundleUtilities) > 2 > 3 set(bundle "${CMAKE_INSTALL_PREFIX}/main at CMAKE_EXECUTABLE_SUFFIX@") > 4 > 5 set(other_libs "") > 6 set(dirs > 7 "@CMAKE_RUNTIME_OUTPUT_DIRECTORY@" > 8 "@CMAKE_LIBRARY_OUTPUT_DIRECTORY@" > 9 ) > 10 > 11 fixup_bundle("${bundle}" "${other_libs}" "${dirs}") > 12 From dank at kegel.com Sat Sep 12 20:10:44 2015 From: dank at kegel.com (Dan Kegel) Date: Sat, 12 Sep 2015 17:10:44 -0700 Subject: [CMake] fixup_bundles on macosx for non-.app target In-Reply-To: <43A20A83-1405-44A5-9ABF-7160BAC2AE2D@gmail.com> References: <1038F7E4-9919-4287-A331-7E44AAD7A619@gmail.com> <43A20A83-1405-44A5-9ABF-7160BAC2AE2D@gmail.com> Message-ID: On Sep 12, 2015 4:54 PM, "Seth Cantrell" wrote: > > I would prefer to not be required to use the .app bundle directory structure at all. I'm not producing a .app. The program is a command line program intended to be run directly from Terminal.app, not a GUI program intended to be launched from Mac OS's Finder. So provide a symlink or wrapper script, that's what I do. Don't fight the Force :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Sat Sep 12 21:09:59 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Sat, 12 Sep 2015 21:09:59 -0400 Subject: [CMake] fixup_bundles on macosx for non-.app target In-Reply-To: <43A20A83-1405-44A5-9ABF-7160BAC2AE2D@gmail.com> References: <1038F7E4-9919-4287-A331-7E44AAD7A619@gmail.com> <43A20A83-1405-44A5-9ABF-7160BAC2AE2D@gmail.com> Message-ID: <47FE5E52-9F6B-4648-9726-D7AFBC68152E@bluequartz.net> I have a mix of .app and command line executables for our project on OS X. I wrote a templated .sh file that cmake uses to ?configure_file()? by filling in details needed. The Script itself does the ?fix up? stuff by running otool, parsing the output, looking for the libraries and then updating everything. You are welcome to the script if you find it useful. Mike Jackson > On Sep 12, 2015, at 7:54 PM, Seth Cantrell wrote: > >> >> On Sep 12, 2015, at 5:28 PM, Dan Kegel wrote: >> >> On Sat, Sep 12, 2015 at 1:52 PM, Seth Cantrell wrote: >>> I have a project which uses fixup_bundle on Windows to package up the exe with the third-party dlls it requires. On Mac OS X this same packaging process fails. It looks like on Mac OS X this utility is assuming I want to producing a .app bundle. >> >> Given that a .app bundle is just a directory containing the executable and >> the things it depends on, what's wrong with what fixup_bundle does? >> Do you have a special reason to not want to follow the .app convention? >> - Dan > > The primary problem is simply that install and CPack processes fail on Mac OS X. If I can get the process to succeed, even if that means producing a .app directory structure for this non-.app, command line executable that would be a fine first step. But ultimately I'd rather not have to fake the .app structure either. > > On Windows installing and packaging succeed. For example on windows I get a .zip file named myproj-0.1.1-win64.zip that contains: > > myproj-0.1.1-win64.zip\ > myproj-0.1.1-win64\ > main.exe > somelib.dll > someotherlib.dll > > And of course the _CPack_Packages structure used to generate this is > > _CPack_Packages\ > win64\ > ZIP\ > myproj-0.1.1-win64\ > main.exe > somelib.dll > someotherlib.dll > > This is the same structure I'd like to produce on OS X. > > On Mac OS X the packaging process fails: > >> [1/1] Run CPack packaging tool... >> CPack: Create package using ZIP >> CPack: Install projects >> CPack: - Install project: scratch >> exe_dotapp_dir/='/Volumes/D/Builds/scratch/_CPack_Packages/Darwin/ZIP/scratch-0.1.1-Darwin/' >> item_substring='/Volumes/D/Builds/scratch/_CPack_Packages/Darwin/ZIP/MacOS/somelib' >> resolved_embedded_item='/Volumes/D/Builds/scratch/_CPack_Packages/Darwin/ZIP/MacOS/somelib.dylib' >> >> Install or copy the item into the bundle before calling fixup_bundle. >> Or maybe there's a typo or incorrect path in one of the args to fixup_bundle? >> >> CMake Error at /Applications/CMake.app/Contents/share/cmake-3.3/Modules/BundleUtilities.cmake:737 (message): >> cannot fixup an item that is not in the bundle... >> Call Stack (most recent call first): >> /Applications/CMake.app/Contents/share/cmake-3.3/Modules/BundleUtilities.cmake:848 (fixup_bundle_item) >> /Volumes/D/Builds/scratch/FixBundle.cmake:11 (fixup_bundle) >> /Volumes/D/Builds/scratch/cmake_install.cmake:41 (include) >> >> >> CPack Error: Error when generating package: scratch >> FAILED: cd /Volumes/D/Builds/scratch && /Applications/CMake.app/Contents/bin/cpack --config ./CPackConfig.cmake >> ninja: build stopped: subcommand failed. > > On Mac OS X after the packaging failure I can see that _CPack_Packages contains a directory structure > > _CPack_Packages\ > Darwin\ > ZIP\ > MacOS\ > somelib.dylib > someotherlib.dylib > myproj-0.1.1-Darwin\ > main > > and the process has stopped before generating the zip file. > > The initial error is due to the fact that I'm putting the executable in the root of the install tree: install(TARGETS main DESTINATION "."). This causes fixup_bundle's behavior on Mac OS to put the libraries outside the directory that CPack is preparing to zip, causing an error where fixup (quite correctly) refuses to work when the dylibs aren't in the directory that's going to be zipped up > > Even so, the packaging process has clearly gone as far as correctly identifying the dylibs and copying them into the _CPack_Packages directory. Using otool I can see that the executable's rpath's for finding the dylibs have been updated: @executable_path/../MacOS/somelib.dylib. Using DYLD_PRINT_LIBRARIES I can see that running the executable does indeed load the intended .dylibs the the program runs correctly. > > Trying to fix the issue of the dylibs being put outside the zip directory, I changed the install command to not put the executable at the root of the install location: install(TARGET main DESTINATION "bin"). This still does not succeed because fixup_bundle is explicitly verifying whether the directory structure is a valid bundle, which this is not. > >> CMake Error at /Applications/CMake.app/Contents/share/cmake-3.3/Modules/BundleUtilities.cmake:860 (message): >> error: fixup_bundle: not a valid bundle > > And of course just trying to ape the .app directory structure still does not produce a valid .app bundle: install(TARGETS main DESTINATION "foo.app/Contents/MacOS") > > > I would prefer to not be required to use the .app bundle directory structure at all. I'm not producing a .app. The program is a command line program intended to be run directly from Terminal.app, not a GUI program intended to be launched from Mac OS's Finder. I just want to automatically detect the necessary .dylibs, copy them into the folder that gets zipped up, fix up the dyld paths to make the executable relocatable, and zip up the whole thing. > > --- > > Here's the scripts I've got on Windows and which produce the desired products, but which fail on Mac OS. > > CMakeLists.txt: > > ... >> 7 add_executable(main main.cpp) > ... >> 10 target_include_directories(main PRIVATE ${somelib_INCLUDE_DIRS}) >> 11 target_link_libraries(main PRIVATE ${somelib_LIBRARIES}) > ... >> 14 install(TARGETS main DESTINATION ".") >> 15 >> 16 configure_file( >> 17 ${CMAKE_CURRENT_SOURCE_DIR}/FixBundle.cmake.in >> 18 ${CMAKE_CURRENT_BINARY_DIR}/FixBundle.cmake >> 19 @ONLY) >> 20 >> 21 install(SCRIPT ${CMAKE_CURRENT_BINARY_DIR}/FixBundle.cmake) >> 22 >> 23 set(CPACK_GENERATOR ZIP 7Z TBZ2) >> 24 include(CPack) > > FixBundle.cmake.in > >> 1 include(BundleUtilities) >> 2 >> 3 set(bundle "${CMAKE_INSTALL_PREFIX}/main at CMAKE_EXECUTABLE_SUFFIX@") >> 4 >> 5 set(other_libs "") >> 6 set(dirs >> 7 "@CMAKE_RUNTIME_OUTPUT_DIRECTORY@" >> 8 "@CMAKE_LIBRARY_OUTPUT_DIRECTORY@" >> 9 ) >> 10 >> 11 fixup_bundle("${bundle}" "${other_libs}" "${dirs}") >> 12 > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 seth.cantrell at gmail.com Sat Sep 12 23:07:09 2015 From: seth.cantrell at gmail.com (Seth Cantrell) Date: Sat, 12 Sep 2015 23:07:09 -0400 Subject: [CMake] fixup_bundles on macosx for non-.app target In-Reply-To: <47FE5E52-9F6B-4648-9726-D7AFBC68152E@bluequartz.net> References: <1038F7E4-9919-4287-A331-7E44AAD7A619@gmail.com> <43A20A83-1405-44A5-9ABF-7160BAC2AE2D@gmail.com> <47FE5E52-9F6B-4648-9726-D7AFBC68152E@bluequartz.net> Message-ID: Please, I would like to see that script template. I'm also looking at the source for BundleUtilities. It seems like it shouldn't be difficult to make a module that provides the generic functionality across platforms. > On Sep 12, 2015, at 9:09 PM, Michael Jackson wrote: > > I have a mix of .app and command line executables for our project on OS X. I wrote a templated .sh file that cmake uses to ?configure_file()? by filling in details needed. The Script itself does the ?fix up? stuff by running otool, parsing the output, looking for the libraries and then updating everything. You are welcome to the script if you find it useful. > > Mike Jackson > >> On Sep 12, 2015, at 7:54 PM, Seth Cantrell wrote: >> >>> >>> On Sep 12, 2015, at 5:28 PM, Dan Kegel wrote: >>> >>> On Sat, Sep 12, 2015 at 1:52 PM, Seth Cantrell wrote: >>>> I have a project which uses fixup_bundle on Windows to package up the exe with the third-party dlls it requires. On Mac OS X this same packaging process fails. It looks like on Mac OS X this utility is assuming I want to producing a .app bundle. >>> >>> Given that a .app bundle is just a directory containing the executable and >>> the things it depends on, what's wrong with what fixup_bundle does? >>> Do you have a special reason to not want to follow the .app convention? >>> - Dan >> >> The primary problem is simply that install and CPack processes fail on Mac OS X. If I can get the process to succeed, even if that means producing a .app directory structure for this non-.app, command line executable that would be a fine first step. But ultimately I'd rather not have to fake the .app structure either. >> >> On Windows installing and packaging succeed. For example on windows I get a .zip file named myproj-0.1.1-win64.zip that contains: >> >> myproj-0.1.1-win64.zip\ >> myproj-0.1.1-win64\ >> main.exe >> somelib.dll >> someotherlib.dll >> >> And of course the _CPack_Packages structure used to generate this is >> >> _CPack_Packages\ >> win64\ >> ZIP\ >> myproj-0.1.1-win64\ >> main.exe >> somelib.dll >> someotherlib.dll >> >> This is the same structure I'd like to produce on OS X. >> >> On Mac OS X the packaging process fails: >> >>> [1/1] Run CPack packaging tool... >>> CPack: Create package using ZIP >>> CPack: Install projects >>> CPack: - Install project: scratch >>> exe_dotapp_dir/='/Volumes/D/Builds/scratch/_CPack_Packages/Darwin/ZIP/scratch-0.1.1-Darwin/' >>> item_substring='/Volumes/D/Builds/scratch/_CPack_Packages/Darwin/ZIP/MacOS/somelib' >>> resolved_embedded_item='/Volumes/D/Builds/scratch/_CPack_Packages/Darwin/ZIP/MacOS/somelib.dylib' >>> >>> Install or copy the item into the bundle before calling fixup_bundle. >>> Or maybe there's a typo or incorrect path in one of the args to fixup_bundle? >>> >>> CMake Error at /Applications/CMake.app/Contents/share/cmake-3.3/Modules/BundleUtilities.cmake:737 (message): >>> cannot fixup an item that is not in the bundle... >>> Call Stack (most recent call first): >>> /Applications/CMake.app/Contents/share/cmake-3.3/Modules/BundleUtilities.cmake:848 (fixup_bundle_item) >>> /Volumes/D/Builds/scratch/FixBundle.cmake:11 (fixup_bundle) >>> /Volumes/D/Builds/scratch/cmake_install.cmake:41 (include) >>> >>> >>> CPack Error: Error when generating package: scratch >>> FAILED: cd /Volumes/D/Builds/scratch && /Applications/CMake.app/Contents/bin/cpack --config ./CPackConfig.cmake >>> ninja: build stopped: subcommand failed. >> >> On Mac OS X after the packaging failure I can see that _CPack_Packages contains a directory structure >> >> _CPack_Packages\ >> Darwin\ >> ZIP\ >> MacOS\ >> somelib.dylib >> someotherlib.dylib >> myproj-0.1.1-Darwin\ >> main >> >> and the process has stopped before generating the zip file. >> >> The initial error is due to the fact that I'm putting the executable in the root of the install tree: install(TARGETS main DESTINATION "."). This causes fixup_bundle's behavior on Mac OS to put the libraries outside the directory that CPack is preparing to zip, causing an error where fixup (quite correctly) refuses to work when the dylibs aren't in the directory that's going to be zipped up >> >> Even so, the packaging process has clearly gone as far as correctly identifying the dylibs and copying them into the _CPack_Packages directory. Using otool I can see that the executable's rpath's for finding the dylibs have been updated: @executable_path/../MacOS/somelib.dylib. Using DYLD_PRINT_LIBRARIES I can see that running the executable does indeed load the intended .dylibs the the program runs correctly. >> >> Trying to fix the issue of the dylibs being put outside the zip directory, I changed the install command to not put the executable at the root of the install location: install(TARGET main DESTINATION "bin"). This still does not succeed because fixup_bundle is explicitly verifying whether the directory structure is a valid bundle, which this is not. >> >>> CMake Error at /Applications/CMake.app/Contents/share/cmake-3.3/Modules/BundleUtilities.cmake:860 (message): >>> error: fixup_bundle: not a valid bundle >> >> And of course just trying to ape the .app directory structure still does not produce a valid .app bundle: install(TARGETS main DESTINATION "foo.app/Contents/MacOS") >> >> >> I would prefer to not be required to use the .app bundle directory structure at all. I'm not producing a .app. The program is a command line program intended to be run directly from Terminal.app, not a GUI program intended to be launched from Mac OS's Finder. I just want to automatically detect the necessary .dylibs, copy them into the folder that gets zipped up, fix up the dyld paths to make the executable relocatable, and zip up the whole thing. >> >> --- >> >> Here's the scripts I've got on Windows and which produce the desired products, but which fail on Mac OS. >> >> CMakeLists.txt: >> >> ... >>> 7 add_executable(main main.cpp) >> ... >>> 10 target_include_directories(main PRIVATE ${somelib_INCLUDE_DIRS}) >>> 11 target_link_libraries(main PRIVATE ${somelib_LIBRARIES}) >> ... >>> 14 install(TARGETS main DESTINATION ".") >>> 15 >>> 16 configure_file( >>> 17 ${CMAKE_CURRENT_SOURCE_DIR}/FixBundle.cmake.in >>> 18 ${CMAKE_CURRENT_BINARY_DIR}/FixBundle.cmake >>> 19 @ONLY) >>> 20 >>> 21 install(SCRIPT ${CMAKE_CURRENT_BINARY_DIR}/FixBundle.cmake) >>> 22 >>> 23 set(CPACK_GENERATOR ZIP 7Z TBZ2) >>> 24 include(CPack) >> >> FixBundle.cmake.in >> >>> 1 include(BundleUtilities) >>> 2 >>> 3 set(bundle "${CMAKE_INSTALL_PREFIX}/main at CMAKE_EXECUTABLE_SUFFIX@") >>> 4 >>> 5 set(other_libs "") >>> 6 set(dirs >>> 7 "@CMAKE_RUNTIME_OUTPUT_DIRECTORY@" >>> 8 "@CMAKE_LIBRARY_OUTPUT_DIRECTORY@" >>> 9 ) >>> 10 >>> 11 fixup_bundle("${bundle}" "${other_libs}" "${dirs}") >>> 12 >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > From jsvanbethlehem at gmail.com Sun Sep 13 06:13:50 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Sun, 13 Sep 2015 12:13:50 +0200 Subject: [CMake] Generated .rc files silently ignored In-Reply-To: <8D981219EEA621479C112DA9BDC39A8E348BAE05@EXMBS1.ad.igd.fraunhofer.de> References: <8D981219EEA621479C112DA9BDC39A8E348BAE05@EXMBS1.ad.igd.fraunhofer.de> Message-ID: Hej, Some more information about how you setup things would be useful. For instance: you would need to add the filename of the generated .rc file to the executable/library for which it is generated: are you doing that? In the application I currently work on, we have created a small function to wrap the generation of the .rc file. I just checked that we actually also build a full path. That actually makes sense, because the generated file is put in the ${CMAKE_CURRENT_BINARY_DIR} and *not* in the current source dir. In other words: we could never accomplish this with any type of ?relative? path anyway. Are you maybe also mixing up the *SOURCE_DIR and *BINARY_DIR? Sincerely, Jakob > On 07 Sep 2015, at 13:08, Mueller-Roemer, Johannes Sebastian wrote: > > While adding versioning info to a .dll I noticed that .rc files that are generated (via configure_file) are silently being ignored. Adding them via an absolute path works, but using a relative leads to it being ignored. > > Is this a bug or is this by design? At the very least just silently ignoring it seems wrong. > > -- > Johannes S. Mueller-Roemer, MSc > Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) > > Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD > Fraunhoferstr. 5 | 64283 Darmstadt | Germany > Tel +49 6151 155-606 | Fax +49 6151 155-139 > johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsvanbethlehem at gmail.com Sun Sep 13 06:30:33 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Sun, 13 Sep 2015 12:30:33 +0200 Subject: [CMake] Object targets and link libraries In-Reply-To: <55F02DD3.9050104@simtech.uni-stuttgart.de> References: <55F02DD3.9050104@simtech.uni-stuttgart.de> Message-ID: <5425AA76-8095-4F5B-9C8C-D7FD77D47A1D@gmail.com> Hej, Did you notice this one? https://public.kitware.com/Bug/bug_relationship_graph.php?bug_id=14778&graph=relation Also, since you?re asking about a ?why?, you could check out this thread: http://public.kitware.com/pipermail/cmake-developers/2015-February/024518.html The less involved option would be to do exactly what you mention you don?t want. You don?t mention why you don?t want to create a separate library though, which may be of importance to guess a different solution. Sincerely, Jakob > On 09 Sep 2015, at 15:02, Daniel Wirtz wrote: > > Hey all, > > i've been wondering why CMake (3.3.+) yells at me if i want to add link libraries to an OBJECT target. > Consider the scenario > > find_package(package_with_bar_target) > > add_library(foo OBJECT ${foo_src}) > > # Would like to write > > # target_link_libraries(foo bar) > > # But have to use > > target_include_directories(foo PRIVATE $) > > > I know that intuitively "link library" is something different than "include directory". but one of the nice things > of cmake is that it automatically sorts out everything for you when you specify link libraries. > if there are more bar-dependent properties that need to be set in order to successfully compile foo (e.g. compile flags), > i have to literally re-write all the nice internal cmake logic to establish the compile environment of bar for foo. > > what's the plan with that? or are there any other (less involved) solutions? i need the objects of foo inside a larger > target and want to avoid having a separate library being build that needs extra linking. > > cheers! > > -- > Dr. Daniel Wirtz > Dipl. Math. Dipl. Inf. > SRC SimTech > Pfaffenwaldring 5a > +49 711 685 60044 > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsvanbethlehem at gmail.com Sun Sep 13 06:34:18 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Sun, 13 Sep 2015 12:34:18 +0200 Subject: [CMake] FindGit.cmake proposal In-Reply-To: <55F194E5.4030300@simtech.uni-stuttgart.de> References: <55F194E5.4030300@simtech.uni-stuttgart.de> Message-ID: <6D1EA086-A86D-4E67-BFE3-CB9CBD1B0ECC@gmail.com> Hej, > > if this is not the "right way" of proposing such things, where to go to? > Pretty simple if you have a look at the website http://www.cmake.org/get-involved/ - you?ll need to send patches to the dev-list Sincerely, Jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: From netbandit at gmx.de Sun Sep 13 09:07:45 2015 From: netbandit at gmx.de (=?UTF-8?Q?Andr=c3=a9_Netzeband?=) Date: Sun, 13 Sep 2015 15:07:45 +0200 Subject: [CMake] CMake [nmake target] is adding backslash at end of cd command In-Reply-To: <55EEFF46.8080000@kitware.com> References: <55E9A578.9010609@netzeband.eu> <55E9A7ED.1010101@gmx.de> <55EEFF46.8080000@kitware.com> Message-ID: <55F57521.5040100@gmx.de> Hi Sorry for the late answer, I was some days offline. Am 08.09.2015 um 17:31 schrieb Brad King: > On 9/4/2015 10:17 AM, Andr? Netzeband wrote: >> I have a very strange issue with generated nmake makefiles from cmake 3.3.1 > Is this problem new in 3.3 or are you just reporting this as the version > you are using? I just tried 3.3.1, so the issue could also be there with older versions. > >> In a very complex project with many sub-cmake files (Ogre3D) the >> generated nmake makefiles (build.make) contain backslashes at the end of >> some cd commands. > That project turns on the CMAKE_USE_RELATIVE_PATHS option > which is documented as not fully implemented and unsupported: > http://www.cmake.org/cmake/help/v3.3/variable/CMAKE_USE_RELATIVE_PATHS.html > > That option should not be used. > > -Brad > Where do you see this? When I look with cmake-gui at the variables of Ogre3D CMake-system, it is disabled. Best regards, Andr? From wmamrak at gmail.com Mon Sep 14 06:10:50 2015 From: wmamrak at gmail.com (Wojciech Mamrak) Date: Mon, 14 Sep 2015 12:10:50 +0200 Subject: [CMake] Libraries for a Target and/or its Dependents Message-ID: Hello, The docs say [1]: "Libraries and targets following PRIVATE are linked to, but are not made part of the link interface." If so, why does this snippet: add_library(private_lib STATIC ...) add_library(public_lib STATIC ...) target_link_libraries(Test PRIVATE private_lib PUBLIC public_lib) install(EXPORT ...) sets Test's imported target's properties with: IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "private_lib;public_lib" I thought BUILD_INTERFACE and INSTALL_INTERFACE generator expressions can solve this, but it turns out BUILD_INTERFACE is propagated, and INSTALL_INTERFACE is not, i.e. IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "private_lib;public_lib;build_interface_lib" regards [1] http://www.cmake.org/cmake/help/v3.3/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents From gjasny at googlemail.com Mon Sep 14 11:45:17 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Mon, 14 Sep 2015 17:45:17 +0200 Subject: [CMake] FindGit.cmake proposal In-Reply-To: <55F194E5.4030300@simtech.uni-stuttgart.de> References: <55F194E5.4030300@simtech.uni-stuttgart.de> Message-ID: <55F6EB8D.6000204@googlemail.com> Hello, On 10/09/15 16:34, Daniel Wirtz wrote: > i've now quite often encountered the need to access basic git > information about the source tree from within cmake. > i've attached the current FindGit.cmake module shipped with CMake > enhanced by two functions: getGitRevision and getGitBranch. > if you fancy the idea of having this included, feel free to include any > part of it in future releases. Very helpful. ARAIR functions declared inside modules should be prefixed by the module name. So your functions should become git_get_xyz() Please also properly document your function (add a .. command:: ): http://www.cmake.org/cmake/help/v3.3/manual/cmake-developer.7.html#help If you need assistance, I'm glad to help. Thanks, Gregor From carl.poirier.2 at gmail.com Mon Sep 14 15:35:33 2015 From: carl.poirier.2 at gmail.com (Carl Poirier) Date: Mon, 14 Sep 2015 15:35:33 -0400 Subject: [CMake] Need help with COMPILE_DEFINITIONS_ Message-ID: Hi folks, I need some help setting the COMPILE_DEFINITIONS_. I'm using the Visual Studio 2008 generator. I use this command to do so which I took in the notes when the feature was added: set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG ATEST) Then, once the solution and project is generated, I go into the project properties under the C++ preprocessor and I can't see the define. Removing the configuration name does set it correctly for all of them, so it leads me to believe the rest of my CMakeLists.txt is fine: set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS ATEST) So is this supposed to work? Thank you, Carl -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgquiles at elpauer.org Mon Sep 14 16:25:00 2015 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Mon, 14 Sep 2015 22:25:00 +0200 Subject: [CMake] Need help with COMPILE_DEFINITIONS_ In-Reply-To: References: Message-ID: Hello, Have you tried set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG -DATEST) ? On Mon, Sep 14, 2015 at 9:35 PM, Carl Poirier wrote: > Hi folks, > > I need some help setting the COMPILE_DEFINITIONS_. I'm using the > Visual Studio 2008 generator. I use this command to do so which I took in > the notes when the feature > was added: > > set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG ATEST) > > Then, once the solution and project is generated, I go into the project > properties under the C++ preprocessor and I can't see the define. Removing > the configuration name does set it correctly for all of them, so it leads > me to believe the rest of my CMakeLists.txt is fine: > > set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS ATEST) > > So is this supposed to work? > > Thank you, > > Carl > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Mon Sep 14 16:33:10 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Mon, 14 Sep 2015 22:33:10 +0200 Subject: [CMake] Need help with COMPILE_DEFINITIONS_ In-Reply-To: References: Message-ID: <4430A696-C804-4265-B192-3A5B91C43C4C@hendrik-sattler.de> Am 14. September 2015 22:25:00 MESZ, schrieb Pau Garcia i Quiles : >Hello, > >Have you tried > >set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG >-DATEST) That would be the right thing for add_definitions() but not here. He could try with generator expressions though. > >On Mon, Sep 14, 2015 at 9:35 PM, Carl Poirier > >wrote: > >> Hi folks, >> >> I need some help setting the COMPILE_DEFINITIONS_. I'm using >the >> Visual Studio 2008 generator. I use this command to do so which I >took in >> the notes when the >feature >> was added: >> >> set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG >ATEST) >> >> Then, once the solution and project is generated, I go into the >project >> properties under the C++ preprocessor and I can't see the define. >Removing >> the configuration name does set it correctly for all of them, so it >leads >> me to believe the rest of my CMakeLists.txt is fine: >> >> set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS ATEST) >> >> So is this supposed to work? >> >> Thank you, >> >> Carl >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For >more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 Sep 14 23:19:08 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Mon, 14 Sep 2015 23:19:08 -0400 Subject: [CMake] fixup_bundles on macosx for non-.app target In-Reply-To: References: <1038F7E4-9919-4287-A331-7E44AAD7A619@gmail.com> <43A20A83-1405-44A5-9ABF-7160BAC2AE2D@gmail.com> <47FE5E52-9F6B-4648-9726-D7AFBC68152E@bluequartz.net> Message-ID: <84C33DE7-9C68-454E-A2BF-969235773252@bluequartz.net> Sorry for the delay. https://github.com/dream3d/DREAM3D/tree/develop/Support/cmp/OSX_Tools the CompleteTool.cmake.in calls the CompleteTool.sh.in files through a custom cmake command after they are "Configured" through "configure_file". I think you can figure out what is going on. There may be some issues with the shell script regarding temp file cleanup but it generally works. We build and package every night on our build systems. Mike Jackson On Sep 12, 2015, at 11:07 PM, Seth Cantrell wrote: > Please, I would like to see that script template. I'm also looking at the source for BundleUtilities. It seems like it shouldn't be difficult to make a module that provides the generic functionality across platforms. > >> On Sep 12, 2015, at 9:09 PM, Michael Jackson wrote: >> >> I have a mix of .app and command line executables for our project on OS X. I wrote a templated .sh file that cmake uses to ?configure_file()? by filling in details needed. The Script itself does the ?fix up? stuff by running otool, parsing the output, looking for the libraries and then updating everything. You are welcome to the script if you find it useful. >> >> Mike Jackson >> >>> On Sep 12, 2015, at 7:54 PM, Seth Cantrell wrote: >>> >>>> >>>> On Sep 12, 2015, at 5:28 PM, Dan Kegel wrote: >>>> >>>> On Sat, Sep 12, 2015 at 1:52 PM, Seth Cantrell wrote: >>>>> I have a project which uses fixup_bundle on Windows to package up the exe with the third-party dlls it requires. On Mac OS X this same packaging process fails. It looks like on Mac OS X this utility is assuming I want to producing a .app bundle. >>>> >>>> Given that a .app bundle is just a directory containing the executable and >>>> the things it depends on, what's wrong with what fixup_bundle does? >>>> Do you have a special reason to not want to follow the .app convention? >>>> - Dan >>> >>> The primary problem is simply that install and CPack processes fail on Mac OS X. If I can get the process to succeed, even if that means producing a .app directory structure for this non-.app, command line executable that would be a fine first step. But ultimately I'd rather not have to fake the .app structure either. >>> >>> On Windows installing and packaging succeed. For example on windows I get a .zip file named myproj-0.1.1-win64.zip that contains: >>> >>> myproj-0.1.1-win64.zip\ >>> myproj-0.1.1-win64\ >>> main.exe >>> somelib.dll >>> someotherlib.dll >>> >>> And of course the _CPack_Packages structure used to generate this is >>> >>> _CPack_Packages\ >>> win64\ >>> ZIP\ >>> myproj-0.1.1-win64\ >>> main.exe >>> somelib.dll >>> someotherlib.dll >>> >>> This is the same structure I'd like to produce on OS X. >>> >>> On Mac OS X the packaging process fails: >>> >>>> [1/1] Run CPack packaging tool... >>>> CPack: Create package using ZIP >>>> CPack: Install projects >>>> CPack: - Install project: scratch >>>> exe_dotapp_dir/='/Volumes/D/Builds/scratch/_CPack_Packages/Darwin/ZIP/scratch-0.1.1-Darwin/' >>>> item_substring='/Volumes/D/Builds/scratch/_CPack_Packages/Darwin/ZIP/MacOS/somelib' >>>> resolved_embedded_item='/Volumes/D/Builds/scratch/_CPack_Packages/Darwin/ZIP/MacOS/somelib.dylib' >>>> >>>> Install or copy the item into the bundle before calling fixup_bundle. >>>> Or maybe there's a typo or incorrect path in one of the args to fixup_bundle? >>>> >>>> CMake Error at /Applications/CMake.app/Contents/share/cmake-3.3/Modules/BundleUtilities.cmake:737 (message): >>>> cannot fixup an item that is not in the bundle... >>>> Call Stack (most recent call first): >>>> /Applications/CMake.app/Contents/share/cmake-3.3/Modules/BundleUtilities.cmake:848 (fixup_bundle_item) >>>> /Volumes/D/Builds/scratch/FixBundle.cmake:11 (fixup_bundle) >>>> /Volumes/D/Builds/scratch/cmake_install.cmake:41 (include) >>>> >>>> >>>> CPack Error: Error when generating package: scratch >>>> FAILED: cd /Volumes/D/Builds/scratch && /Applications/CMake.app/Contents/bin/cpack --config ./CPackConfig.cmake >>>> ninja: build stopped: subcommand failed. >>> >>> On Mac OS X after the packaging failure I can see that _CPack_Packages contains a directory structure >>> >>> _CPack_Packages\ >>> Darwin\ >>> ZIP\ >>> MacOS\ >>> somelib.dylib >>> someotherlib.dylib >>> myproj-0.1.1-Darwin\ >>> main >>> >>> and the process has stopped before generating the zip file. >>> >>> The initial error is due to the fact that I'm putting the executable in the root of the install tree: install(TARGETS main DESTINATION "."). This causes fixup_bundle's behavior on Mac OS to put the libraries outside the directory that CPack is preparing to zip, causing an error where fixup (quite correctly) refuses to work when the dylibs aren't in the directory that's going to be zipped up >>> >>> Even so, the packaging process has clearly gone as far as correctly identifying the dylibs and copying them into the _CPack_Packages directory. Using otool I can see that the executable's rpath's for finding the dylibs have been updated: @executable_path/../MacOS/somelib.dylib. Using DYLD_PRINT_LIBRARIES I can see that running the executable does indeed load the intended .dylibs the the program runs correctly. >>> >>> Trying to fix the issue of the dylibs being put outside the zip directory, I changed the install command to not put the executable at the root of the install location: install(TARGET main DESTINATION "bin"). This still does not succeed because fixup_bundle is explicitly verifying whether the directory structure is a valid bundle, which this is not. >>> >>>> CMake Error at /Applications/CMake.app/Contents/share/cmake-3.3/Modules/BundleUtilities.cmake:860 (message): >>>> error: fixup_bundle: not a valid bundle >>> >>> And of course just trying to ape the .app directory structure still does not produce a valid .app bundle: install(TARGETS main DESTINATION "foo.app/Contents/MacOS") >>> >>> >>> I would prefer to not be required to use the .app bundle directory structure at all. I'm not producing a .app. The program is a command line program intended to be run directly from Terminal.app, not a GUI program intended to be launched from Mac OS's Finder. I just want to automatically detect the necessary .dylibs, copy them into the folder that gets zipped up, fix up the dyld paths to make the executable relocatable, and zip up the whole thing. >>> >>> --- >>> >>> Here's the scripts I've got on Windows and which produce the desired products, but which fail on Mac OS. >>> >>> CMakeLists.txt: >>> >>> ... >>>> 7 add_executable(main main.cpp) >>> ... >>>> 10 target_include_directories(main PRIVATE ${somelib_INCLUDE_DIRS}) >>>> 11 target_link_libraries(main PRIVATE ${somelib_LIBRARIES}) >>> ... >>>> 14 install(TARGETS main DESTINATION ".") >>>> 15 >>>> 16 configure_file( >>>> 17 ${CMAKE_CURRENT_SOURCE_DIR}/FixBundle.cmake.in >>>> 18 ${CMAKE_CURRENT_BINARY_DIR}/FixBundle.cmake >>>> 19 @ONLY) >>>> 20 >>>> 21 install(SCRIPT ${CMAKE_CURRENT_BINARY_DIR}/FixBundle.cmake) >>>> 22 >>>> 23 set(CPACK_GENERATOR ZIP 7Z TBZ2) >>>> 24 include(CPack) >>> >>> FixBundle.cmake.in >>> >>>> 1 include(BundleUtilities) >>>> 2 >>>> 3 set(bundle "${CMAKE_INSTALL_PREFIX}/main at CMAKE_EXECUTABLE_SUFFIX@") >>>> 4 >>>> 5 set(other_libs "") >>>> 6 set(dirs >>>> 7 "@CMAKE_RUNTIME_OUTPUT_DIRECTORY@" >>>> 8 "@CMAKE_LIBRARY_OUTPUT_DIRECTORY@" >>>> 9 ) >>>> 10 >>>> 11 fixup_bundle("${bundle}" "${other_libs}" "${dirs}") >>>> 12 >>> >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware 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 david.gobbi at gmail.com Tue Sep 15 01:33:41 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 14 Sep 2015 23:33:41 -0600 Subject: [CMake] FindPythonLibs patches for version searching and frameworks Message-ID: Hi All, I've attached three suggested patches for cmake. The first is trivial, it simply adds Python 3.5 and 3.6 to the search list. The second removes the long-deprecated PYTHON_INCLUDE_PATH as a suggestion for PYTHON_INCLUDE_DIR. The third does two important things: 1) it fixes bugs for searching for specific versions of the libs and headers for framework installs of Python on OS X, and 2) it doesn't search for the include directory until after library has been found, so that it can use the library version to direct the search for the include directory. Any comments on these patches would be appreciated. Cheers, - David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-Python-3.6-3.5-to-the-versions-searched-for.patch Type: application/octet-stream Size: 1361 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Remove-PYTHON_INCLUDE_PATH-as-input-to-FindPythonLib.patch Type: application/octet-stream Size: 1270 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Match-python-include-dir-to-library-version.patch Type: application/octet-stream Size: 4328 bytes Desc: not available URL: From daniel.wirtz at simtech.uni-stuttgart.de Tue Sep 15 05:53:06 2015 From: daniel.wirtz at simtech.uni-stuttgart.de (Daniel Wirtz) Date: Tue, 15 Sep 2015 11:53:06 +0200 Subject: [CMake] Intel C99 standard Message-ID: <55F7EA82.2050500@simtech.uni-stuttgart.de> Folks, so CMake introduced those nice features "[CMAKE_]C_STANDARD[_REQUIRED]" etc to automatically add appropriate flags to compilers. so, while i can see there's settings for clang and gnu in Modules/Compiler/.. the Intel-* script do not define any (current cmake 3.3.1). but the intel devzone says there are flags you can use: https://software.intel.com/en-us/articles/c99-support-in-intel-c-compiler i ran into that problem as the "SUPERLU_DIST" package requires C99 standard, which failed to compile using intel compilers because cmake did not add the "-std=c99" c flags. so has that simply not come up yet or is there a reason cmake does not add those flags for intel? thanks! -- Dr. Daniel Wirtz Dipl. Math. Dipl. Inf. SRC SimTech Pfaffenwaldring 5a +49 711 685 60044 From tamas.kenez at gmail.com Tue Sep 15 06:07:47 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Tue, 15 Sep 2015 12:07:47 +0200 Subject: [CMake] Libraries for a Target and/or its Dependents In-Reply-To: References: Message-ID: I guess `Test` is also a static library. In that case this is the intended behaviour. Since `private_lib` is not compiled into `Test`'s object files, when you link the consumer of `Test` you still need to pull in `private_lib`. If `Test` were a shared lib then `private_lib` would not be listed. Tamas On Mon, Sep 14, 2015 at 12:10 PM, Wojciech Mamrak wrote: > Hello, > > The docs say [1]: > "Libraries and targets following PRIVATE are linked to, but are not > made part of the link interface." > > If so, why does this snippet: > > add_library(private_lib STATIC ...) > add_library(public_lib STATIC ...) > > target_link_libraries(Test PRIVATE private_lib > PUBLIC public_lib) > install(EXPORT ...) > > sets Test's imported target's properties with: > > IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "private_lib;public_lib" > > I thought BUILD_INTERFACE and INSTALL_INTERFACE generator expressions > can solve this, but it turns out BUILD_INTERFACE is propagated, and > INSTALL_INTERFACE is not, i.e. > > IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE > "private_lib;public_lib;build_interface_lib" > > regards > > [1] > http://www.cmake.org/cmake/help/v3.3/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 tino.mettler at alcnetworx.de Tue Sep 15 08:07:42 2015 From: tino.mettler at alcnetworx.de (Tino Mettler) Date: Tue, 15 Sep 2015 14:07:42 +0200 Subject: [CMake] Shared library from ExternalProject In-Reply-To: <1441803501.13183.17.camel@alcnetworx.de> References: <1441803501.13183.17.camel@alcnetworx.de> Message-ID: <1442318862.17596.15.camel@alcnetworx.de> Hi, it would be nice to know if the usage of add_library(foo SHARED IMPORTED) is the way to go in this case. find_package() seems to be useless, as it requires that the external library is already present when cmake is invoked, which is not the case with an external project. So it seems like I have to define everything via set_target_properies(). What I see is that cmake uses rpath for linking using gcc/binutils. Is there a way to just use -L here? In the final installation (an embedded device), the libraries will be placed in the standard search path of the dynamic linker, so the rpath is just build system specific and not needed for the resulting binary. I also discovered that the build of the external project is not updated when the filesystem timestamp as well as the contents of external.tar.gz were changed. How can I achieve this? Here is my minimized example: cmake_minimum_required(VERSION 3.0.0) project (hello) add_executable(hello helloworld.cpp) include(ExternalProject) ExternalProject_Add(externalproject URL ../../../external.tar.gz) ExternalProject_Get_Property(externalproject binary_dir) add_library(externallib SHARED IMPORTED) set_target_properties(externallib PROPERTIES IMPORTED_LOCATION ${binary_dir}/install/lib/${CMAKE_SHARED_LIBRARY_PREFIX}mylib${CMAKE_SHARED_LIBRARY_SUFFIX} ) include_directories(${binary_dir}/install/include/) target_link_libraries(hello externallib) add_dependencies(hello externalproject) Regards, Tino From tamas.kenez at gmail.com Tue Sep 15 10:32:08 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Tue, 15 Sep 2015 16:32:08 +0200 Subject: [CMake] Shared library from ExternalProject In-Reply-To: <1442318862.17596.15.camel@alcnetworx.de> References: <1441803501.13183.17.camel@alcnetworx.de> <1442318862.17596.15.camel@alcnetworx.de> Message-ID: > it would be nice to know if the usage of add_library(foo SHARED > IMPORTED) is the way to go in this case. I wouldn't think this is the way to go. One thing we love CMake for is that it separates the concerns of the library and the consumer target so it's best to stick to find_package. This is the usage pattern of ExternalProject with find_package: Create a super project which contains the library and the consumer target in 2 separate ExternalProjects so the library can be installed before the main target's CMakeLists is configured. In certain cases you can also clone, build and install the library in an init shell script of your project, outside of the main CMakeLists.txt. This can be achieved either in a separate CMakeLists.txt (e.g. ./dependencies/CMakeLists.txt) or by raw shell commands (calling curl, git, cmake, cmake --build directly) Tamas On Tue, Sep 15, 2015 at 2:07 PM, Tino Mettler wrote: > Hi, > > it would be nice to know if the usage of add_library(foo SHARED > IMPORTED) is the way to go in this case. > > find_package() seems to be useless, as it requires that the external > library is already present when cmake is invoked, which is not the case > with an external project. > > So it seems like I have to define everything via set_target_properies(). > > What I see is that cmake uses rpath for linking using gcc/binutils. Is > there a way to just use -L here? In the final installation (an embedded > device), the libraries will be placed in the standard search path of the > dynamic linker, so the rpath is just build system specific and not > needed for the resulting binary. > > I also discovered that the build of the external project is not updated > when the filesystem timestamp as well as the contents of external.tar.gz > were changed. How can I achieve this? > > Here is my minimized example: > > cmake_minimum_required(VERSION 3.0.0) > project (hello) > add_executable(hello helloworld.cpp) > include(ExternalProject) > ExternalProject_Add(externalproject URL ../../../external.tar.gz) > ExternalProject_Get_Property(externalproject binary_dir) > add_library(externallib SHARED IMPORTED) > set_target_properties(externallib PROPERTIES IMPORTED_LOCATION > ${binary_dir}/install/lib/${CMAKE_SHARED_LIBRARY_PREFIX}mylib${CMAKE_SHARED_LIBRARY_SUFFIX} > ) > include_directories(${binary_dir}/install/include/) > target_link_libraries(hello externallib) > add_dependencies(hello externalproject) > > Regards, > Tino > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Sep 15 10:49:39 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 15 Sep 2015 10:49:39 -0400 Subject: [CMake] Intel C99 standard In-Reply-To: <55F7EA82.2050500@simtech.uni-stuttgart.de> References: <55F7EA82.2050500@simtech.uni-stuttgart.de> Message-ID: <55F83003.1000603@kitware.com> On 09/15/2015 05:53 AM, Daniel Wirtz wrote: > because cmake did not add the "-std=c99" c flags. > so has that simply not come up yet or is there a reason cmake does not > add those flags for intel? The necessary tables of information have simply not been filled out for the Intel compiler. No one has stepped forward to do it so far, and it requires non-trivial research and testing. One must construct a table of what versions of Intel support what standards, and what the corresponding -std= flags are. There also need to be tables of which features: http://www.cmake.org/cmake/help/v3.3/prop_gbl/CMAKE_C_KNOWN_FEATURES.html http://www.cmake.org/cmake/help/v3.3/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html are supported by each version of the compiler. These are encoded as preprocessor conditional test fragments. See Modules/Compiler/GNU-CXX-FeatureTests.cmake for an example. -Brad From Nicholas.Crast at saabsensis.com Tue Sep 15 13:05:20 2015 From: Nicholas.Crast at saabsensis.com (Crast, Nicholas) Date: Tue, 15 Sep 2015 17:05:20 +0000 Subject: [CMake] Generating Eclipse Project Files - No Source Message-ID: <36A43B0E1E88D84791516F9D44BC4833281C5FF3@corpmail01.corp.sensis.com> Hi all, I am attempting to use CMake to generate eclipse project files. Although I am able to build successfully, I am unable to browse or edit the source in eclipse. This is an out of tree build, where my build directory is at the same level as my source directory. I am using the following command to generate the eclipse files: cmake -G"Eclipse CDT4 - Unix Makefiles" -DBoost_NO_BOOST_CMAKE=ON -DBOOST_ROOT=/usr/local/lib -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE ../proc The source directory has many different modules, but the top level CMakeLists file is essentially a bunch of add_subdirectory commands adding each module. Is this incorrect? Thanks, Nick ---------------------------------------- Nick Crast Software Engineer Saab Sensis Corporation Phone: 315-445-5703 Email: Nicholas.Crast at saabsensis.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Tue Sep 15 16:15:12 2015 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 15 Sep 2015 22:15:12 +0200 Subject: [CMake] Generating Eclipse Project Files - No Source In-Reply-To: <36A43B0E1E88D84791516F9D44BC4833281C5FF3@corpmail01.corp.sensis.com> References: <36A43B0E1E88D84791516F9D44BC4833281C5FF3@corpmail01.corp.sensis.com> Message-ID: 2015-09-15 19:05 GMT+02:00 Crast, Nicholas : > Hi all, > > > > I am attempting to use CMake to generate eclipse project files. Although I > am able to build successfully, I am unable to browse or edit the source in > eclipse. > You don't see any source as link ressource or you see them but cannot browse/edit the sources? > This is an out of tree build, where my build directory is at the same > level as my source directory. I am using the following command to generate > the eclipse files: > > > > cmake -G"Eclipse CDT4 - Unix Makefiles" -DBoost_NO_BOOST_CMAKE=ON > -DBOOST_ROOT=/usr/local/lib -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE > ../proc > > > > The source directory has many different modules, but the top level > CMakeLists file is essentially a bunch of add_subdirectory commands adding > each module. Is this incorrect? > Would you be able to reproduce the issue on a stripped down project (like only two modules) ? Which version of Eclipse CDT and CMake are you using? On which system? -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From benapetr at gmail.com Wed Sep 16 07:26:28 2015 From: benapetr at gmail.com (Petr Bena) Date: Wed, 16 Sep 2015 13:26:28 +0200 Subject: [CMake] Parallel builds Message-ID: Hi, Is it possible to enable multithreaded builds by default in Visual Studio projects? It seems that cmake generates the solution files in a way that they are forbidden, so even if global preference is to use multithreaded builds, the compiler never does that for sln files create by cmake, because multithreaded builds are not allowed on project level. Is there any way to enable them so that I don't have to do that by hand all time? From benapetr at gmail.com Wed Sep 16 07:30:56 2015 From: benapetr at gmail.com (Petr Bena) Date: Wed, 16 Sep 2015 13:30:56 +0200 Subject: [CMake] Parallel builds In-Reply-To: References: Message-ID: There is /MP compiler flag that I need to enable for every single project to be precise. On Wed, Sep 16, 2015 at 1:26 PM, Petr Bena wrote: > Hi, > > Is it possible to enable multithreaded builds by default in Visual > Studio projects? It seems that cmake generates the solution files in a > way that they are forbidden, so even if global preference is to use > multithreaded builds, the compiler never does that for sln files > create by cmake, because multithreaded builds are not allowed on > project level. > > Is there any way to enable them so that I don't have to do that by > hand all time? From tino.mettler at alcnetworx.de Wed Sep 16 09:22:34 2015 From: tino.mettler at alcnetworx.de (Tino Mettler) Date: Wed, 16 Sep 2015 15:22:34 +0200 Subject: [CMake] Shared library from ExternalProject In-Reply-To: References: <1441803501.13183.17.camel@alcnetworx.de> <1442318862.17596.15.camel@alcnetworx.de> Message-ID: <1442409754.17596.19.camel@alcnetworx.de> On Tue, 2015-09-15 at 16:32 +0200, Tam?s Ken?z wrote: > > it would be nice to know if the usage of add_library(foo SHARED > > IMPORTED) is the way to go in this case. > > I wouldn't think this is the way to go. One thing we love CMake for is that > it separates the concerns of the library and the consumer target so it's > best to stick to find_package. > > This is the usage pattern of ExternalProject with find_package: > Create a super project which contains the library and the consumer target > in 2 separate ExternalProjects so the library can be installed before the > main target's CMakeLists is configured. Hi, thanks for that hint. However, that would still not make externals from a .tar.gz being rebuilt if their archive was changed. Am I right? Regards, Tino From Nicholas.Crast at saabsensis.com Wed Sep 16 09:34:38 2015 From: Nicholas.Crast at saabsensis.com (Crast, Nicholas) Date: Wed, 16 Sep 2015 13:34:38 +0000 Subject: [CMake] Generating Eclipse Project Files - No Source In-Reply-To: References: <36A43B0E1E88D84791516F9D44BC4833281C5FF3@corpmail01.corp.sensis.com> Message-ID: <36A43B0E1E88D84791516F9D44BC4833281C6256@corpmail01.corp.sensis.com> Eric, Thanks for the reply. Turned out it was fine all along. I did not see that the eclipse project contained a folder called [Source Directory], which I can use to browse the source files. -Nick ---------------------------------------- Nick Crast Software Engineer Saab Sensis Corporation Phone: 315-445-5703 Email: Nicholas.Crast at saabsensis.com From: Eric Noulard [mailto:eric.noulard at gmail.com] Sent: Tuesday, September 15, 2015 4:16 PM To: cmake at cmake.org Cc: Crast, Nicholas Subject: Re: [CMake] Generating Eclipse Project Files - No Source 2015-09-15 19:05 GMT+02:00 Crast, Nicholas >: Hi all, I am attempting to use CMake to generate eclipse project files. Although I am able to build successfully, I am unable to browse or edit the source in eclipse. You don't see any source as link ressource or you see them but cannot browse/edit the sources? This is an out of tree build, where my build directory is at the same level as my source directory. I am using the following command to generate the eclipse files: cmake -G"Eclipse CDT4 - Unix Makefiles" -DBoost_NO_BOOST_CMAKE=ON -DBOOST_ROOT=/usr/local/lib -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE ../proc The source directory has many different modules, but the top level CMakeLists file is essentially a bunch of add_subdirectory commands adding each module. Is this incorrect? Would you be able to reproduce the issue on a stripped down project (like only two modules) ? Which version of Eclipse CDT and CMake are you using? On which system? -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Wed Sep 16 11:14:54 2015 From: d3ck0r at gmail.com (J Decker) Date: Wed, 16 Sep 2015 08:14:54 -0700 Subject: [CMake] Parallel builds In-Reply-To: References: Message-ID: Tools->Option->Projects and soltuions->Build and Run at the top is 'maximum number of parallel project builds. This is external setting to what CMake generates.... so in the IDE that's what it uses. >From the command line... C:\tools\unix\cmake\bin\cmake.exe --build . --config Debug --target INSTALL -- /m:4 /v:m the /m:4 flag is number of processes to parallel build. and that works. --- now if that's not what you mean and you mean 'Multi-threaded DLL'(/MD) vs 'multi-threaded'(/MT) which selects the runtime to use cmake by default generates /MD. This is set in CMAKE_${lang}_FLAGS_DEBUG_INIT which you can do if( ${CMAKE_BUILD_TYPE} MATCHES "[dD][eE][bB][uU][gG]" ) string( REPLACE "/MDd" "/MTd" CMAKE_C_FLAGS_INIT ${CMAKE_C_FLAGS_INIT} ) string( REPLACE "/MDd" "/MTd" CMAKE_CXX_FLAGS_INIT ${CMAKE_CXX_FLAGS_INIT} ) else() string( REPLACE "/MD" "/MT" CMAKE_C_FLAGS_INIT ${CMAKE_C_FLAGS_INIT} ) string( REPLACE "/MD" "/MT" CMAKE_CXX_FLAGS_INIT ${CMAKE_CXX_FLAGS_INIT} ) endif() something like that.... On Wed, Sep 16, 2015 at 4:30 AM, Petr Bena wrote: > There is /MP compiler flag that I need to enable for every single > project to be precise. > > On Wed, Sep 16, 2015 at 1:26 PM, Petr Bena wrote: >> Hi, >> >> Is it possible to enable multithreaded builds by default in Visual >> Studio projects? It seems that cmake generates the solution files in a >> way that they are forbidden, so even if global preference is to use >> multithreaded builds, the compiler never does that for sln files >> create by cmake, because multithreaded builds are not allowed on >> project level. >> >> Is there any way to enable them so that I don't have to do that by >> hand all time? > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From bill.hoffman at kitware.com Wed Sep 16 11:28:11 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 16 Sep 2015 11:28:11 -0400 Subject: [CMake] Parallel builds In-Reply-To: References: Message-ID: <55F98A8B.3070802@kitware.com> http://www.kitware.com/blog/home/post/434 -Bill From benapetr at gmail.com Wed Sep 16 11:44:33 2015 From: benapetr at gmail.com (Petr Bena) Date: Wed, 16 Sep 2015 17:44:33 +0200 Subject: [CMake] Parallel builds In-Reply-To: <55F98A8B.3070802@kitware.com> References: <55F98A8B.3070802@kitware.com> Message-ID: I know that I can pass -j parameter to GNU make as well as there is some sort of option to run MSVC compiler by hand and give that similar parameter, but that's not exactly what I want. I would prefer a way to get cmake to generate solution files for MSVC in a way that these options are enabled by default. Right now I need to do this by hand and when I run cmake again, it overwrites the solution files I modified and restore back the settings that disallow the multithreaded builds. Basically I would like to know if there is some option I would add to CMakeLists.txt that would make it do so. I understand that this may not possible with current version of CMake though. Thanks On Wed, Sep 16, 2015 at 5:28 PM, Bill Hoffman wrote: > http://www.kitware.com/blog/home/post/434 > > -Bill > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From cory.quammen at kitware.com Wed Sep 16 11:55:19 2015 From: cory.quammen at kitware.com (Cory Quammen) Date: Wed, 16 Sep 2015 11:55:19 -0400 Subject: [CMake] Parallel builds In-Reply-To: References: <55F98A8B.3070802@kitware.com> Message-ID: Hi Petr, VTK exposes the /MP compiler flag in its CMake configuration. Here is the relevant code from http://www.vtk.org/gitweb?p=VTK.git;a=blob;f=CMake/vtkDetermineCompilerFlags.cmake;h=1398050afb34ff8c0a74137d847c19a6f63b12e9;hb=HEAD 126 # Enable /MP flag for Visual Studio 2008 and greator 127 IF(MSVC_VERSION GREATER 1400) 128 SET(CMAKE_CXX_MP_FLAG OFF CACHE BOOL "Build with /MP flag enabled") 129 SET(PROCESSOR_COUNT "$ENV{NUMBER_OF_PROCESSORS}") 130 SET(CMAKE_CXX_MP_NUM_PROCESSORS CACHE ${PROCESSOR_COUNT} "The maximum number of processes for the /MP flag") 131 IF (CMAKE_CXX_MP_FLAG) 132 SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /MP${CMAKE_CXX_MP_NUM_PROCESSORS}") 133 SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /MP${CMAKE_CXX_MP_NUM_PROCESSORS}") 134 ENDIF () 135 ENDIF() Hope that helps, Cory On Wed, Sep 16, 2015 at 11:44 AM, Petr Bena wrote: > I know that I can pass -j parameter to GNU make as well as there is > some sort of option to run MSVC compiler by hand and give that similar > parameter, but that's not exactly what I want. > > I would prefer a way to get cmake to generate solution files for MSVC > in a way that these options are enabled by default. Right now I need > to do this by hand and when I run cmake again, it overwrites the > solution files I modified and restore back the settings that disallow > the multithreaded builds. Basically I would like to know if there is > some option I would add to CMakeLists.txt that would make it do so. I > understand that this may not possible with current version of CMake > though. > > Thanks > > On Wed, Sep 16, 2015 at 5:28 PM, Bill Hoffman > wrote: > > http://www.kitware.com/blog/home/post/434 > > > > -Bill > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Cory Quammen R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Wed Sep 16 12:00:06 2015 From: d3ck0r at gmail.com (J Decker) Date: Wed, 16 Sep 2015 09:00:06 -0700 Subject: [CMake] Parallel builds In-Reply-To: References: <55F98A8B.3070802@kitware.com> Message-ID: On Wed, Sep 16, 2015 at 8:44 AM, Petr Bena wrote: > I know that I can pass -j parameter to GNU make as well as there is > some sort of option to run MSVC compiler by hand and give that similar > parameter, but that's not exactly what I want. > > I would prefer a way to get cmake to generate solution files for MSVC > in a way that these options are enabled by default. Right now I need > to do this by hand and when I run cmake again, it overwrites the > solution files I modified and restore back the settings that disallow > the multithreaded builds. Basically I would like to know if there is > some option I would add to CMakeLists.txt that would make it do so. I > understand that this may not possible with current version of CMake > though. > What modification do you make? I have to do none myself to get it; because again that's a setting that's outside of the project/solution files. It's something the IDE has internally to pass to MSBUILD as a parameter (/m:) > Thanks > > On Wed, Sep 16, 2015 at 5:28 PM, Bill Hoffman wrote: >> http://www.kitware.com/blog/home/post/434 >> >> -Bill >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 rwan.work at gmail.com Wed Sep 16 12:03:41 2015 From: rwan.work at gmail.com (Raymond Wan) Date: Thu, 17 Sep 2015 00:03:41 +0800 Subject: [CMake] Parallel builds In-Reply-To: References: <55F98A8B.3070802@kitware.com> Message-ID: On Wed, Sep 16, 2015 at 11:44 PM, Petr Bena wrote: > I would prefer a way to get cmake to generate solution files for MSVC > in a way that these options are enabled by default. Right now I need > to do this by hand and when I run cmake again, it overwrites the > solution files I modified and restore back the settings that disallow > the multithreaded builds. Basically I would like to know if there is > some option I would add to CMakeLists.txt that would make it do so. I > understand that this may not possible with current version of CMake > though. I sort of don't see this as being CMake's problem. Suppose your computer has 4 cores. Do you mean you would like CMake to detect that there are 4 cores and to change the Makefile automatically? Someone showed this with two Makefiles [1] -- it's an interesting solution if you want to try to make the same pair of Makefiles with CMake. (I have no idea how, but I guess it's possible?) I don't know what is the Windows equivalent, but on Linux, I've aliased "make" to "make -j 4". So, what you describe about "solution files" generated by CMake that get overwritten isn't really an issue. Or maybe I've completely misunderstood you? Do you want CMake to detect the number of threads and then to pass that to (a) the program that would be generated [i.e., for its execution] or (b) the compilation of such a program? I've assumed you meant (b)... Ray [1] http://stackoverflow.com/questions/2527496/how-can-i-write-a-makefile-to-auto-detect-and-parallelize-the-build-with-gnu-mak From benapetr at gmail.com Wed Sep 16 12:07:44 2015 From: benapetr at gmail.com (Petr Bena) Date: Wed, 16 Sep 2015 18:07:44 +0200 Subject: [CMake] Parallel builds In-Reply-To: References: <55F98A8B.3070802@kitware.com> Message-ID: This seems to be the precise answer to my question! Thank you On Wed, Sep 16, 2015 at 5:55 PM, Cory Quammen wrote: > Hi Petr, > > VTK exposes the /MP compiler flag in its CMake configuration. > > Here is the relevant code from > http://www.vtk.org/gitweb?p=VTK.git;a=blob;f=CMake/vtkDetermineCompilerFlags.cmake;h=1398050afb34ff8c0a74137d847c19a6f63b12e9;hb=HEAD > > 126 # Enable /MP flag for Visual Studio 2008 and greator > 127 IF(MSVC_VERSION GREATER 1400) > 128 SET(CMAKE_CXX_MP_FLAG OFF CACHE BOOL "Build with /MP flag enabled") > 129 SET(PROCESSOR_COUNT "$ENV{NUMBER_OF_PROCESSORS}") > 130 SET(CMAKE_CXX_MP_NUM_PROCESSORS CACHE ${PROCESSOR_COUNT} "The maximum > number of processes for the /MP flag") > 131 IF (CMAKE_CXX_MP_FLAG) > 132 SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} > /MP${CMAKE_CXX_MP_NUM_PROCESSORS}") > 133 SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} > /MP${CMAKE_CXX_MP_NUM_PROCESSORS}") > 134 ENDIF () > 135 ENDIF() > > Hope that helps, > Cory > > On Wed, Sep 16, 2015 at 11:44 AM, Petr Bena wrote: >> >> I know that I can pass -j parameter to GNU make as well as there is >> some sort of option to run MSVC compiler by hand and give that similar >> parameter, but that's not exactly what I want. >> >> I would prefer a way to get cmake to generate solution files for MSVC >> in a way that these options are enabled by default. Right now I need >> to do this by hand and when I run cmake again, it overwrites the >> solution files I modified and restore back the settings that disallow >> the multithreaded builds. Basically I would like to know if there is >> some option I would add to CMakeLists.txt that would make it do so. I >> understand that this may not possible with current version of CMake >> though. >> >> Thanks >> >> On Wed, Sep 16, 2015 at 5:28 PM, Bill Hoffman >> wrote: >> > http://www.kitware.com/blog/home/post/434 >> > >> > -Bill >> > >> > >> > -- >> > >> > Powered by www.kitware.com >> > >> > Please keep messages on-topic and check the CMake FAQ at: >> > http://www.cmake.org/Wiki/CMake_FAQ >> > >> > Kitware offers various services to support the CMake community. For more >> > information on each offering, please visit: >> > >> > CMake Support: http://cmake.org/cmake/help/support.html >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> > CMake Training Courses: http://cmake.org/cmake/help/training.html >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/cmake >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > > > > > -- > Cory Quammen > R&D Engineer > Kitware, Inc. From greg.marr at autodesk.com Wed Sep 16 12:17:39 2015 From: greg.marr at autodesk.com (Greg Marr) Date: Wed, 16 Sep 2015 16:17:39 +0000 Subject: [CMake] Parallel builds In-Reply-To: References: <55F98A8B.3070802@kitware.com> Message-ID: On Wed, Sep 16, 2015 at 5:55 PM, Cory Quammen wrote: > VTK exposes the /MP compiler flag in its CMake configuration. > > Here is the relevant code from > http://www.vtk.org/gitweb?p=VTK.git;a=blob;f=CMake/vtkDetermineCompilerFlags.cmake;h=1398050afb34ff8c0a74137d847c19a6f63b12e9;hb=HEAD > > 126 # Enable /MP flag for Visual Studio 2008 and greator > 132 SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /MP${CMAKE_CXX_MP_NUM_PROCESSORS}") > 133 SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /MP${CMAKE_CXX_MP_NUM_PROCESSORS}") If you're just going to set it to the number of processors on the machine, you might as well just use /MP, which means use the number of processors on the machine. The only time you need a number is when you want to use a different number of parallel processes, such as only using half your capacity because something else is using the other half, or leaving one or two cores open for GUI work. From d3ck0r at gmail.com Wed Sep 16 13:30:10 2015 From: d3ck0r at gmail.com (J Decker) Date: Wed, 16 Sep 2015 10:30:10 -0700 Subject: [CMake] Parallel builds In-Reply-To: References: <55F98A8B.3070802@kitware.com> Message-ID: On Wed, Sep 16, 2015 at 9:17 AM, Greg Marr wrote: > On Wed, Sep 16, 2015 at 5:55 PM, Cory Quammen wrote: >> VTK exposes the /MP compiler flag in its CMake configuration. >> >> Here is the relevant code from >> http://www.vtk.org/gitweb?p=VTK.git;a=blob;f=CMake/vtkDetermineCompilerFlags.cmake;h=1398050afb34ff8c0a74137d847c19a6f63b12e9;hb=HEAD >> >> 126 # Enable /MP flag for Visual Studio 2008 and greator >> 132 SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /MP${CMAKE_CXX_MP_NUM_PROCESSORS}") >> 133 SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /MP${CMAKE_CXX_MP_NUM_PROCESSORS}") > > If you're just going to set it to the number of processors on the machine, you might as well just use /MP, which means use the number of processors on the machine. The only time you need a number is when you want to use a different number of parallel processes, such as only using half your capacity because something else is using the other half, or leaving one or two cores open for GUI work. > /mp has no effect on cmake projects since each file is compiled with a separate command... it relies more on msbuild /m: option... from https://msdn.microsoft.com/en-us/library/bb385193.aspx?f=255&MSPPError=-2147217396 cl /MP7 a.cpp b.cpp c.cpp d.cpp e.cpp but cl is invoked for each source already; multiple sources aren't passed to cl. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 greg.marr at autodesk.com Wed Sep 16 13:39:33 2015 From: greg.marr at autodesk.com (Greg Marr) Date: Wed, 16 Sep 2015 17:39:33 +0000 Subject: [CMake] Parallel builds In-Reply-To: References: <55F98A8B.3070802@kitware.com> Message-ID: From: J Decker [mailto:d3ck0r at gmail.com] Sent: Wednesday, September 16, 2015 1:30 PM To: Greg Marr Cc: Petr Bena; Cory Quammen; cmake at cmake.org; Bill Hoffman Subject: Re: [CMake] Parallel builds /mp has no effect on cmake projects since each file is compiled with a separate command... it relies more on msbuild /m: option... from https://msdn.microsoft.com/en-us/library/bb385193.aspx?f=255&MSPPError=-2147217396 cl /MP7 a.cpp b.cpp c.cpp d.cpp e.cpp but cl is invoked for each source already; multiple sources aren't passed to cl. That's not true for the Visual Studio generator. CMake generates project files, and Visual Studio builds them just like any other project file, including using the /MP flag. From d3ck0r at gmail.com Wed Sep 16 13:47:52 2015 From: d3ck0r at gmail.com (J Decker) Date: Wed, 16 Sep 2015 10:47:52 -0700 Subject: [CMake] Parallel builds In-Reply-To: References: <55F98A8B.3070802@kitware.com> Message-ID: On Wed, Sep 16, 2015 at 10:39 AM, Greg Marr wrote: > From: J Decker [mailto:d3ck0r at gmail.com] > Sent: Wednesday, September 16, 2015 1:30 PM > To: Greg Marr > Cc: Petr Bena; Cory Quammen; cmake at cmake.org; Bill Hoffman > Subject: Re: [CMake] Parallel builds > > /mp has no effect on cmake projects since each file is compiled with a > separate command... it relies more on msbuild /m: option... > > from https://msdn.microsoft.com/en-us/library/bb385193.aspx?f=255&MSPPError=-2147217396 > > cl /MP7 a.cpp b.cpp c.cpp d.cpp e.cpp > > but cl is invoked for each source already; multiple sources aren't passed to cl. > > That's not true for the Visual Studio generator. CMake generates project files, and Visual Studio builds them just like any other project file, including using the /MP flag. > I see yer right. Details get foggy after years. well that's something to add :) From bill.hoffman at kitware.com Wed Sep 16 13:59:49 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 16 Sep 2015 13:59:49 -0400 Subject: [CMake] Parallel builds In-Reply-To: References: <55F98A8B.3070802@kitware.com> Message-ID: <55F9AE15.2080408@kitware.com> On 9/16/2015 1:47 PM, J Decker wrote: > I see yer right. > Details get foggy after years. > well that's something to add:) > All covered my blog. :) -Bill From greg.marr at autodesk.com Wed Sep 16 14:06:10 2015 From: greg.marr at autodesk.com (Greg Marr) Date: Wed, 16 Sep 2015 18:06:10 +0000 Subject: [CMake] Parallel builds In-Reply-To: <55F9AE15.2080408@kitware.com> References: <55F98A8B.3070802@kitware.com> <55F9AE15.2080408@kitware.com> Message-ID: <24ba15783f8e4ad79791b34ed7114fc0@BN1PR79MB006.MGDADSK.autodesk.com> -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Bill Hoffman Sent: Wednesday, September 16, 2015 2:00 PM To: cmake at cmake.org Subject: Re: [CMake] Parallel builds On 9/16/2015 1:47 PM, J Decker wrote: > I see yer right. > Details get foggy after years. > well that's something to add:) > All covered my blog. :) This part here is inaccurate, at least with the current CMake and Visual Studio: "To set the flag you will have to edit the CMake cache with the cmake-gui and add it to the CMAKE_CXX_FLAGS and the CMAKE_C_FLAGS." This is all we do in the CMake file that we include in all our projects: add_compile_options(/MP$ENV{NUMBER_OF_PROCESSORS}) If you don't have a NUMBER_OF_PROCESSORS environment variable, you just get /MP. The oversubscription part is still true, but I've never seen randomly bad object files. From bill.hoffman at kitware.com Wed Sep 16 14:41:29 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 16 Sep 2015 14:41:29 -0400 Subject: [CMake] Parallel builds In-Reply-To: <24ba15783f8e4ad79791b34ed7114fc0@BN1PR79MB006.MGDADSK.autodesk.com> References: <55F98A8B.3070802@kitware.com> <55F9AE15.2080408@kitware.com> <24ba15783f8e4ad79791b34ed7114fc0@BN1PR79MB006.MGDADSK.autodesk.com> Message-ID: <55F9B7D9.5010507@kitware.com> On 9/16/2015 2:06 PM, Greg Marr wrote: > This part here is inaccurate, at least with the current CMake and > Visual Studio: "To set the flag you will have to edit the CMake cache > with the cmake-gui and add it to the CMAKE_CXX_FLAGS and the > CMAKE_C_FLAGS." > > This is all we do in the CMake file that we include in all our > projects: add_compile_options(/MP$ENV{NUMBER_OF_PROCESSORS}) > > If you don't have a NUMBER_OF_PROCESSORS environment variable, you > just get /MP. > > The oversubscription part is still true, but I've never seen randomly > bad object files. I was writing it from the point of view of NOT having to edit the project. Seems like more of a per build decision to me. As there could be issues, the most reliable way to build is to not use /MP which is why CMake does not just do this by default. So, I would not want to recommend that projects make it a default. But, you can change the flags either by editing the CMakeLists.txt files or by editing the CMakeCache.txt file to change the flags in the build. -Bill From carl.poirier.2 at gmail.com Thu Sep 17 10:14:41 2015 From: carl.poirier.2 at gmail.com (Carl Poirier) Date: Thu, 17 Sep 2015 10:14:41 -0400 Subject: [CMake] Need help with COMPILE_DEFINITIONS_ In-Reply-To: <4430A696-C804-4265-B192-3A5B91C43C4C@hendrik-sattler.de> References: <4430A696-C804-4265-B192-3A5B91C43C4C@hendrik-sattler.de> Message-ID: Hi guys, Thanks for the information. I opened a bug ticket here . Carl On Mon, Sep 14, 2015 at 4:33 PM, Hendrik Sattler wrote: > > > Am 14. September 2015 22:25:00 MESZ, schrieb Pau Garcia i Quiles < > pgquiles at elpauer.org>: > >Hello, > > > >Have you tried > > > >set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG > >-DATEST) > > That would be the right thing for add_definitions() but not here. > He could try with generator expressions though. > > > > >On Mon, Sep 14, 2015 at 9:35 PM, Carl Poirier > > > >wrote: > > > >> Hi folks, > >> > >> I need some help setting the COMPILE_DEFINITIONS_. I'm using > >the > >> Visual Studio 2008 generator. I use this command to do so which I > >took in > >> the notes when the > >feature > >> was added: > >> > >> set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG > >ATEST) > >> > >> Then, once the solution and project is generated, I go into the > >project > >> properties under the C++ preprocessor and I can't see the define. > >Removing > >> the configuration name does set it correctly for all of them, so it > >leads > >> me to believe the rest of my CMakeLists.txt is fine: > >> > >> set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS ATEST) > >> > >> So is this supposed to work? > >> > >> Thank you, > >> > >> Carl > >> > >> -- > >> > >> Powered by www.kitware.com > >> > >> Please keep messages on-topic and check the CMake FAQ at: > >> http://www.cmake.org/Wiki/CMake_FAQ > >> > >> Kitware offers various services to support the CMake community. For > >more > >> information on each offering, please visit: > >> > >> CMake Support: http://cmake.org/cmake/help/support.html > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/cmake > >> > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.poirier.2 at gmail.com Thu Sep 17 10:24:57 2015 From: carl.poirier.2 at gmail.com (Carl Poirier) Date: Thu, 17 Sep 2015 10:24:57 -0400 Subject: [CMake] Need help with COMPILE_DEFINITIONS_ In-Reply-To: References: <4430A696-C804-4265-B192-3A5B91C43C4C@hendrik-sattler.de> Message-ID: I got a reply on the bug tracker. It's a normal and documented behavior. http://www.cmake.org/cmake/help/v3.3/prop_tgt/COMPILE_DEFINITIONS_CONFIG.html On Thu, Sep 17, 2015 at 10:14 AM, Carl Poirier wrote: > Hi guys, > > Thanks for the information. I opened a bug ticket here > . > > Carl > > On Mon, Sep 14, 2015 at 4:33 PM, Hendrik Sattler > wrote: > >> >> >> Am 14. September 2015 22:25:00 MESZ, schrieb Pau Garcia i Quiles < >> pgquiles at elpauer.org>: >> >Hello, >> > >> >Have you tried >> > >> >set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG >> >-DATEST) >> >> That would be the right thing for add_definitions() but not here. >> He could try with generator expressions though. >> >> > >> >On Mon, Sep 14, 2015 at 9:35 PM, Carl Poirier >> > >> >wrote: >> > >> >> Hi folks, >> >> >> >> I need some help setting the COMPILE_DEFINITIONS_. I'm using >> >the >> >> Visual Studio 2008 generator. I use this command to do so which I >> >took in >> >> the notes when the >> >feature >> >> was added: >> >> >> >> set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS_DEBUG >> >ATEST) >> >> >> >> Then, once the solution and project is generated, I go into the >> >project >> >> properties under the C++ preprocessor and I can't see the define. >> >Removing >> >> the configuration name does set it correctly for all of them, so it >> >leads >> >> me to believe the rest of my CMakeLists.txt is fine: >> >> >> >> set_property(TARGET ${PrjName0} PROPERTY COMPILE_DEFINITIONS ATEST) >> >> >> >> So is this supposed to work? >> >> >> >> Thank you, >> >> >> >> Carl >> >> >> >> -- >> >> >> >> Powered by www.kitware.com >> >> >> >> Please keep messages on-topic and check the CMake FAQ at: >> >> http://www.cmake.org/Wiki/CMake_FAQ >> >> >> >> Kitware offers various services to support the CMake community. For >> >more >> >> information on each offering, please visit: >> >> >> >> CMake Support: http://cmake.org/cmake/help/support.html >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://public.kitware.com/mailman/listinfo/cmake >> >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Thu Sep 17 12:25:51 2015 From: saadrustam at gmail.com (Saad Khattak) Date: Thu, 17 Sep 2015 16:25:51 +0000 Subject: [CMake] Linking with an external project also built with CMake Message-ID: Hello, I have a project *ExternalLib* that uses CMake to build its libraries. I then have my own project (separate from the external library) that needs to include ExternalLib's headers and link with its libraries. ExternalLib does not have a find_package module. Since ExternalLib is also built using CMake, is there no 'automatic' way to have CMake figure out where the source files and library files are (since CMake built them in the first place)? That is, I want to avoid writing a find_package module for ExternalLib and since I have to build it using CMake anyway, I was hoping there would be some way to automatically fill in the correct paths for the libraries and source file directories in MyProject which also uses CMake. Thanks, Saad -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Sep 17 15:04:21 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 17 Sep 2015 15:04:21 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.3.2 available for download Message-ID: We are pleased to announce that CMake 3.3.2 is now available for download. Please use the latest release from our download page: http://www.cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.3.2 since 3.3.1: Brad King (2): Makefile: Print color escapes only when necessary CMake 3.3.2 Chuck Atkins (1): find_*: Fix search order when the environment duplicates some HINTS Daniel Pfeifer (3): cmExtra{Kate,SublimeText}Generator: Remove unused cmXMLSafe includes cmCTest{BZR,GIT,P4}: Remove unused cmXMLSafe includes CTest: Fix XML double-encoding cases Matt McCormick (1): CMakeDetermine{C,CXX}Compiler: Avoid if() auto-dereferene in quoted arguments From tamas.kenez at gmail.com Thu Sep 17 16:52:09 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Thu, 17 Sep 2015 22:52:09 +0200 Subject: [CMake] Linking with an external project also built with CMake In-Reply-To: References: Message-ID: 1. There is a (semi-)automatic way: you can export the targets of ExternalLib with install(EXPORT...) from its CMakeLists.txt. In the simplest cases you can use the generated export file as a config module: install(TARGETS ... EXPORT externallib ...) install(EXPORT externallib FILE externallib-config.cmake ...) Of course you also need to set the appropriate properties of the targets of ExternalLib by using the target_* commands. 2. (Another option) If you build the ExternalLib in the same project, its targets will be available in the main project. On Thu, Sep 17, 2015 at 6:25 PM, Saad Khattak wrote: > Hello, > > I have a project *ExternalLib* that uses CMake to build its libraries. I > then have my own project (separate from the external library) that needs to > include ExternalLib's headers and link with its libraries. ExternalLib does > not have a find_package module. > > Since ExternalLib is also built using CMake, is there no 'automatic' way > to have CMake figure out where the source files and library files are > (since CMake built them in the first place)? That is, I want to avoid > writing a find_package module for ExternalLib and since I have to build it > using CMake anyway, I was hoping there would be some way to automatically > fill in the correct paths for the libraries and source file directories in > MyProject which also uses CMake. > > Thanks, > Saad > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 Thu Sep 17 16:54:17 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Thu, 17 Sep 2015 22:54:17 +0200 Subject: [CMake] Shared library from ExternalProject In-Reply-To: <1442409754.17596.19.camel@alcnetworx.de> References: <1441803501.13183.17.camel@alcnetworx.de> <1442318862.17596.15.camel@alcnetworx.de> <1442409754.17596.19.camel@alcnetworx.de> Message-ID: > However, that would still not make externals from > a .tar.gz being rebuilt if their archive was changed. Am I right? Yes, you're right, the UPDATE step is available only for git and svn. On Wed, Sep 16, 2015 at 3:22 PM, Tino Mettler wrote: > On Tue, 2015-09-15 at 16:32 +0200, Tam?s Ken?z wrote: > > > it would be nice to know if the usage of add_library(foo SHARED > > > IMPORTED) is the way to go in this case. > > > > I wouldn't think this is the way to go. One thing we love CMake for is > that > > it separates the concerns of the library and the consumer target so it's > > best to stick to find_package. > > > > This is the usage pattern of ExternalProject with find_package: > > Create a super project which contains the library and the consumer target > > in 2 separate ExternalProjects so the library can be installed before the > > main target's CMakeLists is configured. > > Hi, > > thanks for that hint. However, that would still not make externals from > a .tar.gz being rebuilt if their archive was changed. Am I right? > > Regards, > Tino > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 wmamrak at gmail.com Fri Sep 18 06:03:20 2015 From: wmamrak at gmail.com (Wojtek Mamrak) Date: Fri, 18 Sep 2015 12:03:20 +0200 Subject: [CMake] Linking with an external project also built with CMake In-Reply-To: References: Message-ID: Or you can export ExternalLib directly from the build tree. export(TARGETS ExternalLib FILE "${PROJECT_BINARY_DIR}/ExternalLibTargets.cmake") configure_file("${PROJECT_SOURCE_DIR}/ExternalLibConfig.cmake" "${PROJECT_BINARY_DIR}/ExternalLibConfig.cmake") export(PACKAGE ExternalLib) with ExternalLibConfig.cmake having something like: include("ExternalLibTargets.cmake") regards 2015-09-17 22:52 GMT+02:00 Tam?s Ken?z : > 1. There is a (semi-)automatic way: you can export the targets of > ExternalLib with install(EXPORT...) from its CMakeLists.txt. In the simplest > cases you can use the generated export file as a config module: > > install(TARGETS ... EXPORT externallib ...) > install(EXPORT externallib FILE externallib-config.cmake ...) > > Of course you also need to set the appropriate properties of the targets of > ExternalLib by using the target_* commands. > > 2. (Another option) If you build the ExternalLib in the same project, its > targets will be available in the main project. > > On Thu, Sep 17, 2015 at 6:25 PM, Saad Khattak wrote: >> >> Hello, >> >> I have a project ExternalLib that uses CMake to build its libraries. I >> then have my own project (separate from the external library) that needs to >> include ExternalLib's headers and link with its libraries. ExternalLib does >> not have a find_package module. >> >> Since ExternalLib is also built using CMake, is there no 'automatic' way >> to have CMake figure out where the source files and library files are (since >> CMake built them in the first place)? That is, I want to avoid writing a >> find_package module for ExternalLib and since I have to build it using CMake >> anyway, I was hoping there would be some way to automatically fill in the >> correct paths for the libraries and source file directories in MyProject >> which also uses CMake. >> >> Thanks, >> Saad >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware 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 j.wuttke at fz-juelich.de Fri Sep 18 09:45:17 2015 From: j.wuttke at fz-juelich.de (Joachim Wuttke) Date: Fri, 18 Sep 2015 15:45:17 +0200 Subject: [CMake] a cmake module that improves upon CheckLibrariesExists Message-ID: <55FC156D.8000500@fz-juelich.de> may I invite your comments at http://codereview.stackexchange.com/questions/105020/a-cmake-module-that-improves-upon-checklibrariesexists where I am proposing a module AssertLibraryFunction that improves upon CheckLibrariesExists in two respects: - It honors the optional argument REQUIRED of find_package: if the check fails, it raises a FATAL_ERROR. It also honors QUIET. - Its result is cached in a variable named ${LIBNAME}_${FUNCTION}. Therefore, argument 4 of CheckLibrariesExists, VARIABLE, is no longer needed. Thanks for any feedback (preferentially on said codereview site, if that is compatible with etiquette at this mailing list), Joachim -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5013 bytes Desc: S/MIME Cryptographic Signature URL: From tamas.kenez at gmail.com Fri Sep 18 10:38:00 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Fri, 18 Sep 2015 16:38:00 +0200 Subject: [CMake] config-module installed to '/share/cmake' - good or bad? Message-ID: Note: this question was motivated by having some troubles with HDF5 but requires no familiarity with HDF5. The HDF5 source distribution installs a very nice config-module (creates imported targets unlike FindHDF5.cmake). However it installs it to `/share/cmake` which path is not searched by `find_package(hdf5 CONFIG)`, in accordance with the documentation. I'd like to hear the opinion of the wise cmake people here whether this is a bug or not. I failed to convince a developer over at HDFGroup that it is a bug and they should install to '/share/cmake/hdf5' instead. But maybe I'm wrong, that's why I'm asking it here. Cheers, Tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: From randallsturner13 at gmail.com Fri Sep 18 13:22:56 2015 From: randallsturner13 at gmail.com (Randy Turner) Date: Fri, 18 Sep 2015 13:22:56 -0400 Subject: [CMake] Port from Debian to Windows: Include files not found Message-ID: I am having trouble building a Code Composer Studio project with CMake. Executing from the same directory in Linux compiles successfully, but in Linux it fails to find any included files that aren't in the same directory as the .c file that it's building. I can provide a relative path to help it move on, but it will just fail to find the files referenced by that one. The very first #include of the project is which is located in the compiler's install files. As shown in my StackOVerflow question about this issue ( http://stackoverflow.com/questions/32591626/cmake-header-files-cannot-be-opened) I can confirm that the files are in the directory that is included in the CMakeLists.txt file and can be found while CMake is executing, but fail to be located by make. I am using MinGW's make, and using the commands make and mingw32-make both ellicit the same result, "fatal error: could not open source file "stdbool.h" (no directories in search list)." Is there something that I'm missing here? Is something else necessary beyond using INCLUDE_DIRECTORIES for all of the directories in the project? -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Fri Sep 18 13:26:44 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Fri, 18 Sep 2015 17:26:44 +0000 Subject: [CMake] Port from Debian to Windows: Include files not found In-Reply-To: References: Message-ID: <8B259A9A-11F3-4A8A-BF59-6D503FBFCAA8@ionicsecurity.com> As a diagnostic measure, can you try running in verbose mode, ala: make VERBOSE=1 That will dump out the exact command lines that are being used, so you can see the search paths. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: CMake on behalf of Randy Turner Date: Friday, September 18, 2015 at 1:22 PM To: "cmake at cmake.org" Subject: [CMake] Port from Debian to Windows: Include files not found I am having trouble building a Code Composer Studio project with CMake. Executing from the same directory in Linux compiles successfully, but in Linux it fails to find any included files that aren't in the same directory as the .c file that it's building. I can provide a relative path to help it move on, but it will just fail to find the files referenced by that one. The very first #include of the project is which is located in the compiler's install files. As shown in my StackOVerflow question about this issue (http://stackoverflow.com/questions/32591626/cmake-header-files-cannot-be-opened) I can confirm that the files are in the directory that is included in the CMakeLists.txt file and can be found while CMake is executing, but fail to be located by make. I am using MinGW's make, and using the commands make and mingw32-make both ellicit the same result, "fatal error: could not open source file "stdbool.h" (no directories in search list)." Is there something that I'm missing here? Is something else necessary beyond using INCLUDE_DIRECTORIES for all of the directories in the project? -------------- next part -------------- An HTML attachment was scrubbed... URL: From randallsturner13 at gmail.com Fri Sep 18 14:01:45 2015 From: randallsturner13 at gmail.com (Randy Turner) Date: Fri, 18 Sep 2015 14:01:45 -0400 Subject: [CMake] Port from Debian to Windows: Include files not found In-Reply-To: <8B259A9A-11F3-4A8A-BF59-6D503FBFCAA8@ionicsecurity.com> References: <8B259A9A-11F3-4A8A-BF59-6D503FBFCAA8@ionicsecurity.com> Message-ID: Awesome suggestion. I'm surprised that I hadn't yet tried that. I sent the output to a file and included the relevant portion below. I'm not the most familiar with parsing the output of makefiles, but it seems to only be using the include_paths for the first assembly object and not any of the subsequent c objects. I feel like there is something really obvious that I'm missing. [ 6%] Building ASM object CMakeFiles/timer1.dir/os/vecs_timer1.asm.obj c:\ti\ccsv6\tools\compiler\c6000_7.4.15\bin\cl6x.exe --compile_only --asm_file=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\os\vecs_timer1.asm --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\C6xCSL\include --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\C6xCSL\lib_3x --include_path=c:\ti\ccsv6\tools\compiler\c6000_7.4.15\include --include_path=c:\ti\ccsv6\tools\compiler\c6000_7.4.15\lib --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\udp_ip --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\os --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\sys --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\utilities -g --define="_DEBUG" --define="CHIP_6713" --define="RUNTEST" --output_file=CMakeFiles\timer1.dir\os\vecs_timer1.asm.obj [ 13%] Building C object CMakeFiles/timer1.dir/os/Arinc.c.obj c:\ti\ccsv6\tools\compiler\c6000_7.4.15\bin\cl6x.exe --compile_only --c_file=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\os\Arinc.c -mv6710 --abi=coffabi --quiet --diag_wrap=off @CMakeFiles/timer1.dir/includes_C.rsp -g --define="_DEBUG" --define="CHIP_6713" --define="RUNTEST" --output_file=CMakeFiles\timer1.dir\os\Arinc.c.obj >> Compilation failure On Fri, Sep 18, 2015 at 1:26 PM, Parag Chandra wrote: > As a diagnostic measure, can you try running in verbose mode, ala: > > make VERBOSE=1 > > That will dump out the exact command lines that are being used, so you can > see the search paths. > > > > *Parag Chandra *Senior Software Engineer, Mobile Team > Mobile: +1.919.824.1410 > > > > Ionic Security Inc. > 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 > > > > > > > > > From: CMake on behalf of Randy Turner > Date: Friday, September 18, 2015 at 1:22 PM > To: "cmake at cmake.org" > Subject: [CMake] Port from Debian to Windows: Include files not found > > I am having trouble building a Code Composer Studio project with CMake. > Executing from the same directory in Linux compiles successfully, but in > Linux it fails to find any included files that aren't in the same directory > as the .c file that it's building. I can provide a relative path to help it > move on, but it will just fail to find the files referenced by that one. > > The very first #include of the project is which is located in > the compiler's install files. As shown in my StackOVerflow question about > this issue ( > http://stackoverflow.com/questions/32591626/cmake-header-files-cannot-be-opened) > I can confirm that the files are in the directory that is included in the > CMakeLists.txt file and can be found while CMake is executing, but fail to > be located by make. I am using MinGW's make, and using the commands make > and mingw32-make both ellicit the same result, "fatal error: could not open > source file "stdbool.h" (no directories in search list)." > > Is there something that I'm missing here? Is something else necessary > beyond using INCLUDE_DIRECTORIES for all of the directories in the project? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonhodgson.devlists at googlemail.com Fri Sep 18 14:03:37 2015 From: jonhodgson.devlists at googlemail.com (Jon Hodgson) Date: Fri, 18 Sep 2015 19:03:37 +0100 Subject: [CMake] CMakeGraphVizOptions not working consistently Message-ID: Hi, I'm using the graphviz functionality of CMake to allow me to extract dependencies and thus a sub-project build order for auto builds (I'm using buildbot, and building sub projects separately gives more informative feedback since I can see which ones fail) Now as part of that I generate a CMakeGraphVizOptions file containing three lines set(GRAPHVIZ_EXTERNAL_LIBS FALSE) set(GRAPHVIZ_GENERATE_PER_TARGET FALSE) set(GRAPHVIZ_GENERATE_DEPENDERS FALSE) Now on windows, using CMake 3.2.1 this works as expected, I get just one file, the one fro the whole project, with no external libs referenced. But on OSX, using CMake 3.3.2, only the GRAPHVIZ_EXTERNAL_LIBS variable seems to make a difference. So I get graphiz files for every target and depender files for them all. I thought it might be just responding to the first line, but tried switching them around and the result was the same. Luckily the one variable that is working is the one that is crucial for my needs, the others are just to avoid unnecessary files cluttering things up, but I'm still intrigued as to why it's failing. Have I missed something, or is there a bug? regards Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Fri Sep 18 14:08:29 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Fri, 18 Sep 2015 18:08:29 +0000 Subject: [CMake] Port from Debian to Windows: Include files not found In-Reply-To: References: <8B259A9A-11F3-4A8A-BF59-6D503FBFCAA8@ionicsecurity.com> Message-ID: That is interesting. I?m used to seeing ?-I/header/search/path?, but in this case it?s doing ??include_path=/header/search/path?; I guess you?re using some specialized compiler toolchain. So if I understand you correctly, if you were to manually edit the command that you pasted such that it had the necessary include paths in it and manually re-run it, then the command would succeed? Maybe you need to explicitly set the supported LANGUAGES in your project() command so that it includes both assembly and C? Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: Randy Turner Date: Friday, September 18, 2015 at 2:01 PM To: Parag Chandra Cc: "cmake at cmake.org" Subject: Re: [CMake] Port from Debian to Windows: Include files not found Awesome suggestion. I'm surprised that I hadn't yet tried that. I sent the output to a file and included the relevant portion below. I'm not the most familiar with parsing the output of makefiles, but it seems to only be using the include_paths for the first assembly object and not any of the subsequent c objects. I feel like there is something really obvious that I'm missing. [ 6%] Building ASM object CMakeFiles/timer1.dir/os/vecs_timer1.asm.obj c:\ti\ccsv6\tools\compiler\c6000_7.4.15\bin\cl6x.exe --compile_only --asm_file=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\os\vecs_timer1.asm --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\C6xCSL\include --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\C6xCSL\lib_3x --include_path=c:\ti\ccsv6\tools\compiler\c6000_7.4.15\include --include_path=c:\ti\ccsv6\tools\compiler\c6000_7.4.15\lib --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\udp_ip --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\os --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\sys --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\utilities -g --define="_DEBUG" --define="CHIP_6713" --define="RUNTEST" --output_file=CMakeFiles\timer1.dir\os\vecs_timer1.asm.obj [ 13%] Building C object CMakeFiles/timer1.dir/os/Arinc.c.obj c:\ti\ccsv6\tools\compiler\c6000_7.4.15\bin\cl6x.exe --compile_only --c_file=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\os\Arinc.c -mv6710 --abi=coffabi --quiet --diag_wrap=off @CMakeFiles/timer1.dir/includes_C.rsp -g --define="_DEBUG" --define="CHIP_6713" --define="RUNTEST" --output_file=CMakeFiles\timer1.dir\os\Arinc.c.obj >> Compilation failure On Fri, Sep 18, 2015 at 1:26 PM, Parag Chandra > wrote: As a diagnostic measure, can you try running in verbose mode, ala: make VERBOSE=1 That will dump out the exact command lines that are being used, so you can see the search paths. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: CMake on behalf of Randy Turner Date: Friday, September 18, 2015 at 1:22 PM To: "cmake at cmake.org" Subject: [CMake] Port from Debian to Windows: Include files not found I am having trouble building a Code Composer Studio project with CMake. Executing from the same directory in Linux compiles successfully, but in Linux it fails to find any included files that aren't in the same directory as the .c file that it's building. I can provide a relative path to help it move on, but it will just fail to find the files referenced by that one. The very first #include of the project is which is located in the compiler's install files. As shown in my StackOVerflow question about this issue (http://stackoverflow.com/questions/32591626/cmake-header-files-cannot-be-opened) I can confirm that the files are in the directory that is included in the CMakeLists.txt file and can be found while CMake is executing, but fail to be located by make. I am using MinGW's make, and using the commands make and mingw32-make both ellicit the same result, "fatal error: could not open source file "stdbool.h" (no directories in search list)." Is there something that I'm missing here? Is something else necessary beyond using INCLUDE_DIRECTORIES for all of the directories in the project? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnewcomb at nvidia.com Fri Sep 18 14:42:22 2015 From: bnewcomb at nvidia.com (Bill Newcomb) Date: Fri, 18 Sep 2015 11:42:22 -0700 Subject: [CMake] Determining a library name at configure time Message-ID: <55FC5B0E.4050800@nvidia.com> Suppose I add a library in my project: add_library(foo STATIC foo.c bar.c) Is there a way I can get the name of the generated library file at configure time? LIBRARY_OUTPUT_NAME and OUTPUT_NAME for the target do not seem to be set: get_target_property(libname foo LIBRARY_OUTPUT_NAME) message(STATUS "libname is ${libname} ... -- libname is libname-NOTFOUND ... Thanks, B. ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From tom.kacvinsky at vectorcast.com Fri Sep 18 15:08:51 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Fri, 18 Sep 2015 15:08:51 -0400 Subject: [CMake] OBJECT library and $ Message-ID: Snippet: add_libary(foo OBJECT a.c b.c) add_custom_command( OUTPUT exports.def COMMAND lib /out:static.lib $ COMMAND python export.py" static.lib exports.def DEPENDS export.py" ) Results in: CMake Error at CMakeLists.txt:289 (add_custom_command): Error evaluating generator expression: $ Expression did not evaluate to a known generator expression What am I doing wrong? I am using cmake 2.8.11.2 on windows and my understanding is that the TARGET_OBJECTS generator expression was introduced in 2.8.8 Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From randallsturner13 at gmail.com Fri Sep 18 15:10:41 2015 From: randallsturner13 at gmail.com (Randy Turner) Date: Fri, 18 Sep 2015 15:10:41 -0400 Subject: [CMake] Port from Debian to Windows: Include files not found In-Reply-To: References: <8B259A9A-11F3-4A8A-BF59-6D503FBFCAA8@ionicsecurity.com> Message-ID: We are building for a TI TMS320C6713 DSK and are using a version of the .cmake file discussed on this mailing list here: http://marc.info/?l=cmake&m=136308196810830&w=2. Yes, the include path flag has been overridden. We actually don't have a project() declaration, but adding the line 'project(${TARGET_NAME} LANGUAGES C ASM)' enters into an infinite loop where cmake appears to be failing to clear the cache. I would assume that the omission of those include statements is what is causing the problem. I've manually run just that section to build Arinc.c.obj and included those include statements but it has dependencies on other things in the makefile and can't be run on its own. One warning that command generates that was not shown in what I sent you previously is "WARNING: more than one source file is specified; option --output_file is ignored." I can't be sure that that is related to the issue that I am having but it is regularly generated via make under Windows but is not present in the same command in Linux. On Fri, Sep 18, 2015 at 2:08 PM, Parag Chandra wrote: > That is interesting. I?m used to seeing ?-I/header/search/path?, but in > this case it?s doing ??include_path=/header/search/path?; I guess you?re > using some specialized compiler toolchain. So if I understand you > correctly, if you were to manually edit the command that you pasted such > that it had the necessary include paths in it and manually re-run it, then > the command would succeed? Maybe you need to explicitly set the supported > LANGUAGES in your project() command so that it includes both assembly and C? > > > > *Parag Chandra *Senior Software Engineer, Mobile Team > Mobile: +1.919.824.1410 > > > > Ionic Security Inc. > 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 > > > > > > > > > From: Randy Turner > Date: Friday, September 18, 2015 at 2:01 PM > To: Parag Chandra > Cc: "cmake at cmake.org" > Subject: Re: [CMake] Port from Debian to Windows: Include files not found > > Awesome suggestion. I'm surprised that I hadn't yet tried that. I sent the > output to a file and included the relevant portion below. I'm not the most > familiar with parsing the output of makefiles, but it seems to only be > using the include_paths for the first assembly object and not any of the > subsequent c objects. I feel like there is something really obvious that > I'm missing. > > [ 6%] Building ASM object CMakeFiles/timer1.dir/os/vecs_timer1.asm.obj > c:\ti\ccsv6\tools\compiler\c6000_7.4.15\bin\cl6x.exe --compile_only > --asm_file=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\os\vecs_timer1.asm > --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\C6xCSL\include > --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\C6xCSL\lib_3x > --include_path=c:\ti\ccsv6\tools\compiler\c6000_7.4.15\include > --include_path=c:\ti\ccsv6\tools\compiler\c6000_7.4.15\lib > --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\udp_ip > --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem > --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\os > --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\sys > --include_path=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\utilities > -g --define="_DEBUG" --define="CHIP_6713" --define="RUNTEST" > --output_file=CMakeFiles\timer1.dir\os\vecs_timer1.asm.obj > [ 13%] Building C object CMakeFiles/timer1.dir/os/Arinc.c.obj > c:\ti\ccsv6\tools\compiler\c6000_7.4.15\bin\cl6x.exe --compile_only > --c_file=C:\Users\aec_user-14\Documents\Repos\OperatingSystem\os\Arinc.c > -mv6710 --abi=coffabi --quiet --diag_wrap=off > @CMakeFiles/timer1.dir/includes_C.rsp -g --define="_DEBUG" > --define="CHIP_6713" --define="RUNTEST" > --output_file=CMakeFiles\timer1.dir\os\Arinc.c.obj > > >> Compilation failure > > On Fri, Sep 18, 2015 at 1:26 PM, Parag Chandra > wrote: > >> As a diagnostic measure, can you try running in verbose mode, ala: >> >> make VERBOSE=1 >> >> That will dump out the exact command lines that are being used, so you >> can see the search paths. >> >> >> >> *Parag Chandra *Senior Software Engineer, Mobile Team >> Mobile: +1.919.824.1410 >> >> >> >> Ionic Security Inc. >> 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 >> >> >> >> >> >> >> >> >> From: CMake on behalf of Randy Turner >> Date: Friday, September 18, 2015 at 1:22 PM >> To: "cmake at cmake.org" >> Subject: [CMake] Port from Debian to Windows: Include files not found >> >> I am having trouble building a Code Composer Studio project with CMake. >> Executing from the same directory in Linux compiles successfully, but in >> Linux it fails to find any included files that aren't in the same directory >> as the .c file that it's building. I can provide a relative path to help it >> move on, but it will just fail to find the files referenced by that one. >> >> The very first #include of the project is which is located in >> the compiler's install files. As shown in my StackOVerflow question about >> this issue ( >> http://stackoverflow.com/questions/32591626/cmake-header-files-cannot-be-opened) >> I can confirm that the files are in the directory that is included in the >> CMakeLists.txt file and can be found while CMake is executing, but fail to >> be located by make. I am using MinGW's make, and using the commands make >> and mingw32-make both ellicit the same result, "fatal error: could not open >> source file "stdbool.h" (no directories in search list)." >> >> Is there something that I'm missing here? Is something else necessary >> beyond using INCLUDE_DIRECTORIES for all of the directories in the project? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- cmake_minimum_required(VERSION 2.8) #Include the toolchain include("toolchain_c671_dsp.cmake") #Set the Target, Library, and Include Directories set (TARGET_NAME timer1) set (CSL_LIB ${CMAKE_SOURCE_DIR}/C6xCSL/lib_3x) set (CSL_INCLUDE ${CMAKE_SOURCE_DIR}/C6xCSL/include) set (COMPILER_INCLUDE ${CGT_COMPILER_ROOT}/include) set (COMPILER_LIB ${CGT_COMPILER_ROOT}/lib) #set (DSK_LIB /opt/ti/CCStudio_v3.1/c6000/dsk6713/lib) set (IP_INCLUDE ${CMAKE_SOURCE_DIR}/udp_ip) set (COMMON_INCLUDE ${CMAKE_SOURCE_DIR}) set (OS_INCLUDE ${CMAKE_SOURCE_DIR}/os) #set (AS_INCLUDE ${CMAKE_SOURCE_DIR}/AS) set (SYS_INCLUDE ${CMAKE_SOURCE_DIR}/sys) set (UTIL_INCLUDE ${CMAKE_SOURCE_DIR}/utilities) # Include the directories INCLUDE_DIRECTORIES ("${CSL_INCLUDE}") INCLUDE_DIRECTORIES ("${CSL_LIB}") INCLUDE_DIRECTORIES ("${COMPILER_INCLUDE}") INCLUDE_DIRECTORIES ("${COMPILER_LIB}") #INCLUDE_DIRECTORIES ("${DSK_LIB}") INCLUDE_DIRECTORIES ("${IP_INCLUDE}") INCLUDE_DIRECTORIES ("${COMMON_INCLUDE}") INCLUDE_DIRECTORIES ("${OS_INCLUDE}") #INCLUDE_DIRECTORIES ("${AS_INCLUDE}") INCLUDE_DIRECTORIES ("${SYS_INCLUDE}") INCLUDE_DIRECTORIES ("${UTIL_INCLUDE}") #Surpress CMAKE from adding -rdynamic to the linking SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "") #Specify the C Flags and global definitions set(CMAKE_C_FLAGS "-mv6710 --abi=coffabi --quiet --diag_wrap=off") add_definitions("-g --define=\"_DEBUG\" --define=\"CHIP_6713\" --define=\"RUNTEST\"") set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ./Debug) set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ./Debug) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ./Debug) #Make the executable with the included files add_executable(${TARGET_NAME} ./os/vecs_timer1.asm ./os/Arinc.c ./os/cpld.c ./os/emif.c ./os/Gpio.c ./os/Mcbsp.c main.c ./os/Queues.c ./os/TaskDefinition.c ./os/Timer.c ./os/test/TestArinc.c ./os/test/test_os.c ./os/test/test_os_Runner.c ./os/test/unity.c) #Set the Linker Flags / Libraries target_link_libraries (${TARGET_NAME} ${UTIL_INCLUDE}/dsk6713bsl.lib ${UTIL_INCLUDE}/rts6700.lib ${CSL_LIB}/csl6713.lib ${UTIL_INCLUDE}/timer1.cmd) SET_TARGET_PROPERTIES (${TARGET_NAME} PROPERTIES LINK_FLAGS "--reread_libs --warn_sections --rom_model --xml_link_info=./Debug/${TARGET_NAME}_linkinfo.xml --display_error_number") -------------- next part -------------- A non-text attachment was scrubbed... Name: toolchain_c671_dsp.cmake Type: application/octet-stream Size: 3721 bytes Desc: not available URL: From tom.kacvinsky at vectorcast.com Fri Sep 18 15:44:28 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Fri, 18 Sep 2015 15:44:28 -0400 Subject: [CMake] OBJECT library and $ In-Reply-To: References: Message-ID: On Fri, Sep 18, 2015 at 3:08 PM, Tom Kacvinsky wrote: > Snippet: > > add_libary(foo OBJECT a.c b.c) > > add_custom_command( > OUTPUT exports.def > COMMAND lib /out:static.lib $ > COMMAND python export.py" static.lib exports.def > DEPENDS export.py" > ) > > Results in: > > CMake Error at CMakeLists.txt:289 (add_custom_command): > Error evaluating generator expression: > > $ > > Expression did not evaluate to a known generator expression > > What am I doing wrong? I am using cmake 2.8.11.2 on windows and my > understanding is that the TARGET_OBJECTS generator expression was > introduced in 2.8.8 > > Thanks, > > Tom > > I figured it out. That generator expression is only valid inside an add_library or add_executable target. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgquiles at elpauer.org Fri Sep 18 15:49:19 2015 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Fri, 18 Sep 2015 21:49:19 +0200 Subject: [CMake] Port from Debian to Windows: Include files not found In-Reply-To: References: Message-ID: Hello, You may need something like this in the toolchain file: # search for programs in the build host directories SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) # for libraries and headers in the target directories SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH) SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) On Fri, Sep 18, 2015 at 7:22 PM, Randy Turner wrote: > I am having trouble building a Code Composer Studio project with CMake. > Executing from the same directory in Linux compiles successfully, but in > Linux it fails to find any included files that aren't in the same directory > as the .c file that it's building. I can provide a relative path to help it > move on, but it will just fail to find the files referenced by that one. > > The very first #include of the project is which is located in > the compiler's install files. As shown in my StackOVerflow question about > this issue ( > http://stackoverflow.com/questions/32591626/cmake-header-files-cannot-be-opened) > I can confirm that the files are in the directory that is included in the > CMakeLists.txt file and can be found while CMake is executing, but fail to > be located by make. I am using MinGW's make, and using the commands make > and mingw32-make both ellicit the same result, "fatal error: could not open > source file "stdbool.h" (no directories in search list)." > > Is there something that I'm missing here? Is something else necessary > beyond using INCLUDE_DIRECTORIES for all of the directories in the project? > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtcacct at gmail.com Fri Sep 18 18:42:15 2015 From: jtcacct at gmail.com (Joe) Date: Fri, 18 Sep 2015 22:42:15 +0000 (UTC) Subject: [CMake] =?utf-8?q?Using_add=5Fsubdirectory_to_manage_project_depe?= =?utf-8?q?ndencies_that_aren=27t_actually_in_a_subdirectory?= Message-ID: Hi. I was hoping to get some guidance on if this is bad practice. I am simply trying to find a way to manage internal dependencies of my project but with a file structure that is distributed. It looks like this: /path/to/A /path/to/B B depends on A. I cannot change this directory structure. The solution we have chose is to create the following: /path/to/modules/FindA.cmake: ... if (NOT TARGET A) set(PATH_TO_A ${CMAKE_CURRENT_LIST_DIR}../A) add_subdirectory(${PATH_TO_A} ${PATH_TO_A}/build) endif() ... This way, A' CMakeLists is invoked and the library is compiled and built. Then in B's CMakeLists.txt: ... set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_CURRENT_LIST_DIR}/../modules) find_package(A) add_executable(main_B src/main_B.cpp) target_link_libraries(main_B A) ... Is this bad practice? I tried to figure out find_package in CONFIG mode but every example I've found seems complicated and obtuse. Thank you. From iosif.neitzke+cmake at gmail.com Fri Sep 18 19:24:59 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Fri, 18 Sep 2015 18:24:59 -0500 Subject: [CMake] Using add_subdirectory to manage project dependencies that aren't actually in a subdirectory In-Reply-To: References: Message-ID: Why not just go one directory up? Add /path/to/CMakeLists.txt containing at least: add_subdirectory(A) add_subdirectory(B) https://github.com/toomuchatonce/cmake-examples/blob/master/staticlibs-add_subdir/CMakeLists.txt On Fri, Sep 18, 2015 at 5:42 PM, Joe wrote: > Hi. I was hoping to get some guidance on if this is bad practice. I am > simply trying to find a way to manage internal dependencies of my project > but with a file structure that is distributed. It looks like this: > > /path/to/A > > /path/to/B > > B depends on A. I cannot change this directory structure. The solution we > have chose is to create the following: > > /path/to/modules/FindA.cmake: > > ... > if (NOT TARGET A) > set(PATH_TO_A ${CMAKE_CURRENT_LIST_DIR}../A) > add_subdirectory(${PATH_TO_A} ${PATH_TO_A}/build) > endif() > ... > > This way, A' CMakeLists is invoked and the library is compiled and built. > Then in B's CMakeLists.txt: > > ... > set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} > ${CMAKE_CURRENT_LIST_DIR}/../modules) > > find_package(A) > add_executable(main_B src/main_B.cpp) > target_link_libraries(main_B A) > ... > > Is this bad practice? I tried to figure out find_package in CONFIG mode but > every example I've found seems complicated and obtuse. Thank you. > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From jtcacct at gmail.com Fri Sep 18 22:51:46 2015 From: jtcacct at gmail.com (Joe) Date: Sat, 19 Sep 2015 02:51:46 +0000 (UTC) Subject: [CMake] =?utf-8?q?Using_add=5Fsubdirectory_to_manage_project_depe?= =?utf-8?q?ndencies_that_aren=27t_actually_in_a_subdirectory?= References: Message-ID: Iosif Neitzke writes: > > Why not just go one directory up? Add /path/to/CMakeLists.txt > containing at least: > > add_subdirectory(A) > add_subdirectory(B) > > https://github.com/toomuchatonce/cmake-examples/blob/master/staticlibs- add_subdir/CMakeLists.txt > > On Fri, Sep 18, 2015 at 5:42 PM, Joe wrote: > > Hi. I was hoping to get some guidance on if this is bad practice. I am > > simply trying to find a way to manage internal dependencies of my project > > but with a file structure that is distributed. It looks like this: > > > > /path/to/A > > > > /path/to/B > > > > B depends on A. I cannot change this directory structure. The solution we > > have chose is to create the following: > > > > /path/to/modules/FindA.cmake: > > > > ... > > if (NOT TARGET A) > > set(PATH_TO_A ${CMAKE_CURRENT_LIST_DIR}../A) > > add_subdirectory(${PATH_TO_A} ${PATH_TO_A}/build) > > endif() > > ... > > > > This way, A' CMakeLists is invoked and the library is compiled and built. > > Then in B's CMakeLists.txt: > > > > ... > > set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} > > ${CMAKE_CURRENT_LIST_DIR}/../modules) > > > > find_package(A) > > add_executable(main_B src/main_B.cpp) > > target_link_libraries(main_B A) > > ... > > > > Is this bad practice? I tried to figure out find_package in CONFIG mode but > > every example I've found seems complicated and obtuse. Thank you. > > > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more information on each offering, > please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake Iosif, thanks for the reply. Unfortunately, I do not have control over that (the long answer is that the projects are arranged in a Clearcase VOB file structure). Honestly, what I really need is just a way to invoke a CMakeLists.txt for a project that lives in a completely arbitrary place on the filesystem. I tried to read the documentation, but I can't seem to figure out if I'm supposed to use ExternalProject_Add or find_package. If the answer is find_package, I can't seem to tell if I'm supposed to be using it in MODULE mode or CONFIG mode. CONFIG mode seems really confusing, which is why I came up with the approach used in the first post. Basically, I use add_subdirectory() simply a mechanism to invoke another project's CMakeLists.txt. I could have used include(), but I liked the idea of distributing the build by using the second parameter of add_subdirectory to build the project in it's own area. From rwan.work at gmail.com Fri Sep 18 23:35:36 2015 From: rwan.work at gmail.com (Raymond Wan) Date: Sat, 19 Sep 2015 11:35:36 +0800 Subject: [CMake] Using add_subdirectory to manage project dependencies that aren't actually in a subdirectory In-Reply-To: References: Message-ID: Hi Joe, On Sat, Sep 19, 2015 at 6:42 AM, Joe wrote: > /path/to/modules/FindA.cmake: > > ... > if (NOT TARGET A) > set(PATH_TO_A ${CMAKE_CURRENT_LIST_DIR}../A) > add_subdirectory(${PATH_TO_A} ${PATH_TO_A}/build) > endif() > ... > > This way, A' CMakeLists is invoked and the library is compiled and built. > Then in B's CMakeLists.txt: > > ... > set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} > ${CMAKE_CURRENT_LIST_DIR}/../modules) > > find_package(A) > add_executable(main_B src/main_B.cpp) > target_link_libraries(main_B A) > ... > > Is this bad practice? I tried to figure out find_package in CONFIG mode but > every example I've found seems complicated and obtuse. Thank you. I'm interested in what you find. Until now, I've been doing what you and losif are doing. The reason is that the top-level program (i.e., Z) makes use of A and B. But also, I want to test B independently of Z, but I need to link in A to do it. I'm not sure if this is relevant, but what I've been doing is following this old thread: http://www.cmake.org/pipermail/cmake/2010-December/041150.html . I'm not sure if a better way is available with the current version of CMake... Anyway, perhaps this post will help (it's not from me)? Ray From wmamrak at gmail.com Sun Sep 20 14:10:19 2015 From: wmamrak at gmail.com (Wojtek Mamrak) Date: Sun, 20 Sep 2015 20:10:19 +0200 Subject: [CMake] How does reload cache work of CMake GUI? Message-ID: Hello, what is the semantics of CMake Gui's reload cache? Is it possible to achieve the same from the command line? regards From wmamrak at gmail.com Sun Sep 20 18:14:15 2015 From: wmamrak at gmail.com (Wojtek Mamrak) Date: Mon, 21 Sep 2015 00:14:15 +0200 Subject: [CMake] How does reload cache work of CMake GUI? In-Reply-To: References: Message-ID: Looks like deleting both CMakeFiles\generate.stamp and CMakeFiles\generate.stamp.depend does the job, yet it is not the CMake Gui way. Is there any more convenient approach? 2015-09-20 20:10 GMT+02:00 Wojtek Mamrak : > Hello, > > what is the semantics of CMake Gui's reload cache? Is it possible to > achieve the same from the command line? > > regards From brandon.ess at gmail.com Mon Sep 21 00:36:47 2015 From: brandon.ess at gmail.com (Brandon Ess) Date: Sun, 20 Sep 2015 21:36:47 -0700 Subject: [CMake] package version control Message-ID: Hi, I'm working on implementing a way to enforce library version control for library dependencies and I'm trying to figure out the best way to accomplish this. For example, find_package(foo 1.2 required) Where version 1.2 or greater must be used. If cmake finds version 1.1 or less it will not use that library and print an error message. Reading various cmake modules it seems everyone has a different way of going about it. I see there is an implementation built into cmake but I cannot seem to quite grasp how it works. http://www.cmake.org/Wiki/CMake/Tutorials/Packaging I do have package config working and the library version is being defined there so when the package foo is found it prints the version found via package config but I'm not sure if relying on that is the best approach. Could someone point me in the right direction? thanks, Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jakub.Golebiewski at dnvgl.com Mon Sep 21 02:20:56 2015 From: Jakub.Golebiewski at dnvgl.com (Golebiewski, Jakub) Date: Mon, 21 Sep 2015 06:20:56 +0000 Subject: [CMake] How to create a custom solution with Visual Studio 2010 generator? Message-ID: Hi, I'm trying to create a solution with custom set of projects (in VS sense) for Visual Studio 2010. I have a top level CMakeLists.txt with PROJECT() declared and then several CMakeLists.txt below in a tree also with PROJECT() in each of them. However for lower level PROJECT() directives I get all the targets that I specify in CMakeLists.txt and all the targets that they depend on. My goal is to have a solution only with a specific set of targets, without dependencies. Is there a way to do that in cmake? Thanks for help, Jakub ************************************************************************************** This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited. ************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at junovagen.se Mon Sep 21 03:37:11 2015 From: thomas at junovagen.se (thoni56) Date: Mon, 21 Sep 2015 00:37:11 -0700 (MST) Subject: [CMake] CMP0054 and CMake Modules In-Reply-To: References: Message-ID: <1442821031560-7591577.post@n2.nabble.com> I can't find a bug report on this. Is there one? Surely Cmake distributed modules should not generate this type of warnings. Or am I misinterpreting the messages? I'm encountering numerous such problems/warnings in Cmake distributed modules: CMake Warning (dev) at /usr/share/cmake-3.3.1/Modules/CMakeParseImplicitLinkInfo.cmake:58 (if): Policy CMP0054 is not set: Only interpret if() arguments as variables or keywords when unquoted. Run "cmake --help-policy CMP0054" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Quoted variables like "" will no longer be dereferenced when the policy is set to NEW. Since the policy is not set the OLD behavior will be used. Call Stack (most recent call first): /usr/share/cmake-3.3.1/Modules/CMakeDetermineCompilerABI.cmake:80 (CMAKE_PARSE_IMPLICIT_LINK_INFO) /usr/share/cmake-3.3.1/Modules/CMakeTestCXXCompiler.cmake:68 (CMAKE_DETERMINE_COMPILER_ABI) src/CMakeLists.txt:2 (project) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.3.1/Modules/CMakeParseImplicitLinkInfo.cmake:39 (if): Policy CMP0054 is not set: Only interpret if() arguments as variables or keywords when unquoted. Run "cmake --help-policy CMP0054" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Quoted variables like "" will no longer be dereferenced when the policy is set to NEW. Since the policy is not set the OLD behavior will be used. Call Stack (most recent call first): /usr/share/cmake-3.3.1/Modules/CMakeDetermineCompilerABI.cmake:80 (CMAKE_PARSE_IMPLICIT_LINK_INFO) /usr/share/cmake-3.3.1/Modules/CMakeTestCXXCompiler.cmake:68 (CMAKE_DETERMINE_COMPILER_ABI) src/CMakeLists.txt:2 (project) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.3.1/Modules/CMakeParseImplicitLinkInfo.cmake:100 (elseif): Policy CMP0054 is not set: Only interpret if() arguments as variables or keywords when unquoted. Run "cmake --help-policy CMP0054" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Quoted variables like "" will no longer be dereferenced when the policy is set to NEW. Since the policy is not set the OLD behavior will be used. Call Stack (most recent call first): /usr/share/cmake-3.3.1/Modules/CMakeDetermineCompilerABI.cmake:80 (CMAKE_PARSE_IMPLICIT_LINK_INFO) /usr/share/cmake-3.3.1/Modules/CMakeTestCXXCompiler.cmake:68 (CMAKE_DETERMINE_COMPILER_ABI) src/CMakeLists.txt:2 (project) This warning is for project developers. Use -Wno-dev to suppress it. -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Warning (dev) at /usr/share/cmake-3.3.1/Modules/CTest.cmake:96 (if): Policy CMP0054 is not set: Only interpret if() arguments as variables or keywords when unquoted. Run "cmake --help-policy CMP0054" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Quoted variables like "" will no longer be dereferenced when the policy is set to NEW. Since the policy is not set the OLD behavior will be used. Call Stack (most recent call first): /usr/share/cmake-3.3.1/Modules/CTest.cmake:106 (SET_IF_SET_AND_NOT_SET) cmake/Modules/MacroAddUnitTest.cmake:10 (include) CMakeLists.txt:64 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at /usr/share/cmake-3.3.1/Modules/CTest.cmake:251 (if): Policy CMP0054 is not set: Only interpret if() arguments as variables or keywords when unquoted. Run "cmake --help-policy CMP0054" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Quoted variables like "" will no longer be dereferenced when the policy is set to NEW. Since the policy is not set the OLD behavior will be used. Call Stack (most recent call first): cmake/Modules/MacroAddUnitTest.cmake:10 (include) CMakeLists.txt:64 (include) This warning is for project developers. Use -Wno-dev to suppress it. -- View this message in context: http://cmake.3232098.n2.nabble.com/CMP0054-and-CMake-Modules-tp7590137p7591577.html Sent from the CMake mailing list archive at Nabble.com. From thomas at junovagen.se Mon Sep 21 03:39:26 2015 From: thomas at junovagen.se (Thomas Nilsson) Date: Mon, 21 Sep 2015 09:39:26 +0200 Subject: [CMake] CMP0054 and CMake Modules In-Reply-To: <1442821031560-7591577.post@n2.nabble.com> References: <1442821031560-7591577.post@n2.nabble.com> Message-ID: <55FFB42E.20406@junovagen.se> Sorry, this turned out kind of brief, it was posted in context in Nabble. I'm seeing this on Cygwin. /Thomas > thoni56 > 21 september 2015 09:37 > I can't find a bug report on this. Is there one? > > Surely Cmake distributed modules should not generate this type of > warnings. > Or am I misinterpreting the messages? > > I'm encountering numerous such problems/warnings in Cmake distributed > modules: > > CMake Warning (dev) at > /usr/share/cmake-3.3.1/Modules/CMakeParseImplicitLinkInfo.cmake:58 (if): > Policy CMP0054 is not set: Only interpret if() arguments as variables or > keywords when unquoted. Run "cmake --help-policy CMP0054" for policy > details. Use the cmake_policy command to set the policy and suppress this > warning. > > Quoted variables like "" will no longer be dereferenced when the > policy is > set to NEW. Since the policy is not set the OLD behavior will be used. > Call Stack (most recent call first): > /usr/share/cmake-3.3.1/Modules/CMakeDetermineCompilerABI.cmake:80 > (CMAKE_PARSE_IMPLICIT_LINK_INFO) > /usr/share/cmake-3.3.1/Modules/CMakeTestCXXCompiler.cmake:68 > (CMAKE_DETERMINE_COMPILER_ABI) > src/CMakeLists.txt:2 (project) > This warning is for project developers. Use -Wno-dev to suppress it. > > CMake Warning (dev) at > /usr/share/cmake-3.3.1/Modules/CMakeParseImplicitLinkInfo.cmake:39 (if): > Policy CMP0054 is not set: Only interpret if() arguments as variables or > keywords when unquoted. Run "cmake --help-policy CMP0054" for policy > details. Use the cmake_policy command to set the policy and suppress this > warning. > > Quoted variables like "" will no longer be dereferenced when the > policy is > set to NEW. Since the policy is not set the OLD behavior will be used. > Call Stack (most recent call first): > /usr/share/cmake-3.3.1/Modules/CMakeDetermineCompilerABI.cmake:80 > (CMAKE_PARSE_IMPLICIT_LINK_INFO) > /usr/share/cmake-3.3.1/Modules/CMakeTestCXXCompiler.cmake:68 > (CMAKE_DETERMINE_COMPILER_ABI) > src/CMakeLists.txt:2 (project) > This warning is for project developers. Use -Wno-dev to suppress it. > > CMake Warning (dev) at > /usr/share/cmake-3.3.1/Modules/CMakeParseImplicitLinkInfo.cmake:100 > (elseif): > Policy CMP0054 is not set: Only interpret if() arguments as variables or > keywords when unquoted. Run "cmake --help-policy CMP0054" for policy > details. Use the cmake_policy command to set the policy and suppress this > warning. > > Quoted variables like "" will no longer be dereferenced when the > policy is > set to NEW. Since the policy is not set the OLD behavior will be used. > Call Stack (most recent call first): > /usr/share/cmake-3.3.1/Modules/CMakeDetermineCompilerABI.cmake:80 > (CMAKE_PARSE_IMPLICIT_LINK_INFO) > /usr/share/cmake-3.3.1/Modules/CMakeTestCXXCompiler.cmake:68 > (CMAKE_DETERMINE_COMPILER_ABI) > src/CMakeLists.txt:2 (project) > This warning is for project developers. Use -Wno-dev to suppress it. > > -- Detecting CXX compile features > -- Detecting CXX compile features - done > CMake Warning (dev) at /usr/share/cmake-3.3.1/Modules/CTest.cmake:96 > (if): > Policy CMP0054 is not set: Only interpret if() arguments as variables or > keywords when unquoted. Run "cmake --help-policy CMP0054" for policy > details. Use the cmake_policy command to set the policy and suppress this > warning. > > Quoted variables like "" will no longer be dereferenced when the > policy is > set to NEW. Since the policy is not set the OLD behavior will be used. > Call Stack (most recent call first): > /usr/share/cmake-3.3.1/Modules/CTest.cmake:106 (SET_IF_SET_AND_NOT_SET) > cmake/Modules/MacroAddUnitTest.cmake:10 (include) > CMakeLists.txt:64 (include) > This warning is for project developers. Use -Wno-dev to suppress it. > > CMake Warning (dev) at /usr/share/cmake-3.3.1/Modules/CTest.cmake:251 > (if): > Policy CMP0054 is not set: Only interpret if() arguments as variables or > keywords when unquoted. Run "cmake --help-policy CMP0054" for policy > details. Use the cmake_policy command to set the policy and suppress this > warning. > > Quoted variables like "" will no longer be dereferenced when the > policy is > set to NEW. Since the policy is not set the OLD behavior will be used. > Call Stack (most recent call first): > cmake/Modules/MacroAddUnitTest.cmake:10 (include) > CMakeLists.txt:64 (include) > This warning is for project developers. Use -Wno-dev to suppress it. > > > > -- > View this message in context: > http://cmake.3232098.n2.nabble.com/CMP0054-and-CMake-Modules-tp7590137p7591577.html > Sent from the CMake mailing list archive at Nabble.com. > Domen Vrankar > 26 mars 2015 10:48 > > ATM each CMake provided module has to set its own policies otherwise > policies from CMakeLists.txt minimum required version setting are > used. > Please file a bug report. > > Thanks, > Domen > J?rg Kreuzberger > 26 mars 2015 10:29 > Updated to cmake 3.2.1 from 3.0.0 and got several hints due to POLICY > CMP0054 (handling of quoted variables) > > i set the policy to new and changed my local cmake files. > > But i also got a warning from CMake Modules like FindMFC.cmake (Line 39). > > do i make something wrong or is this an Error in FindMFC which i have > to report? > > Can i assume that ALL Modules provided with normal cmake install > support this policy with NEW? > Currently i get no warning from other modules if policy is unset. > i also assume i can change the policy during cmake processing? > > (e.g. set the behaviour to old, include FindMFC.cmake, set the > behaviour to new and do the rest of my CMakeLists.txt) > > Thanks for any support, > Joerg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Sep 21 04:10:40 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 21 Sep 2015 10:10:40 +0200 Subject: [CMake] CMP0054 and CMake Modules In-Reply-To: <1442821031560-7591577.post@n2.nabble.com> References: <1442821031560-7591577.post@n2.nabble.com> Message-ID: <55FFBB80.3030903@gmail.com> On 09/21/2015 09:37 AM, thoni56 wrote: > Quoted variables like "" will no longer be dereferenced when the policy is You apparently have a variable whose name is the empty string. With the old (pre CMP0054) behavior this will break comparisons with empty strings take e.g. set("" foobar) set(MYVAR foobar) if(MYVAR STREQUAL "") message("unexpectedly true") endif() Where the if() comparison with old behavior will unexpectedly (for most authors of such conditions) evaluate true. With CMP0054's new behavior the same condition will evaluate false. Since most cmake provided modules have to work with both the old and new behavior a common work around is e.g. if("x${MYVAR}" STREQUAL "x") This workaround however only works if by convention there are no variables starting with a lower case x in their name. I think by that same reasoning you should avoid defining variables whose name is the empty string. Nils From thomas at junovagen.se Mon Sep 21 04:24:41 2015 From: thomas at junovagen.se (thoni56) Date: Mon, 21 Sep 2015 01:24:41 -0700 (MST) Subject: [CMake] CMP0054 and CMake Modules In-Reply-To: <55FFBB80.3030903@gmail.com> References: <1442821031560-7591577.post@n2.nabble.com> <55FFBB80.3030903@gmail.com> Message-ID: <1442823881550-7591580.post@n2.nabble.com> Aahh, I was looking at the trace and it only included "include":s so I thought that offending IF was in cmake's own files since it pointed there. But, you are saying that probably the culprit is a variable set before the first include, right? (It was definitely not by intention a variable was as having the empty name ;-). And if I look at /usr/share/cmake-3.3.1/Modules/CMakeParseImplicitLinkInfo.cmake:58 I should probably see the variable (or one that expands to include it)? /Thomas Nils Gladitz-2 wrote > On 09/21/2015 09:37 AM, thoni56 wrote: >> Quoted variables like "" will no longer be dereferenced when the >> policy is > > You apparently have a variable whose name is the empty string. > > ... > > Since most cmake provided modules have to work with both the old and new > behavior a common work around is e.g. > > if("x${MYVAR}" STREQUAL "x") > > This workaround however only works if by convention there are no > variables starting with a lower case x in their name. > > I think by that same reasoning you should avoid defining variables whose > name is the empty string. > > 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/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- View this message in context: http://cmake.3232098.n2.nabble.com/CMP0054-and-CMake-Modules-tp7590137p7591580.html Sent from the CMake mailing list archive at Nabble.com. From thomas at junovagen.se Mon Sep 21 04:46:31 2015 From: thomas at junovagen.se (thoni56) Date: Mon, 21 Sep 2015 01:46:31 -0700 (MST) Subject: [CMake] CMP0054 and CMake Modules In-Reply-To: <1442823881550-7591580.post@n2.nabble.com> References: <1442821031560-7591577.post@n2.nabble.com> <55FFBB80.3030903@gmail.com> <1442823881550-7591580.post@n2.nabble.com> Message-ID: <1442825191964-7591581.post@n2.nabble.com> Also, this does not happen on MacOSX with Macports cmake. But does on Cygwin. thoni56 wrote > > Nils Gladitz-2 wrote >> On 09/21/2015 09:37 AM, thoni56 wrote: >>> Quoted variables like "" will no longer be dereferenced when the >>> policy is >> >> You apparently have a variable whose name is the empty string. >> >> ... >> >> Since most cmake provided modules have to work with both the old and new >> behavior a common work around is e.g. >> >> if("x${MYVAR}" STREQUAL "x") >> >> This workaround however only works if by convention there are no >> variables starting with a lower case x in their name. >> >> I think by that same reasoning you should avoid defining variables whose >> name is the empty string. >> >> 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/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake -- View this message in context: http://cmake.3232098.n2.nabble.com/CMP0054-and-CMake-Modules-tp7590137p7591581.html Sent from the CMake mailing list archive at Nabble.com. From nilsgladitz at gmail.com Mon Sep 21 04:47:20 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 21 Sep 2015 10:47:20 +0200 Subject: [CMake] CMP0054 and CMake Modules In-Reply-To: <1442823881550-7591580.post@n2.nabble.com> References: <1442821031560-7591577.post@n2.nabble.com> <55FFBB80.3030903@gmail.com> <1442823881550-7591580.post@n2.nabble.com> Message-ID: <55FFC418.6090305@gmail.com> On 09/21/2015 10:24 AM, thoni56 wrote: > Aahh, I was looking at the trace and it only included "include":s so I > thought that offending IF was in cmake's own files since it pointed there. > > But, you are saying that probably the culprit is a variable set before the > first include, right? (It was definitely not by intention a variable was as > having the empty name ;-). The culprit is the empty named variable being set before the condition in that included module is evaluated, yes. If you aren't the one setting it it might also be accidentally set somewhere in cmake code of course. It probably isn't something as obvious as set("" foobar) but perhaps something like e.g. set("${MY_VAR_NAME}" foobar) (where MY_VAR_NAME is an unset variable e.g. due to typo or unexpected program logic). > > And if I look at > /usr/share/cmake-3.3.1/Modules/CMakeParseImplicitLinkInfo.cmake:58 I should > probably see the variable (or one that expands to include it)? The condition in that line is: if("${cmd}" MATCHES "${linker_regex}") So apparently ${cmd} expands empty (which may or may not be expected but is a distinct issue). With old behavior cmake will therefor look for a variable with the empty name and in your case finds and expands it. If you don't know where the empty named variable might come from I would expect cmake's new --trace-expand might be helpful. I haven't tried it myself yet and you would have to use a nightly build though since it hasn't made it into a release yet. Nils From randallsturner13 at gmail.com Mon Sep 21 08:38:41 2015 From: randallsturner13 at gmail.com (Randy Turner) Date: Mon, 21 Sep 2015 08:38:41 -0400 Subject: [CMake] Port from Debian to Windows: Include files not found In-Reply-To: References: Message-ID: Thanks for all of the input, everyone! Unfortunately the problem still persists. I don't have much to report this morning. I've removed the calls to build the assembly file and confirmed that it is an ASM vs C issue as opposed to an ordering issue. It continued to attempt to build the C file without calls to include relevant directories and fails at the first include. On Fri, Sep 18, 2015 at 3:49 PM, Pau Garcia i Quiles wrote: > Hello, > > You may need something like this in the toolchain file: > > # search for programs in the build host directories > SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) > > # for libraries and headers in the target directories > SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH) > SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH) > > set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) > > > On Fri, Sep 18, 2015 at 7:22 PM, Randy Turner > wrote: > >> I am having trouble building a Code Composer Studio project with CMake. >> Executing from the same directory in Linux compiles successfully, but in >> Linux it fails to find any included files that aren't in the same directory >> as the .c file that it's building. I can provide a relative path to help it >> move on, but it will just fail to find the files referenced by that one. >> >> The very first #include of the project is which is located in >> the compiler's install files. As shown in my StackOVerflow question about >> this issue ( >> http://stackoverflow.com/questions/32591626/cmake-header-files-cannot-be-opened) >> I can confirm that the files are in the directory that is included in the >> CMakeLists.txt file and can be found while CMake is executing, but fail to >> be located by make. I am using MinGW's make, and using the commands make >> and mingw32-make both ellicit the same result, "fatal error: could not open >> source file "stdbool.h" (no directories in search list)." >> >> Is there something that I'm missing here? Is something else necessary >> beyond using INCLUDE_DIRECTORIES for all of the directories in the project? >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.custin at hpe.com Mon Sep 21 10:17:15 2015 From: jay.custin at hpe.com (Custin, Jay (CSC Sw Middleware)) Date: Mon, 21 Sep 2015 14:17:15 +0000 Subject: [CMake] Continued issues in trying to get CMake working on OpenVMS Message-ID: So I ran into a few minor issues compiling/linking the CMake images (compiler threw a few "warnings" which didn't really prove significant so I simply "silenced" the warnings to enable the code to compile clean and link). I accomplished this with the following: bash$ export CFLAGS="-Wc/warnings=disable=all" bash$ export CXXFLAGS="-Wc/warnings=disable=all" bash$ ./configure The bootstrap "happily" compiles and links ALL the code without any issues... but then CMake does some self-evaluation and things get very ugly... very fast. For whatever reason the bootstrap has no issues "finding" the various C/C++ header files to compile and link the CMake source... but when the "interim" CMake itself then tries to find them... complete and utter failure. At present I have what I would call the "interim" version of CMake built (which at this phase requires adding the option -DCMAKE_BOOTSTRAP=1 on the end of the cmake command to do much of anything). I have included an abbreviated version of this build below: bash$ export CFLAGS="-Wc/warnings=disable=all" bash$ export CXXFLAGS="-Wc/warnings=disable=all" bash$ ./configure --system-curl --system-zlib --verbose --init=BuildCMakeOpenVMS_CacheFlags.cmake --------------------------------------------- Source directory: /PRJ_ROOT/CMAKE-3_3_1 Binary directory: /PRJ_ROOT/CMAKE-3_3_1 Prefix directory: /usr/local System: OpenVMS --------------------------------------------- CMake 3.3.1, Copyright 2000-2015 Kitware, Inc. C compiler on this system is: cc -Wc/warnings=disable=all C++ compiler on this system is: CXX -Wc/warnings=disable=all %DCL-E-PARSEFAIL, error parsing DCL$PATH:"cc".* -RMS-F-FNM, error in file name Makefile processor on this system is: make %DCL-E-NOTFR, no transfer address CXX is not GNU compiler %DCL-E-NOTFR, no transfer address CXX is not SolarisStudio compiler CXX has setenv CXX has unsetenv CXX does not have environ in stdlib.h CXX has STL in std:: namespace CXX has ANSI streams CXX has streams in std:: namespace CXX has sstream CXX has operator!=(string, char*) CXX has stl iterator_traits CXX has standard template allocator CXX has allocator<>::rebind<> CXX does not have non-standard allocator<>::max_size argument CXX has stl containers supporting allocator objects CXX has stl wstring CXX has header cstddef CXX does not require template friends to use <> CXX supports member templates CXX has standard template specialization syntax CXX has argument dependent lookup CXX does not have struct stat with st_mtim member CXX has ios::binary openmode --------------------------------------------- CXX -Wc/warnings=disable=all -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -I/PRJ_ROOT/CMAKE-3_3_1/Source -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -c /PRJ_ROOT/CMAKE-3_3_1/Source/cmake.cxx -o cmake.o CXX -Wc/warnings=disable=all -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -I/PRJ_ROOT/CMAKE-3_3_1/Source -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -c /PRJ_ROOT/CMAKE-3_3_1/Source/cmakemain.cxx -o cmakemain.o CXX -Wc/warnings=disable=all -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -I/PRJ_ROOT/CMAKE-3_3_1/Source -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -c /PRJ_ROOT/CMAKE-3_3_1/Source/cmcmd.cxx -o cmcmd.o <> <> <> cc -Wc/warnings=disable=all -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -I/PRJ_ROOT/CMAKE-3_3_1/Source -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -DKWSYS_NAMESPACE=cmsys -c /PRJ_ROOT/CMAKE-3_3_1/Source/kwsys/Terminal.c -o Terminal.o CXX -Wc/warnings=disable=all -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk -I/PRJ_ROOT/CMAKE-3_3_1/Source -I/PRJ_ROOT/CMAKE-3_3_1/Bootstrap_cmk cmake.o cmakemain.o cmcmd.o cmCommandArgumentLexer.o cmCommandArgumentParser.o cmCommandArgumentParserHelper.o cmCPackPrope rtiesGenerator.o cmDefinitions.o cmDepends.o cmDependsC.o cmDocumentationFormatter.o cmPolicies.o cmProperty.o cmPropertyMap.o cmPro pertyDefinition.o cmPropertyDefinitionMap.o cmMakeDepend.o cmMakefile.o cmExportFileGenerator.o cmExportInstallFileGenerator.o cmExp ortTryCompileFileGenerator.o cmExportSet.o cmExportSetMap.o cmExternalMakefileProjectGenerator.o cmGeneratorExpressionEvaluationFile .o cmGeneratedFileStream.o cmGeneratorTarget.o cmGeneratorExpressionContext.o cmGeneratorExpressionDAGChecker.o cmGeneratorExpressio nEvaluator.o cmGeneratorExpressionLexer.o cmGeneratorExpressionNode.o cmGeneratorExpressionParser.o cmGeneratorExpression.o cmGlobal Generator.o cmInstallDirectoryGenerator.o cmLocalGenerator.o cmInstalledFile.o cmInstallGenerator.o cmInstallExportGenerator.o cmIns tallFilesGenerator.o cmInstallScriptGenerator.o cmInstallTargetGenerator.o cmScriptGenerator.o cmSourceFile.o cmSourceFileLocation.o cmState.o cmSystemTools.o cmTestGenerator.o cmVersion.o cmFileTimeComparison.o cmGlobalUnixMakefileGenerator3.o cmLocalUnixMakefile Generator3.o cmMakefileExecutableTargetGenerator.o cmMakefileLibraryTargetGenerator.o cmMakefileTargetGenerator.o cmMakefileUtilityT argetGenerator.o cmOSXBundleGenerator.o cmNewLineStyle.o cmBootstrapCommands1.o cmBootstrapCommands2.o cmCommandsForBootstrap.o cmTa rget.o cmTest.o cmCustomCommand.o cmCustomCommandGenerator.o cmCacheManager.o cmListFileCache.o cmComputeLinkDepends.o cmComputeLink Information.o cmOrderDirectories.o cmComputeTargetDepends.o cmComputeComponentGraph.o cmExprLexer.o cmExprParser.o cmExprParserHelpe r.o cmGlobalNinjaGenerator.o cmLocalNinjaGenerator.o cmNinjaTargetGenerator.o cmNinjaNormalTargetGenerator.o cmNinjaUtilityTargetGen erator.o cmListFileLexer.o Directory.o EncodingCXX.o FStream.o Glob.o RegularExpression.o SystemTools.o EncodingC.o ProcessUNIX.o St ring.o System.o Terminal.o -o cmake <> <> now the self-testing phase begins... and the responses become things like "no", "not found", failed,... <> -- Checking if compiler supports C++11 unordered_map -- Checking if compiler supports C++11 unordered_map - no -- Looking for unsetenv -- Looking for unsetenv - not found -- Looking for environ -- Looking for environ - not found -- Checking whether header cstdio is available -- Checking whether header cstdio is available - no -- Checking for Large File Support -- Checking for Large File Support - failed to compile -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - no -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - no -- Checking whether strstream.h is available -- Checking whether strstream.h is available - no -- Checking whether strstrea.h is available -- Checking whether strstrea.h is available - no -- Checking whether header cstddef is available -- Checking whether header cstddef is available - no -- Checking whether stl string has operator!= for char* -- Checking whether stl string has operator!= for char* - no -- Checking whether stl has iterator_traits -- Checking whether stl has iterator_traits - no -- Checking whether stl has old iterator_category -- Checking whether stl has old iterator_category - no -- Checking whether stl has internal __iterator_category -- Checking whether stl has internal __iterator_category - no -- Checking whether stl has standard template allocator -- Checking whether stl has standard template allocator - no -- Checking whether stl has old non-template allocator -- Checking whether stl has old non-template allocator - no -- Checking whether stl containers support allocator objects. -- Checking whether stl containers support allocator objects. - no -- Checking whether stl string has ostream operator<< -- Checking whether stl string has ostream operator<< - no -- Checking whether stl string has istream operator>> -- Checking whether stl string has istream operator>> - no -- Checking whether ios has binary openmode -- Checking whether ios has binary openmode - no -- Checking whether "<>" is needed for template friends -- Checking whether "<>" is needed for template friends - yes -- Checking for member template support -- Checking for member template support - no -- Checking for standard template specialization syntax -- Checking for standard template specialization syntax - no -- Checking whether argument dependent lookup is supported -- Checking whether argument dependent lookup is supported - no -- Checking whether struct stat has st_mtim member -- Checking whether struct stat has st_mtim member - no -- Checking whether C++ compiler has 'long long' -- Checking whether C++ compiler has 'long long' - no -- Checking whether C++ compiler has '__int64' -- Checking whether C++ compiler has '__int64' - no -- Checking for C type size macros -- Checking for C type size macros - failed -- Looking for sys/types.h -- Looking for sys/types.h - not found -- Looking for stdint.h -- Looking for stdint.h - not found -- Looking for stddef.h -- Looking for stddef.h - not found -- Check size of char -- Check size of char - failed -- Check size of short -- Check size of short - failed -- Check size of int -- Check size of int - failed On and on it goes. This gets made even more frustrating in that it appears that the testing phase does a VERY good job cleaning up after itself... I had to go in to the files, insert a series of MESSAGE statements to display the code it would try to build, then manually generate one of the files which it said failed to compile... but then I could manually compile and link from the very same Bash shell without any issue. So the very headers that the configure/bootstrap used to compile and link the CMake images... it then can't find when it RUNS its tests using those same images. I figure that it MAY have something to do with something like the following: Modules/CheckIncludeFile.cmake Modules/ CheckIncludeFileCXX.cmake Anyone have any suggestions? Any ideas on how to get how to get the partially built image (the initial image that requires passing -DCMAKE_BOOTSTRAP=1 to run) to NOT clean up after itself? I figure this might help me discern where things have got haywire. JayC From d3ck0r at gmail.com Mon Sep 21 10:50:16 2015 From: d3ck0r at gmail.com (J Decker) Date: Mon, 21 Sep 2015 07:50:16 -0700 Subject: [CMake] How to create a custom solution with Visual Studio 2010 generator? In-Reply-To: References: Message-ID: CMake's PROJECT directive maps to 'Solution' (should only be one project() per chain) ... use set( PROJECT projectname) and then reference ${PROJECT} later instead of ${PROJECT_NAME} for easy conversion. add_library, add_executable map to 'project' from http://www.cmake.org/Wiki/CMake_Useful_Variables you can wrap the projects you want to omit with If's if( NOT MSVC10 ) add_library( one I don't want in 2010) endif( NOT MSVC10 ) On Sun, Sep 20, 2015 at 11:20 PM, Golebiewski, Jakub wrote: > Hi, > > > > I?m trying to create a solution with custom set of projects (in VS sense) > for Visual Studio 2010. > > I have a top level CMakeLists.txt with PROJECT() declared and then several > CMakeLists.txt below in a tree also with PROJECT() in each of them. > > However for lower level PROJECT() directives I get all the targets that I > specify in CMakeLists.txt and all the targets that they depend on. > > > > My goal is to have a solution only with a specific set of targets, without > dependencies. > > > > Is there a way to do that in cmake? > > > > Thanks for help, > > Jakub > > > ************************************************************************************** > This e-mail and any attachments thereto may contain confidential information > and/or information protected by intellectual property rights for the > exclusive attention of the intended addressees named above. If you have > received this transmission in error, please immediately notify the sender by > return e-mail and delete this message and its attachments. Unauthorized use, > copying or further full or partial distribution of this e-mail or its > contents is prohibited. > ************************************************************************************** > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From bill.hoffman at kitware.com Mon Sep 21 10:55:27 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon, 21 Sep 2015 10:55:27 -0400 Subject: [CMake] Continued issues in trying to get CMake working on OpenVMS In-Reply-To: References: Message-ID: <56001A5F.2050908@kitware.com> On 9/21/2015 10:17 AM, Custin, Jay (CSC Sw Middleware) wrote: > This gets made even more frustrating in that it appears that the > testing phase does a VERY good job cleaning up after itself... So, the output should all be in CMakeOutput.log and CMakeError.log found in the build tree in the CMakeFiles directory. If you want CMake not to delete the temp files you can use --debug-trycompile http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html -Bill From jay.custin at hpe.com Mon Sep 21 11:29:11 2015 From: jay.custin at hpe.com (Custin, Jay (CSC Sw Middleware)) Date: Mon, 21 Sep 2015 15:29:11 +0000 Subject: [CMake] Continued issues in trying to get CMake working on OpenVMS In-Reply-To: <56001A5F.2050908@kitware.com> References: <56001A5F.2050908@kitware.com> Message-ID: I will try adding that option and see what it may reveal... the output contained in the CMakeOutput.log and CMakeError.log offered nothing other than politely telling me the test failed. -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Bill Hoffman Sent: Monday, September 21, 2015 10:55 AM To: cmake at cmake.org Subject: Re: [CMake] Continued issues in trying to get CMake working on OpenVMS On 9/21/2015 10:17 AM, Custin, Jay (CSC Sw Middleware) wrote: > This gets made even more frustrating in that it appears that the > testing phase does a VERY good job cleaning up after itself... So, the output should all be in CMakeOutput.log and CMakeError.log found in the build tree in the CMakeFiles directory. If you want CMake not to delete the temp files you can use --debug-trycompile http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake From bill.hoffman at kitware.com Mon Sep 21 11:36:59 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon, 21 Sep 2015 11:36:59 -0400 Subject: [CMake] Continued issues in trying to get CMake working on OpenVMS In-Reply-To: References: <56001A5F.2050908@kitware.com> Message-ID: <5600241B.906@kitware.com> On 9/21/2015 11:29 AM, Custin, Jay (CSC Sw Middleware) wrote: > I will try adding that option and see what it may reveal... the > output contained in the CMakeOutput.log and CMakeError.log offered > nothing other than politely telling me the test failed. That is odd... It should have the stderr/stdout. There maybe some issue with that. Can you send me those files off the list? You may want to create a small project to test the flag. Then use the bootstraped cmake to configure it with the --debug-trycompile. -Bill From tom.kacvinsky at vectorcast.com Mon Sep 21 17:37:44 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Mon, 21 Sep 2015 17:37:44 -0400 Subject: [CMake] add(library foo SHARED...) is not creating a PDB file Message-ID: I am using cmake 2.8.11.2 on Windows 7 with Visual Studio 2008 This is the snipped of my CMakeLists.txt file add_library(commoncpp_objects OBJECT ) add_library(commoncpp_static STATIC $) add_dependencies(commoncpp_static commoncpp_objects) add_library(commoncpp SHARED $ commoncpp_exports.def ) The objects, static library, and dll/import lib/exp files are created, but there is no commoncpp.pdb file. Any ideas what I am doing wrong? Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jakub.Golebiewski at dnvgl.com Tue Sep 22 01:39:15 2015 From: Jakub.Golebiewski at dnvgl.com (Golebiewski, Jakub) Date: Tue, 22 Sep 2015 05:39:15 +0000 Subject: [CMake] How to create a custom solution with Visual Studio 2010 generator? In-Reply-To: References: Message-ID: This may be a solution, I will check this asap. This should be clearer, I have something like this: Main Project - PROJECT() \Sub Project 1 - PROJECT() \target 1 - ADD_LIBRARY() \target 2 - ADD_LIBRARY() \Sub Project 2 - PROJECT() \target 3 - ADD_LIBRARY() \target 4 - ADD_LIBRARY() \Sub Project 3 - PROJECT() \target 5 - ADD_LIBRARY() \target 6 - ADD_LIBRARY() Targets 5 and 6 depend on 1, 2, 3 and 4. Now when I run cmake on Main Project I will get .sln files for Main Project and each Sub Project. .sln file for Sub Project 3 will contain all the targets (So I will get .sln with projects for target 1 ? 6 in VS terminology). What I need to have is for Sub Project 3 to have only target 5 and target 6 in .sln without dependencies from other Sub Projects. So I worry that with your solution I will get unknown targets error? Is there any way to ignore missing targets errors? Thanks for help, JG -----Original Message----- From: J Decker [mailto:d3ck0r at gmail.com] Sent: Monday, September 21, 2015 4:50 PM To: Golebiewski, Jakub Cc: cmake at cmake.org Subject: Re: [CMake] How to create a custom solution with Visual Studio 2010 generator? CMake's PROJECT directive maps to 'Solution' (should only be one project() per chain) ... use set( PROJECT projectname) and then reference ${PROJECT} later instead of ${PROJECT_NAME} for easy conversion. add_library, add_executable map to 'project' from http://www.cmake.org/Wiki/CMake_Useful_Variables you can wrap the projects you want to omit with If's if( NOT MSVC10 ) add_library( one I don't want in 2010) endif( NOT MSVC10 ) On Sun, Sep 20, 2015 at 11:20 PM, Golebiewski, Jakub wrote: > Hi, > > > > I?m trying to create a solution with custom set of projects (in VS > sense) for Visual Studio 2010. > > I have a top level CMakeLists.txt with PROJECT() declared and then > several CMakeLists.txt below in a tree also with PROJECT() in each of them. > > However for lower level PROJECT() directives I get all the targets > that I specify in CMakeLists.txt and all the targets that they depend on. > > > > My goal is to have a solution only with a specific set of targets, > without dependencies. > > > > Is there a way to do that in cmake? > > > > Thanks for help, > > Jakub > > > ********************************************************************** > **************** This e-mail and any attachments thereto may contain > confidential information and/or information protected by intellectual > property rights for the exclusive attention of the intended addressees > named above. If you have received this transmission in error, please > immediately notify the sender by return e-mail and delete this message > and its attachments. Unauthorized use, copying or further full or > partial distribution of this e-mail or its contents is prohibited. > ********************************************************************** > **************** > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake ************************************************************************************** This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited. ************************************************************************************** From d3ck0r at gmail.com Tue Sep 22 02:12:08 2015 From: d3ck0r at gmail.com (J Decker) Date: Mon, 21 Sep 2015 23:12:08 -0700 Subject: [CMake] How to create a custom solution with Visual Studio 2010 generator? In-Reply-To: References: Message-ID: On Mon, Sep 21, 2015 at 10:39 PM, Golebiewski, Jakub wrote: > This may be a solution, I will check this asap. > > This should be clearer, I have something like this: > > Main Project - PROJECT() > \Sub Project 1 - PROJECT() > \target 1 - ADD_LIBRARY() > \target 2 - ADD_LIBRARY() > \Sub Project 2 - PROJECT() > \target 3 - ADD_LIBRARY() > \target 4 - ADD_LIBRARY() > \Sub Project 3 - PROJECT() > \target 5 - ADD_LIBRARY() > \target 6 - ADD_LIBRARY() > > Targets 5 and 6 depend on 1, 2, 3 and 4. > > Now when I run cmake on Main Project I will get .sln files for Main Project and each Sub Project. > .sln file for Sub Project 3 will contain all the targets (So I will get .sln with projects for target 1 ? 6 in VS terminology). > What I need to have is for Sub Project 3 to have only target 5 and target 6 in .sln without dependencies from other Sub Projects. > > So I worry that with your solution I will get unknown targets error? Is there any way to ignore missing targets errors? > For each invokation of cmake you only get one .sln file. It's name comes from the last PROJECT in the root CMakeLists.txt If you run cmake for each subproject I suppose one could set a variable like IF( NOT PROJECT_ROOT ) SET( PROJECT_ROOT SomeName ) ENDIF() and later test if( PROJECT_ROOT STREQUAL SomeName ) add_subdirectory( "../Sub Project3" Sub3 ) endif() or the not of that and don't include the others... and the root would unconditionally add_subdirectory for all of those... I'd probably just make like OPTION( BUILD_EXTRAS "enable building extras" OFF ) in the root and test for BUILD_EXTRAS to include other things... and make them cmake configuration options that would show as check boxes in cmake-gui. In my case I have a core set of libraries that get built and then various projects that use those libraries. I build it in two steps in two separate build directories using two separate cmake invoations... and then I have a super-project that can build the core plus all extras in one fell swoop by just building each one. (uses custom macro that's a few dozen lines to do each build) > Thanks for help, > JG > > -----Original Message----- > From: J Decker [mailto:d3ck0r at gmail.com] > Sent: Monday, September 21, 2015 4:50 PM > To: Golebiewski, Jakub > Cc: cmake at cmake.org > Subject: Re: [CMake] How to create a custom solution with Visual Studio 2010 generator? > > CMake's PROJECT directive maps to 'Solution' (should only be one > project() per chain) ... use set( PROJECT projectname) and then reference ${PROJECT} later instead of ${PROJECT_NAME} for easy conversion. > > add_library, add_executable map to 'project' > > from http://www.cmake.org/Wiki/CMake_Useful_Variables > > you can wrap the projects you want to omit with If's > > if( NOT MSVC10 ) > add_library( one I don't want in 2010) endif( NOT MSVC10 ) > > > > > On Sun, Sep 20, 2015 at 11:20 PM, Golebiewski, Jakub wrote: >> Hi, >> >> >> >> I?m trying to create a solution with custom set of projects (in VS >> sense) for Visual Studio 2010. >> >> I have a top level CMakeLists.txt with PROJECT() declared and then >> several CMakeLists.txt below in a tree also with PROJECT() in each of them. >> >> However for lower level PROJECT() directives I get all the targets >> that I specify in CMakeLists.txt and all the targets that they depend on. >> >> >> >> My goal is to have a solution only with a specific set of targets, >> without dependencies. >> >> >> >> Is there a way to do that in cmake? >> >> >> >> Thanks for help, >> >> Jakub >> >> >> ********************************************************************** >> **************** This e-mail and any attachments thereto may contain >> confidential information and/or information protected by intellectual >> property rights for the exclusive attention of the intended addressees >> named above. If you have received this transmission in error, please >> immediately notify the sender by return e-mail and delete this message >> and its attachments. Unauthorized use, copying or further full or >> partial distribution of this e-mail or its contents is prohibited. >> ********************************************************************** >> **************** >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For >> more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > > ************************************************************************************** > This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited. > ************************************************************************************** From Jakub.Golebiewski at dnvgl.com Tue Sep 22 02:49:57 2015 From: Jakub.Golebiewski at dnvgl.com (Golebiewski, Jakub) Date: Tue, 22 Sep 2015 06:49:57 +0000 Subject: [CMake] How to create a custom solution with Visual Studio 2010 generator? In-Reply-To: References: Message-ID: > -----Original Message----- > From: J Decker [mailto:d3ck0r at gmail.com] > Sent: Tuesday, September 22, 2015 8:12 AM > To: Golebiewski, Jakub > Cc: cmake at cmake.org > Subject: Re: [CMake] How to create a custom solution with Visual Studio > 2010 generator? > > On Mon, Sep 21, 2015 at 10:39 PM, Golebiewski, Jakub > wrote: > > This may be a solution, I will check this asap. > > > > This should be clearer, I have something like this: > > > > Main Project - PROJECT() > > \Sub Project 1 - PROJECT() > > \target 1 - ADD_LIBRARY() > > \target 2 - ADD_LIBRARY() > > \Sub Project 2 - PROJECT() > > \target 3 - ADD_LIBRARY() > > \target 4 - ADD_LIBRARY() > > \Sub Project 3 - PROJECT() > > \target 5 - ADD_LIBRARY() > > \target 6 - ADD_LIBRARY() > > > > Targets 5 and 6 depend on 1, 2, 3 and 4. > > > > Now when I run cmake on Main Project I will get .sln files for Main Project > and each Sub Project. > > .sln file for Sub Project 3 will contain all the targets (So I will get .sln with > projects for target 1 ? 6 in VS terminology). > > What I need to have is for Sub Project 3 to have only target 5 and target 6 > in .sln without dependencies from other Sub Projects. > > > > So I worry that with your solution I will get unknown targets error? Is there > any way to ignore missing targets errors? > > > > For each invokation of cmake you only get one .sln file. It's name comes When I run cmake on Main Project I get .sln for the Main Project and every Sub Project. > from the last PROJECT in the root CMakeLists.txt If you run cmake for each > subproject I suppose one could set a variable like I've tried running cmake independently for each subproject but I get errors about unknown Targets since every Sub Project depends on targets from 'earlier' one. I have about 620 targets (VS projects) so when I open Main Project.sln (with 620 projects) in VS it is impossible to work with. Currently cmake produces .sln for each Sub Project but includes dependencies from other projects and that's something I don?t want Since the amount of projects in each .sln increases the further I go and most of them (later in the dependency chain) are not possible to work with either. I'm trying to divide it into .slns that developers could work with in VS. > > IF( NOT PROJECT_ROOT ) > SET( PROJECT_ROOT SomeName ) > ENDIF() > > and later test > if( PROJECT_ROOT STREQUAL SomeName ) > add_subdirectory( "../Sub Project3" Sub3 ) > endif() > > or the not of that and don't include the others... > > and the root would unconditionally add_subdirectory for all of those... > > I'd probably just make like > OPTION( BUILD_EXTRAS "enable building extras" OFF ) in the root and test > for BUILD_EXTRAS to include other things... and make them cmake > configuration options that would show as check boxes in cmake-gui. > > In my case I have a core set of libraries that get built and then various > projects that use those libraries. I build it in two steps in two separate build > directories using two separate cmake invoations... > and then I have a super-project that can build the core plus all extras in one > fell swoop by just building each one. (uses custom macro that's a few dozen > lines to do each build) > > > > > Thanks for help, > > JG > > > > -----Original Message----- > > From: J Decker [mailto:d3ck0r at gmail.com] > > Sent: Monday, September 21, 2015 4:50 PM > > To: Golebiewski, Jakub > > Cc: cmake at cmake.org > > Subject: Re: [CMake] How to create a custom solution with Visual Studio > 2010 generator? > > > > CMake's PROJECT directive maps to 'Solution' (should only be one > > project() per chain) ... use set( PROJECT projectname) and then reference > ${PROJECT} later instead of ${PROJECT_NAME} for easy conversion. > > > > add_library, add_executable map to 'project' > > > > from http://www.cmake.org/Wiki/CMake_Useful_Variables > > > > you can wrap the projects you want to omit with If's > > > > if( NOT MSVC10 ) > > add_library( one I don't want in 2010) endif( NOT MSVC10 ) > > > > > > > > > > On Sun, Sep 20, 2015 at 11:20 PM, Golebiewski, Jakub > wrote: > >> Hi, > >> > >> > >> > >> I?m trying to create a solution with custom set of projects (in VS > >> sense) for Visual Studio 2010. > >> > >> I have a top level CMakeLists.txt with PROJECT() declared and then > >> several CMakeLists.txt below in a tree also with PROJECT() in each of > them. > >> > >> However for lower level PROJECT() directives I get all the targets > >> that I specify in CMakeLists.txt and all the targets that they depend on. > >> > >> > >> > >> My goal is to have a solution only with a specific set of targets, > >> without dependencies. > >> > >> > >> > >> Is there a way to do that in cmake? > >> > >> > >> > >> Thanks for help, > >> > >> Jakub > >> > >> > >> > ******************************************************************* > ** > >> * > >> **************** This e-mail and any attachments thereto may contain > >> confidential information and/or information protected by intellectual > >> property rights for the exclusive attention of the intended > >> addressees named above. If you have received this transmission in > >> error, please immediately notify the sender by return e-mail and > >> delete this message and its attachments. Unauthorized use, copying or > >> further full or partial distribution of this e-mail or its contents is > prohibited. > >> > ******************************************************************* > ** > >> * > >> **************** > >> > >> -- > >> > >> Powered by www.kitware.com > >> > >> Please keep messages on-topic and check the CMake FAQ at: > >> http://www.cmake.org/Wiki/CMake_FAQ > >> > >> Kitware offers various services to support the CMake community. For > >> more information on each offering, please visit: > >> > >> CMake Support: http://cmake.org/cmake/help/support.html > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/cmake > > > > > ******************************************************************* > *** > > **************** This e-mail and any attachments thereto may contain > > confidential information and/or information protected by intellectual > property rights for the exclusive attention of the intended addressees > named above. If you have received this transmission in error, please > immediately notify the sender by return e-mail and delete this message > and its attachments. Unauthorized use, copying or further full or partial > distribution of this e-mail or its contents is prohibited. > > > ******************************************************************* > *** > > **************** ************************************************************************************** This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited. ************************************************************************************** From d3ck0r at gmail.com Tue Sep 22 03:40:04 2015 From: d3ck0r at gmail.com (J Decker) Date: Tue, 22 Sep 2015 00:40:04 -0700 Subject: [CMake] How to create a custom solution with Visual Studio 2010 generator? In-Reply-To: References: Message-ID: > I've tried running cmake independently for each subproject but I get errors about unknown > Targets since every Sub Project depends on targets from 'earlier' one. > > I have about 620 targets (VS projects) so when I open Main Project.sln (with 620 projects) in VS it is impossible to work with. > Currently cmake produces .sln for each Sub Project but includes dependencies from other projects and that's something I don?t want > Since the amount of projects in each .sln increases the further I go and most of them (later in the dependency chain) are not possible to work > with either. I'm trying to divide it into .slns that developers could work with in VS. > Hmm; I was going to check to see if .sln's were made in subdirs... and they are... wonder if it was always taht way. But... the projects deeper in the tree only have those things that it depended on... so I don't get why you say 'the amount of projects increases the further you go' Yes... high level projects will have all of their dependancies but nothing extra... isn't it already making the minimal solutions you're suggesting you make by hand anyway? Other than as I use this; the Install rule in the sub-solution doesn't install everything... could wish the OutputPath cmake built was relative to the solution instead of the projects... then at least nothing funky would have to be done to run applications from the debugger; other than data resources could still be missing. From post at hendrik-sattler.de Tue Sep 22 05:46:20 2015 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Tue, 22 Sep 2015 11:46:20 +0200 Subject: [CMake] How to create a custom solution with Visual Studio 2010 generator? In-Reply-To: References: Message-ID: Hi, Am 22. September 2015 08:49:57 MESZ, schrieb "Golebiewski, Jakub" : >I have about 620 targets (VS projects) so when I open Main Project.sln >(with 620 projects) in VS it is impossible to work with. >Currently cmake produces .sln for each Sub Project but includes >dependencies from other projects and that's something I don?t want >Since the amount of projects in each .sln increases the further I go >and most of them (later in the dependency chain) are not possible to >work >with either. I'm trying to divide it into .slns that developers could >work with in VS. That is exactly what imported targets are for. However, they refer to already built projects. I'd also suggest a two-step approach: first configure and build the thing with all projects in the solution. The libraries need to create cmake build tree export config files. After that step, define a cmake variable to switch to using the previously created export config files only. These create the imported targets and don't show up in the IDE. HS From Pere.Mato at cern.ch Tue Sep 22 06:18:41 2015 From: Pere.Mato at cern.ch (Pere Mato Vila) Date: Tue, 22 Sep 2015 10:18:41 +0000 Subject: [CMake] Does CMake 3.3.1 ignore CXX env variable on OSX10.10? Message-ID: Hi, On previous versions I was setting the variables CC and CXX to force the compiler. This is not working anymore. Is this intended? Cheers, Pere ??????? macitois13:test sftnight$ cmake --version cmake version 3.3.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). macitois13:test sftnight$ echo $CXX /usr/bin/clang++ macitois13:test sftnight$ cmake . -- The CXX compiler identification is AppleClang 6.1.0.6020053 -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done CMAKE_CXX_COMPILER=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- Configuring done -- Generating done -- Build files have been written to: /build/jenkins/workspace/root-release-6.04/BUILDTYPE/Release/COMPILER/native/LABEL/mac1010/build/test ------------------------------------------------------------- Pere Mato CERN, PH Department, CH 1211 Geneva 23, Switzerland e-mail: pere.mato at cern.ch tel: +41 22 76 78696 fax: +41 22 76 68792 gsm: +41 75 41 10855 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bmorgan.warwick at gmail.com Tue Sep 22 08:02:55 2015 From: bmorgan.warwick at gmail.com (Ben Morgan) Date: Tue, 22 Sep 2015 13:02:55 +0100 Subject: [CMake] Does CMake 3.3.1 ignore CXX env variable on OSX10.10? In-Reply-To: References: Message-ID: <8D679764-42BF-428A-B94F-A6E0B2F92095@gmail.com> Hi Pere, > On 22 Sep 2015, at 11:18, Pere Mato Vila wrote: > > Hi, > > On previous versions I was setting the variables CC and CXX to force the compiler. This is not working anymore. Is this intended? > Cheers, > I think it *is* honouring CC/CXX, but from CMake 3.2 (?) the full path to the actual compiler is resolved to ensure the same compiler is used at build time. This is the relevant commit: https://github.com/Kitware/CMake/commit/1f085e11e40a20f8e8702da7920e950e47deb27c Cheers, Ben. > Pere > ??????? > macitois13:test sftnight$ cmake --version > cmake version 3.3.1 > > CMake suite maintained and supported by Kitware (kitware.com/cmake ). > macitois13:test sftnight$ echo $CXX > /usr/bin/clang++ > macitois13:test sftnight$ cmake . > -- The CXX compiler identification is AppleClang 6.1.0.6020053 > -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ > -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > CMAKE_CXX_COMPILER=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ > -- Configuring done > -- Generating done > -- Build files have been written to: /build/jenkins/workspace/root-release-6.04/BUILDTYPE/Release/COMPILER/native/LABEL/mac1010/build/test > > > > ------------------------------------------------------------- > Pere Mato CERN, PH Department, CH 1211 Geneva 23, Switzerland > e-mail: pere.mato at cern.ch > tel: +41 22 76 78696 > fax: +41 22 76 68792 > gsm: +41 75 41 10855 > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- ================== Dr. Ben Morgan Senior Research Fellow Department of Physics University of Warwick Coventry CV4 7AL ================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.kacvinsky at vectorcast.com Tue Sep 22 09:25:07 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Tue, 22 Sep 2015 09:25:07 -0400 Subject: [CMake] add(library foo SHARED...) is not creating a PDB file In-Reply-To: References: Message-ID: On Mon, Sep 21, 2015 at 5:37 PM, Tom Kacvinsky wrote: > I am using cmake 2.8.11.2 on Windows 7 with Visual Studio 2008 > > This is the snipped of my CMakeLists.txt file > > add_library(commoncpp_objects > OBJECT > > ) > > add_library(commoncpp_static STATIC $) > add_dependencies(commoncpp_static commoncpp_objects) > > add_library(commoncpp SHARED > $ > commoncpp_exports.def > ) > > The objects, static library, and dll/import lib/exp files are created, but > there is no commoncpp.pdb file. > > Any ideas what I am doing wrong? > I think this is a bug. If I list the object files ia the generator, the PDB file is not created, but if I list the sources and force them to be compiled, then the PDB is created. Please note whether listing the object files or compiling from source, there is the cl option to create PDB debugging information. That is, the object files were created that way, regardless of how I listed the files to the add_library. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Sep 22 09:41:31 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Sep 2015 09:41:31 -0400 Subject: [CMake] add_library(foo SHARED...) is not creating a PDB file In-Reply-To: References: Message-ID: <56015A8B.3010708@kitware.com> On 09/22/2015 09:25 AM, Tom Kacvinsky wrote: > I am using cmake 2.8.11.2 on Windows 7 with Visual Studio 2008 [snip] > whether listing the object files or compiling from source, there is > the cl option to create PDB debugging information. Please try with CMake 3.1 or higher: http://www.cmake.org/Bug/view.php?id=14763 There is a distinction between compiler-generated and linker-generated .pdb files. See these target properties to configure each: http://www.cmake.org/cmake/help/v3.3/prop_tgt/COMPILE_PDB_NAME.html http://www.cmake.org/cmake/help/v3.3/prop_tgt/COMPILE_PDB_OUTPUT_DIRECTORY.html http://www.cmake.org/cmake/help/v3.3/prop_tgt/PDB_NAME.html http://www.cmake.org/cmake/help/v3.3/prop_tgt/PDB_OUTPUT_DIRECTORY.html -Brad From tom.kacvinsky at vectorcast.com Tue Sep 22 09:57:03 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Tue, 22 Sep 2015 09:57:03 -0400 Subject: [CMake] add_library(foo SHARED...) is not creating a PDB file In-Reply-To: <56015A8B.3010708@kitware.com> References: <56015A8B.3010708@kitware.com> Message-ID: On Tue, Sep 22, 2015 at 9:41 AM, Brad King wrote: > On 09/22/2015 09:25 AM, Tom Kacvinsky wrote: > > I am using cmake 2.8.11.2 on Windows 7 with Visual Studio 2008 > [snip] > > whether listing the object files or compiling from source, there is > > the cl option to create PDB debugging information. > > Please try with CMake 3.1 or higher: > > http://www.cmake.org/Bug/view.php?id=14763 > > There is a distinction between compiler-generated and linker-generated > .pdb files. See these target properties to configure each: > > http://www.cmake.org/cmake/help/v3.3/prop_tgt/COMPILE_PDB_NAME.html > > http://www.cmake.org/cmake/help/v3.3/prop_tgt/COMPILE_PDB_OUTPUT_DIRECTORY.html > http://www.cmake.org/cmake/help/v3.3/prop_tgt/PDB_NAME.html > http://www.cmake.org/cmake/help/v3.3/prop_tgt/PDB_OUTPUT_DIRECTORY.html > I will give 3.3.2 a try. In the meantime, I am getting a PDB file by listing the source files for the add_library(commoncpp SHARED ), but when I run in the visual studio debugger, it says there are no symbols loaded for the DLL. The PDB path recorded in the DLL points to the right PDB file, but the PDB file typically is larger than the DLL. but in this case it is not. Is that because I am not gettin gall of thde bug information, and a later version of cmake will guarantee that we get the right information? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pere.Mato at cern.ch Tue Sep 22 10:43:40 2015 From: Pere.Mato at cern.ch (Pere Mato Vila) Date: Tue, 22 Sep 2015 14:43:40 +0000 Subject: [CMake] Does CMake 3.3.1 ignore CXX env variable on OSX10.10? In-Reply-To: <8D679764-42BF-428A-B94F-A6E0B2F92095@gmail.com> References: <8D679764-42BF-428A-B94F-A6E0B2F92095@gmail.com> Message-ID: <0C81E48E-E758-4C29-9FB7-A39204F5D8F8@cern.ch> Hi Ben, Thanks, but in my case CXX is already a full path (/usr/bin/clang++). It is set like this export CXX=`which clang++` I do not understand how /usr/bin/clang++ gets converted to /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ Cheers, Pere > On 22 Sep 2015, at 14:02, Ben Morgan wrote: > > Hi Pere, > >> On 22 Sep 2015, at 11:18, Pere Mato Vila wrote: >> >> Hi, >> >> On previous versions I was setting the variables CC and CXX to force the compiler. This is not working anymore. Is this intended? >> Cheers, >> > > I think it *is* honouring CC/CXX, but from CMake 3.2 (?) the full path to the actual compiler is resolved to > ensure the same compiler is used at build time. This is the relevant commit: > > https://github.com/Kitware/CMake/commit/1f085e11e40a20f8e8702da7920e950e47deb27c > > Cheers, > > Ben. > > >> Pere >> ??????? >> macitois13:test sftnight$ cmake --version >> cmake version 3.3.1 >> >> CMake suite maintained and supported by Kitware (kitware.com/cmake). >> macitois13:test sftnight$ echo $CXX >> /usr/bin/clang++ >> macitois13:test sftnight$ cmake . >> -- The CXX compiler identification is AppleClang 6.1.0.6020053 >> -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ >> -- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -- works >> -- Detecting CXX compiler ABI info >> -- Detecting CXX compiler ABI info - done >> -- Detecting CXX compile features >> -- Detecting CXX compile features - done >> CMAKE_CXX_COMPILER=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ >> -- Configuring done >> -- Generating done >> -- Build files have been written to: /build/jenkins/workspace/root-release-6.04/BUILDTYPE/Release/COMPILER/native/LABEL/mac1010/build/test >> >> >> >> ------------------------------------------------------------- >> Pere Mato CERN, PH Department, CH 1211 Geneva 23, Switzerland >> e-mail: pere.mato at cern.ch >> tel: +41 22 76 78696 >> fax: +41 22 76 68792 >> gsm: +41 75 41 10855 >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > > -- > ================== > Dr. Ben Morgan > Senior Research Fellow > Department of Physics > University of Warwick > Coventry CV4 7AL > ================== ------------------------------------------------------------- Pere Mato CERN, PH Department, CH 1211 Geneva 23, Switzerland e-mail: pere.mato at cern.ch tel: +41 22 76 78696 fax: +41 22 76 68792 gsm: +41 75 41 10855 From nilsgladitz at gmail.com Tue Sep 22 11:08:14 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 22 Sep 2015 17:08:14 +0200 Subject: [CMake] Does CMake 3.3.1 ignore CXX env variable on OSX10.10? In-Reply-To: <0C81E48E-E758-4C29-9FB7-A39204F5D8F8@cern.ch> References: <8D679764-42BF-428A-B94F-A6E0B2F92095@gmail.com> <0C81E48E-E758-4C29-9FB7-A39204F5D8F8@cern.ch> Message-ID: <56016EDE.1000407@gmail.com> On 09/22/2015 04:43 PM, Pere Mato Vila wrote: > Hi Ben, > > Thanks, but in my case CXX is already a full path (/usr/bin/clang++). It is set like this > > export CXX=`which clang++` > > I do not understand how /usr/bin/clang++ gets converted to /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ >> https://github.com/Kitware/CMake/commit/1f085e11e40a20f8e8702da7920e950e47deb27c As the commit seems to explain the /usr/bin/clang++ binary is not the actual clang++ binary but rather an apple provided tool that delegates to the actual compiler depending on the current environment. CMake runs "xcrun --find clang++" to find out which binary is currently the actual compiler. This is done since CMake does not allow compilers to change once they have been configured given that this would invalidate information previously collected. Nils From tom.kacvinsky at vectorcast.com Tue Sep 22 11:16:37 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Tue, 22 Sep 2015 11:16:37 -0400 Subject: [CMake] add_library(foo SHARED...) is not creating a PDB file In-Reply-To: References: <56015A8B.3010708@kitware.com> Message-ID: On Tue, Sep 22, 2015 at 9:57 AM, Tom Kacvinsky wrote: > > > On Tue, Sep 22, 2015 at 9:41 AM, Brad King wrote: > >> On 09/22/2015 09:25 AM, Tom Kacvinsky wrote: >> > I am using cmake 2.8.11.2 on Windows 7 with Visual Studio 2008 >> [snip] >> > whether listing the object files or compiling from source, there is >> > the cl option to create PDB debugging information. >> >> Please try with CMake 3.1 or higher: >> >> http://www.cmake.org/Bug/view.php?id=14763 >> >> There is a distinction between compiler-generated and linker-generated >> .pdb files. See these target properties to configure each: >> >> http://www.cmake.org/cmake/help/v3.3/prop_tgt/COMPILE_PDB_NAME.html >> >> http://www.cmake.org/cmake/help/v3.3/prop_tgt/COMPILE_PDB_OUTPUT_DIRECTORY.html >> http://www.cmake.org/cmake/help/v3.3/prop_tgt/PDB_NAME.html >> http://www.cmake.org/cmake/help/v3.3/prop_tgt/PDB_OUTPUT_DIRECTORY.html >> > > I will give 3.3.2 a try. In the meantime, I am getting a PDB file by > listing the source files for the add_library(commoncpp SHARED file>), but when I run in the visual studio debugger, it says there are no > symbols loaded for the DLL. The PDB path recorded in the DLL points to the > right PDB file, but the PDB file typically is larger than the DLL. but in > this case it is not. Is that because I am not getting all of the debug > information, and a later version of cmake will guarantee that we get the > right information? > > Ah yes, I was doing a release build, so link was not invoked with /debug. No wonder my PDB files were so small. For the moment, I just manually created the debug PDB so I can debug my application. Right now, having two builds (debug and release) doesn't fit our workflow, so that will have to be considered. Thanks for the help, Brad. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Tue Sep 22 11:19:59 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Sep 2015 11:19:59 -0400 Subject: [CMake] add_library(foo SHARED...) is not creating a PDB file In-Reply-To: References: <56015A8B.3010708@kitware.com> Message-ID: <5601719F.2070609@kitware.com> On 09/22/2015 11:16 AM, Tom Kacvinsky wrote: > having two builds (debug and release) doesn't fit our workflow Try using the RelWithDebInfo configuration. -Brad From iosif.neitzke+cmake at gmail.com Tue Sep 22 11:49:29 2015 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Tue, 22 Sep 2015 10:49:29 -0500 Subject: [CMake] How to create a custom solution with Visual Studio 2010 generator? In-Reply-To: References: Message-ID: Just as a point of information illustrating the opposite, we like using a CMakeList file for each target that contains a project() command where the name of the project is the name of the target. This is nice (for us) in that you get many .sln files generated from the larger source tree where you can open a .sln file anywhere in the build tree hierarchy with the name of the target you want to work on and get a sub-tree development environment with only that target and its dependencies, instead of everything in the top-level solution (which may contain 100+ targets). On Tue, Sep 22, 2015 at 4:46 AM, Hendrik Sattler wrote: > Hi, > > > Am 22. September 2015 08:49:57 MESZ, schrieb "Golebiewski, Jakub" : >>I have about 620 targets (VS projects) so when I open Main Project.sln >>(with 620 projects) in VS it is impossible to work with. >>Currently cmake produces .sln for each Sub Project but includes >>dependencies from other projects and that's something I don?t want >>Since the amount of projects in each .sln increases the further I go >>and most of them (later in the dependency chain) are not possible to >>work >>with either. I'm trying to divide it into .slns that developers could >>work with in VS. > > That is exactly what imported targets are for. However, they refer to already built projects. I'd also suggest a two-step approach: first configure and build the thing with all projects in the solution. The libraries need to create cmake build tree export config files. After that step, define a cmake variable to switch to using the previously created export config files only. These create the imported targets and don't show up in the IDE. > > HS > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 Pere.Mato at cern.ch Tue Sep 22 11:53:50 2015 From: Pere.Mato at cern.ch (Pere Mato Vila) Date: Tue, 22 Sep 2015 15:53:50 +0000 Subject: [CMake] Does CMake 3.3.1 ignore CXX env variable on OSX10.10? In-Reply-To: <56016EDE.1000407@gmail.com> References: <8D679764-42BF-428A-B94F-A6E0B2F92095@gmail.com> <0C81E48E-E758-4C29-9FB7-A39204F5D8F8@cern.ch> <56016EDE.1000407@gmail.com> Message-ID: Thanks Nils. This explains it. So, the value of CXX is not honored. The problem we have, is that we record the compiler that we have used to build for runtime usage. If we make a binary distribution, this one will we used by clients that may have the compiler somewhere else. Cheers, Pere > On 22 Sep 2015, at 17:08, Nils Gladitz wrote: > > On 09/22/2015 04:43 PM, Pere Mato Vila wrote: >> Hi Ben, >> >> Thanks, but in my case CXX is already a full path (/usr/bin/clang++). It is set like this >> >> export CXX=`which clang++` >> >> I do not understand how /usr/bin/clang++ gets converted to /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ > >>> https://github.com/Kitware/CMake/commit/1f085e11e40a20f8e8702da7920e950e47deb27c > > As the commit seems to explain the /usr/bin/clang++ binary is not the actual clang++ binary but rather an apple provided tool that delegates to the actual compiler depending on the current environment. > > CMake runs "xcrun --find clang++" to find out which binary is currently the actual compiler. > > This is done since CMake does not allow compilers to change once they have been configured given that this would invalidate information previously collected. > > Nils > > ------------------------------------------------------------- Pere Mato CERN, PH Department, CH 1211 Geneva 23, Switzerland e-mail: pere.mato at cern.ch tel: +41 22 76 78696 fax: +41 22 76 68792 gsm: +41 75 41 10855 From tom.kacvinsky at vectorcast.com Tue Sep 22 11:59:10 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Tue, 22 Sep 2015 11:59:10 -0400 Subject: [CMake] add_library(foo SHARED...) is not creating a PDB file In-Reply-To: <5601719F.2070609@kitware.com> References: <56015A8B.3010708@kitware.com> <5601719F.2070609@kitware.com> Message-ID: On Tue, Sep 22, 2015 at 11:19 AM, Brad King wrote: > On 09/22/2015 11:16 AM, Tom Kacvinsky wrote: > > having two builds (debug and release) doesn't fit our workflow > > Try using the RelWithDebInfo configuration. > > Eeeek, that won't work because we are also using Ada and the plplot Ada module for cmake doesn't support RelWithDebInfo. For the moment, I will just my make development branch debug, debug, and switch back to release mode when it gets merged in. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Sep 22 13:17:54 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 22 Sep 2015 19:17:54 +0200 Subject: [CMake] Does CMake 3.3.1 ignore CXX env variable on OSX10.10? In-Reply-To: References: <8D679764-42BF-428A-B94F-A6E0B2F92095@gmail.com> <0C81E48E-E758-4C29-9FB7-A39204F5D8F8@cern.ch> <56016EDE.1000407@gmail.com> Message-ID: <56018D42.20604@gmail.com> On 22.09.2015 17:53, Pere Mato Vila wrote: > Thanks Nils. This explains it. So, the value of CXX is not honored. I wouldn't go that far given that /usr/bin/clang++ and cmake call the same compiler. If you were to use a compiler in a custom installation prefix (without apple's tool in between) and would pass that to CXX the compiler would be used as-is. CXX is honored even if the path is not preserved. > The problem we have, is that we record the compiler that we have used to build for runtime usage. If we make a binary distribution, this one will we used by clients that may have the compiler somewhere else. Given that /usr/bin/clang++ on the build system and /usr/bin/clang++ on a client system may not actually call the same compilers does it even make sense to record and use it as-is? Nils From bnewcomb at nvidia.com Tue Sep 22 14:31:26 2015 From: bnewcomb at nvidia.com (Bill Newcomb) Date: Tue, 22 Sep 2015 11:31:26 -0700 Subject: [CMake] Determining a library name at configure time In-Reply-To: <55FC5B0E.4050800@nvidia.com> References: <55FC5B0E.4050800@nvidia.com> Message-ID: <56019E7E.9020205@nvidia.com> Anyone? Thanks, B. On 09/18/2015 11:42 AM, Bill Newcomb wrote: > Suppose I add a library in my project: > > add_library(foo STATIC foo.c bar.c) > > Is there a way I can get the name of the generated library file at > configure time? LIBRARY_OUTPUT_NAME and OUTPUT_NAME for the target do > not seem to be set: > > get_target_property(libname foo LIBRARY_OUTPUT_NAME) > message(STATUS "libname is ${libname} > > ... > -- libname is libname-NOTFOUND > ... > > Thanks, > B. > > ----------------------------------------------------------------------------------- > > This email message is for the sole use of the intended recipient(s) > and may contain > confidential information. Any unauthorized review, use, disclosure or > distribution > is prohibited. If you are not the intended recipient, please contact > the sender by > reply email and destroy all copies of the original message. > ----------------------------------------------------------------------------------- > From nilsgladitz at gmail.com Tue Sep 22 14:50:25 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 22 Sep 2015 20:50:25 +0200 Subject: [CMake] Determining a library name at configure time In-Reply-To: <56019E7E.9020205@nvidia.com> References: <55FC5B0E.4050800@nvidia.com> <56019E7E.9020205@nvidia.com> Message-ID: <5601A2F1.2070005@gmail.com> On 09/18/2015 11:42 AM, Bill Newcomb wrote: >> Suppose I add a library in my project: >> >> add_library(foo STATIC foo.c bar.c) >> >> Is there a way I can get the name of the generated library file at >> configure time? LIBRARY_OUTPUT_NAME and OUTPUT_NAME for the target >> do not seem to be set: Can you elaborate your use case? If your use case allows for it you could delegate getting the file name to generation time (which is when the final file name is decided). e.g. $ [1] would expand to the file name (without path) of the given target in the context of e.g. add_custom_command() commands. Nils [1] http://www.cmake.org/cmake/help/v3.3/manual/cmake-generator-expressions.7.html From brad.king at kitware.com Tue Sep 22 14:57:03 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 22 Sep 2015 14:57:03 -0400 Subject: [CMake] Determining a library name at configure time In-Reply-To: <55FC5B0E.4050800@nvidia.com> References: <55FC5B0E.4050800@nvidia.com> Message-ID: <5601A47F.2080900@kitware.com> On 09/18/2015 02:42 PM, Bill Newcomb wrote: > Suppose I add a library in my project: > > add_library(foo STATIC foo.c bar.c) > > Is there a way I can get the name of the generated library file at > configure time? On multi-configuration generators like VS and Xcode there may be more than one library file, one for each configuration like Debug and Release. For this reason CMake does not always know the path to the final file at configure time. Instead one typically needs to use a placeholder of some kind that will be substituted for each build configuration at generate time. What do you actually want to do with the library file name? There are several common and supported use cases. In add_custom_command COMMAND lines for example one can use the $ generator expression: http://www.cmake.org/cmake/help/v3.3/manual/cmake-generator-expressions.7.html http://www.cmake.org/cmake/help/v3.3/command/add_custom_command.html > get_target_property(libname foo LIBRARY_OUTPUT_NAME) That property is only for setting a non-default name. It contributes to the computation of the actual file name which may be specific to the platform. -Brad From bnewcomb at nvidia.com Tue Sep 22 17:17:21 2015 From: bnewcomb at nvidia.com (Bill Newcomb) Date: Tue, 22 Sep 2015 14:17:21 -0700 Subject: [CMake] Determining a library name at configure time In-Reply-To: <5601A2F1.2070005@gmail.com> References: <55FC5B0E.4050800@nvidia.com> <56019E7E.9020205@nvidia.com> <5601A2F1.2070005@gmail.com> Message-ID: <5601C561.6040503@nvidia.com> Disclaimer: The system I'm working on has its origins in pre cmake-2.6 days, and we'd probably make a lot of different decisions if we started anew today. We are using only the Unix Makefiles generator. Our system comprises a number of components, each of which is its own cmake project, and builds libraries, executables, etc. The configure (and make, later) operations on the components are driven by another invocation of cmake (i.e. the user points cmake at a top-level cmakelists, which then invokes cmake again for each component; then the user runs make, which results in 'make install' getting run in each component's configured subdir). When cmake is run, the user may designate it either as global or local--local builds install component products to a local directory in the user's workspace, whereas global builds install to a central well-known location. Periodic automated builds build all components and install globally, so that user builds need not build all components, but rather can use some components from the global area (with the obvious caveats about version incompatibilities). I want a way to enable one component to use a static library from another component. I tried using cmake's export/import functionality, but in that case the exported *.cmake file isn't written until install time, but the system must be able to configure all components before starting to make them. So I was trying to figure out a way to create a skeletal version of the exported *.cmake file at configure time so that the dependent component could include an actual dependency on the static library to be provided by the other component. Figuring out how to get the name of the library is my use case. Please let me know if any of the above requires further description--I know it's a mess :-) Thanks, B. On 09/22/2015 11:50 AM, Nils Gladitz wrote: > On 09/18/2015 11:42 AM, Bill Newcomb wrote: >>> Suppose I add a library in my project: >>> >>> add_library(foo STATIC foo.c bar.c) >>> >>> Is there a way I can get the name of the generated library file at >>> configure time? LIBRARY_OUTPUT_NAME and OUTPUT_NAME for the target >>> do not seem to be set: > > Can you elaborate your use case? > > If your use case allows for it you could delegate getting the file > name to generation time (which is when the final file name is decided). > e.g. $ [1] would expand to the file name > (without path) of the given target in the context of e.g. > add_custom_command() commands. > > Nils > > [1] > http://www.cmake.org/cmake/help/v3.3/manual/cmake-generator-expressions.7.html ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- From nilsgladitz at gmail.com Tue Sep 22 17:38:32 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 22 Sep 2015 23:38:32 +0200 Subject: [CMake] Determining a library name at configure time In-Reply-To: <5601C561.6040503@nvidia.com> References: <55FC5B0E.4050800@nvidia.com> <56019E7E.9020205@nvidia.com> <5601A2F1.2070005@gmail.com> <5601C561.6040503@nvidia.com> Message-ID: <5601CA58.7060808@gmail.com> On 22.09.2015 23:17, Bill Newcomb wrote: > Disclaimer: The system I'm working on has its origins in pre cmake-2.6 > days, and we'd probably make a lot of different decisions if we > started anew today. We are using only the Unix Makefiles generator. > > Our system comprises a number of components, each of which is its own > cmake project, and builds libraries, executables, etc. The configure > (and make, later) operations on the components are driven by another > invocation of cmake (i.e. the user points cmake at a top-level > cmakelists, which then invokes cmake again for each component; then > the user runs make, which results in 'make install' getting run in > each component's configured subdir). > > When cmake is run, the user may designate it either as global or > local--local builds install component products to a local directory in > the user's workspace, whereas global builds install to a central > well-known location. Periodic automated builds build all components > and install globally, so that user builds need not build all > components, but rather can use some components from the global area > (with the obvious caveats about version incompatibilities). > > I want a way to enable one component to use a static library from > another component. I tried using cmake's export/import functionality, > but in that case the exported *.cmake file isn't written until install > time, but the system must be able to configure all components before > starting to make them. So I was trying to figure out a way to create > a skeletal version of the exported *.cmake file at configure time so > that the dependent component could include an actual dependency on the > static library to be provided by the other component. Figuring out > how to get the name of the library is my use case. > CMake can also create target exports for the build tree with export(EXPORT) [1]. These would not require installation and would exist after generation (after cmake finished processing). Which might be an option if you can configure your sub-projects in sequence (e.g. configure the project that provides targets before the projects that consume those targets). If cmake's target exports exceed what is required for your use case you could also use file(GENERATE) to produce custom files at generation time. file(GENERATE) would take an input file containing e.g. a generator expression like $ and produce a corresponding output file with the target's output file name. Nils [1] http://cmake.org/cmake/help/v3.3/command/export.html [2] http://cmake.org/cmake/help/v3.3/command/file.html From Jakub.Golebiewski at dnvgl.com Wed Sep 23 03:35:12 2015 From: Jakub.Golebiewski at dnvgl.com (Golebiewski, Jakub) Date: Wed, 23 Sep 2015 07:35:12 +0000 Subject: [CMake] How to create a custom solution with Visual Studio 2010 generator? In-Reply-To: References: Message-ID: > -----Original Message----- > From: J Decker [mailto:d3ck0r at gmail.com] > Sent: Tuesday, September 22, 2015 9:40 AM > To: Golebiewski, Jakub > Cc: cmake at cmake.org > Subject: Re: [CMake] How to create a custom solution with Visual Studio > 2010 generator? > > > I've tried running cmake independently for each subproject but I get > > errors about unknown Targets since every Sub Project depends on targets > from 'earlier' one. > > > > I have about 620 targets (VS projects) so when I open Main Project.sln > (with 620 projects) in VS it is impossible to work with. > > Currently cmake produces .sln for each Sub Project but includes > > dependencies from other projects and that's something I don?t want > > Since the amount of projects in each .sln increases the further I go and > most of them (later in the dependency chain) are not possible to work with > either. I'm trying to divide it into .slns that developers could work with in VS. > > > Hmm; I was going to check to see if .sln's were made in subdirs... and they > are... wonder if it was always taht way. > But... the projects deeper in the tree only have those things that it > depended on... so I don't get why you say 'the amount of projects > increases the further you go' Yes... high level projects will have > all of their dependancies but nothing extra... I meant that in my case (let's use the original simple example), targets 3,4 depend on 1,2 and 5,6 depend on 3,4 and therefore on 1,2 as well. So in Sub Project 1.sln I get targets 1,2 in Sub Project 2.sln I get 1,2,3,4 and in Sub Project 3.sln I get 1,2,3,4,5,6. This is of course absolutely correct and the right way to do it. But in my case with about 620 projects I have about 19 subprojects. This means that I get solutions more or less like this: 1. 30 projects 2. 50 projects (about 20 as dependencies from 1 - not all because there are unit test projects (executables) in 1 and all the rest) 3. 70 projects (about 50 as dependencies from 1,2) 4. 100 projects (...) 5. 150 projects 6. 200 projects 7. 250 projects 8. 300 projects 9. 350 projects (probably about 75 projects and 300 as dependencies from 1 - 8) ... At this point unfortunately the VS 2010 is so slow that It is impossible to work with 350 project solution. So what I want to do Is to cut the dependencies from other projects to make this usable. (that's what we are currently doing, I'm in the process of converting our current build system to cmake) I hope that's clear enough. > > isn't it already making the minimal solutions you're suggesting you make by > hand anyway? > > Other than as I use this; the Install rule in the sub-solution doesn't install > everything... > could wish the OutputPath cmake built was relative to the solution instead > of the projects... then at least nothing funky would have to be done to run > applications from the debugger; other than data resources could still be > missing. Thanks for help, I really appreciate it ************************************************************************************** This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited. ************************************************************************************** From iraytrace at gmail.com Wed Sep 23 12:03:38 2015 From: iraytrace at gmail.com (Lee Butler) Date: Wed, 23 Sep 2015 12:03:38 -0400 Subject: [CMake] Thoughts on infrastructure for fixup_bundle Message-ID: <5602CD5A.2070209@gmail.com> I've started using fixup_bundle(). One of the things that occurs to me is that much of the information that needs to go into fixup_bundle() arguments (executables and library directories) can be gleaned from arguments to add_executable() and target_link_libraries(). It might be nice to extend these two standard functions to create variables that could be used with fixup_bundle. I could see writing macros or functions to wrap this up for my projects, but I think it might belong in the "standard" versions of these. Perhaps this already exists and I have simply not seen it? I'd like to get to a world where we could do something like: # tell CMake to remember the executable names and libraries for each set(CMAKE_BUILD_FIXUP_ARGS ON) add_executable(execName ... BUNDLEME) target_link_libraries(execName lib1 lib2 ...) install(TARGETS execName ... ) add_executable(progName ... BUNDLEME) target_link_libraries(progName lib1 lib18 ...) install(TARGETS execName ...) fixup_bundle(${CMAKE_INSTALL_TARGETS} "" ${CMAKE_execName_LIBPLACES} ${CMAKE_progName_LIBPLACES}) I'm speculating that it is target_link_libraries that I would extend with the capability to generate the lists of library locations (some code and conventions required for DLL platforms). I could see some people wanting to avoid bundling executables they do not want to install, so a flag for add_executable to indicate whether to bundle seems like it would work. In any case, this would allow you to do a fixup_bundle() as a POST_BUILD stage so that things could be run from the build directory. This is nice for testing prior to doing an install. Thoughts? From cmake at anteru.net Wed Sep 23 15:49:12 2015 From: cmake at anteru.net (=?UTF-8?Q?Matth=c3=a4us_G._Chajdas?=) Date: Wed, 23 Sep 2015 21:49:12 +0200 Subject: [CMake] "Pre-configure" step in CMake Message-ID: <56030238.9020509@anteru.net> Hi, I'm trying to solve the following the problem: I have a C++ application and a dependency fetching script. I want to simplify the initial build such that the following happens: On the first run of cmake, the compiler ID and version is passed to an external script, which fetches some pre-build binaries. It then writes a CMake file which contains basically only set(FOO_INCLUDE_DIR /dep-dir), set(FOO_LIBRARY_DIR /dep-dir) commands. CMake would then read this file and subsequent find_library calls would pick up the values from this new CMake file. The idea is that "actual" build is dependent on this first dependency step, but it's already within the CMake framework so I can grab the compiler info and other build info. The obvious problem is that while I can easily run the external script by using configure_file, and have a custom target that does the dependency fetching and CMake configure file generation. But I don't see an easy way to get CMake to make the "rest of the project" depend on that configure file. How can I make such a "two-stage" build with CMake? Cheers, Matth?us From petr.kmoch at gmail.com Thu Sep 24 02:52:49 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Thu, 24 Sep 2015 08:52:49 +0200 Subject: [CMake] "Pre-configure" step in CMake In-Reply-To: <56030238.9020509@anteru.net> References: <56030238.9020509@anteru.net> Message-ID: Hi Matthaus, do you need the pre-configure step to happen at build time? Would it be an option for you to use file(WRITE) instead of configure_file(), and execute_process() instead of add_custom_target()? Basically, perform the pre-configure step as part of the first CMake run itself. Alternatively, you could look into the ExternalProject module, which is (I believe) designed for situations like yours: http://cmake.org/cmake/help/v3.3/module/ExternalProject.html The basic idea of ExternalProject is that you create one top-level, "SuperBuild" project, which will include each dependency as an external project, and your real project *as an external project too.* That way, you can easily gather all dependencies by building the "SuperBuild". Then you switch to working just with your own project inside the SuperBuild structure, but all the dependencies are already there. (Note: I've never used ExternalProject myself, this info comes from what I've learned on this mailing list from other people using it). Hope this helps, Petr On Wed, Sep 23, 2015 at 9:49 PM, Matth?us G. Chajdas wrote: > Hi, > > I'm trying to solve the following the problem: I have a C++ application > and a dependency fetching script. I want to simplify the initial build > such that the following happens: On the first run of cmake, the compiler > ID and version is passed to an external script, which fetches some > pre-build binaries. It then writes a CMake file which contains basically > only set(FOO_INCLUDE_DIR /dep-dir), set(FOO_LIBRARY_DIR /dep-dir) > commands. CMake would then read this file and subsequent find_library > calls would pick up the values from this new CMake file. The idea is > that "actual" build is dependent on this first dependency step, but it's > already within the CMake framework so I can grab the compiler info and > other build info. > > The obvious problem is that while I can easily run the external script > by using configure_file, and have a custom target that does the > dependency fetching and CMake configure file generation. But I don't see > an easy way to get CMake to make the "rest of the project" depend on > that configure file. How can I make such a "two-stage" build with CMake? > > Cheers, > Matth?us > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 Thu Sep 24 04:14:20 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Thu, 24 Sep 2015 10:14:20 +0200 Subject: [CMake] "Pre-configure" step in CMake In-Reply-To: <56030238.9020509@anteru.net> References: <56030238.9020509@anteru.net> Message-ID: What if you call your dependency-fetcher script with a straight macro/function call or `include` or `execute_process` instead of putting it into a custom target? I'm thinking of something like this: set(DEP_SCRIPT_OUT ${CMAKE_CURRENT_BINARY_DIR}/dep-script-out.cmake) if(NOT EXISTS "${DEP_SCRIPT_OUT}") execute_process(${CMAKE_COMMAND} -DC_COMPILER_ID=${CMAKE_C_COMPILER_ID} -DC_COMPILER_VERSION=${CMAKE_C_COMPILER_VERSION} -DDEP_SCRIPT_OUT =${DEP_SCRIPT_OUT} -P dependency-fetcher.cmake) endif() include(${DEP_SCRIPT_OUT}) or, simply: if(NOT DEPENDENCIES_FETCHED) include(dependency-fetcher.cmake) # fetch_dependencies() # call it in case it's implemented as a macro/function set(DEPENDENCIES_FETCHED ON CACHE BOOL "" FORCE) endif() In the latter case there's no need to write the variables into a script since the fetcher runs in the same scope. Tamas On Wed, Sep 23, 2015 at 9:49 PM, Matth?us G. Chajdas wrote: > Hi, > > I'm trying to solve the following the problem: I have a C++ application > and a dependency fetching script. I want to simplify the initial build > such that the following happens: On the first run of cmake, the compiler > ID and version is passed to an external script, which fetches some > pre-build binaries. It then writes a CMake file which contains basically > only set(FOO_INCLUDE_DIR /dep-dir), set(FOO_LIBRARY_DIR /dep-dir) > commands. CMake would then read this file and subsequent find_library > calls would pick up the values from this new CMake file. The idea is > that "actual" build is dependent on this first dependency step, but it's > already within the CMake framework so I can grab the compiler info and > other build info. > > The obvious problem is that while I can easily run the external script > by using configure_file, and have a custom target that does the > dependency fetching and CMake configure file generation. But I don't see > an easy way to get CMake to make the "rest of the project" depend on > that configure file. How can I make such a "two-stage" build with CMake? > > Cheers, > Matth?us > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware 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 Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Thu Sep 24 05:47:11 2015 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Thu, 24 Sep 2015 09:47:11 +0000 Subject: [CMake] Generated .rc files silently ignored Message-ID: <8D981219EEA621479C112DA9BDC39A8E348D2A69@EXMBS1.ad.igd.fraunhofer.de> Hej hej, for some reason your mail was not delivered to me and I only stumbled upon it by chance in the archives (while trying to find out where another one of my mails to the list disappeared to). In any case, yes, I am adding the .rc file to my add_library command. The issue I have is that if I use mylib.rc in add_library and have an add_custom_command(OUTPUT mylib.rc ...) nothing is created but no error message is produced either (i.e. silently ignored). I have to use ${CMAKE_CURRENT_BINARY_DIR}/mylib.rc explicitly. For most files (such as generated .cpp files) using a relative path just works, because relative paths used in add_custom_command are interpreted relative to ${CMAKE_CURRENT_BINARY_DIR}. Original text: Hej, Some more information about how you setup things would be useful. For instance: you would need to add the filename of the generated .rc file to the executable/library for which it is generated: are you doing that? In the application I currently work on, we have created a small function to wrap the generation of the .rc file. I just checked that we actually also build a full path. That actually makes sense, because the generated file is put in the ${CMAKE_CURRENT_BINARY_DIR} and *not* in the current source dir. In other words: we could never accomplish this with any type of 'relative' path anyway. Are you maybe also mixing up the *SOURCE_DIR and *BINARY_DIR? Sincerely, Jakob -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Thu Sep 24 07:47:41 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Thu, 24 Sep 2015 13:47:41 +0200 Subject: [CMake] Build log generation in a "custom" way Message-ID: <808108FC-73A6-46FC-AE5D-6C69BEDB2F07@gmail.com> Dear All, I'd like to ask for some advice about the following issue. We're migrating a very big project (millions of lines of code...) from a custom build manager to CMake. The software is put together from separate "packages" that are all developed by a different set of people. Our nightly build system collects all these packages, and compiles all of them. In our old build system we could easily save package-specific build log files for the nightly system. Making it easy for the developers to quickly find build problems in their specific package. Now we'd like to do something similar with CMake. To teach it how to generate separate build log files for the separate packages. (Packages in this context are really just subdirectories in the end.) The clumsy thing that we're doing now is to use a script that we set for RULE_LAUNCH_COMPILE, RULE_LAUNCH_LINK, and RULE_LAUNCH_CUSTOM. This script writes log files in a non-too-perfect way, which need to be stitched together at the end of the build to get "package specific" build log files. So the question is whether we could do something better. Does anyone have an idea/suggestion? I'm happy to give more information about our setup if needed. Cheers, Attila From bill.hoffman at kitware.com Thu Sep 24 10:05:34 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 24 Sep 2015 10:05:34 -0400 Subject: [CMake] Build log generation in a "custom" way In-Reply-To: <808108FC-73A6-46FC-AE5D-6C69BEDB2F07@gmail.com> References: <808108FC-73A6-46FC-AE5D-6C69BEDB2F07@gmail.com> Message-ID: <5604032E.4060309@kitware.com> On 9/24/2015 7:47 AM, Attila Krasznahorkay wrote: > Dear All, > > I'd like to ask for some advice about the following issue. We're > migrating a very big project (millions of lines of code...) from a > custom build manager to CMake. > > The software is put together from separate "packages" that are all > developed by a different set of people. Our nightly build system > collects all these packages, and compiles all of them. In our old > build system we could easily save package-specific build log files > for the nightly system. Making it easy for the developers to quickly > find build problems in their specific package. > > Now we'd like to do something similar with CMake. To teach it how to > generate separate build log files for the separate packages. > (Packages in this context are really just subdirectories in the end.) > The clumsy thing that we're doing now is to use a script that we set > for RULE_LAUNCH_COMPILE, RULE_LAUNCH_LINK, and RULE_LAUNCH_CUSTOM. > This script writes log files in a non-too-perfect way, which need to > be stitched together at the end of the build to get "package > specific" build log files. > > So the question is whether we could do something better. Does anyone > have an idea/suggestion? I'm happy to give more information about our > setup if needed. You might want to look into CDash (www.cdash.org). http://www.kitware.com/media/html/CDashSubprojects.html Here is an example in the Trilinos project: http://testing.sandia.gov/cdash/index.php?project=Trilinos&date=2015-09-23 -Bill From sybenzvi at gmail.com Thu Sep 24 10:29:30 2015 From: sybenzvi at gmail.com (Segev BenZvi) Date: Thu, 24 Sep 2015 10:29:30 -0400 Subject: [CMake] CPack picks up AppleDouble files when running in OS X Message-ID: Hi all, I've run into an annoying issue making package sources with CPack in OS X (Mavericks and Yosemite). I set up CPack to produce a tarball of my source tree with bzip, but in OS X tar will pick up the AppleDouble files in the source folder and stuff them into the archive too. As a result my tarball is full of duplicate source files (i.e., source.cc and its double ._source.cc), which causes problems when building the source later. This is **not** the fault of CPack; it is a known issue with tar in OS X. The way to suppress the AppleDouble files when running tar on the command line is to set the environment variable COPYFILE_DISABLE=1, e.g., $> COPYFILE_DISABLE=1 tar cjf package.tbz2 /path/to/src This works just fine for me. Unfortunately, even if I have COPYFILE_DISABLE set in my environment, CPack doesn't seem to pick it up when calling tar. As a result the AppleDouble files keep showing up in my archive when I call "make package_source." While it's not a blocker for me -- I can produce the source package on a Linux box -- I do most of my development on my MacBook so this is pretty annoying. I tried some other tricks, like including the line SET (CPACK_SOURCE_IGNORE_FILES "[.]_.*;") in my top-level CMakeLists.txt, but that doesn't help. I looked through the cmake email archives but couldn't find anyone else who has raised this issue... so either I've missed the right emails or there is an obvious fix I'm overlooking. Any ideas what I'm doing wrong? Thanks for your attention! Best regards, Segev BenZvi -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmake at anteru.net Thu Sep 24 16:26:32 2015 From: cmake at anteru.net (=?UTF-8?Q?Matth=c3=a4us_G._Chajdas?=) Date: Thu, 24 Sep 2015 22:26:32 +0200 Subject: [CMake] "Pre-configure" step in CMake In-Reply-To: References: <56030238.9020509@anteru.net> Message-ID: <56045C78.7020001@anteru.net> Hi, that sounds like it would do the trick. I wasn't aware that execute_process will block the script until it's done executing. Need to check this out but that definitely looks like the way to go, thanks! Cheers, Matth?us Am 24.09.2015 um 10:14 schrieb Tam?s Ken?z: > What if you call your dependency-fetcher script with a straight > macro/function call or `include` or `execute_process` instead of putting > it into a custom target? I'm thinking of something like this: > > set(DEP_SCRIPT_OUT ${CMAKE_CURRENT_BINARY_DIR}/dep-script-out.cmake) > if(NOT EXISTS "${DEP_SCRIPT_OUT}") > execute_process(${CMAKE_COMMAND} > -DC_COMPILER_ID=${CMAKE_C_COMPILER_ID} > -DC_COMPILER_VERSION=${CMAKE_C_COMPILER_VERSION} > -DDEP_SCRIPT_OUT =${DEP_SCRIPT_OUT} > -P dependency-fetcher.cmake) > endif() > include(${DEP_SCRIPT_OUT}) > > or, simply: > > if(NOT DEPENDENCIES_FETCHED) > include(dependency-fetcher.cmake) > # fetch_dependencies() # call it in case it's implemented as a > macro/function > set(DEPENDENCIES_FETCHED ON CACHE BOOL "" FORCE) > endif() > > In the latter case there's no need to write the variables into a script > since the fetcher runs in the same scope. > > Tamas > > > On Wed, Sep 23, 2015 at 9:49 PM, Matth?us G. Chajdas > wrote: > > Hi, > > I'm trying to solve the following the problem: I have a C++ application > and a dependency fetching script. I want to simplify the initial build > such that the following happens: On the first run of cmake, the compiler > ID and version is passed to an external script, which fetches some > pre-build binaries. It then writes a CMake file which contains basically > only set(FOO_INCLUDE_DIR /dep-dir), set(FOO_LIBRARY_DIR /dep-dir) > commands. CMake would then read this file and subsequent find_library > calls would pick up the values from this new CMake file. The idea is > that "actual" build is dependent on this first dependency step, but it's > already within the CMake framework so I can grab the compiler info and > other build info. > > The obvious problem is that while I can easily run the external script > by using configure_file, and have a custom target that does the > dependency fetching and CMake configure file generation. But I don't see > an easy way to get CMake to make the "rest of the project" depend on > that configure file. How can I make such a "two-stage" build with CMake? > > Cheers, > Matth?us > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > > > From bill.hoffman at kitware.com Thu Sep 24 16:30:42 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 24 Sep 2015 16:30:42 -0400 Subject: [CMake] "Pre-configure" step in CMake In-Reply-To: <56045C78.7020001@anteru.net> References: <56030238.9020509@anteru.net> <56045C78.7020001@anteru.net> Message-ID: <56045D72.1090801@kitware.com> On 9/24/2015 4:26 PM, Matth?us G. Chajdas wrote: > Hi, > > that sounds like it would do the trick. I wasn't aware that > execute_process will block the script until it's done executing. Need to > check this out but that definitely looks like the way to go, thanks! ExternalProject might be a better option. It pushes the downloads to build time and handles dependencies without having to re-run CMake. If you run a download script at CMake time, it could take an unknown amount of time to configure. -Bill From brunobg at corollarium.com Thu Sep 24 16:42:11 2015 From: brunobg at corollarium.com (Bruno Barberi Gnecco) Date: Thu, 24 Sep 2015 17:42:11 -0300 Subject: [CMake] Adding files to ARCHIVE packages only in CPack Message-ID: <56046023.80208@corollarium.com> How is it possible to add some files only to the ARCHIVE generators with CMake/CPack? Apparently components do that, but I can't figure how to say "only add component X to generator Y". I did something like this: In CPackConfig.cmake: set(CPACK_PROJECT_CONFIG_FILE "${CMAKE_CURRENT_SOURCE_DIR}/CMakeModules/CMakeCPackOptions.cmake") In CMakeCPackOptions.cmake IF (CPACK_GENERATOR MATCHES "TGZ") install(FILES myextrafile DESTINATION "." COMPONENT static) ENDIF() But I get the following error: /usr/local/bin/cpack --config ./CPackConfig.cmake CMake Error at CMakeModules/CMakeCPackOptions.cmake:4 (install): Unknown CMake command "install". CPack Error: Cannot initialize the generator TGZ What am I doing wrong? Any other way to run `install()` only for certain generators? Thanks From cmake at anteru.net Thu Sep 24 17:02:04 2015 From: cmake at anteru.net (=?UTF-8?Q?Matth=c3=a4us_G._Chajdas?=) Date: Thu, 24 Sep 2015 23:02:04 +0200 Subject: [CMake] "Pre-configure" step in CMake In-Reply-To: <56045D72.1090801@kitware.com> References: <56030238.9020509@anteru.net> <56045C78.7020001@anteru.net> <56045D72.1090801@kitware.com> Message-ID: <560464CC.3080909@anteru.net> Hi, how does the ExternalProject interact with subsequent find_library calls? I've seen projects building dependencies through ExternalProject, but those would the project manually by querying ExternalProject and adding a new imported target. How would I connect an ExternalProject to one or more find_library calls? Is there a downside from configure taking an unknown amount of time? My expectation was that there is no timeout for the configure step. Cheers, Matth?us Am 24.09.2015 um 22:30 schrieb Bill Hoffman: > On 9/24/2015 4:26 PM, Matth?us G. Chajdas wrote: >> Hi, >> >> that sounds like it would do the trick. I wasn't aware that >> execute_process will block the script until it's done executing. Need to >> check this out but that definitely looks like the way to go, thanks! > ExternalProject might be a better option. It pushes the downloads to > build time and handles dependencies without having to re-run CMake. If > you run a download script at CMake time, it could take an unknown amount > of time to configure. > > -Bill > > From bill.hoffman at kitware.com Thu Sep 24 17:15:24 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 24 Sep 2015 17:15:24 -0400 Subject: [CMake] "Pre-configure" step in CMake In-Reply-To: <560464CC.3080909@anteru.net> References: <56030238.9020509@anteru.net> <56045C78.7020001@anteru.net> <56045D72.1090801@kitware.com> <560464CC.3080909@anteru.net> Message-ID: <560467EC.3010509@kitware.com> On 9/24/2015 5:02 PM, Matth?us G. Chajdas wrote: > Hi, > > how does the ExternalProject interact with subsequent find_library calls? > > I've seen projects building dependencies through ExternalProject, but > those would the project manually by querying ExternalProject and adding > a new imported target. How would I connect an ExternalProject to one or > more find_library calls? > So, the trick is it all has to be ExternalProject including your project. Then the find_library stuff will work. EP_add(3rdpartylib) EP_add(myproj) # at build time of myproj all of 3rdparytlib will be done and discoverable by myproj find_* calls. We often have project-bootstrap projects that use external project to configure an environment. 1. build project-bootstrap (all external project stuff) 2. cd myproject, and treat this like a standalone CMake project that has just discovered all of its depends on the system. > Is there a downside from configure taking an unknown amount of time? My > expectation was that there is no timeout for the configure step. It is meant to be an interactive step with cmake-gui. Also, if there are configuration errors you would want to see them up front and not after a wait. -Bill From eric.noulard at gmail.com Fri Sep 25 04:27:40 2015 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 25 Sep 2015 10:27:40 +0200 Subject: [CMake] Adding files to ARCHIVE packages only in CPack In-Reply-To: <56046023.80208@corollarium.com> References: <56046023.80208@corollarium.com> Message-ID: 2015-09-24 22:42 GMT+02:00 Bruno Barberi Gnecco : > How is it possible to add some files only to the ARCHIVE > generators with CMake/CPack? Apparently components do that, but I can't > figure how to say "only add component X to generator Y". I did something > like this: > > In CPackConfig.cmake: > > set(CPACK_PROJECT_CONFIG_FILE > "${CMAKE_CURRENT_SOURCE_DIR}/CMakeModules/CMakeCPackOptions.cmake") > > In CMakeCPackOptions.cmake > > IF (CPACK_GENERATOR MATCHES "TGZ") > install(FILES myextrafile DESTINATION "." COMPONENT static) > ENDIF() > > But I get the following error: > > /usr/local/bin/cpack --config ./CPackConfig.cmake > CMake Error at CMakeModules/CMakeCPackOptions.cmake:4 (install): > Unknown CMake command "install". > > CPack Error: Cannot initialize the generator TGZ > > What am I doing wrong? Any other way to run `install()` only for > certain generators? Thanks > CMakeCPackOptions.cmake is run when CPack runs a.k.a. "CPack time" At that time the CMake language interpreter running is in **scripting mode** (much like when you run cmake -P yourscript.cmake) "install" command is not a scriptable command meaning that is cannot be used in such CMake script. The same is true for add_library or add_executable etc... This is because those commande are **declarative** they do not act when they are processed but they trigger the generation of other commands that will be run when building/installing. Those "non-scriptable" commands may only be used at "CMake time" i.e. when CMake is running for configuring your project. Using COMPONENT is a possible solution. When using COMPONENT the variable CPACK_COMPONENTS_ALL controls which components are to be shipped by the CPack generator. So what you can do in your CPACK_PROJECT_CONFIG_FILE is to selectively set CPACK_COMPONENTS_ALL to appropriate value: if ("${CPACK_GENERATOR}" MATCHES "ZIP") set(CPACK_COMPONENTS_ALL comp1 com2 extracomp) else() set(CPACK_COMPONENTS_ALL comp1 com2) endif() And this should work. More doc references here: http://cmake.org/Wiki/CMake:Component_Install_With_CPack http://cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29 http://cmake.org/cmake/help/v3.0/module/CPackComponent.html http://cmake.org/cmake/help/v3.0/module/CPack.html?highlight=cpack_project#variable:CPACK_PROJECT_CONFIG_FILE -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From bochecha at daitauha.fr Fri Sep 25 04:41:19 2015 From: bochecha at daitauha.fr (Mathieu Bridon) Date: Fri, 25 Sep 2015 10:41:19 +0200 Subject: [CMake] Can't build something with MinGW Message-ID: <1443170479.2322.9.camel@daitauha.fr> Hi everyone, I've been trying to build something for Windows on Fedora with MinGW and I'm hitting a road block. First, the problem: CMake fails trying to test the C++ compiler with the following error message: Linking CXX executable cmTC_f5bba /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_f5bba.dir/link.txt --verbose=1 /usr/bin/i686-w64-mingw32-g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 CMakeFiles/cmTC_f5bba.dir/testCXXCompiler.cxx.o -o cmTC_f5bba -rdynamic i686-w64-mingw32-g++: error: unrecognized command line option '-rdynamic' The -rdynamic flag is indeed not supported with MinGW, so CMake shouldn't pass it. I'm using Fedora's mingw32-cmake command which passes this toolchain file to CMake: http://pkgs.fedoraproject.org/cgit/mingw-filesystem.git/tree/toolchain- mingw32.cmake?h=f22 As you can see, it sets CMAKE_SYSTEM_NAME to Windows. After a few hours of trying to figuring this out, and adding MESSAGE(...) lines everywhere in the /usr/share/cmake files involved in building the project, I added the following line to the top of the /usr/share/cmake/Modules/CMakeCXXInformation.cmake file: MESSAGE("CMAKE_SYSTEM_NAME: ${CMAKE_SYSTEM_NAME}") I'm attaching the full output of the build to this email. In it, you will see that for most of the build, the CMAKE_SYSTEM_NAME variable is correctly set to "Windows", until a point where it is set to "Linux". As a result, the /usr/share/cmake/Modules/Platform/Linux-GNU.cmake file gets loaded, which contains this line: set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-rdynamic") And this is exactly what causes my build to fail. So I guess something is wrong here. I don't know much CMake, but I find it surprising that the CMAKE_SYSTEM_NAME variable would change like this in the middle of the build process. What am I doing wrong? :) Thanks, -- Mathieu -------------- next part -------------- A non-text attachment was scrubbed... Name: build.log Type: text/x-log Size: 3755 bytes Desc: not available URL: From thomas at junovagen.se Fri Sep 25 05:03:28 2015 From: thomas at junovagen.se (thoni56) Date: Fri, 25 Sep 2015 02:03:28 -0700 (MST) Subject: [CMake] CMP0054 and CMake Modules In-Reply-To: <55FFC418.6090305@gmail.com> References: <1442821031560-7591577.post@n2.nabble.com> <55FFBB80.3030903@gmail.com> <1442823881550-7591580.post@n2.nabble.com> <55FFC418.6090305@gmail.com> Message-ID: <1443171808575-7591629.post@n2.nabble.com> Any idea why this only happens on Cygwin? Not on Linux or MacOSX. Is this a clue to something? How can I use this information to debug the issue further? /Thomas -- View this message in context: http://cmake.3232098.n2.nabble.com/CMP0054-and-CMake-Modules-tp7590137p7591629.html Sent from the CMake mailing list archive at Nabble.com. From john.barbero.unenge at gmail.com Fri Sep 25 05:58:03 2015 From: john.barbero.unenge at gmail.com (John Barbero Unenge) Date: Fri, 25 Sep 2015 11:58:03 +0200 Subject: [CMake] find_package for both debug and release with Visual Studio Message-ID: I'm tearing my hair out about how to include thrid party libraries in my cmake project. Currently I build Poco and a bunch of others that all generate their respective Config.cmake which I use with find_package. I have a wrapping build script that builds all of my dependencies and package them separately for debug and release (I don't want to tweak their cmake-scripts unless I really really really need to because maintanance). I thought I could just do: find_package(Foo HINTS "${CMAKE_SOURCE_DIR}/some/path/debug/libFoo/lib/cmake" REQUIRED ) get_target_property(LIB_FOO_DEBUG lib_foo LOCATION) find_package(Foo HINTS "${CMAKE_SOURCE_DIR}/some/path/release/libFoo/lib/cmake" REQUIRED ) get_target_property(LIB_FOO_RELEASE lib_foo LOCATION) set(LIB_FOO_LIBRARIES optimized "${LIB_FOO_RELEASE}" debug "${LIB_FOO_DEBUG}") message("LIB_FOO_LIBRARIES: \"${LIB_FOO_LIBRARIES}\"") # Gives: LIB_FOO_LIBRARIES: " optimized;C:/path/to/proj/some/path/debug/libFoo/lib/foo.lib;debug;C:/path/to/proj/some/path/debug/libFoo/lib/foo.lib" It seems like the first call to find_package for target Foo is cached, whis I don't really want. Am I going about this the wrong way? How do I properly work with 3rd party libraries with the Visual Studio generator? Any pointers are greatly appreciated. / John -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Sep 25 05:58:34 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 25 Sep 2015 11:58:34 +0200 Subject: [CMake] CMP0054 and CMake Modules In-Reply-To: <1443171808575-7591629.post@n2.nabble.com> References: <1442821031560-7591577.post@n2.nabble.com> <55FFBB80.3030903@gmail.com> <1442823881550-7591580.post@n2.nabble.com> <55FFC418.6090305@gmail.com> <1443171808575-7591629.post@n2.nabble.com> Message-ID: <56051ACA.80303@gmail.com> On 09/25/2015 11:03 AM, thoni56 wrote: > Any idea why this only happens on Cygwin? Not on Linux or MacOSX. Is this a > clue to something? How can I use this information to debug the issue > further? There are platform and compiler specific cmake modules which may only get processed when using cygwin. Your project might use conditionals that only evaluate true on cygwin like e.g. the obvious if(CYGWIN) ... endif(). Beyond the aforementioned --trace-expand you could also try inserting something like the following snippet to the very top (before anything else) of your root-CMakeLists.txt: function(my_watch) message("-----------------") foreach(ARG ${ARGN}) message("[${ARG}]") endforeach() endfunction() variable_watch("" my_watch) If you do not have an explicit project() call in your root-CMakeLists.txt yet add one; otherwise the implicit project() call that cmake injects will be evaluated before the rest of your CMakeLists.txt. It should print out locations (sadly apparently without line numbers) where the empty named variable is accessed. That way you might be able to find the first file that modifies the empty named variable at least (probably the first with "MODIFIED_ACCESS"). Nils From audiofanatic at gmail.com Fri Sep 25 06:17:52 2015 From: audiofanatic at gmail.com (Craig Scott) Date: Fri, 25 Sep 2015 20:17:52 +1000 Subject: [CMake] Testing for existence of a target in a generator expression Message-ID: I can't see anything in the CMake docs which seems to facilitate this, but I was wondering if there's any way to test whether a target is defined inside a generator expression? What I'd like to be able to do is something like this: target_compile_definitions(bar PUBLIC $:HAVE_FOO>) This would open up the possibility of setting build flags, etc. depending on things defined later in the CMakeLists.txt file. For a good example of the sort of problem it might solve, have a look at the following question on StackOverflow: http://stackoverflow.com/questions/32766151/check-for-optionally-targets-in-cmake-that-are-not-in-the-correct-order -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dank at kegel.com Fri Sep 25 09:27:56 2015 From: dank at kegel.com (Dan Kegel) Date: Fri, 25 Sep 2015 06:27:56 -0700 Subject: [CMake] find_package for both debug and release with Visual Studio In-Reply-To: References: Message-ID: "John Barbero Unenge" wrote: > > I'm tearing my hair out about how to include thrid party libraries in my cmake project. Currently I build Poco and a bunch of others that all generate their respective Config.cmake which I use with find_package. I have a wrapping build script that builds all of my dependencies and package them separately for debug and release ... > > I thought I could just do: > > find_package(Foo > HINTS "${CMAKE_SOURCE_DIR}/some/path/debug/libFoo/lib/cmake" > REQUIRED > ) > get_target_property(LIB_FOO_DEBUG lib_foo LOCATION) > > find_package(Foo > HINTS "${CMAKE_SOURCE_DIR}/some/path/release/libFoo/lib/cmake" > REQUIRED > ) > get_target_property(LIB_FOO_RELEASE lib_foo LOCATION) > > set(LIB_FOO_LIBRARIES optimized "${LIB_FOO_RELEASE}" debug "${LIB_FOO_DEBUG}") > > message("LIB_FOO_LIBRARIES: \"${LIB_FOO_LIBRARIES}\"") > # Gives: LIB_FOO_LIBRARIES: "optimized;C:/path/to/proj/some/path/debug/libFoo/lib/foo.lib;debug;C:/path/to/proj/some/path/debug/libFoo/lib/foo.lib" > > It seems like the first call to find_package for target Foo is cached, whis I don't really want. > > Am I going about this the wrong way? How do I properly work with 3rd party libraries with the Visual Studio generator? > > Any pointers are greatly appreciated. Qt seems to manage it, if I'm reading http://doc.qt.io/qt-5/cmake-manual.html right. Maybe you can find a clue there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamas.kenez at gmail.com Fri Sep 25 09:35:54 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Fri, 25 Sep 2015 15:35:54 +0200 Subject: [CMake] find_package for both debug and release with Visual Studio In-Reply-To: References: Message-ID: 1. build your own project, too, in separate build trees for debug and release 2. if all your dependencies' are prepared to provide debug and release libs simultanously (like Poco) you can build them in separate trees (however not neccessary) but set CMAKE_INSTALL_PREFIX and CMAKE_PREFIX_PATH to the same location for each configuration 3. you can examine CMakeCache.txt and find which variable is cached during find_package and remove it manually (unset(... CACHE)) but this is a hack Tamas On Fri, Sep 25, 2015 at 11:58 AM, John Barbero Unenge < john.barbero.unenge at gmail.com> wrote: > I'm tearing my hair out about how to include thrid party libraries in my > cmake project. Currently I build Poco and a bunch of others that all > generate their respective Config.cmake which I use with > find_package. I have a wrapping build script that builds all of my > dependencies and package them separately for debug and release (I don't > want to tweak their cmake-scripts unless I really really really need to > because maintanance). > > I thought I could just do: > > find_package(Foo > HINTS "${CMAKE_SOURCE_DIR}/some/path/debug/libFoo/lib/cmake" > REQUIRED > ) > get_target_property(LIB_FOO_DEBUG lib_foo LOCATION) > > find_package(Foo > HINTS "${CMAKE_SOURCE_DIR}/some/path/release/libFoo/lib/cmake" > REQUIRED > ) > get_target_property(LIB_FOO_RELEASE lib_foo LOCATION) > > set(LIB_FOO_LIBRARIES optimized "${LIB_FOO_RELEASE}" debug > "${LIB_FOO_DEBUG}") > > message("LIB_FOO_LIBRARIES: \"${LIB_FOO_LIBRARIES}\"") > # Gives: LIB_FOO_LIBRARIES: " > optimized;C:/path/to/proj/some/path/debug/libFoo/lib/foo.lib;debug;C:/path/to/proj/some/path/debug/libFoo/lib/foo.lib" > > It seems like the first call to find_package for target Foo is cached, > whis I don't really want. > > Am I going about this the wrong way? How do I properly work with 3rd party > libraries with the Visual Studio generator? > > Any pointers are greatly appreciated. > > / John > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brunobg at corollarium.com Fri Sep 25 12:13:42 2015 From: brunobg at corollarium.com (Bruno Barberi Gnecco) Date: Fri, 25 Sep 2015 13:13:42 -0300 Subject: [CMake] Adding files to ARCHIVE packages only in CPack In-Reply-To: References: <56046023.80208@corollarium.com> Message-ID: <560572B6.3010505@corollarium.com> On 09/25/2015 05:27 AM, Eric Noulard wrote: > > > 2015-09-24 22:42 GMT+02:00 Bruno Barberi Gnecco >: > > How is it possible to add some files only to the ARCHIVE generators with > CMake/CPack? Apparently components do that, but I can't figure how to say "only add > component X to generator Y". I did something like this: > > In CPackConfig.cmake: > > set(CPACK_PROJECT_CONFIG_FILE > "${CMAKE_CURRENT_SOURCE_DIR}/CMakeModules/CMakeCPackOptions.cmake") > > In CMakeCPackOptions.cmake > > IF (CPACK_GENERATOR MATCHES "TGZ") > install(FILES myextrafile DESTINATION "." COMPONENT static) > ENDIF() > > But I get the following error: > > /usr/local/bin/cpack --config ./CPackConfig.cmake > CMake Error at CMakeModules/CMakeCPackOptions.cmake:4 (install): > Unknown CMake command "install". > > CPack Error: Cannot initialize the generator TGZ > > What am I doing wrong? Any other way to run `install()` only for certain > generators? Thanks > > > > CMakeCPackOptions.cmake is run when CPack runs a.k.a. "CPack time" > At that time the CMake language interpreter running is in **scripting mode** (much like > when you run cmake -P yourscript.cmake) > > "install" command is not a scriptable command meaning that is cannot be used > in such CMake script. The same is true for add_library or add_executable etc... > This is because those commande are **declarative** they do not act when they are processed > but they trigger the generation of other commands that will be run when building/installing. > > Those "non-scriptable" commands may only be used at "CMake time" i.e. when CMake is > running for configuring your project. > > Using COMPONENT is a possible solution. > > When using COMPONENT the variable CPACK_COMPONENTS_ALL controls which components are to be > shipped by the CPack generator. > So what you can do in your CPACK_PROJECT_CONFIG_FILE is to selectively set > CPACK_COMPONENTS_ALL > to appropriate value: > > if ("${CPACK_GENERATOR}" MATCHES "ZIP") > set(CPACK_COMPONENTS_ALL comp1 com2 extracomp) > else() > set(CPACK_COMPONENTS_ALL comp1 com2) > endif() > > And this should work. > > More doc references here: > http://cmake.org/Wiki/CMake:Component_Install_With_CPack > http://cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29 > http://cmake.org/cmake/help/v3.0/module/CPackComponent.html > http://cmake.org/cmake/help/v3.0/module/CPack.html?highlight=cpack_project#variable:CPACK_PROJECT_CONFIG_FILE > > -- > Eric Eric, I appreciate your detailed reply, but I'm still can't make it work. Here's what I did: CPackConfig.cmake: SET(CPACK_PROJECT_CONFIG_FILE "${CMAKE_CURRENT_SOURCE_DIR}/CMakeModules/CMakeCPackOptions.cmake") # SET(CPACK_COMPONENTS_ALL "") commented out .... install(PROGRAMS "something" DESTINATION "." COMPONENT basic) install(PROGRAMS "otherthing" DESTINATION "." COMPONENT optional) CMakeCPackOptions.cmake IF ("${CPACK_GENERATOR}" MATCHES "TGZ") set(CPACK_COMPONENTS_ALL basic) ELSEIF ("${CPACK_GENERATOR}" MATCHES "TBZ2") set(CPACK_COMPONENTS_ALL basic optional) ELSE() SET(CPACK_COMPONENTS_ALL basic) ENDIF() Result: all files from all components are added to the packages. What am I doing wrong? Do you know of some example that I could follow? Thanks. From eric.noulard at gmail.com Fri Sep 25 12:57:59 2015 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 25 Sep 2015 18:57:59 +0200 Subject: [CMake] Adding files to ARCHIVE packages only in CPack In-Reply-To: <560572B6.3010505@corollarium.com> References: <56046023.80208@corollarium.com> <560572B6.3010505@corollarium.com> Message-ID: You missed the fact that not all CPack generator do handle component as a default. You have to set(CPACK_ARCHIVE_COMPONENT_INSTALL ON see: http://cmake.org/Wiki/CMake:Component_Install_With_CPack#CPack_Generator_specific_behavior You'll find a working example in the attached archive. 2015-09-25 18:13 GMT+02:00 Bruno Barberi Gnecco : > On 09/25/2015 05:27 AM, Eric Noulard wrote: > >> >> >> 2015-09-24 22:42 GMT+02:00 Bruno Barberi Gnecco > >: >> >> >> How is it possible to add some files only to the ARCHIVE >> generators with >> CMake/CPack? Apparently components do that, but I can't figure how to >> say "only add >> component X to generator Y". I did something like this: >> >> In CPackConfig.cmake: >> >> set(CPACK_PROJECT_CONFIG_FILE >> "${CMAKE_CURRENT_SOURCE_DIR}/CMakeModules/CMakeCPackOptions.cmake") >> >> In CMakeCPackOptions.cmake >> >> IF (CPACK_GENERATOR MATCHES "TGZ") >> install(FILES myextrafile DESTINATION "." COMPONENT static) >> ENDIF() >> >> But I get the following error: >> >> /usr/local/bin/cpack --config ./CPackConfig.cmake >> CMake Error at CMakeModules/CMakeCPackOptions.cmake:4 (install): >> Unknown CMake command "install". >> >> CPack Error: Cannot initialize the generator TGZ >> >> What am I doing wrong? Any other way to run `install()` only >> for certain >> generators? Thanks >> >> >> >> CMakeCPackOptions.cmake is run when CPack runs a.k.a. "CPack time" >> At that time the CMake language interpreter running is in **scripting >> mode** (much like >> when you run cmake -P yourscript.cmake) >> >> "install" command is not a scriptable command meaning that is cannot be >> used >> in such CMake script. The same is true for add_library or add_executable >> etc... >> This is because those commande are **declarative** they do not act when >> they are processed >> but they trigger the generation of other commands that will be run when >> building/installing. >> >> Those "non-scriptable" commands may only be used at "CMake time" i.e. >> when CMake is >> running for configuring your project. >> >> Using COMPONENT is a possible solution. >> >> When using COMPONENT the variable CPACK_COMPONENTS_ALL controls which >> components are to be >> shipped by the CPack generator. >> So what you can do in your CPACK_PROJECT_CONFIG_FILE is to selectively set >> CPACK_COMPONENTS_ALL >> to appropriate value: >> >> if ("${CPACK_GENERATOR}" MATCHES "ZIP") >> set(CPACK_COMPONENTS_ALL comp1 com2 extracomp) >> else() >> set(CPACK_COMPONENTS_ALL comp1 com2) >> endif() >> >> And this should work. >> >> More doc references here: >> http://cmake.org/Wiki/CMake:Component_Install_With_CPack >> >> http://cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29 >> http://cmake.org/cmake/help/v3.0/module/CPackComponent.html >> >> http://cmake.org/cmake/help/v3.0/module/CPack.html?highlight=cpack_project#variable:CPACK_PROJECT_CONFIG_FILE >> >> -- >> Eric >> > > Eric, > > I appreciate your detailed reply, but I'm still can't make it > work. Here's what I did: > > CPackConfig.cmake: > SET(CPACK_PROJECT_CONFIG_FILE > "${CMAKE_CURRENT_SOURCE_DIR}/CMakeModules/CMakeCPackOptions.cmake") > # SET(CPACK_COMPONENTS_ALL "") commented out > .... > install(PROGRAMS "something" DESTINATION "." COMPONENT basic) > install(PROGRAMS "otherthing" DESTINATION "." COMPONENT optional) > > CMakeCPackOptions.cmake > IF ("${CPACK_GENERATOR}" MATCHES "TGZ") > set(CPACK_COMPONENTS_ALL basic) > ELSEIF ("${CPACK_GENERATOR}" MATCHES "TBZ2") > set(CPACK_COMPONENTS_ALL basic optional) > ELSE() > SET(CPACK_COMPONENTS_ALL basic) > ENDIF() > > Result: all files from all components are added to the packages. > > What am I doing wrong? Do you know of some example that I could > follow? Thanks. > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ComponentAndCPackProjectCfgFile.zip Type: application/zip Size: 1581 bytes Desc: not available URL: From audiofanatic at gmail.com Fri Sep 25 19:02:47 2015 From: audiofanatic at gmail.com (Craig Scott) Date: Sat, 26 Sep 2015 09:02:47 +1000 Subject: [CMake] CMake Digest, Vol 137, Issue 50 In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- > From: John Barbero Unenge > To: cmake at cmake.org > Cc: > Date: Fri, 25 Sep 2015 11:58:03 +0200 > Subject: [CMake] find_package for both debug and release with Visual Studio > I'm tearing my hair out about how to include thrid party libraries in my > cmake project. Currently I build Poco and a bunch of others that all > generate their respective Config.cmake which I use with > find_package. I have a wrapping build script that builds all of my > dependencies and package them separately for debug and release (I don't > want to tweak their cmake-scripts unless I really really really need to > because maintanance). > > I thought I could just do: > > find_package(Foo > HINTS "${CMAKE_SOURCE_DIR}/some/path/debug/libFoo/lib/cmake" > REQUIRED > ) > get_target_property(LIB_FOO_DEBUG lib_foo LOCATION) > > find_package(Foo > HINTS "${CMAKE_SOURCE_DIR}/some/path/release/libFoo/lib/cmake" > REQUIRED > ) > get_target_property(LIB_FOO_RELEASE lib_foo LOCATION) > > set(LIB_FOO_LIBRARIES optimized "${LIB_FOO_RELEASE}" debug > "${LIB_FOO_DEBUG}") > > message("LIB_FOO_LIBRARIES: \"${LIB_FOO_LIBRARIES}\"") > # Gives: LIB_FOO_LIBRARIES: " > optimized;C:/path/to/proj/some/path/debug/libFoo/lib/foo.lib;debug;C:/path/to/proj/some/path/debug/libFoo/lib/foo.lib" > > It seems like the first call to find_package for target Foo is cached, > whis I don't really want. > > Am I going about this the wrong way? How do I properly work with 3rd party > libraries with the Visual Studio generator? > > Any pointers are greatly appreciated. > > / John > Not sure if it will be relevant for you, but if the third party libraries you want to use are themselves built with CMake, you can make them part of your build directly. This has the following advantages in your scenario: - They will inherit the same debug/release config as your main project. - No need to explicitly tell CMake where anything is because all targets in the third party library are part of the build. Instead of using find_package, you can just link directly to the targets by CMake target name. The trick for this is to download the source of the third party library at CMake time (caching it so it only downloads once) and then pull it in via add_subdirectory(). The technique is discussed here with GoogleTest as the example: http://crascit.com/2015/07/25/cmake-gtest/ The technique uses ExternalProject to manage the download but it does so by invoking it as a script to get it to do its thing at CMake time rather than build time. -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From audiofanatic at gmail.com Fri Sep 25 19:04:33 2015 From: audiofanatic at gmail.com (Craig Scott) Date: Sat, 26 Sep 2015 09:04:33 +1000 Subject: [CMake] Apologies! Message-ID: Sorry for the rookie mistake not changing the subject on that last post. ;) -- Craig Scott Melbourne, Australia http://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramey at rrsd.com Sun Sep 27 00:30:02 2015 From: ramey at rrsd.com (Robert Ramey) Date: Sat, 26 Sep 2015 21:30:02 -0700 Subject: [CMake] CDash [Safe Numerics] - Administration Message-ID: I see that some people are posting results to my dashboard http://my.cdash.org/index.php?project=Safe+Numerics&filtercount=1&showfilters=1&field1=buildstarttime/date&compare1=83&value1=1%20year%20ago - but lately I?ve been getting the following message. Unfortunately, the message doesn?t tell me what to change to make this work! So I need some help. Any suggestions appreciated. Begin forwarded message: From: CDash Subject: CDash [Safe Numerics] - Administration Date: September 23, 2015 at 2:54:51 PM PDT To: admin at cdash.org, ramey at rrsd.com Reply-To: noreply at cdash.org Object: Cannot create handler based on XML content An XML submission from 41.220.69.175 to the project Safe Numerics cannot be parsed. The content of the file is as follow: -CDash on my.cdash.org Robert Ramey Robert Ramey Software Development (805)569-3793 ramey at rrsd.com www.rrsd.com From viridia at gmail.com Sun Sep 27 16:29:15 2015 From: viridia at gmail.com (Talin) Date: Sun, 27 Sep 2015 13:29:15 -0700 Subject: [CMake] Is the situation with CMake + Eclipse ever going to get any better? Message-ID: I've been using CMake and Eclipse for a bunch of different projects over the last several years. Although many aspects of both CMake and Eclipse have improved over the years, using them together still has a lot of problems. >From what I understand, you have three choices when setting up a project: 1) Use in-source builds. 2) Use out-of-source builds with a single generated project. 3) Use out-of-source builds with both a build project and a source project. Option (1) has a lot of problems, especially if you have multiple build configurations. I won't go into the details here, but most of the CMake tutorials I've seen recommend against this. Option (2) means that you can't use EGit or any other version control system integrated with Eclipse. Option (3) means that Eclipse thinks that you have two copies of every source file - every time you search, or open a file by name, you get two entries for the same file. Usually what you end up with is an editor window with lots of duplicate tabs. Now, some people have recommended that you set the "derived" flag on the source files in the "build" project to cause Eclipse to ignore the files in that project, but this creates even worse problems. For one thing, the error links in the build console output point to the build project, not the source project. So when you get a compiler error and click on the link, it opens the wrong version of the file. Thus you still end up with an editor window full of duplicate tabs - and if you select the wrong one and type a character, you get the annoying "this is a derived file, are you sure you want to edit it?" dialog. This happens frequently enough to be a serious annoyance - I generally end up turning 'derived' off since it's less painful. There's a fourth option, actually, which is use a different IDE :) However, my projects tend to be multi-language projects - i.e. they have support libraries for C++, Python, Java, and so on. They also tend to have a lot of custom build targets (an example would be a script that invokes the Google protobuf generator). Unfortunately, there aren't very many decent IDEs that can handle more than one source language or custom build targets. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Sun Sep 27 16:57:33 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Sun, 27 Sep 2015 22:57:33 +0200 Subject: [CMake] Is the situation with CMake + Eclipse ever going to get any better? In-Reply-To: References: Message-ID: <360852601.krIo4RoXxL@tuxedo.neundorf.net> Hi, On Sunday, September 27, 2015 13:29:15 Talin wrote: > I've been using CMake and Eclipse for a bunch of different projects over > the last several years. Although many aspects of both CMake and Eclipse > have improved over the years, using them together still has a lot of > problems. > > From what I understand, you have three choices when setting up a project: > > 1) Use in-source builds. > 2) Use out-of-source builds with a single generated project. > 3) Use out-of-source builds with both a build project and a source project. the problem is that Eclipse does not support a directory layout where the project file is not the root of the source directory. In my simplistic view it would be a simple tag in the .project file, and Eclipse would afterwards use that directory as root directory. If something like that would be done in Eclipse, all those problems would be solved. Alex From DLRdave at aol.com Sun Sep 27 18:35:25 2015 From: DLRdave at aol.com (David Cole) Date: Sun, 27 Sep 2015 18:35:25 -0400 Subject: [CMake] CDash [Safe Numerics] - Administration In-Reply-To: References: Message-ID: This message is sent when an unparseable xml file is submitted to CDash. The email says the contents are as follows, with nothing (the empty string) following... So, usually, this is some bot sending garbage to your CDash url. There is nothing for you to do, but ignore these. If they are too frequent, and coming from a suspicious IP address, you can ban submissions from that IP address. HTH, David C. On Sunday, September 27, 2015, Robert Ramey wrote: > I see that some people are posting results to my dashboard > http://my.cdash.org/index.php?project=Safe+Numerics&filtercount=1&showfilters=1&field1=buildstarttime/date&compare1=83&value1=1%20year%20ago > - but lately I?ve been getting the following message. Unfortunately, the > message doesn?t tell me what to change to make this work! So I need some > help. Any suggestions appreciated. > > > Begin forwarded message: > > From: CDash > Subject: CDash [Safe Numerics] - Administration > Date: September 23, 2015 at 2:54:51 PM PDT > To: admin at cdash.org, ramey at rrsd.com > Reply-To: noreply at cdash.org > > Object: Cannot create handler based on XML content > An XML submission from 41.220.69.175 to the project Safe Numerics cannot > be parsed. The content of the file is as follow: > > -CDash on my.cdash.org > > > Robert Ramey > Robert Ramey Software Development > (805)569-3793 > ramey at rrsd.com > www.rrsd.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 mcatanzaro at gnome.org Sun Sep 27 20:47:32 2015 From: mcatanzaro at gnome.org (Michael Catanzaro) Date: Sun, 27 Sep 2015 19:47:32 -0500 Subject: [CMake] Seemingly-unfixable warning about CMP0058 after upgrade to CMake 3.3 Message-ID: <1443401252.19521.4.camel@gnome.org> Hi, After upgrading to CMake 3.3, I'm seeing this warning when running CMake on WebKitGTK+: CMake Warning (dev): Policy CMP0058 is not set: Ninja requires custom command byproducts to be explicit. Run "cmake --help-policy CMP0058" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This project specifies custom command DEPENDS on files in the build tree that are not specified as the OUTPUT or BYPRODUCTS of any add_custom_command or add_custom_target: DerivedSources/webkit2gtk/WebKit2ResourcesGResourceBundle.xml For compatibility with versions of CMake that did not have the BYPRODUCTS option, CMake is generating phony rules for such files to convince 'ninja' to build. Project authors should add the missing BYPRODUCTS or OUTPUT options to the custom commands that produce these files. This warning is for project developers. Use -Wno-dev to suppress it. But DerivedSources/webkit2gtk/WebKit2ResourcesGResourceBundle.xml is not generated by add_custom_command or add_custom_target, it's generated by the file command (in WebKit/Source/WebKit2/PlatformGTK.cmake [1]): file(WRITE ${DERIVED_SOURCES_WEBKIT2GTK_DIR}/WebKit2ResourcesGResourceBundle.xml "\n" "\n" " \n" ${WebKit2Resources} " \n" "\n" ) So there's no way to specify it as a BYPRODUCT. This seems like a defect in CMake, unless I am missing something...? It's building fine, so not a big deal; just would be nice to get rid of the warning. Michael [1] https://github.com/WebKit/webkit/blob/master/Source/WebKit2/Platfor mGTK.cmake From eldlistmailingz at tropicsoft.com Sun Sep 27 23:08:05 2015 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Sun, 27 Sep 2015 23:08:05 -0400 Subject: [CMake] CMake GUI suggestion - saving/restoring configurations Message-ID: It would really be nice if the CMake GUI program could save and restore configurations for whatever CMake setups the end-user uses. By this I mean the ability to save the paths to the source code and where the binaries should be built, as well as its corresponding cache information, under a user-defined name; and subsequently restore that information once the end-user chooses that user-defined name from a drop-down list of those that have been saved. This would enable as many configurations as the end-user uses CMake for in an easily usable way using the CMake GUI program. Another welcome improvement to the CMake GUI would be a drop-down list or combobox whenever an item has a set of values to choose from, with the CMAKE_BUILD_TYPE being an example of such a field. The CMake GUI is a great program for using CMake and I hope my suggestions can make it better. From istvancsanady at gmail.com Mon Sep 28 04:51:36 2015 From: istvancsanady at gmail.com (=?UTF-8?B?SXN0dsOhbiBDc2Fuw6FkeQ==?=) Date: Mon, 28 Sep 2015 08:51:36 +0000 Subject: [CMake] Xcode Link Binary With Libraries phase Message-ID: Hi, I have multiple framework targets in my project, that depend on each other. I add the linking phase using the target_link_libraries command target_link_libraries (${PROJECT_NAME} ${USED_LIBS}) that will create linker flags like this: /Users/icsanady/occt_git/occt/src/TKernel/Debug$(EFFECTIVE_PLATFORM_NAME)/TKernel.framework/Versions/A/TKernel There are two problems with this: 1. I don't want to link to the full path, but rather a relative path 2. My frameworks are not versioned, so I want the trailing /Versions/A part removed If I add the dependent framework through the Build Phases/Link Binary With Libraries phase, everything works as expected. Can I somehow add that build phase with CMake? Thanks, Istvan -------------- next part -------------- An HTML attachment was scrubbed... URL: From benoit.bleuze at 1000shapes.com Mon Sep 28 09:40:23 2015 From: benoit.bleuze at 1000shapes.com (=?UTF-8?B?QmVub8OudCBCbGV1esOp?=) Date: Mon, 28 Sep 2015 15:40:23 +0200 Subject: [CMake] "Special" targets, and renaming packages Message-ID: <56094347.5010302@1000shapes.com> Hi all, I understand targets such as "install" and "package" are special targets, and that one can not depend on them. I have found in the mailing list's archive an old thread mentioning that very problem (http://cmake.org/pipermail/cmake/2009-November/033210.html), with an allegedly existing bug on that topic. Unfortunately I could not find any trace of such a bug report. Can someone give me pointer on : 1 why are those targets not "dependable"? 2 What was the outcome of the old bug report (if someone know how to find it) and its rationale? 3 Is there any plan to make them first class citizens? Linked to this general question, I have a practical problem. The PACKAGE_NAME variable is fairly limited. When one uses components with the archive generator, one can not control the output name of the packages in a simple variable. This is fine, I guess creating package name variables for each component would be silly. However the problem would be solved with a target that would rename the individual archives AFTER being generated. As a work around, at the moment I use the "configure_file" command to create a bash script that calls this : cmake --build @CMAKE_BINARY_DIR@ --target package --config @PACKAGE_ORIG_CONFIG@ And then the script renames packages (archive components) with some particular naming scheme. This way I get my renamed packages AFTER building my packages, but I need to run cmake a first time to configure the project and my script, then this script can build and package the whole shebang. The script is dumb enough (renaming 5 files after given some regular expressions) that it can run on all platform (msysgit on Windows), but it does not sound very cmake like to me. Is there a better way out there to rename individual archive package component? Thanks for the help, Ben. From nilsgladitz at gmail.com Mon Sep 28 10:04:40 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 28 Sep 2015 16:04:40 +0200 Subject: [CMake] "Special" targets, and renaming packages In-Reply-To: <56094347.5010302@1000shapes.com> References: <56094347.5010302@1000shapes.com> Message-ID: <560948F8.6020803@gmail.com> On 09/28/2015 03:40 PM, Beno?t Bleuz? wrote: > 2 What was the outcome of the old bug report (if someone know how to > find it) and its rationale? http://cmake.org/Bug/view.php?id=8438 > Linked to this general question, I have a practical problem. The > PACKAGE_NAME variable is fairly limited. This might be somewhat related: http://cmake.org/Bug/view.php?id=8438 Nils From benoit.bleuze at 1000shapes.com Mon Sep 28 10:26:47 2015 From: benoit.bleuze at 1000shapes.com (=?UTF-8?B?QmVub8OudCBCbGV1esOp?=) Date: Mon, 28 Sep 2015 16:26:47 +0200 Subject: [CMake] "Special" targets, and renaming packages In-Reply-To: <560948F8.6020803@gmail.com> References: <56094347.5010302@1000shapes.com> <560948F8.6020803@gmail.com> Message-ID: <56094E27.7090001@1000shapes.com> On 09/28/2015 04:04 PM, Nils Gladitz wrote: > On 09/28/2015 03:40 PM, Beno?t Bleuz? wrote: >> 2 What was the outcome of the old bug report (if someone know how to >> find it) and its rationale? > > http://cmake.org/Bug/view.php?id=8438 Thank you Nils for the pointer, I missed the key word "built-in" target which would have brought me there. > >> Linked to this general question, I have a practical problem. The >> PACKAGE_NAME variable is fairly limited. > > This might be somewhat related: > http://cmake.org/Bug/view.php?id=8438 > Yes, sure the comments in that issue are all about depending on a built in target, but I do not see your point, unless you messed up the copy and paste and meant to send another link? ;-) > Nils I guess I'll try to up-vote the issue, but short of diving in and patching the source code of cmake, is there anything a user can do to help fix the issue at this stage? Ben From nilsgladitz at gmail.com Mon Sep 28 10:35:22 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 28 Sep 2015 16:35:22 +0200 Subject: [CMake] "Special" targets, and renaming packages In-Reply-To: <56094E27.7090001@1000shapes.com> References: <56094347.5010302@1000shapes.com> <560948F8.6020803@gmail.com> <56094E27.7090001@1000shapes.com> Message-ID: <5609502A.4040806@gmail.com> On 09/28/2015 04:26 PM, Beno?t Bleuz? wrote: >> This might be somewhat related: >> http://cmake.org/Bug/view.php?id=8438 >> > unless you messed up the copy and paste and meant to send another link? ;-) Yes, sorry about that; this was supposed to be: http://cmake.org/Bug/view.php?id=12997 Nils From benoit.bleuze at 1000shapes.com Mon Sep 28 10:42:42 2015 From: benoit.bleuze at 1000shapes.com (=?UTF-8?B?QmVub8OudCBCbGV1esOp?=) Date: Mon, 28 Sep 2015 16:42:42 +0200 Subject: [CMake] "Special" targets, and renaming packages In-Reply-To: <5609502A.4040806@gmail.com> References: <56094347.5010302@1000shapes.com> <560948F8.6020803@gmail.com> <56094E27.7090001@1000shapes.com> <5609502A.4040806@gmail.com> Message-ID: <560951E2.4040306@1000shapes.com> On 09/28/2015 04:35 PM, Nils Gladitz wrote: > On 09/28/2015 04:26 PM, Beno?t Bleuz? wrote: >>> This might be somewhat related: >>> http://cmake.org/Bug/view.php?id=8438 >>> > >> unless you messed up the copy and paste and meant to send another >> link? ;-) > > Yes, sorry about that; this was supposed to be: > http://cmake.org/Bug/view.php?id=12997 > > Nils > > > This bug exactly describes my current problems, and indeed some user-defined templates for package names would get where I want to be. Thanks again Nils, Ben. From brad.king at kitware.com Mon Sep 28 11:51:52 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 28 Sep 2015 11:51:52 -0400 Subject: [CMake] Seemingly-unfixable warning about CMP0058 after upgrade to CMake 3.3 In-Reply-To: <1443401252.19521.4.camel@gnome.org> References: <1443401252.19521.4.camel@gnome.org> Message-ID: <56096218.4050602@kitware.com> On 09/27/2015 08:47 PM, Michael Catanzaro wrote: > CMake Warning (dev): > Policy CMP0058 is not set: Ninja requires custom command byproducts to be > explicit. Run "cmake --help-policy CMP0058" for policy details. Use the > cmake_policy command to set the policy and suppress this warning. Add this code to the project: if(POLICY CMP0058) cmake_policy(SET CMP0058 NEW) endif() just after any cmake_minimum_required(VERSION) call that does not specify at least CMake 3.3. This will set the policy to NEW and get the new behavior with no warning. In the future when the project's call to cmake_minimum_required(VERSION) specifies 3.3 or higher then this explicit policy setting can be removed. > This project specifies custom command DEPENDS on files in the build tree > that are not specified as the OUTPUT or BYPRODUCTS of any > add_custom_command or add_custom_target: [snip] > But DerivedSources/webkit2gtk/WebKit2ResourcesGResourceBundle.xml is > not generated by add_custom_command or add_custom_target The warning says the file is in the DEPENDS of a custom command, which it is. The warning also says that the file is not specified as generated by a custom command, which it isn't. This is a case for which the warning was intended. > it's generated by the file command (in WebKit/Source/WebKit2/PlatformGTK.cmake [1]): > > file(WRITE ${DERIVED_SOURCES_WEBKIT2GTK_DIR}/WebKit2ResourcesGResourceBundle.xml [snip] > So there's no way to specify it as a BYPRODUCT. [snip] > For compatibility with versions of CMake that did not have the BYPRODUCTS > option, CMake is generating phony rules for such files to convince 'ninja' > to build. CMake is warning that it now prefers to generate the Ninja build file for this case a different way than it did before but is doing it the old way for compatibility just in case the project needs that to build. In this case we know we are providing the file ourselves so it is safe to allow CMake to generate the build file without the extra phony rule. One can set the policy to NEW to get the new preferred behavior, but this has to be done in the project itself once it is known that the new behavior works for the project. See the full policy documentation here for more details: https://cmake.org/cmake/help/v3.3/policy/CMP0058.html -Brad From fifteenknots505 at gmail.com Mon Sep 28 14:00:44 2015 From: fifteenknots505 at gmail.com (Martin Weber) Date: Mon, 28 Sep 2015 20:00:44 +0200 Subject: [CMake] Is the situation with CMake + Eclipse ever going to get any better? In-Reply-To: References: Message-ID: <4929585.MATVY4vXx5@linux> Am Sonntag, 27. September 2015, 13:29:15 schrieb Talin: > I've been using CMake and Eclipse for a bunch of different projects over > the last several years. Although many aspects of both CMake and Eclipse > have improved over the years, using them together still has a lot of > problems. > > From what I understand, you have three choices when setting up a project: > > 1) Use in-source builds. > 2) Use out-of-source builds with a single generated project. > 3) Use out-of-source builds with both a build project and a source project. If you are building C/C++ sources, set up a CDT project. ADVERTISING: Then let generate the makefiles. (I am the author of it). It is not perfect due to the quirks in CDT, but it avoids that extra manual invocation of 'cmake -G whatever'. Martin -- Cd wrttn wtht vwls s mch trsr. From gerryw at compvia.com Tue Sep 29 06:25:18 2015 From: gerryw at compvia.com (Gerry Weaver) Date: Tue, 29 Sep 2015 10:25:18 +0000 Subject: [CMake] Custom Module Message-ID: <1443522312917.8279@compvia.com> Hello All, I'm trying to use a custom module, but I can't get cmake to see it. I am on FreeBSD 9.3 (amd64) using cmake-3.3.2. I have read and tried everything I can find on the topic. I have verified the module path via the "MESSAGE" command, but no joy. I have included all relevant information below. Any help would be much appreciated. BTW: I also tried putting the .cmake files in the cmake Modules directory. Thanks, -S set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_CURRENT_SOURCE_DIR}/cmake/Modules/") MESSAGE( STATUS "CMAKE_MODULE_PATH: " ${CMAKE_MODULE_PATH} ) find_package(NIM) FindNIM.cmake --------------------- include(CMakeParseArguments) find_program(NIM_EXECUTABLE nimrod PATHS ENV PATH) mark_as_advanced(NIM_EXECUTABLE) # Determine the valac version if(NIM_EXECUTABLE) execute_process(COMMAND ${NIM_EXECUTABLE} "--version" OUTPUT_VARIABLE NIM_VERSION OUTPUT_STRIP_TRAILING_WHITESPACE) STRING(REGEX MATCH "[0-9]+\\.[0-9]+\\.[0-9]+" NIM_VERSION ${NIM_VERSION}) endif(NIM_EXECUTABLE) # Handle the QUIETLY and REQUIRED arguments, which may be given to the find call . # set NIM_FOUND to TRUE if Nimrod has been found include(FindPackageHandleStandardArgs) find_package_handle_standard_args(Nim REQUIRED_VARS NIM_EXECUTABLE VERSION_VAR NIM_VERSION) set(NIM_USE_FILE "${CMAKE_CURRENT_LIST_DIR}/UseNim.cmake") UseNim.cmake -------------------- include(CMakeParseArguments) function(add_nim_executable ) cmake_parse_arguments(ARGS "" "TARGET" "SOURCES" ${ARGN}) # collect set of input source files set(in_files "") foreach(src ${ARGS_SOURCES} ${ARGS_UNPARSED_ARGUMENTS}) list(APPEND in_files "${CMAKE_CURRENT_SOURCE_DIR}/${src}") endforeach(src ${ARGS_SOURCES} ${ARGS_UNPARSED_ARGUMENTS}) # set the target binary and nim cache directory set(nim_target "${CMAKE_CURRENT_BINARY_DIR}/${ARGS_TARGET}") set(DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/nimcache") # add target to trigger the nimrod compiler add_custom_target( nim ALL COMMAND ${NIM_EXECUTABLE} "c" "--nimcache:" ${DIRECTORY} "--out:" ${nim_ target} ${in_files} DEPENDS ${in_files} endfunction(add_nim_executable) -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Sep 29 06:44:56 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 29 Sep 2015 12:44:56 +0200 Subject: [CMake] Custom Module In-Reply-To: <1443522312917.8279@compvia.com> References: <1443522312917.8279@compvia.com> Message-ID: <560A6BA8.3080900@gmail.com> On 09/29/2015 12:25 PM, Gerry Weaver wrote: > Hello All, > > > I'm trying to use a custom module, but I can't get cmake to see it. I am > on FreeBSD 9.3 (amd64) using cmake-3.3.2. I have read and tried > everything I can find on the topic. I have verified the module path via > the "MESSAGE" command, but no joy. I have included all relevant > information below. Any help would be much appreciated. What exact output (diagnostics) do you get from cmake? The module is found for me (Ubuntu) as expected but contains a syntax error. FindNIM.cmake contains a line with nothing but a "." but that may be a copy&paste error? Nils From mcatanzaro at gnome.org Tue Sep 29 08:40:49 2015 From: mcatanzaro at gnome.org (Michael Catanzaro) Date: Tue, 29 Sep 2015 07:40:49 -0500 Subject: [CMake] Seemingly-unfixable warning about CMP0058 after upgrade to CMake 3.3 In-Reply-To: <56096218.4050602@kitware.com> References: <1443401252.19521.4.camel@gnome.org> <56096218.4050602@kitware.com> Message-ID: <1443530449.2889.2.camel@gnome.org> On Mon, 2015-09-28 at 11:51 -0400, Brad King wrote: > CMake is warning that it now prefers to generate the Ninja build file > for this case a different way than it did before but is doing it the > old way for compatibility just in case the project needs that to > build. > In this case we know we are providing the file ourselves so it is > safe > to allow CMake to generate the build file without the extra phony > rule. > One can set the policy to NEW to get the new preferred behavior, but > this has to be done in the project itself once it is known that the > new > behavior works for the project. Thanks for the explanation, Brad! Michael From attila.krasznahorkay at gmail.com Tue Sep 29 10:01:49 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Tue, 29 Sep 2015 16:01:49 +0200 Subject: [CMake] Associating a single build step with multiple sub-projects in CDash Message-ID: Dear All, After the suggestion from Bill Hoffman, I played with CDash for a while now. I was able to create a ctest script that would build the packages/subdirectories of my project one by one, and then upload the build/test results to a CDash server. With the results being quite user friendly on the webpage. However this is unfortunately terribly slow. The project that I'm trying to build as an exercise has ~120 packages/subdirectories. Each with 1-20 source files. As you can imagine there's a huge difference between calling "make" just once to let all targets build at the same time, or to call it 120 times for the separate packages. The CPU utilisation in the latter case is less than 50% overall. (With the "Unix Makefiles" generator it's around 30%, and with Ninja around 50%. On an machine with 8 threads.) But I noticed that when I build the project with CTEST_USE_LAUNCHERS enabled, even in a fully parallel build the output generated by CTest/CMake associates the build warnings/errors with the labels that I gave to the targets in my build. (Which correspond to the names of the packages.) Unfortunately however I'm unable to upload the results from this single build step to CDash such that the warnings/errors belonging to the different sub-projects would show up under those sub-projects. :-( I tried this with the following code: # Execute the project build: ctest_build( BUILD ${CTEST_BINARY_DIRECTORY} APPEND ) # The subprojects to build/test: set( _subprojects @CTEST_PROJECT_SUBPROJECTS@ ) foreach( _subproject ${_subprojects} ) # Upload the build results for this package: set_property( GLOBAL PROPERTY SubProject Package_${_subproject} ) set_property( GLOBAL PROPERTY Label Package_${_subproject} ) set( CTEST_BUILD_TARGET Package_${_subproject} ) ctest_submit( PARTS Build ) # Execute the test(s) of the subproject: ctest_test( BUILD ${CTEST_BINARY_DIRECTORY} INCLUDE_LABEL Package_${_subproject} APPEND ) ctest_submit( PARTS Test ) endforeach() But this doesn't do what I was hoping for. (No filtering is made from the one big XML to just pick out the warnings/errors belonging to the currently processed package.) Now, the current situation is already a lot better than I was in a few days ago. As the XML files generated by ctest in this case seem like a very good starting point to process using our nightly build system to present the warnings/errors on our privately produced webpages. But I wonder if it could be possible to also teach CTest/CDash how to do this sort of thing out of the box... Cheers, Attila From mkeeler at tenable.com Tue Sep 29 15:03:12 2015 From: mkeeler at tenable.com (Matthew Keeler) Date: Tue, 29 Sep 2015 19:03:12 +0000 Subject: [CMake] Is there a variable containing the C flags that would be used to compile something in a directory Message-ID: There are various variables like CMAKE_C_FLAGS_ that can influence the final flags sent to the compiler. Is there a variable that exists or a function to call to get the final C flags. What I am trying to do is invoke a custom command to run make on an external source tree. This makefile has CC, AR, RANLIB CFLAGS and LDFLAGS variables. The command I would like to do is add_custom_command( COMMAND make CC=${CMAKE_C_COMPILER} AR=${CMAKE_AR} RANLIB=${CMAKE_RANLIB} CFLAGS= LDFLAGS= ??) However it doesn?t seem like there is a variable that contains a set of all the flags that cmake would use. For example, when building on OS X the -mmacosx-version-min flag gets tacked on by cmake but I can?t find a variable that contains this flag. Is there a way to do what I want or am I going to have to manage all the C flags manually? -- Matt Keeler -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at utk.edu Wed Sep 30 01:26:17 2015 From: roland at utk.edu (Roland Schulz) Date: Tue, 29 Sep 2015 22:26:17 -0700 Subject: [CMake] Is the situation with CMake + Eclipse ever going to get any better? In-Reply-To: <1abb399e34be4695a3d9b1b626850cad@BY2PR0201MB0584.namprd02.prod.outlook.com> References: <1abb399e34be4695a3d9b1b626850cad@BY2PR0201MB0584.namprd02.prod.outlook.com> Message-ID: Hi, also Doug, the CDT co-lead, is working on an integration of cmake into cdt. You can find information in the archive of cdt-dev at eclipse.org. I think you can expect well integration, similar to clion or qt-developer, with the next major release next year. Roland On Mon, Sep 28, 2015 at 11:00 AM, Martin Weber wrote: > Am Sonntag, 27. September 2015, 13:29:15 schrieb Talin: > > I've been using CMake and Eclipse for a bunch of different projects over > > the last several years. Although many aspects of both CMake and Eclipse > > have improved over the years, using them together still has a lot of > > problems. > > > > From what I understand, you have three choices when setting up a project: > > > > 1) Use in-source builds. > > 2) Use out-of-source builds with a single generated project. > > 3) Use out-of-source builds with both a build project and a source > project. > > If you are building C/C++ sources, set up a CDT project. > ADVERTISING: > Then let generate > the > makefiles. (I am the author of it). > > It is not perfect due to the quirks in CDT, but it avoids that extra manual > invocation of 'cmake -G whatever'. > > Martin > > -- > Cd wrttn wtht vwls s mch trsr. > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- ORNL/UT Center for Molecular Biophysics cmb.ornl.gov 865-241-1537, ORNL PO BOX 2008 MS6309 -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.kreuzberger at procitec.de Wed Sep 30 02:33:18 2015 From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=) Date: Wed, 30 Sep 2015 08:33:18 +0200 Subject: [CMake] cmake install behaviour with git Message-ID: Hi! the cmake install behaviour of files was ok for me, as long as we used svn. Now we changed to git and i have a problem now with the install behaviour. On git the timestamps of all files get the time of the clone. So files not build (e.g. configuration files, xml files etc) from the repository have the same timestamp. Now install behaves differnt, cause cmake checks only file time difference. Files previously overwritten are now considered Up-to-date I am forcing now overwrite with CMAKE_ALWAYS_INSTALL, but this takes then a long time, cause now all binary files (with differnt timestamps) get installed (e.g. huge qt dlls, executables etc :-) ) Has anyone found a solution for this after a git migration? Adapting the file timestamps after clone seems not the thing i want to do :-) Or should i post a feature-request to check also the file size for Up-to-date checking? Thanks for any hints, Joerg From jsvanbethlehem at gmail.com Wed Sep 30 03:16:09 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Wed, 30 Sep 2015 09:16:09 +0200 Subject: [CMake] cmake install behaviour with git In-Reply-To: References: Message-ID: Hej, > > Now install behaves differnt, cause cmake checks only file time difference. Files previously overwritten are now > considered Up-to-date Why would you want to overwrite files that have not changed? > Has anyone found a solution for this after a git migration? We?re using CMake with git without any trouble - no solution to be found. The install target works flawlessly and as expected. I think you?ll need to provide some more details about what you?re doing. Are you by any chance doing in-source builds? Why are you so focussed on 'git clone?? That is the kind of thing you would do once, and then almost never again, so I don?t see how that can be related to running an install target. Sincerely, Jakob From Jakub.Golebiewski at dnvgl.com Wed Sep 30 04:45:17 2015 From: Jakub.Golebiewski at dnvgl.com (Golebiewski, Jakub) Date: Wed, 30 Sep 2015 08:45:17 +0000 Subject: [CMake] How to create a custom solution with Visual Studio 2010 generator? In-Reply-To: References: Message-ID: Hi, So I've sort of solved my initial problem by simply moving from VS2010 to VS2013. I'm still using VS2010 toolchain but in VS2013 IDE and it performs much much better and can handle ~600 project solutions. Thanks everybody for help, Regards, JG > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Golebiewski, > Jakub > Sent: Wednesday, September 23, 2015 9:35 AM > To: J Decker > Cc: cmake at cmake.org > Subject: Re: [CMake] How to create a custom solution with Visual Studio 2010 > generator? > > > -----Original Message----- > > From: J Decker [mailto:d3ck0r at gmail.com] > > Sent: Tuesday, September 22, 2015 9:40 AM > > To: Golebiewski, Jakub > > Cc: cmake at cmake.org > > Subject: Re: [CMake] How to create a custom solution with Visual > > Studio > > 2010 generator? > > > > > I've tried running cmake independently for each subproject but I get > > > errors about unknown Targets since every Sub Project depends on > > > targets > > from 'earlier' one. > > > > > > I have about 620 targets (VS projects) so when I open Main > > > Project.sln > > (with 620 projects) in VS it is impossible to work with. > > > Currently cmake produces .sln for each Sub Project but includes > > > dependencies from other projects and that's something I don?t want > > > Since the amount of projects in each .sln increases the further I go > > > and > > most of them (later in the dependency chain) are not possible to work > > with either. I'm trying to divide it into .slns that developers could work with > in VS. > > > > > Hmm; I was going to check to see if .sln's were made in subdirs... and > > they are... wonder if it was always taht way. > > But... the projects deeper in the tree only have those things that it > > depended on... so I don't get why you say 'the amount of projects > > increases the further you go' Yes... high level projects will have > > all of their dependancies but nothing extra... > > I meant that in my case (let's use the original simple example), targets 3,4 > depend on 1,2 and 5,6 depend on 3,4 and therefore on > 1,2 as well. So in Sub Project 1.sln I get targets 1,2 in Sub Project 2.sln I get > 1,2,3,4 and in Sub Project 3.sln I get 1,2,3,4,5,6. > This is of course absolutely correct and the right way to do it. But in my case > with about 620 projects I have about 19 subprojects. > This means that I get solutions more or less like this: > > 1. 30 projects > 2. 50 projects (about 20 as dependencies from 1 - not all because there are > unit test projects (executables) in 1 and all the rest) 3. 70 projects (about 50 > as dependencies from 1,2) 4. 100 projects (...) 5. 150 projects 6. 200 projects 7. > 250 projects 8. 300 projects 9. 350 projects (probably about 75 projects and > 300 as dependencies from 1 - 8) ... > > At this point unfortunately the VS 2010 is so slow that It is impossible to work > with 350 project solution. > So what I want to do Is to cut the dependencies from other projects to make > this usable. > (that's what we are currently doing, I'm in the process of converting our > current build system to cmake) > > I hope that's clear enough. > > > > > isn't it already making the minimal solutions you're suggesting you > > make by hand anyway? > > > > Other than as I use this; the Install rule in the sub-solution doesn't > > install everything... > > could wish the OutputPath cmake built was relative to the solution > > instead of the projects... then at least nothing funky would have to > > be done to run applications from the debugger; other than data > > resources could still be missing. > > Thanks for help, I really appreciate it > > ********************************************************** > **************************** > This e-mail and any attachments thereto may contain confidential > information and/or information protected by intellectual property rights for > the exclusive attention of the intended addressees named above. If you > have received this transmission in error, please immediately notify the > sender by return e-mail and delete this message and its attachments. > Unauthorized use, copying or further full or partial distribution of this e-mail > or its contents is prohibited. > ********************************************************** > **************************** > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake ************************************************************************************** This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited. **************************************************************************************