From frodak17 at gmail.com Tue Jan 1 16:48:56 2019 From: frodak17 at gmail.com (frodak17) Date: Tue, 1 Jan 2019 16:48:56 -0500 Subject: [CMake] Help with non-standard use of CMake In-Reply-To: References: <54faf2d1-f81b-c220-1eed-8c33cfe6f259@instantiations.com> <1546292301.4676.26.camel@kitware.com> Message-ID: On Mon, Dec 31, 2018 at 9:47 PM Donald MacQueen [|] via CMake < cmake at cmake.org> wrote: > On 12/31/2018 4:38 PM, Kyle Edwards wrote: > > On Mon, 2018-12-31 at 16:16 -0500, Donald MacQueen [|] via CMake wrote: > >> First, CMake is quite impressive. Nice job. > >> > >> I am using it in a non-standard way where I set a bunch of variables > >> and > >> then go straight to CTest thatI installs our software and then runs > >> several hundred tests on it. The batch file looks like this: > >> > >> rmdir /s/q build > >> mkdir build > >> cd build > >> cmake -Dx64=%x64% -Doption:STRING="%opt%" .. > >> ctest -D Experimental -S > >> > >> I do not make or build or compile. > >> > >> I recently hooked this up to a CDash server which is very handy. I > >> want > >> to get the results that are sent to CDash, currently from Windows > >> only, > >> to be all green. > >> > >> However, I am a little curious about what you're doing in your use > >> case. You say you're not building anything. Does your sofware exist in > >> the form of scripts (Python, Perl, etc.), or are you downloading pre- > >> built binaries from somewhere? > > The purpose here is to 1) test that the installation of our product is > successful (all the files are there with the correct permissions, etc.) > and 2) that the 13k+ tests we have run correctly after installation. > The installer is created using Install Shield. > > My CMakelists.txt looks something like this: > > ++++++++++++++++++++++++++++++++++++++++++++++++++ > > cmake_minimum_required(VERSION 2.8.8) > if(CMAKE_VERSION VERSION_GREATER "3.1") > cmake_policy(SET CMP0054 NEW) > endif() > > > if (${CMAKE_SYSTEM_PROCESSOR} MATCHES "64") > set (vasttst_isX86_OS FALSE) > set (vasttst_OsBitness 64) > endif() > set (vasttst_isX86_OS TRUE) > set (vasttst_OsBitness 86) > endif () > > 200 more lines.. > > ENABLE_TESTING() > > include(CTest) > > add_subdirectory(test) > > ++++++++++++++++++++++++++++++++++++++++++++++++++ > > rmdir /s/q build > mkdir build > cd build > ctest -D Experimental -S cdash.txt > > That way I avoid make/build/compile and go straight to CTest. > > Right? > > -- > Donald [|] > A bad day in [] is better than a good day in {}. > > > I'm trying to follow along but you are calling cmake to do the install and set everything up before you run ctest. And that the software was already built and packaged separately. > cmake -Dx64=%x64% -Doption:STRING="%opt%" .. If the CMakeLists.txt file has the project() command in it that is enough to kick of an implicit build and look for a working compiler using the default generator. I think you can work around this by using LANGUAGES NONE in the project() command. Alternatively if CMakeLists.txt can be converted into a pure script without targets then you could run it as cmake -D... -P script_file.cmake But I'm not sure if that is possible because at some point something makes the test configuration file and the tests need to be found somewhere. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmacq at instantiations.com Tue Jan 1 16:55:27 2019 From: dmacq at instantiations.com (Donald MacQueen [|]) Date: Tue, 1 Jan 2019 16:55:27 -0500 Subject: [CMake] Help with non-standard use of CMake In-Reply-To: References: <54faf2d1-f81b-c220-1eed-8c33cfe6f259@instantiations.com> <1546292301.4676.26.camel@kitware.com> Message-ID: <2e397f80-dd58-f40d-667a-c5bc44a1e074@instantiations.com> On 1/1/2019 4:48 PM, frodak17 wrote: > > > I'm trying to follow along but you are calling cmake to do the install > and set everything up before you run ctest. > And that the software was already built and packaged separately. No. CMakelists.txt does nothing but download the correct installer (32 or 64 bit) from our server, set a bunch of variables, and then run CTest.? I invoke the InstallShield installer from a command line in a CTest. There is no project, no make, no compile, no build. Just set a bunch of variables and run CTest. I think from what Kyle said I need to migrate(?) this to a script that can be called from CTest directly, e.g., ctest -D Experimental -S cdash.txt. Thanks for the reply. -- Donald [|] A bad day in [] is better than a good day in {}. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodak17 at gmail.com Tue Jan 1 20:48:55 2019 From: frodak17 at gmail.com (frodak17) Date: Tue, 1 Jan 2019 20:48:55 -0500 Subject: [CMake] Help with non-standard use of CMake In-Reply-To: <2e397f80-dd58-f40d-667a-c5bc44a1e074@instantiations.com> References: <54faf2d1-f81b-c220-1eed-8c33cfe6f259@instantiations.com> <1546292301.4676.26.camel@kitware.com> <2e397f80-dd58-f40d-667a-c5bc44a1e074@instantiations.com> Message-ID: On Tue, Jan 1, 2019 at 4:55 PM Donald MacQueen [|] wrote: > > On 1/1/2019 4:48 PM, frodak17 wrote: > > > > I'm trying to follow along but you are calling cmake to do the install and > set everything up before you run ctest. > And that the software was already built and packaged separately. > > > No. CMakelists.txt does nothing but download the correct installer (32 or > 64 bit) from our server, set a bunch of variables, and then run CTest. I > invoke the InstallShield installer from a command line in a CTest. > > There is no project, no make, no compile, no build. Just set a bunch of > variables and run CTest. > > I think from what Kyle said I need to migrate(?) this to a script that can > be called from CTest directly, e.g., ctest -D Experimental -S cdash.txt. > > Thanks for the reply. > > The point I was trying to make is that the mere existence of a CMakeLists.txt is enough for the implicit try_compile() For example use the following lines: cmake_minimum_required(VERSION 2.8.8) > if(CMAKE_VERSION VERSION_GREATER "3.1") > cmake_policy(SET CMP0054 NEW) > endif() > Now go into the build folder and type `cmake ..` and it will default with an implicit project with C and C++ languages enabled. Then it will use the default generator and try to build the sample project to verify a working build system. After this it will continue to process the rest of the script. Now it may be that I misunderstood which log you were referring to that contained the error. But typically any time `cmake` is used (unless used with -P or -E) it will do an implicit build unless something like "project( empty LANGUAGES NONE )" is used. BTW: > if (${CMAKE_SYSTEM_PROCESSOR} MATCHES "64") > set (vasttst_isX86_OS FALSE) > set (vasttst_OsBitness 64) > endif() > set (vasttst_isX86_OS TRUE) > set (vasttst_OsBitness 86) > endif () has a syntax error, it should be else() As for the error in question > The system cannot find the file specified. > CMake Error: Generator: execution of make failed. > Make command was: "nmake" "/nologo" "-i" > This error is generated when "cmake --build" is used. Using a CMakeLists.txt file with no targets, like the one above, then the following steps can be used to generate the error. 1) Open a VS Native Tools Command shell 2) Run: cmake -G"NMake Makefiles" ..\no_targets -- This is enough to setup the cache to a working nmake 3) Open a regular cmd.exe shell 4) Run: cmake --build . -- -i The system cannot find the file specified CMake Error: Generator: execution of make failed. Make command was: "nmake" "/nologo" "-i" As for suppressing these steps the only way I am aware of them occurring is if the test itself is trying to build either through issuing a `ctest --test-and-build` or `cmake --build`. Doesn't the log file mention which test generated the error? For example when running the tests for cmake there is a file called LastTest.log. It contains details on all the tests and their results. I don't think simply running a script is sufficient to use ctest because it seems to need a configured build directory that contains the test configuration file before running the tests. -- F -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Wed Jan 2 09:39:39 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Wed, 02 Jan 2019 09:39:39 -0500 Subject: [CMake] Help with non-standard use of CMake In-Reply-To: <2e397f80-dd58-f40d-667a-c5bc44a1e074@instantiations.com> References: <54faf2d1-f81b-c220-1eed-8c33cfe6f259@instantiations.com> <1546292301.4676.26.camel@kitware.com> <2e397f80-dd58-f40d-667a-c5bc44a1e074@instantiations.com> Message-ID: <1546439979.4676.31.camel@kitware.com> On Tue, 2019-01-01 at 16:55 -0500, Donald MacQueen [|] wrote: > No. CMakelists.txt does nothing but download the correct installer > (32 or 64 bit) from our server, set a bunch of variables, and then > run CTest.? I invoke the InstallShield installer from a command line > in a CTest. > There is no project, no make, no compile, no build. Just set a bunch > of variables and run CTest. > I think from what Kyle said I need to migrate(?) this to a script > that can be called from CTest directly, e.g., ctest -D Experimental > -S cdash.txt. > Thanks for the reply. If CMakeLists.txt is only downloading and running an installer, then perhaps it would be best to move this step into your CTest dashboard script as you suggested. Your CMakeLists.txt is generating the CTestTestfile.cmake file for you, but you can also write this file yourself with a series of add_test() calls, which would enable you to completely get rid of CMakeLists.txt. If you're not comfortable doing this, you can also just do project(foo LANGUAGES NONE) in your CMakeLists.txt as has already been suggested. FWIW, the usual convention for CMake scripts is for anything other than CMakeLists.txt to have a .cmake extension (though this isn't enforced, it's just a convention.) And the -D argument to CTest isn't necessary when running a dashboard script. So your CTest invocation would look like this: ctest -S dashboard.cmake You can also have this script run ctest_configure(), which will run CMake for you (if you decide not to migrate from CMakeLists.txt) so you don't have to do it in the batch file. Good luck, and let us know if you have any more questions! Kyle From dmacq at instantiations.com Wed Jan 2 12:01:17 2019 From: dmacq at instantiations.com (Donald MacQueen [|]) Date: Wed, 2 Jan 2019 12:01:17 -0500 Subject: [CMake] Help with non-standard use of CMake In-Reply-To: <1546439979.4676.31.camel@kitware.com> References: <54faf2d1-f81b-c220-1eed-8c33cfe6f259@instantiations.com> <1546292301.4676.26.camel@kitware.com> <2e397f80-dd58-f40d-667a-c5bc44a1e074@instantiations.com> <1546439979.4676.31.camel@kitware.com> Message-ID: <603b6825-2a26-7e95-e478-5915dcf741ad@instantiations.com> Hi Kyle, I looked at the example of Using ctest and cdash without cmake (https://gitlab.kitware.com/cmake/community/wikis/doc/ctest/Using-CTEST-and-CDASH-without-CMAKE#steercmake) and I think I will try to go in that direction. Part of my confusion is that I inherited this from a former employee and have been learning by doing/hacking. Thanks for the reply. On 1/2/2019 9:39 AM, Kyle Edwards wrote: > On Tue, 2019-01-01 at 16:55 -0500, Donald MacQueen [|] wrote: >> No. CMakelists.txt does nothing but download the correct installer >> (32 or 64 bit) from our server, set a bunch of variables, and then >> run CTest.? I invoke the InstallShield installer from a command line >> in a CTest. >> There is no project, no make, no compile, no build. Just set a bunch >> of variables and run CTest. >> I think from what Kyle said I need to migrate(?) this to a script >> that can be called from CTest directly, e.g., ctest -D Experimental >> -S cdash.txt. >> Thanks for the reply. > If CMakeLists.txt is only downloading and running an installer, then > perhaps it would be best to move this step into your CTest dashboard > script as you suggested. Your CMakeLists.txt is generating the > CTestTestfile.cmake file for you, but you can also write this file > yourself with a series of add_test() calls, which would enable you to > completely get rid of CMakeLists.txt. > > If you're not comfortable doing this, you can also just do project(foo > LANGUAGES NONE) in your CMakeLists.txt as has already been suggested. > > FWIW, the usual convention for CMake scripts is for anything other than > CMakeLists.txt to have a .cmake extension (though this isn't enforced, > it's just a convention.) And the -D argument to CTest isn't necessary > when running a dashboard script. So your CTest invocation would look > like this: > > ctest -S dashboard.cmake > > You can also have this script run ctest_configure(), which will run > CMake for you (if you decide not to migrate from CMakeLists.txt) so you > don't have to do it in the batch file. > > Good luck, and let us know if you have any more questions! > > Kyle -- Donald [|] A bad day in [] is better than a good day in {}. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From kyle.edwards at kitware.com Wed Jan 2 12:26:29 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Wed, 02 Jan 2019 12:26:29 -0500 Subject: [CMake] Help with non-standard use of CMake In-Reply-To: <603b6825-2a26-7e95-e478-5915dcf741ad@instantiations.com> References: <54faf2d1-f81b-c220-1eed-8c33cfe6f259@instantiations.com> <1546292301.4676.26.camel@kitware.com> <2e397f80-dd58-f40d-667a-c5bc44a1e074@instantiations.com> <1546439979.4676.31.camel@kitware.com> <603b6825-2a26-7e95-e478-5915dcf741ad@instantiations.com> Message-ID: <1546449989.4676.33.camel@kitware.com> On Wed, 2019-01-02 at 12:01 -0500, Donald MacQueen [|] wrote: > I looked at the example of Using ctest and cdash without cmake? > (https://gitlab.kitware.com/cmake/community/wikis/doc/ctest/Using-CTE > ST-and-CDASH-without-CMAKE#steercmake)? > and I think I will try to go in that direction. Donald, I just looked at that page, and it looks like it was written a very long time ago, before cmake_host_system_information() and execute_process() were created. The exec_program() command has been deprecated for years. I'm going to work on updating it a little bit right now. Kyle From eric.noulard at gmail.com Wed Jan 2 12:51:42 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 2 Jan 2019 18:51:42 +0100 Subject: [CMake] Help with non-standard use of CMake In-Reply-To: <1546449989.4676.33.camel@kitware.com> References: <54faf2d1-f81b-c220-1eed-8c33cfe6f259@instantiations.com> <1546292301.4676.26.camel@kitware.com> <2e397f80-dd58-f40d-667a-c5bc44a1e074@instantiations.com> <1546439979.4676.31.camel@kitware.com> <603b6825-2a26-7e95-e478-5915dcf741ad@instantiations.com> <1546449989.4676.33.camel@kitware.com> Message-ID: Hi Kyle & Donald, ctest scripting is documented in here as well: https://cmake.org/cmake/help/v3.13/manual/ctest.1.html#ctest-script Since this is generated from in-source documentation: https://github.com/Kitware/CMake/blob/master/Help/manual/ctest.1.rst may be an explanation on how to use ctest without cmake directly in a subsection of this manual would be a way to keep it more up-to-date along with the source. Le mer. 2 janv. 2019 ? 18:26, Kyle Edwards via CMake a ?crit : > On Wed, 2019-01-02 at 12:01 -0500, Donald MacQueen [|] wrote: > > I looked at the example of Using ctest and cdash without cmake > > (https://gitlab.kitware.com/cmake/community/wikis/doc/ctest/Using-CTE > > ST-and-CDASH-without-CMAKE#steercmake) > > and I think I will try to go in that direction. > > Donald, > > I just looked at that page, and it looks like it was written a very > long time ago, before cmake_host_system_information() and > execute_process() were created. The exec_program() command has been > deprecated for years. I'm going to work on updating it a little bit > right now. > > Kyle > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmacq at instantiations.com Thu Jan 3 12:24:20 2019 From: dmacq at instantiations.com (Donald MacQueen [|]) Date: Thu, 3 Jan 2019 12:24:20 -0500 Subject: [CMake] CDash documentation suggestions Message-ID: I had a difficult time getting CDash to work even though I am familiar with MySQL. Here are some suggestions for the documentation: 1) CDash requires these Python modules ( * bcmath * cURL (for site statistics) * GD (for regression tests) * mbstring * pdo-mysql or pdo-postgresql * XSL ). One of the distros I found installed these modules by default. I did not know this until I ran php -m which displays what modules are installed. 2) For security reasons, MySQL no longer allows you to set the initial password from a regular (non-sudo) command line unless you ssh in.? Entering sudo mysql -u root -p and then typing the root password works. You can also do it like this: ||ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'yourPassword';|| 3) The easiest way to do the initial MySQL configuration is to edit (or create) /etc/mysql/my.cnf, add these lines, [mysqld] sql-mode=ONLY_FULL_GROUP_BY,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION and then restart MySQL. sudo mysqld restart 4) This (https://askubuntu.com/questions/337874/change-apache-document-root-folder-to-secondary-hard-drive) is an example of how to change DocumentRoot to point to the CDash directory. Remember to restart Apache2 afterwards: |sudo /etc/init.d/apache2 restart| 5) Finally, the docs say you should initially go to ||http://localhost/users.php|| This will not work until you first do the install from here: ||http://localhost/install.php || ||If you get a database connection refused while doing the install, your MySQL password is probably not set correctly.|| |||| ||Hope this helps,|| |||| || || -- Donald [|] A bad day in [] is better than a good day in {}. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From victornement at free.fr Thu Jan 3 13:31:32 2019 From: victornement at free.fr (victornement at free.fr) Date: Thu, 3 Jan 2019 19:31:32 +0100 (CET) Subject: [CMake] Problem when linking a library on a target with CUDA sources Message-ID: <1715873062.357261304.1546540292531.JavaMail.root@zimbra31-e6.priv.proxad.net> Hello, I have a project with a few dependencies (Qt, opencv, aravis, etc) and I would like to add some sources in CUDA. Here is a minimal example: cmake_minimum_required(VERSION 3.0) project(myproject CXX CUDA) find_package(Qt5 REQUIRED COMPONENTS Core) add_executable(mytarget main.cpp gpu.cu) target_link_libraries(mytarget PUBLIC Qt5::Core) The previous example gives the following output [ 25%] Building CUDA object CMakeFiles/mytarget.dir/gpu.cu.o nvcc fatal : Unknown option 'fPIC' make[2]: *** [CMakeFiles/mytarget.dir/build.make:76: CMakeFiles/mytarget.dir/gpu.cu.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:73: CMakeFiles/mytarget.dir/all] Error 2 make: *** [Makefile:84: all] Error 2 I would get the same problem if I replace target_link_libraries with set_target_properties(mytarget PROPERTIES COMPILE_OPTIONS -pthread) Does anyone know why I get this error? Am I doing it rightly? Is it a bug? Sincerely, Victor ML From robert.maynard at kitware.com Thu Jan 3 15:56:43 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 3 Jan 2019 15:56:43 -0500 Subject: [CMake] Problem when linking a library on a target with CUDA sources In-Reply-To: <1715873062.357261304.1546540292531.JavaMail.root@zimbra31-e6.priv.proxad.net> References: <1715873062.357261304.1546540292531.JavaMail.root@zimbra31-e6.priv.proxad.net> Message-ID: This is caused by a combination of two things: 1. nvcc does not accept standard flags such as fpic or pthread 2. Packages such as Qt or your call to set_target_properties not handling CUDA/C++ compilers having different flags. For your pthread example you can use the following ( which is what FindThreads.cmake does ) set_target_property((mytarget PROPERTIES COMPILE_OPTIONS "$<$:SHELL:-Xcompiler -pthread> $<$>:-pthread>") On Thu, Jan 3, 2019 at 1:31 PM wrote: > > Hello, > > I have a project with a few dependencies (Qt, opencv, aravis, etc) and I would like to add some sources in CUDA. > > Here is a minimal example: > > cmake_minimum_required(VERSION 3.0) > project(myproject CXX CUDA) > find_package(Qt5 REQUIRED COMPONENTS Core) > add_executable(mytarget main.cpp gpu.cu) > target_link_libraries(mytarget PUBLIC Qt5::Core) > > The previous example gives the following output > > [ 25%] Building CUDA object CMakeFiles/mytarget.dir/gpu.cu.o > nvcc fatal : Unknown option 'fPIC' > make[2]: *** [CMakeFiles/mytarget.dir/build.make:76: CMakeFiles/mytarget.dir/gpu.cu.o] Error 1 > make[1]: *** [CMakeFiles/Makefile2:73: CMakeFiles/mytarget.dir/all] Error 2 > make: *** [Makefile:84: all] Error 2 > > I would get the same problem if I replace target_link_libraries with > > set_target_properties(mytarget PROPERTIES COMPILE_OPTIONS -pthread) > > Does anyone know why I get this error? Am I doing it rightly? Is it a bug? > > Sincerely, > > Victor ML > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake From 2goodproductions at gmail.com Fri Jan 4 13:46:25 2019 From: 2goodproductions at gmail.com (2GooD Productions) Date: Fri, 4 Jan 2019 18:46:25 +0000 Subject: [CMake] After working for a well over a year my cmake has suddenly stopped working, CMake Gui now fails to configure any project with the error.. Message-ID: > > Selecting Windows SDK version 10.0.17763.0 to target Windows 6.3.9600. > > CMake Error at CMakeLists.txt:45 (project): > Failed to run MSBuild command: > > C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/MSBuild/15.0/Bin/MSBuild.exe > > to get the value of VCTargetsPath: > > The system cannot find the file specified > > > Configuring incomplete, errors occurred! See also > "G:/dev/CPP/libraries/LibraryBuilds/GLEW_TEST/CMakeFiles/CMakeOutput.log". > When I try to use VS2017 to build, I get this error... CMake Error at C:/Program Files (x86)/Microsoft Visual >> Studio/2017/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/CMakeTestCCompiler.cmake:52 >> (message): >> > The C compiler > > >> "C:/Program Files (x86)/Microsoft Visual >> Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe" > > >> is not able to compile a simple test program. > > >> It fails with the following output: > > >> Change Dir: >> C:/Users/2Good/CMakeBuilds/774fd661-ecad-c93e-a053-ab53694fc56d/build/x64-Debug >> (default)/CMakeFiles/CMakeTmp > > > > Run Build Command:"C:/Program Files (x86)/Microsoft Visual >> Studio/2017/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja/ninja.exe" >> "cmTC_5cf10" > > ninja: fatal: couldn't open nul > > > > >> > > >> CMake will not be able to correctly generate this project. C:/Program >> Files (x86)/Microsoft Visual >> Studio/2017/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/CMakeTestCCompiler.cmake >> 52 > > Yes, Im a noob, but I could really use some help, Ive been trying to fix this for over a week. Ive reinstalled CMake, VS2017, and MSBuild, added to the environment path variable the path to the compiler, but nothing Ive done has worked. Ive ran VS2017 as admin, Ive ran Cmake as admin. Can somebody please help this noob out? -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmilano at gmail.com Sat Jan 5 06:06:31 2019 From: fmilano at gmail.com (Federico Milano) Date: Sat, 5 Jan 2019 08:06:31 -0300 Subject: [CMake] Removing RPATH from existing binaries Message-ID: Hi. When packaging my application, I'm using install (FILES...) to copy some third party executables to my binary folder. 1. I do not know if I'm doing it right or if I should use install (PROGRAMS...) 2. Some of the binaries have a RPATH, and I want to remove it. Is there any CMake macro/function to do that, or should I call directly chrpath? Thanks in advance, Federico -------------- next part -------------- An HTML attachment was scrubbed... URL: From ax487 at gmx.de Sat Jan 5 08:42:19 2019 From: ax487 at gmx.de (Unknown) Date: Sat, 05 Jan 2019 14:42:19 +0100 Subject: [CMake] Get linker flags / include directories for a library target In-Reply-To: References: <965c52de901d462e84324b3748195ed4a36bf4e4.camel@gmx.de> <4BF6D799-4941-4460-871C-9F18B80E88EB@gmail.com> <8a711a8d20249114189f9ab89359e561c464c4e1.camel@gmx.de> <8763e456344433bc0833c003ee92801ae47b5f8a.camel@gmx.de> Message-ID: <34055e7650568dd1a6d0918cf2cfef518ed0869c.camel@gmx.de> On Sat, 2018-12-29 at 16:06 -0500, frodak17 wrote: > On Fri, Dec 28, 2018 at 6:04 PM Unknown wrote: > > I would like to thank all of you for your suggestions. I have > > gathered > > > > the following (correct me if I am wrong): > > > > > > > > - The LINK_FLAGS target property is used in cmake 2.x, the > > > > INTERFACE_LINK_LIBRARIES in cmake 3.x, the latter contains a ;- > > list > > > > of libraries. > > > > - The list may contain generator expressions, it is however > > > > possible to to use file(GENERATE ..) to obtain evaluate those. > > > > - In any case, the library list contains libraries having > > different > > > > formats (see [1]), full paths, (imported) targets, and plain > > names. > > > > - When Makefiles (or files for other build systems) are generated, > > > > the list is turned into -L/-l flags used by ld. This happens > > > > on the C++ side of things, the functionality is not exposed > > > > to cmake scripts. > > > > > > > > As for automatic generation of a pkg-config .pc file, there have > > > > been some inquiries ([2], [3], and [4]), the last one being rather > > > > recent. > > > > > > > > The answers point out that pkg-config files can be generated using > > > > configure_file(...), that cmake has its own (imported target) > > method > > > > for handling dependencies. > > > > > > > > I don't mean to be disrespectful or unappreciative of the work put > > > > into cmake (in fact I think it is a vast improvement over > > automake), > > > > but since there is no way to obtain the required information > > > > programatically, all users of my library have to either use > > > > cmake themselves, or use non-portable workarounds which are prone > > > > to break sooner than later. > > > > > > > > If I want to use an external tool (think setup.py) to build > > > > extensions (in-place or not), the same problem occurs. > > > > > > > > This is rather disappointing to be honest... > > > > > > > > ax487 > > > > > > > > > > The answer to [2] was that the information required to automatically > generate > a .pc file was not available. > https://linux.die.net/man/1/pkg-config > https://people.freedesktop.org/~dbn/pkg-config-guide.html#writing > I don't see how CMake could know which packages your library > conflicts with or which versions of which libraries are required.For > example a library target can link against an imported target but it > won't know that only imported target version 1.0.0 is compatible as > opposed to versions >= 1.5. > > > > > It seems that you are trying to provide more than how to link > against > your library but also against everything your library wants to be > linked > against. > > For example the .pc file you want generated contains "Libs: > -L${libdirbar} > -L${libdirfoo} > > -lbar -lfoo".But that isn't the proper way of a .pc file should > reference separate libraries it should use the Requires field. > > Also if your library is linking against an imported library > `libbaz::libbaz` how is this library being provided to the people > using your library?Are you trying to generate a .pc file for the > imported library because it didn't provide one and incorporate the > flags into library you are creating? > I think that no one has volunteered to write a CMake package to > create .pc files is because generating a .pc file is pretty simple. > It's just a template and a configure_file() command. > https://cmake.org/pipermail/cmake/2018-March/067293.html > > Thank you for your reply, As for the answer provided in [2]: I don't expect conflict or version detection to be conducted automatically. Clearly, you have to require the correct packages in the correct versions, and you have to pass that information along to a generated pc file, that much is clear. But I think that the same holds true for imported targets, unless something really clever happens in the background which I am not aware of. You are quite right in assuming that I want to (mis-)use the Libs / Libs.private field. I would of course prefer the Requires field, but unfortunately a lot of my dependencies don't generate pc files either, so I don't really see any other way to get pkg-config working. A dependency of the form libbaz::libbaz would be provided as an imported target. That is, the authors of libbaz are using cmake as well, and they are installing a target. I am assuming that the users of my library have the dependency libbaz installed as well. I simply want to pass that information along in a format understood by pkg-config. I would also go through the dependency libraries, but I doubt that any contributions of pc file generators to those projects would be accepted. Regarding the fact that no one has written a generator for .pc files: It is obviously possible to use configure_file templates. In fact it is quite easy. But it hinges on the libraries as well. The post you mention references a project which generates linker flags by hand. You see that the CMakeLists.txt contains a lot of lines like this one: set(PKGCONF_LIBS_PRIV "${PKGCONF_LIBS_PRIV} -lbass -lbassmidi") This works as long as all dependencies are in a precisely known format, i.e. a list of -l flags. In fact, I think the approach would still work if the authors were to use the built-in pkg-config find scripts for their dependencies. But this approach will break down immediately once they add an imported target as a dependency. Note that the authors also use the Libs.private field instead of the Requires field :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From romain.leguay at gmail.com Sat Jan 5 11:08:19 2019 From: romain.leguay at gmail.com (Romain LEGUAY) Date: Sat, 5 Jan 2019 17:08:19 +0100 Subject: [CMake] Check Build Type/Config Changed Message-ID: Hi everyone, Is there a way to test if the build type changed? I try to create a cache variable with CMAKE_BUILD_TYPE as value but I found an unexpected result: CMAKE_BUILD_TYPE or CMAKE_CONFIGURATION_TYPES are not defined (I'm working on Windows with Visual Studio 2017, Visual Studio Code and Qt Creator). Thank you, Romain -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodak17 at gmail.com Sat Jan 5 11:34:52 2019 From: frodak17 at gmail.com (frodak17) Date: Sat, 5 Jan 2019 11:34:52 -0500 Subject: [CMake] Check Build Type/Config Changed In-Reply-To: References: Message-ID: On Sat, Jan 5, 2019 at 11:08 AM Romain LEGUAY wrote: > Hi everyone, > > > > Is there a way to test if the build type changed? > > > I try to create a cache variable with CMAKE_BUILD_TYPE as value but I > found an unexpected result: CMAKE_BUILD_TYPE or CMAKE_CONFIGURATION_TYPES > are not defined (I'm working on Windows with Visual Studio 2017, Visual > Studio Code and Qt Creator). > > > Thank you, > > > CMAKE_CONFIGURATION_TYPES is used by multi-config generators and CMAKE_BUILD_TYPE isn't used. CMAKE_CONFIGURATION_TYPES should default to "Debug;Release;MinSizeRel;RelWithDebInfo" for Visual Studio generators unless it was explicitly set to something else. If you aren't using a multi-config generator then CMAKE_BUILD_TYPE will be empty unless it was set by the user or the CMakeLists.txt sets a default value if empty. When building with Visual Studio the build type probably could be written to a file using a post-build rule or something like that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From romain.leguay at gmail.com Sun Jan 6 09:59:59 2019 From: romain.leguay at gmail.com (Romain LEGUAY) Date: Sun, 6 Jan 2019 15:59:59 +0100 Subject: [CMake] Check Build Type/Config Changed In-Reply-To: References: Message-ID: Thank you for your answer! What I found strange is that CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE are empty at the begining of the cmake script. When do those variables instanciated? The purpose to know if the build type changed is to reactivate a superbuild variable to build my external dependencies in the good build type. Le sam. 5 janv. 2019 ? 17:35, frodak17 a ?crit : > > > On Sat, Jan 5, 2019 at 11:08 AM Romain LEGUAY > wrote: > >> Hi everyone, >> >> >> >> Is there a way to test if the build type changed? >> >> >> I try to create a cache variable with CMAKE_BUILD_TYPE as value but I >> found an unexpected result: CMAKE_BUILD_TYPE or CMAKE_CONFIGURATION_TYPES >> are not defined (I'm working on Windows with Visual Studio 2017, Visual >> Studio Code and Qt Creator). >> >> >> Thank you, >> >> >> > CMAKE_CONFIGURATION_TYPES is used by multi-config generators and > CMAKE_BUILD_TYPE isn't used. > CMAKE_CONFIGURATION_TYPES should default to > "Debug;Release;MinSizeRel;RelWithDebInfo" for Visual Studio generators > unless it was explicitly set to something else. > > If you aren't using a multi-config generator then CMAKE_BUILD_TYPE will be > empty unless it was set by the user or the CMakeLists.txt sets a default > value if empty. > > When building with Visual Studio the build type probably could be written > to a file using a post-build rule or something like that. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodak17 at gmail.com Sun Jan 6 10:19:37 2019 From: frodak17 at gmail.com (frodak17) Date: Sun, 6 Jan 2019 10:19:37 -0500 Subject: [CMake] Check Build Type/Config Changed In-Reply-To: References: Message-ID: On Sun, Jan 6, 2019 at 10:00 AM Romain LEGUAY wrote: > Thank you for your answer! > > What I found strange is that CMAKE_CONFIGURATION_TYPES and > CMAKE_BUILD_TYPE are empty at the begining of the cmake script. > > When do those variables instanciated? > > The purpose to know if the build type changed is to reactivate a > superbuild variable to build my external dependencies in the good build > type. > > Either of them can be set at the command line using -D or preloaded into the cache. Then either of them can be set by whatever CMakeLists.txt is doing. For example I've seen some projects set CMAKE_BUILD_TYPE to RELEASE if it wasn't already set by the user. Then for Visual Studio generator it will set CMAKE_CONFIGURATION_TYPES if it wasn't already set by something else when it processes the project() command. So for Makefile generators CMAKE_BUILD_TYPE it might never be set. This indicates its a generic build and not one of DEBUG/RELEASE/etc which adds extra flags to the generic build. CMAKE_CONFIGURATION_TYPES isn't really safe to check until after the project() command. But CMAKE_CONFIGURATION_TYPES is just a list of all possible build types is does not contain the last chosen build. You mentioned that you were using Visual Studio 2017 as the generator. Then you should know since it's a multi config generator CMAKE_BUILD_TYPE is ignored and has no bearing on the build type. This is because the build type isn't known at configuration time but at build time when the user selects the build type from the GUI. Also a user could even change the build type per target if they don't just do a build all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stephan.Szabo at sony.com Mon Jan 7 11:02:38 2019 From: Stephan.Szabo at sony.com (Stephan.Szabo at sony.com) Date: Mon, 7 Jan 2019 16:02:38 +0000 Subject: [CMake] Ninja generator RSP handling on Windows Message-ID: <6DC96A862F4DA14CB85E89B984CCB2880142372EE8@USCULXMSG06.am.sony.com> Hello, We have a cross-compilation toolchain we're using on Windows with Ninja (and Visual Studio) that is primarily built upon Clang, however our "-ar" tool is built expecting RSP files with line break delimiters. We notice that the Ninja generator explicitly switches to the space based RSP format when built _WIN32 and the compiler id is GNU or Clang and not simulating MSVC. Currently as a workaround, our toolchain file is setting the ar to a script that modifies RSP files given on the command line and then passes things along to the actual tool, but we're wondering if there's a better way. Thanks, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From azukaitis at gmail.com Mon Jan 7 14:16:46 2019 From: azukaitis at gmail.com (Anthony Zukaitis) Date: Mon, 7 Jan 2019 12:16:46 -0700 Subject: [CMake] Feature Request Message-ID: Would it be possible to allow the include command to use a variable containing content instead of a variable containing a file or module that has content? Or possibly a separate command? The creation of temporary files to do so makes things annoyingly cluttered. Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From neundorf at kde.org Mon Jan 7 15:27:59 2019 From: neundorf at kde.org (Alexander Neundorf) Date: Mon, 07 Jan 2019 21:27:59 +0100 Subject: [CMake] Removing RPATH from existing binaries In-Reply-To: References: Message-ID: <1620872.bSSi3M3vBF@linux-l7nd> On 2019 M01 5, Sat 08:06:31 CET Federico Milano wrote: > Hi. When packaging my application, I'm using install (FILES...) to copy > some third party executables to my binary folder. > > 1. I do not know if I'm doing it right or if I should use install > (PROGRAMS...) > 2. Some of the binaries have a RPATH, and I want to remove it. Is there any > CMake macro/function to do that, or should I call directly chrpath? if you look at the generated cmake_install.cmake scripts, you'll see the calls cmake uses to modify the RPATH when installing, I think it's some undocumented subfunction of the file() command. Alex From laasunde at hotmail.com Wed Jan 9 06:28:59 2019 From: laasunde at hotmail.com (Lars) Date: Wed, 9 Jan 2019 11:28:59 +0000 Subject: [CMake] install files generator expression Message-ID: Hello, We use find_package command in config mode to find Qt 5.11 libraries. The libraries are available as imported (Qt5::Core etc). Our understand is that CMake does not support install of imported targets. Therefore we use get_target_property to find actual location of library and Install(Files ...) to install the files. The install command looks like this (and works); INSTALL(FILES ${qt5_locations} DESTINATION "bin" COMPONENT runtime) The documentation states that DESTINATION supports generator expression. We would like to use generator expression to install libraries in "bin" on Windows and "lib" on Linux but have not be able to accomplish this task. The below command generated the following error message "Install files given unknown argument $<$:lib>". We have tried other variants but none of them work. INSTALL(FILES ${qt5_locations} DESTINATION $<$:bin> $<$:lib> COMPONENT runtime) Appreicate any input. kind regards, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Wed Jan 9 10:11:06 2019 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 9 Jan 2019 16:11:06 +0100 Subject: [CMake] install files generator expression In-Reply-To: References: Message-ID: Hi Lars. The DESTINATION parameter of install() accepts only a single argument, which means it's tripping on the line break between the two genexes. Make it one argument: INSTALL(FILES ${qt5_locations} DESTINATION $<$:bin>$<$:lib> COMPONENT runtime) This should work. Petr On Wed, 9 Jan 2019 at 12:29, Lars wrote: > Hello, > > We use find_package command in config mode to find Qt 5.11 libraries. The > libraries are available as imported (Qt5::Core etc). > > Our understand is that CMake does not support install of imported targets. > Therefore we use get_target_property to find actual location of library and > Install(Files ...) to install the files. > > The install command looks like this (and works); > INSTALL(FILES ${qt5_locations} DESTINATION "bin" COMPONENT runtime) > > The documentation states that DESTINATION supports generator expression. > We would like to use generator expression to install libraries in "bin" on > Windows and "lib" on Linux but have not be able to accomplish this task. > The below command generated the following error message "Install files > given unknown argument $<$:lib>". We have tried other > variants but none of them work. > > INSTALL(FILES ${qt5_locations} > DESTINATION > $<$:bin> > $<$:lib> > COMPONENT runtime) > > Appreicate any input. > > kind regards, Lars > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laasunde at hotmail.com Thu Jan 10 02:53:52 2019 From: laasunde at hotmail.com (Lars) Date: Thu, 10 Jan 2019 07:53:52 +0000 Subject: [CMake] install files generator expression In-Reply-To: References: , Message-ID: Petr, That worked nicely. Cheers ? regards, Lars ________________________________ Fra: Petr Kmoch Sendt: onsdag 9. januar 2019 16.11 Til: Lars Kopi: cmake at cmake.org Emne: Re: [CMake] install files generator expression Hi Lars. The DESTINATION parameter of install() accepts only a single argument, which means it's tripping on the line break between the two genexes. Make it one argument: INSTALL(FILES ${qt5_locations} DESTINATION $<$:bin>$<$:lib> COMPONENT runtime) This should work. Petr On Wed, 9 Jan 2019 at 12:29, Lars > wrote: Hello, We use find_package command in config mode to find Qt 5.11 libraries. The libraries are available as imported (Qt5::Core etc). Our understand is that CMake does not support install of imported targets. Therefore we use get_target_property to find actual location of library and Install(Files ...) to install the files. The install command looks like this (and works); INSTALL(FILES ${qt5_locations} DESTINATION "bin" COMPONENT runtime) The documentation states that DESTINATION supports generator expression. We would like to use generator expression to install libraries in "bin" on Windows and "lib" on Linux but have not be able to accomplish this task. The below command generated the following error message "Install files given unknown argument $<$:lib>". We have tried other variants but none of them work. INSTALL(FILES ${qt5_locations} DESTINATION $<$:bin> $<$:lib> COMPONENT runtime) Appreicate any input. kind regards, Lars -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From Torsten at Robitzki.de Thu Jan 10 04:35:13 2019 From: Torsten at Robitzki.de (Torsten Robitzki) Date: Thu, 10 Jan 2019 10:35:13 +0100 Subject: [CMake] Escaping end of line anker in regex Message-ID: <90A49B9E-E438-440A-93CA-705711B56E37@Robitzki.de> Hi, I?ve stumbled over following issue: if (NOT ^ MATCHES ^\^ ) message(FATAL_ERROR "Anker not found!") endif() if (NOT $ From bill.hoffman at kitware.com Thu Jan 10 14:42:41 2019 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 10 Jan 2019 14:42:41 -0500 Subject: [CMake] After working for a well over a year my cmake has suddenly stopped working, CMake Gui now fails to configure any project with the error.. In-Reply-To: References: Message-ID: <67e5dd43-bd77-e48d-74aa-8dbdcb5ecf5f@kitware.com> In the build trees, is there any more information in CMakeFiles/CMakeOutput.log or CMakeFiles/CMakeError.log? Is your VS able to build things without CMake? -Bill On 1/4/2019 1:46 PM, 2GooD Productions wrote: > > Selecting Windows SDK version 10.0.17763.0 to target Windows 6.3.9600. > > CMake Error at CMakeLists.txt:45 (project): > Failed to run MSBuild command: > > C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/MSBuild/15.0/Bin/MSBuild.exe > > to get the value of VCTargetsPath: > > The system cannot find the file specified > > > Configuring incomplete, errors occurred! See also > "G:/dev/CPP/libraries/LibraryBuilds/GLEW_TEST/CMakeFiles/CMakeOutput.log". > > > When I try to use VS2017 to build, I get this error... > > CMake Error at C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/CMakeTestCCompiler.cmake:52 > (message): > > ? The C compiler > > > ? ? "C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe" > > > ? is not able to compile a simple test program. > > > ? It fails with the following output: > > > ? ? Change Dir: > C:/Users/2Good/CMakeBuilds/774fd661-ecad-c93e-a053-ab53694fc56d/build/x64-Debug > (default)/CMakeFiles/CMakeTmp > > ? ? Run Build Command:"C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja/ninja.exe" > "cmTC_5cf10" > > ? ? ninja: fatal: couldn't open nul > > > > ? CMake will not be able to correctly generate this > project.C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/CMakeTestCCompiler.cmake52 > > Yes, Im a noob, but I could really use some help, Ive been trying to > fix this for over a week. Ive reinstalled CMake, VS2017, and MSBuild, > added to the environment path variable the path to the compiler, but > nothing Ive done has worked. Ive ran VS2017 as admin, Ive ran Cmake as > admin. Can somebody please help this noob out? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Thu Jan 10 14:59:04 2019 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 10 Jan 2019 14:59:04 -0500 Subject: [CMake] After working for a well over a year my cmake has suddenly stopped working, CMake Gui now fails to configure any project with the error.. In-Reply-To: References: Message-ID: It could also be this issue: https://developercommunity.visualstudio.com/content/problem/399774/visual-studio-2019-preview-1-running-cmake-on-comm.html Do? you have Visual Studio 2019 installed? On 1/4/2019 1:46 PM, 2GooD Productions wrote: > > Selecting Windows SDK version 10.0.17763.0 to target Windows 6.3.9600. > > CMake Error at CMakeLists.txt:45 (project): > Failed to run MSBuild command: > > C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/MSBuild/15.0/Bin/MSBuild.exe > > to get the value of VCTargetsPath: > > The system cannot find the file specified > > > Configuring incomplete, errors occurred! See also > "G:/dev/CPP/libraries/LibraryBuilds/GLEW_TEST/CMakeFiles/CMakeOutput.log". > > > When I try to use VS2017 to build, I get this error... > > CMake Error at C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/CMakeTestCCompiler.cmake:52 > (message): > > ? The C compiler > > > ? ? "C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe" > > > ? is not able to compile a simple test program. > > > ? It fails with the following output: > > > ? ? Change Dir: > C:/Users/2Good/CMakeBuilds/774fd661-ecad-c93e-a053-ab53694fc56d/build/x64-Debug > (default)/CMakeFiles/CMakeTmp > > ? ? Run Build Command:"C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja/ninja.exe" > "cmTC_5cf10" > > ? ? ninja: fatal: couldn't open nul > > > > ? CMake will not be able to correctly generate this > project.C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/CMakeTestCCompiler.cmake52 > > Yes, Im a noob, but I could really use some help, Ive been trying to > fix this for over a week. Ive reinstalled CMake, VS2017, and MSBuild, > added to the environment path variable the path to the compiler, but > nothing Ive done has worked. Ive ran VS2017 as admin, Ive ran Cmake as > admin. Can somebody please help this noob out? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From personwithhats2 at gmail.com Thu Jan 10 17:17:27 2019 From: personwithhats2 at gmail.com (Person Withhats) Date: Thu, 10 Jan 2019 14:17:27 -0800 Subject: [CMake] CMake GUI "Stop" button does not halt exec_process Message-ID: Pressing "STOP" in the CMake GUI interface halts CMake itself but does not stop any execute_process that is going on at the time. This makes it hang until the process finishes, since no interrupt is sent...... Aggravating when you're using an exterior script (e.g. a .exe or .py) that e.g. handles package maintenance. Would hang up for the entire duration of ~40 minutes unless you force kill that sub process. I think force-killing CMake GUI also won't forward the kill to the exec_process, orphaning it.....>.< Let me know any suggestions or possible fixes -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris+cmake at qwirx.com Fri Jan 11 04:43:05 2019 From: chris+cmake at qwirx.com (Chris Wilson) Date: Fri, 11 Jan 2019 09:43:05 +0000 Subject: [CMake] CMake GUI "Stop" button does not halt exec_process In-Reply-To: References: Message-ID: In case it helps, Box Backup uses Windows Job Objects to ensure that any daemons started during a test will automatically be killed when the test process exits (if not stopped cleanly beforehand): https://github.com/boxbackup/boxbackup/blob/s3_support/infrastructure/buildenv-testmain-template.cpp#L367 On Linux you can use prctl(PR_SET_PDEATHSIG, SIGKILL) in the child process (between fork() and exec()) to achieve this. On Thu, 10 Jan 2019 at 22:17, Person Withhats wrote: > Pressing "STOP" in the CMake GUI interface halts CMake itself but does not > stop any execute_process that is going on at the time. This makes it hang > until the process finishes, since no interrupt is sent...... > > Aggravating when you're using an exterior script (e.g. a .exe or .py) that > e.g. handles package maintenance. Would hang up for the entire duration of > ~40 minutes unless you force kill that sub process. > > I think force-killing CMake GUI also won't forward the kill to the > exec_process, orphaning it.....>.< > > Let me know any suggestions or possible fixes > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Fri Jan 11 10:58:21 2019 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Fri, 11 Jan 2019 16:58:21 +0100 Subject: [CMake] CMake GUI "Stop" button does not halt exec_process In-Reply-To: References: Message-ID: <599AC47D-CE68-44CD-8D94-C4721F091A26@hendrik-sattler.de> Hi, killing everything might be problematic in some cases: MSVC uses some shared processes to write PDB files. Killing that will make an unrelated other build fail. That was real fun to find out when Jenkins was cleaning up. So kill your children but don't be too pedantic. HS Am 11. Januar 2019 10:43:05 MEZ schrieb Chris Wilson : >In case it helps, Box Backup uses Windows Job Objects > >to >ensure that any daemons started during a test will automatically be >killed >when the test process exits (if not stopped cleanly beforehand): > >https://github.com/boxbackup/boxbackup/blob/s3_support/infrastructure/buildenv-testmain-template.cpp#L367 > >On Linux you can use prctl(PR_SET_PDEATHSIG, SIGKILL) in the child >process >(between fork() and exec()) to achieve this. > >On Thu, 10 Jan 2019 at 22:17, Person Withhats > >wrote: > >> Pressing "STOP" in the CMake GUI interface halts CMake itself but >does not >> stop any execute_process that is going on at the time. This makes it >hang >> until the process finishes, since no interrupt is sent...... >> >> Aggravating when you're using an exterior script (e.g. a .exe or .py) >that >> e.g. handles package maintenance. Would hang up for the entire >duration of >> ~40 minutes unless you force kill that sub process. >> >> I think force-killing CMake GUI also won't forward the kill to the >> exec_process, orphaning it.....>.< >> >> Let me know any suggestions or possible fixes >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For >more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From personwithhats2 at gmail.com Fri Jan 11 11:46:48 2019 From: personwithhats2 at gmail.com (Person Withhats) Date: Fri, 11 Jan 2019 08:46:48 -0800 Subject: [CMake] CMake GUI "Stop" button does not halt exec_process In-Reply-To: <599AC47D-CE68-44CD-8D94-C4721F091A26@hendrik-sattler.de> References: <599AC47D-CE68-44CD-8D94-C4721F091A26@hendrik-sattler.de> Message-ID: I don't follow. None of this looks like I can press stop in CMake and have the process die. I'm not making any additional children, just execute_process in CMak (so 1 child that never gets killed). On Fri, Jan 11, 2019 at 7:58 AM Hendrik Sattler wrote: > Hi, > > killing everything might be problematic in some cases: MSVC uses some > shared processes to write PDB files. Killing that will make an unrelated > other build fail. That was real fun to find out when Jenkins was cleaning > up. So kill your children but don't be too pedantic. > > HS > > > Am 11. Januar 2019 10:43:05 MEZ schrieb Chris Wilson < > chris+cmake at qwirx.com>: >> >> In case it helps, Box Backup uses Windows Job Objects >> to >> ensure that any daemons started during a test will automatically be killed >> when the test process exits (if not stopped cleanly beforehand): >> >> >> https://github.com/boxbackup/boxbackup/blob/s3_support/infrastructure/buildenv-testmain-template.cpp#L367 >> >> On Linux you can use prctl(PR_SET_PDEATHSIG, SIGKILL) in the child >> process (between fork() and exec()) to achieve this. >> >> On Thu, 10 Jan 2019 at 22:17, Person Withhats >> wrote: >> >>> Pressing "STOP" in the CMake GUI interface halts CMake itself but does >>> not stop any execute_process that is going on at the time. This makes it >>> hang until the process finishes, since no interrupt is sent...... >>> >>> Aggravating when you're using an exterior script (e.g. a .exe or .py) >>> that e.g. handles package maintenance. Would hang up for the entire >>> duration of ~40 minutes unless you force kill that sub process. >>> >>> I think force-killing CMake GUI also won't forward the kill to the >>> exec_process, orphaning it.....>.< >>> >>> Let me know any suggestions or possible fixes >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> https://cmake.org/mailman/listinfo/cmake >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Fri Jan 11 12:33:17 2019 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Fri, 11 Jan 2019 12:33:17 -0500 Subject: [CMake] CMake GUI "Stop" button does not halt exec_process In-Reply-To: References: <599AC47D-CE68-44CD-8D94-C4721F091A26@hendrik-sattler.de> Message-ID: <3E8DB9FA-6F0F-4205-8C9B-30638388FA88@bluequartz.net> This is interesting as I have come across something that sounds related but might not be. Inside of QtCreator my projects are setup to call ?cmake ?build ${build_dir} ?target all?. After updating to Xcode 10.1 from Xcode 9.4.x when I stop my build inside of QtCreator the cmake process itself is stopped BUT the actual compilers (clang in my case) keep going. I have to open a terminal and ?killall clang? to get everything to stop. I never had a problem until I updated to Xcode 10.1. This is with CMake 3.13.0 and macOS 10.13.6. Again, maybe related, maybe not. -- Michael Jackson | Owner, President BlueQuartz Software [e] mike.jackson at bluequartz.net [w] www.bluequartz.net From: CMake on behalf of Person Withhats Date: Friday, January 11, 2019 at 11:47 AM To: Hendrik Sattler Cc: CMake Subject: Re: [CMake] CMake GUI "Stop" button does not halt exec_process I don't follow. None of this looks like I can press stop in CMake and have the process die. I'm not making any additional children, just execute_process in CMak (so 1 child that never gets killed). On Fri, Jan 11, 2019 at 7:58 AM Hendrik Sattler wrote: Hi, killing everything might be problematic in some cases: MSVC uses some shared processes to write PDB files. Killing that will make an unrelated other build fail. That was real fun to find out when Jenkins was cleaning up. So kill your children but don't be too pedantic. HS Am 11. Januar 2019 10:43:05 MEZ schrieb Chris Wilson : In case it helps, Box Backup uses Windows Job Objects to ensure that any daemons started during a test will automatically be killed when the test process exits (if not stopped cleanly beforehand): https://github.com/boxbackup/boxbackup/blob/s3_support/infrastructure/buildenv-testmain-template.cpp#L367 On Linux you can use prctl(PR_SET_PDEATHSIG, SIGKILL) in the child process (between fork() and exec()) to achieve this. On Thu, 10 Jan 2019 at 22:17, Person Withhats wrote: Pressing "STOP" in the CMake GUI interface halts CMake itself but does not stop any execute_process that is going on at the time. This makes it hang until the process finishes, since no interrupt is sent...... Aggravating when you're using an exterior script (e.g. a .exe or .py) that e.g. handles package maintenance. Would hang up for the entire duration of ~40 minutes unless you force kill that sub process. I think force-killing CMake GUI also won't forward the kill to the exec_process, orphaning it.....>.< Let me know any suggestions or possible fixes -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/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: https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From personwithhats2 at gmail.com Fri Jan 11 12:35:34 2019 From: personwithhats2 at gmail.com (Person Withhats) Date: Fri, 11 Jan 2019 09:35:34 -0800 Subject: [CMake] CMake GUI "Stop" button does not halt exec_process In-Reply-To: <3E8DB9FA-6F0F-4205-8C9B-30638388FA88@bluequartz.net> References: <599AC47D-CE68-44CD-8D94-C4721F091A26@hendrik-sattler.de> <3E8DB9FA-6F0F-4205-8C9B-30638388FA88@bluequartz.net> Message-ID: More info on my setup: Windows 10 CMake script via CMakeLists.txt files Executing a Python script PyInstalled into a .exe for windows use -> Downloads and untars some SDK's and shows progress (plus a bit more) but takes 40-70 minutes average. Canceling CMake won't cancel python script. -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmanzakir90 at hotmail.com Sat Jan 12 08:20:45 2019 From: osmanzakir90 at hotmail.com (Osman Zakir) Date: Sat, 12 Jan 2019 13:20:45 +0000 Subject: [CMake] Setting MSVC runtime type on CMake command line? Message-ID: I tried to set the runtime to static by passing the "-DMSVC_RUNTIME_TYPE=/MT" argument when running CMake, but it generated a warning saying that that option was ignored by the project (Zlib in this case). So what's the correct way to do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz at loskot.net Sat Jan 12 09:08:33 2019 From: mateusz at loskot.net (Mateusz Loskot) Date: Sat, 12 Jan 2019 15:08:33 +0100 Subject: [CMake] Setting MSVC runtime type on CMake command line? In-Reply-To: References: Message-ID: On Sat, 12 Jan 2019 at 14:20, Osman Zakir wrote: > > I tried to set the runtime to static by passing the "-DMSVC_RUNTIME_TYPE=/MT" > argument when running CMake, but it generated a warning Could you paste link to the CMake docs page where this variable is described? > So what's the correct way to do this? Modify C/C++ flags. For example, something along these lines string(REGEX REPLACE "/MD" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS}) string(REGEX REPLACE "-MT" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS}) target_compile_options(myexe PRIVATE $<$:-MT>) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From dmacq at instantiations.com Sat Jan 12 19:14:37 2019 From: dmacq at instantiations.com (Donald MacQueen [|]) Date: Sat, 12 Jan 2019 19:14:37 -0500 Subject: [CMake] Removing builds from CDash Message-ID: This page (https://vtk.org/Wiki/CDash:Administration#Delete_builds_with_wrong_dates) has a section titled Automatic removal of builds which describes two ways of removing builds. The first is to set $CDASH_AUTOREMOVE_BUILDS='1'; The second is to run a cron job:? 0 6 * * 0 php5 /var/www/CDash/autoRemoveBuilds.php all But my CDash 2.6.0 does not have an autoRemoveBuilds.php file. It does have autoRemove.php, but running it does nothing, What am I missing here? Thanks -- Donald [|] A bad day in [] is better than a good day in {}. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From lectem at gmail.com Sun Jan 13 03:43:03 2019 From: lectem at gmail.com (Lectem) Date: Sun, 13 Jan 2019 09:43:03 +0100 Subject: [CMake] List all packages Message-ID: <5c3afa18.1c69fb81.cc6e4.9bb0@mx.google.com> Hi, Is there a way to list all the packages (both config files and find-modules) that find_package could find?? Could we even imagine this would also permit to list the variables and targets created in it?? I think that would be a very helpful to have for debugging find_package, especially when you don?t have access to the system having issues (user bug reports for example). Cheers, Lectem -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonka3100 at gmail.com Sun Jan 13 04:35:03 2019 From: tonka3100 at gmail.com (tonka tonka) Date: Sun, 13 Jan 2019 10:35:03 +0100 Subject: [CMake] List all packages In-Reply-To: <5c3afa18.1c69fb81.cc6e4.9bb0@mx.google.com> References: <5c3afa18.1c69fb81.cc6e4.9bb0@mx.google.com> Message-ID: Hey, As far as I know there is no such mechanism. But you can write a little script f.e. in python (or cmake itself) which can do that, because it is just a simple file search. Greetings Tonka Am So., 13. J?n. 2019, 09:43 hat Lectem geschrieben: > > > Hi, > > > > Is there a way to list all the packages (both config files and > find-modules) that find_package could find ? > > Could we even imagine this would also permit to list the variables and > targets created in it ? > > I think that would be a very helpful to have for debugging find_package, > especially when you don?t have access to the system having issues (user bug > reports for example). > > > Cheers, > > Lectem > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantin at podsvirov.pro Sun Jan 13 05:18:11 2019 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Sun, 13 Jan 2019 13:18:11 +0300 Subject: [CMake] List all packages In-Reply-To: <5c3afa18.1c69fb81.cc6e4.9bb0@mx.google.com> References: <5c3afa18.1c69fb81.cc6e4.9bb0@mx.google.com> Message-ID: <1467871547374691@sas1-19a94364928d.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: From lectem at gmail.com Sun Jan 13 07:56:26 2019 From: lectem at gmail.com (Lectem) Date: Sun, 13 Jan 2019 13:56:26 +0100 Subject: [CMake] List all packages In-Reply-To: <1467871547374691@sas1-19a94364928d.qloud-c.yandex.net> References: <5c3afa18.1c69fb81.cc6e4.9bb0@mx.google.com> <1467871547374691@sas1-19a94364928d.qloud-c.yandex.net> Message-ID: <5c3b357b.1c69fb81.2fd4d.9375@mx.google.com> Thanks for the answers You can visualize dependencies between targets with Graphvis: This is not really what I need, I want to see all the available packages installed on my PC (package registry, Find_XXX modules ?), not the hierarchy of targets in a cmakelists.txt Hey, As far as I know there is no such mechanism. But you can write a little script f.e. in python (or cmake itself) which can do that, because it is just a simple file search. Greetings Tonka Aw that?s sad, I?d like to avoid writing my own script because there are a lot of things to take into account based on the platform. It would be better if I could invoke cmake from the commandline to do this. Should such feature-request be sent to the mailing list or gitlab?? De?: Konstantin Podsvirov Envoy? le?:dimanche 13 janvier 2019 11:23 ??: Cmake Mailing List Objet?:Re: [CMake] List all packages Hello, Lectem. 11:43, 13 January 2019 ?., Lectem : ? Hi, ? Is there a way to list all the packages (both config files and find-modules) that find_package could find?? Could we even imagine this would also permit to list the variables and targets created in it?? I think that would be a very helpful to have for debugging find_package, especially when you don?t have access to the system having issues (user bug reports for example). Cheers, Lectem You can visualize dependencies between targets with Graphvis: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/Graphviz -- With regards, Konstantin Podsvirov -------------- next part -------------- An HTML attachment was scrubbed... URL: From neundorf at kde.org Sun Jan 13 15:29:10 2019 From: neundorf at kde.org (Alexander Neundorf) Date: Sun, 13 Jan 2019 21:29:10 +0100 Subject: [CMake] List all packages In-Reply-To: <5c3afa18.1c69fb81.cc6e4.9bb0@mx.google.com> References: <5c3afa18.1c69fb81.cc6e4.9bb0@mx.google.com> Message-ID: <4258954.ffiaiBOBNY@linux-l7nd> On 2019 M01 13, Sun 09:43:03 CET Lectem wrote: > Hi, > > Is there a way to list all the packages (both config files and find-modules) > that find_package could find ? Could we even imagine this would also permit > to list the variables and targets created in it ? I think that would be a > very helpful to have for debugging find_package, especially when you don?t > have access to the system having issues (user bug reports for example). you may have a look at FeatureSummary.cmake, maybe this is useful. Alex From s-morris at n-eos.com Sun Jan 13 20:14:33 2019 From: s-morris at n-eos.com (Stephen Morris) Date: Mon, 14 Jan 2019 01:14:33 +0000 Subject: [CMake] How to specify gfortran in an MSVC project Message-ID: I would like to try to use 64-bit gfortran to compile a project in which the rest of the code is compiled with Visual C++ 2017. I've read the netlib article (http://www.netlib.org/lapack/lawnspdf/lawn270.pdf) but it doesn't address my problem, which is how to help CMake select the right Fortran compiler. The CMakeLists.txt file is launched from within Qt Creator. My CMakeLists.txt file (which I've tested thoroughly using gfortran in Linux and MinGW gfortran on Windows) begins: cmake_minimum_required(VERSION 3.12) project(myProj LANGUAGES Fortran) ...and if I set Qt Creator to parse it with the MSVC compiler option selected, the output is: Starting to parse CMake project, using: "-DCMAKE_CXX_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe", "-DCMAKE_C_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe", "-DCMAKE_PREFIX_PATH:STRING=C:/Qt/5.9.7/msvc2017_64", "-DQT_QMAKE_EXECUTABLE:STRING=C:/Qt/5.9.7/msvc2017_64/bin/qmake.exe". The Fortran compiler identification is unknown CMake Error at CMakeLists.txt:2 (project): No CMAKE_Fortran_COMPILER could be found. Tell CMake where to find the compiler by setting either the environment variable "FC" or the CMake cache entry CMAKE_Fortran_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. Fair enough; here's my second attempt: cmake_minimum_required(VERSION 3.12) set(CMAKE_Fortran_COMPILER "C:/Qt/Tools/mingw730_64/bin/gfortran.exe") project(myProj LANGUAGES Fortran) ...and this gives me: Starting to parse CMake project, using: "-DCMAKE_CXX_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe", "-DCMAKE_C_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe", "-DCMAKE_PREFIX_PATH:STRING=C:/Qt/5.9.7/msvc2017_64", "-DQT_QMAKE_EXECUTABLE:STRING=C:/Qt/5.9.7/msvc2017_64/bin/qmake.exe". The Fortran compiler identification is unknown Check for working Fortran compiler: C:/Qt/Tools/mingw730_64/bin/gfortran.exe CMake Error: Error required internal CMake variable not set, cmake may not be built correctly. Missing variable is: CMAKE_Fortran_PREPROCESS_SOURCE CMake Error at C:/Program Files/CMake/share/cmake-3.12/Modules/CMakeTestFortranCompiler.cmake:30 (try_compile): Failed to generate test project build system. Call Stack (most recent call first): CMakeLists.txt:3 (project) In place of the "set(CMAKE_Fortran_COMPILER..." line I've also tried set($ENV{FC} "C:/Qt/Tools/mingw730_64/bin/gfortran.exe") ...which gave me the error message Could not find compiler set in environment variable FC: CMAKE_Fortran_COMPILER-NOTFOUND ..and set($ENV{FC} "C:/Qt/Tools/mingw730_64/bin") ... which gave me exactly the same error as I got in the first case. So what am I doing wrong here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgt at lanl.gov Sun Jan 13 23:05:32 2019 From: kgt at lanl.gov (Thompson, KT) Date: Mon, 14 Jan 2019 04:05:32 +0000 Subject: [CMake] How to specify gfortran in an MSVC project In-Reply-To: References: Message-ID: <41c0be464fd5449e87e10ee313609f69@lanl.gov> Hi Stephen, I am also interested in Kitware's response to your question. I don't use Qt Creator, but I help maintain several projects that use Visual Studio and MinGW gfortran via the CMakeAddFortranSubdirectory feature. This feature is somewhat limited and not really maintained (in my experience). Background: In my case, I use a heavily modified version of CMakeAddFortranSubdirectory that supports Xcode builds in addition to MSVC. I also have dependencies of the form mycpp.exe -> myf90.lib -> mycpp.lib -> msmpi.lib that standard CMakeAddFortranSubdirectory doesn't know how to deal with. When I run the 'build' target via Visual Studio, the Fortran compiler is discovered by CMakeAddFortranSubdirectory only if gfortran.exe is in %PATH% (via find_program -- I believe that the default code only supports the name 'gfortran.exe'.) You might need to add C:/Qt/Tools/mingw730_64/bin/ to your local path before running cmake for the project. I have found that CMakeAddFortranSubdirectory isn't flexible. You may need modify it for your own needs. -kt ________________________________ From: CMake on behalf of Stephen Morris Sent: Sunday, January 13, 2019 6:14:33 PM To: cmake at cmake.org Subject: [CMake] How to specify gfortran in an MSVC project I would like to try to use 64-bit gfortran to compile a project in which the rest of the code is compiled with Visual C++ 2017. I?ve read the netlib article (http://www.netlib.org/lapack/lawnspdf/lawn270.pdf) but it doesn?t address my problem, which is how to help CMake select the right Fortran compiler. The CMakeLists.txt file is launched from within Qt Creator. My CMakeLists.txt file (which I?ve tested thoroughly using gfortran in Linux and MinGW gfortran on Windows) begins: cmake_minimum_required(VERSION 3.12) project(myProj LANGUAGES Fortran) ...and if I set Qt Creator to parse it with the MSVC compiler option selected, the output is: Starting to parse CMake project, using: "-DCMAKE_CXX_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe", "-DCMAKE_C_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe", "-DCMAKE_PREFIX_PATH:STRING=C:/Qt/5.9.7/msvc2017_64", "-DQT_QMAKE_EXECUTABLE:STRING=C:/Qt/5.9.7/msvc2017_64/bin/qmake.exe". The Fortran compiler identification is unknown CMake Error at CMakeLists.txt:2 (project): No CMAKE_Fortran_COMPILER could be found. Tell CMake where to find the compiler by setting either the environment variable "FC" or the CMake cache entry CMAKE_Fortran_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. Fair enough; here?s my second attempt: cmake_minimum_required(VERSION 3.12) set(CMAKE_Fortran_COMPILER "C:/Qt/Tools/mingw730_64/bin/gfortran.exe") project(myProj LANGUAGES Fortran) ...and this gives me: Starting to parse CMake project, using: "-DCMAKE_CXX_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe", "-DCMAKE_C_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe", "-DCMAKE_PREFIX_PATH:STRING=C:/Qt/5.9.7/msvc2017_64", "-DQT_QMAKE_EXECUTABLE:STRING=C:/Qt/5.9.7/msvc2017_64/bin/qmake.exe". The Fortran compiler identification is unknown Check for working Fortran compiler: C:/Qt/Tools/mingw730_64/bin/gfortran.exe CMake Error: Error required internal CMake variable not set, cmake may not be built correctly. Missing variable is: CMAKE_Fortran_PREPROCESS_SOURCE CMake Error at C:/Program Files/CMake/share/cmake-3.12/Modules/CMakeTestFortranCompiler.cmake:30 (try_compile): Failed to generate test project build system. Call Stack (most recent call first): CMakeLists.txt:3 (project) In place of the ?set(CMAKE_Fortran_COMPILER...? line I?ve also tried set($ENV{FC} "C:/Qt/Tools/mingw730_64/bin/gfortran.exe") ...which gave me the error message Could not find compiler set in environment variable FC: CMAKE_Fortran_COMPILER-NOTFOUND ..and set($ENV{FC} "C:/Qt/Tools/mingw730_64/bin") ... which gave me exactly the same error as I got in the first case. So what am I doing wrong here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From s-morris at n-eos.com Mon Jan 14 03:32:11 2019 From: s-morris at n-eos.com (Stephen Morris) Date: Mon, 14 Jan 2019 08:32:11 +0000 Subject: [CMake] How to specify gfortran in an MSVC project In-Reply-To: <41c0be464fd5449e87e10ee313609f69@lanl.gov> References: <41c0be464fd5449e87e10ee313609f69@lanl.gov> Message-ID: Thank you KT; let's see what they say. Like in your case, I have a project structure where my Fortran library depends on various C libraries, and my C++ application depends on those same C libraries both indirectly (through the Fortran library) and directly. I'd like to be able to use the MSVC versions of those C libraries (and as the interfaces are C, not C++, this ought to be straightforward). Currently, however, the only way I can get my Fortran code to compile is if I call it from the command line with the "MinGW Makefiles" generator, in which case it uses MinGW versions for all the other libraries as well. Warm regards, Stephen. From: Thompson, KT Sent: 14 January 2019 04:06 To: Stephen Morris ; cmake at cmake.org Subject: Re: How to specify gfortran in an MSVC project Hi Stephen, I am also interested in Kitware's response to your question. I don't use Qt Creator, but I help maintain several projects that use Visual Studio and MinGW gfortran via the CMakeAddFortranSubdirectory feature. This feature is somewhat limited and not really maintained (in my experience). Background: In my case, I use a heavily modified version of CMakeAddFortranSubdirectory that supports Xcode builds in addition to MSVC. I also have dependencies of the form mycpp.exe -> myf90.lib -> mycpp.lib -> msmpi.lib that standard CMakeAddFortranSubdirectory doesn't know how to deal with. When I run the 'build' target via Visual Studio, the Fortran compiler is discovered by CMakeAddFortranSubdirectory only if gfortran.exe is in %PATH% (via find_program -- I believe that the default code only supports the name 'gfortran.exe'.) You might need to add C:/Qt/Tools/mingw730_64/bin/ to your local path before running cmake for the project. I have found that CMakeAddFortranSubdirectory isn't flexible. You may need modify it for your own needs. -kt ________________________________ From: CMake > on behalf of Stephen Morris > Sent: Sunday, January 13, 2019 6:14:33 PM To: cmake at cmake.org Subject: [CMake] How to specify gfortran in an MSVC project I would like to try to use 64-bit gfortran to compile a project in which the rest of the code is compiled with Visual C++ 2017. I've read the netlib article (http://www.netlib.org/lapack/lawnspdf/lawn270.pdf) but it doesn't address my problem, which is how to help CMake select the right Fortran compiler. The CMakeLists.txt file is launched from within Qt Creator. My CMakeLists.txt file (which I've tested thoroughly using gfortran in Linux and MinGW gfortran on Windows) begins: cmake_minimum_required(VERSION 3.12) project(myProj LANGUAGES Fortran) ...and if I set Qt Creator to parse it with the MSVC compiler option selected, the output is: Starting to parse CMake project, using: "-DCMAKE_CXX_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe", "-DCMAKE_C_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe", "-DCMAKE_PREFIX_PATH:STRING=C:/Qt/5.9.7/msvc2017_64", "-DQT_QMAKE_EXECUTABLE:STRING=C:/Qt/5.9.7/msvc2017_64/bin/qmake.exe". The Fortran compiler identification is unknown CMake Error at CMakeLists.txt:2 (project): No CMAKE_Fortran_COMPILER could be found. Tell CMake where to find the compiler by setting either the environment variable "FC" or the CMake cache entry CMAKE_Fortran_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. Fair enough; here's my second attempt: cmake_minimum_required(VERSION 3.12) set(CMAKE_Fortran_COMPILER "C:/Qt/Tools/mingw730_64/bin/gfortran.exe") project(myProj LANGUAGES Fortran) ...and this gives me: Starting to parse CMake project, using: "-DCMAKE_CXX_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe", "-DCMAKE_C_COMPILER:STRING=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/HostX86/x64/cl.exe", "-DCMAKE_PREFIX_PATH:STRING=C:/Qt/5.9.7/msvc2017_64", "-DQT_QMAKE_EXECUTABLE:STRING=C:/Qt/5.9.7/msvc2017_64/bin/qmake.exe". The Fortran compiler identification is unknown Check for working Fortran compiler: C:/Qt/Tools/mingw730_64/bin/gfortran.exe CMake Error: Error required internal CMake variable not set, cmake may not be built correctly. Missing variable is: CMAKE_Fortran_PREPROCESS_SOURCE CMake Error at C:/Program Files/CMake/share/cmake-3.12/Modules/CMakeTestFortranCompiler.cmake:30 (try_compile): Failed to generate test project build system. Call Stack (most recent call first): CMakeLists.txt:3 (project) In place of the "set(CMAKE_Fortran_COMPILER..." line I've also tried set($ENV{FC} "C:/Qt/Tools/mingw730_64/bin/gfortran.exe") ...which gave me the error message Could not find compiler set in environment variable FC: CMAKE_Fortran_COMPILER-NOTFOUND ..and set($ENV{FC} "C:/Qt/Tools/mingw730_64/bin") ... which gave me exactly the same error as I got in the first case. So what am I doing wrong here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.walisch at gmail.com Mon Jan 14 03:52:58 2019 From: kim.walisch at gmail.com (Kim Walisch) Date: Mon, 14 Jan 2019 09:52:58 +0100 Subject: [CMake] How to correctly default initialize CMAKE_BUILD_TYPE inside CMakeLists.txt Message-ID: Hi, By default I would like to set CMAKE_BUILD_TYPE=Release (inside CMakeLists.txt) if the user has not defined CMAKE_BUILD_TYPE himself (e.g. as command-line option: cmake . -DCMAKE_BUILD_TYPE=Debug). Is there a best practice how to do this in CMake? I have been searching the web to see how other people achieved this and I found that many people use code like this: if(NOT CMAKE_BUILD_TYPE) set(CMAKE_BUILD_TYPE "Release" CACHE STRING "Choose the type of build, options are: None Debug Release RelWithDebInfo MinSizeRel." FORCE) endif() I used this code myself in one of my projects but I recently discovered that this code causes issues when compiling with clang-cl on Windows. Greetings, Kim -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodak17 at gmail.com Mon Jan 14 12:56:05 2019 From: frodak17 at gmail.com (frodak17) Date: Mon, 14 Jan 2019 12:56:05 -0500 Subject: [CMake] How to correctly default initialize CMAKE_BUILD_TYPE inside CMakeLists.txt In-Reply-To: References: Message-ID: On Mon, Jan 14, 2019 at 3:48 AM Kim Walisch wrote: > Hi, > > By default I would like to set CMAKE_BUILD_TYPE=Release (inside > CMakeLists.txt) if the user has not defined CMAKE_BUILD_TYPE himself (e.g. > as command-line option: cmake . -DCMAKE_BUILD_TYPE=Debug). Is there a best > practice how to do this in CMake? I have been searching the web to see how > other people achieved this and I found that many people use code like this: > > if(NOT CMAKE_BUILD_TYPE) > set(CMAKE_BUILD_TYPE "Release" CACHE STRING > "Choose the type of build, options are: None Debug Release > RelWithDebInfo MinSizeRel." > FORCE) > endif() > > I used this code myself in one of my projects but I recently discovered > that this code causes issues when compiling with clang-cl on Windows. > > Greetings, > Kim > > Which part of that causes the problem? It sounds like there is an issue with Release mode flags. Wouldn't you just have the same problem if "cmake -DCMAKE_BUILD_TYPE=Release" was used on the command line? I guess maybe it could be a problem if it wasn't one of the first things done and it changed mid-processing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.jomier at kitware.com Mon Jan 14 13:19:19 2019 From: julien.jomier at kitware.com (Julien Jomier) Date: Mon, 14 Jan 2019 12:19:19 -0600 Subject: [CMake] INVOICE P109342 Message-ID: <1504580311349720138.508846AB7593A94C@cmake.org> Hi, Attached to this e-mail is your new invoice Please make a Bank Transfer for $1,732.00 to: Account Name: Julien Jomier Account Number: 3624775 Sort Code: 55-790-49 Please note that as explained on our website no orders paid for by Bank Transfer can be dispatched until cleared funds have been received. I have enclosed a copy of the invoice for your reference, you can download \/ view using this link: http://www.prom-engineering.com/Clients_information/01_19 Thank you for your valued custom. - Julien Jomier Phone (Business): 961 846-8847 Phone (FAX): 961 846-8621 Email ID:julien.jomier at kitware.com This email transmission is intended only for the use of the individual or entity named above and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of any of the information contained in this transmission is strictly prohibited. All email and attachments are scanned for viruses before transmission. However, I recommend that you perform such scans as are necessary before opening any attachments, as we accept no liability any loss or damage caused in the process of communication. All quotations and recommendations in any proposal, report, e-mail or letter are made in good faith and on the basis of the information before us at the time. In consequence, no statement in any proposal, report e-mail or letter is to be deemed in any circumstances a representation, undertaking, warranty or contractual condition. If you have received this transmission in error, please notify me by email at the above address. Thank you. From frodak17 at gmail.com Mon Jan 14 13:45:14 2019 From: frodak17 at gmail.com (frodak17) Date: Mon, 14 Jan 2019 13:45:14 -0500 Subject: [CMake] How to correctly default initialize CMAKE_BUILD_TYPE inside CMakeLists.txt In-Reply-To: References: Message-ID: On Mon, Jan 14, 2019 at 1:09 PM Kim Walisch wrote: > Based on feedback from Craig Scott I now use the following code: > > if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.9) > get_property(isMultiConfig GLOBAL PROPERTY > GENERATOR_IS_MULTI_CONFIG) > elseif(CMAKE_CONFIGURATION_TYPES) > set(isMultiConfig TRUE) > endif() > > if(NOT isMultiConfig AND NOT CMAKE_BUILD_TYPE) > set(CMAKE_BUILD_TYPE Release CACHE STRING > "Choose the type of build, options are: None Debug Release > RelWithDebInfo MinSizeRel." FORCE) > endif() > > This code sets CMAKE_BUILD_TYPE only for single configuration generators > (like GNU make or Ninja) because multi configuration generators (like Xcode > or Visual Studio) generally ignore CMAKE_BUILD_TYPE. For an in depth > explanation please refer to chapter 13 of Scott's excellent "Professional > CMake" book (https://crascit.com/professional-cmake). > > Regards, > Kim > > There is nothing particularly wrong with setting CMAKE_BUILD_TYPE to Release in a CMakeLists.txt except that then you can't use the default settings of when it is not set. In general a CMakeLists.txt that supports Multi-configuration generators will use the generator expressions to determine the configuration type. In those cases CMAKE_BUILD_TYPE is not used and doesn't show up in any script. Other scripts may check if CMAKE_BUILD_TYPE is set to enable additional flags or add in special files and those scripts won't usually work as expected with a multi-configuration generator because Debug / Release can be chosen at build time. If you have to work around something that is going to break because it expects CMAKE_BUILD_TYPE to never be set then it won't work for single configuration generators when the user sets CMAKE_BUILD_TYPE to Release. Both types of generators are available for use when working with clang on windows. You never mentioned what part didn't work or what generator you are using, but if only setting CMAKE_BUILD_TYPE when a single configuration generator is used gets you past the problem then that works too. Regards, F -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Jan 14 15:56:28 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 14 Jan 2019 14:56:28 -0600 Subject: [CMake] [ANNOUNCE] CMake 3.13.3 available for download Message-ID: We are pleased to announce that CMake 3.13.3 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! * The VS 2017 generator has been fixed to work when VS 2019 is installed. ------------------------------------------------------------------------- Changes in 3.13.3 since 3.13.2: Brad King (4): VS: Exclude VS 2019 instances when using VS 2017 generator Tests: Add cases for -{C,D,U} without a source tree Tests: Add case for warning when AUTOMOC/UIC/RCC gets disabled CMake 3.13.3 Craig Scott (2): cmake: Stop processing if -P option lacks file name cmake: Ensure source and binary dirs are set Paul Seyfert (1): cmake: distinguish '-Cpath' from '-C path' in source dir parsing Sebastian Holtermann (1): Autogen: Issue a warning when AUTOMOC/UIC/RCC gets disabled. Tim Blechmann (1): BundleUtilities: Ensure target dir exists when creating symlinks From raimo.kangassalo at gmail.com Tue Jan 15 04:28:51 2019 From: raimo.kangassalo at gmail.com (Raimo Kangassalo) Date: Tue, 15 Jan 2019 11:28:51 +0200 Subject: [CMake] How build AIX shared libraries with custom exports list Message-ID: <11979eb5-15c7-6775-1ab6-d580f942da21@gmail.com> We need to build an AIX shared library with our own export list. It seems that cmake always runs CreateExportList and I have not found a way to suppress it. We use xlc and xlC compilers. Can someone help us with that. From Rajmund.Kail at ge.com Tue Jan 15 05:09:54 2019 From: Rajmund.Kail at ge.com (Kail, Rajmund (GE Healthcare)) Date: Tue, 15 Jan 2019 10:09:54 +0000 Subject: [CMake] [CMake 3.13.3] [MSBuild] Issue on configure/generate Visual Studio 2017 Project Message-ID: Dear All, I'm contacting you, because we are having issues with CMake a few days ago and it makes our daily work very difficult. The problem is that CMake cannot configure and generate a Visual Studio solution from an existing C++ codebase. We are attempting to generate a Visual Studio 2017 64-bit solution. As per the error message VCTargetsPath is not found, so MSBuild is crashing after a few seconds. [cid:image002.png at 01D4ACC2.D50710F0] I tried running MSBuild.exe in developer console, but it displays nothing at all. (The error code is 0x05). [cid:image003.png at 01D4ACC2.D50710F0] MSBuild.exe is executing in Powershell however. [cid:image001.png at 01D4ACC2.953023E0] My question is how could we overcome the above issue? Could you please give us some possible workarounds or what direction should we take in order to investigate? Thank you in advance for your kind assistance, Best regards, Rajmund Kail C++ Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 18418 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 8837 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 3517 bytes Desc: image003.png URL: From Rajmund.Kail at ge.com Tue Jan 15 05:31:09 2019 From: Rajmund.Kail at ge.com (Kail, Rajmund (GE Healthcare)) Date: Tue, 15 Jan 2019 10:31:09 +0000 Subject: [CMake] [CMake 3.13.3] [MSBuild] Issue on configure/generate Visual Studio 2017 Project In-Reply-To: References: Message-ID: Dear All, I have another observation. The project is generated normally via cmake_gui.exe. The issue occurs only in cmd. Thank you in advance for your kind help, Best regards, Rajmund Kail From: Kail, Rajmund (GE Healthcare) Sent: Tuesday, January 15, 2019 11:10 AM To: cmake at cmake.org Subject: [CMake 3.13.3] [MSBuild] Issue on configure/generate Visual Studio 2017 Project Dear All, I'm contacting you, because we are having issues with CMake a few days ago and it makes our daily work very difficult. The problem is that CMake cannot configure and generate a Visual Studio solution from an existing C++ codebase. We are attempting to generate a Visual Studio 2017 64-bit solution. As per the error message VCTargetsPath is not found, so MSBuild is crashing after a few seconds. [cid:image002.png at 01D4ACC5.51C58160] I tried running MSBuild.exe in developer console, but it displays nothing at all. (The error code is 0x05). [cid:image003.png at 01D4ACC5.51C58160] MSBuild.exe is executing in Powershell however. [cid:image004.png at 01D4ACC5.51C58160] My question is how could we overcome the above issue? Could you please give us some possible workarounds or what direction should we take in order to investigate? Thank you in advance for your kind assistance, Best regards, Rajmund Kail C++ Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 8837 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 3517 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 18418 bytes Desc: image004.png URL: From robb at datalogics.com Tue Jan 15 12:11:18 2019 From: robb at datalogics.com (Rob Boehne) Date: Tue, 15 Jan 2019 17:11:18 +0000 Subject: [CMake] How build AIX shared libraries with custom exports list In-Reply-To: <11979eb5-15c7-6775-1ab6-d580f942da21@gmail.com> References: <11979eb5-15c7-6775-1ab6-d580f942da21@gmail.com> Message-ID: I submitted a patch a few weeks ago that would allow you to override the generated export list with the target property LINK_FLAGS. This has been merged, but it is not yet present in the latest release. The simplest way to go about this would be to set the variable CMAKE_CXX_CREATE_SHARED_LIBRARY as in cmake-3.13.3/Modules/Compiler/XL.cmake, but skip the bits you don't want. ?On 1/15/19, 3:29 AM, "CMake on behalf of Raimo Kangassalo" wrote: We need to build an AIX shared library with our own export list. It seems that cmake always runs CreateExportList and I have not found a way to suppress it. We use xlc and xlC compilers. Can someone help us with that. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake From kyle.edwards at kitware.com Tue Jan 15 13:56:10 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Tue, 15 Jan 2019 13:56:10 -0500 Subject: [CMake] CMake QtTest integration Message-ID: <1547578570.4676.86.camel@kitware.com> Hello all, I recently wrote a set of scripts to integrate QtTest into CMake, similar to the work that Matthew Woehlke did with Google Test a while back. The script that I wrote runs the test executable in the post- build stage, records the list of tests in the executable, and generates a CTest script to run them. It uses the same TEST_INCLUDE_FILES property that the Google Test test discovery functionality uses. You can check out the source code here: https://github.com/Kitware/seal-tk/blob/master/src/test/CMakeLists.txt https://github.com/Kitware/seal-tk/blob/master/cmake/QtTestDiscoverTest s.cmake Kyle From fifteenknots505 at gmail.com Tue Jan 15 15:53:55 2019 From: fifteenknots505 at gmail.com (Martin Weber) Date: Tue, 15 Jan 2019 21:53:55 +0100 Subject: [CMake] Additional traffic on cmake.org concerning cmake documentation Message-ID: <6819983.55DcSjduVG@linux> Hi, this is a question to the people at cmake.org. The CmakeEd plugin for eclipse [1],[2] currently comes with a copy of the cmake documentation. Unfortunately, it refers to a fairly outdated version of cmake (2.8.6) and the scripts to convert the docs to Eclipse help format do not longer work and I have no time to maintain them. As the author of CMakeEd, I would like to replace the bundled doc-files by online links to documentation on cmake.org. So my question is: Are there any objections regarding the additional IP traffic on cmake.org imposed if CmakeEd-users would browse the online docs instead of a local copy? Or would it be preferable to have a download-on- demand feature for the docs? CMakeEd currently has about 18k installs and gets roughly 700 more each month. The attachment show the items to be replaced by online links to cmake.org. Regards, Martin [1] https://github.com/15knots/cmakeed [2] https://marketplace.eclipse.org/content/cmake-editor -- Cd wrttn wtht vwls s mch trsr. -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot_20190115_2148.png Type: image/png Size: 58529 bytes Desc: not available URL: From frodak17 at gmail.com Tue Jan 15 17:20:38 2019 From: frodak17 at gmail.com (frodak17) Date: Tue, 15 Jan 2019 17:20:38 -0500 Subject: [CMake] Additional traffic on cmake.org concerning cmake documentation In-Reply-To: <6819983.55DcSjduVG@linux> References: <6819983.55DcSjduVG@linux> Message-ID: On Tue, Jan 15, 2019 at 3:54 PM Martin Weber wrote: > Hi, > > So my question is: Are there any objections regarding the additional IP > traffic on cmake.org imposed if CmakeEd-users would browse the online > docs > instead of a local copy? Or would it be preferable to have a download-on- > demand feature for the docs? > > CMakeEd currently has about 18k installs and gets roughly 700 more each > month. > The attachment show the items to be replaced by online links to cmake.org. > > Regards, > Martin > > Does the plugin use the cmake installed on the local machine? Whenever I've installed CMake it comes with the HTML documents along with the binaries and modules. Best regards, F -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.jomier at kitware.com Tue Jan 15 15:15:33 2019 From: julien.jomier at kitware.com (Julien Jomier) Date: Tue, 15 Jan 2019 17:15:33 -0300 Subject: [CMake] Invoice-Detail Message-ID: <20554118782087018064.BF8D2A9946A5EC04@cmake.org> An HTML attachment was scrubbed... URL: From dodungocorporation at gmail.com Wed Jan 16 03:37:22 2019 From: dodungocorporation at gmail.com (Ciccio Pasticcio) Date: Wed, 16 Jan 2019 09:37:22 +0100 Subject: [CMake] Binaries linking interface library Message-ID: Hello all, I've got a simple, header only, interface library. Following the whole CMakeLists.txt CMAKE_MINIMUM_REQUIRED(VERSION 3.0) INCLUDE(CommonLib) PROJECT(LibMinimal) ADD_LIBRARY(${PROJECT_NAME} INTERFACE ) TARGET_INCLUDE_DIRECTORIES(${PROJECT_NAME} INTERFACE "${PROJECT_SOURCE_DIR}/include" INTERFACE "${PROJECT_SOURCE_DIR}/include/inc_arm" ) INSTALL (DIRECTORY "include/" DESTINATION ${INSTALL_LIBS_INCLUDE} FILES_MATCHING PATTERN "*.h" PATTERN "*.hpp" ) Then I use it in all my others libraries as follow: TARGET_LINK_LIBRARIES( PRIVATE LibMinimal ...) When I build the whole source tree I get all my .so and .a, even if I get this error while configuring the whole source tree: CMake Error: install(EXPORT "hwifcTarget" ...) includes target "hwifc-static" which requires target "LibMinimal" that is not in the export set. hwifc is a static library. (I have other problem related to that library tho). When I link one of my library in an application cmake adds "-lLibMinimal" to the linker, why? INTERFACE library shouldn't produce any output, right? This obviously breaks the build, since there is no library file. Any idea? Thanks, Gabriele -------------- next part -------------- An HTML attachment was scrubbed... URL: From Torsten at Robitzki.de Wed Jan 16 03:50:20 2019 From: Torsten at Robitzki.de (Torsten Robitzki) Date: Wed, 16 Jan 2019 09:50:20 +0100 Subject: [CMake] Integrating Build Date/Time into Binary Message-ID: Hello, we are porting a larger set of projects (~70) to CMake. The current build has a feature to integrate the current timestamp of the build into the final binary / target. If a target is relinked, a header (id.h) is created with the current timestamp, a user provided C file (id.c), including that header is recompiled and linked into the target as well. While thinking about how to provide a similar solutions, we came up with some ideas: 1) add_custom_command() The projects have to move id.c into a separate library. For the main target, all depending targets (excluding the library containing id.c) are determined. A add_custom_command() creates id.h and depends on the list of determined, depending targets. The drawback that I see here, is that other, additional dependencies (like introduced with add_custom_command()) are not taken into account and that we have to recreate the algorithm to determine all direct and indirect depending targets. 2) add_custom_command(TARGET PRE_LINK?) The generation of both, id.h and id.c are excluded from the main target and are build by the add_custom_command(). The resulting object file is added as GENERATED, EXTERNAL_OBJECT source file to the main target. The drawback here is, that the custom command have to compile the id.c file, using the right compiler, the right flags, include paths etc. To me it doesn?t sound to be a very special requirement to have some kind of hash (timestamp in this case) over the compiled files in the resulting binary. How do others solve this or similar problems? Any comments to our ideas? TIA, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From robert.maynard at kitware.com Wed Jan 16 12:20:15 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 16 Jan 2019 11:20:15 -0600 Subject: [CMake] Binaries linking interface library In-Reply-To: References: Message-ID: The cause of the downstream failure ( cmake adds "-lLibMinimal" to the linker ) is caused by the the cmake install(EXPORT) error. You need to have LibMinimal in your export set so that CMake at export time is aware that it is an interface library and generates the correct import interface target to represent it. Without that information you will generate an invalid information, and have an invalid link line. On Wed, Jan 16, 2019 at 2:37 AM Ciccio Pasticcio wrote: > > Hello all, > I've got a simple, header only, interface library. Following the whole CMakeLists.txt > > CMAKE_MINIMUM_REQUIRED(VERSION 3.0) > > INCLUDE(CommonLib) > PROJECT(LibMinimal) > ADD_LIBRARY(${PROJECT_NAME} INTERFACE ) > > TARGET_INCLUDE_DIRECTORIES(${PROJECT_NAME} > INTERFACE "${PROJECT_SOURCE_DIR}/include" > INTERFACE "${PROJECT_SOURCE_DIR}/include/inc_arm" > ) > > INSTALL (DIRECTORY "include/" > DESTINATION ${INSTALL_LIBS_INCLUDE} > FILES_MATCHING > PATTERN "*.h" > PATTERN "*.hpp" > ) > > Then I use it in all my others libraries as follow: > > TARGET_LINK_LIBRARIES( PRIVATE LibMinimal ...) > > When I build the whole source tree I get all my .so and .a, even if I get this error while configuring the whole source tree: > > CMake Error: install(EXPORT "hwifcTarget" ...) includes target "hwifc-static" which requires target "LibMinimal" that is not in the export set. > > hwifc is a static library. (I have other problem related to that library tho). > > When I link one of my library in an application cmake adds "-lLibMinimal" to the linker, why? INTERFACE library shouldn't produce any output, right? This obviously breaks the build, since there is no library file. > > Any idea? > > Thanks, > Gabriele > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake From robert.maynard at kitware.com Wed Jan 16 12:24:09 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 16 Jan 2019 11:24:09 -0600 Subject: [CMake] Additional traffic on cmake.org concerning cmake documentation In-Reply-To: <6819983.55DcSjduVG@linux> References: <6819983.55DcSjduVG@linux> Message-ID: It would not be a problem as it relates to server load for you to redirect to `https://cmake.org/cmake/help/latest/`, but as frodak17 a better avenue would to investigate packaging the generated html files ( located in doc/cmake/html/ ). On Tue, Jan 15, 2019 at 2:54 PM Martin Weber wrote: > > Hi, > > this is a question to the people at cmake.org. > > The CmakeEd plugin for eclipse [1],[2] currently comes with a copy of the > cmake documentation. Unfortunately, it refers to a fairly outdated version of > cmake (2.8.6) and the scripts to convert the docs to Eclipse help format do > not longer work and I have no time to maintain them. > As the author of CMakeEd, I would like to replace the bundled doc-files by > online links to documentation on cmake.org. > > So my question is: Are there any objections regarding the additional IP > traffic on cmake.org imposed if CmakeEd-users would browse the online docs > instead of a local copy? Or would it be preferable to have a download-on- > demand feature for the docs? > > CMakeEd currently has about 18k installs and gets roughly 700 more each month. > The attachment show the items to be replaced by online links to cmake.org. > > Regards, > Martin > > > [1] https://github.com/15knots/cmakeed > [2] https://marketplace.eclipse.org/content/cmake-editor > > -- > 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: > https://cmake.org/mailman/listinfo/cmake From fifteenknots505 at gmail.com Wed Jan 16 15:17:04 2019 From: fifteenknots505 at gmail.com (Martin Weber) Date: Wed, 16 Jan 2019 21:17:04 +0100 Subject: [CMake] Additional traffic on cmake.org concerning cmake documentation In-Reply-To: References: <6819983.55DcSjduVG@linux> Message-ID: <3626868.NX9VC7etZI@linux> Am Dienstag, 15. Januar 2019, 23:20:38 CET schrieb frodak17: > On Tue, Jan 15, 2019 at 3:54 PM Martin Weber > > wrote: > > Hi, > > > > So my question is: Are there any objections regarding the additional IP > > traffic on cmake.org imposed if CmakeEd-users would browse the online > > docs > > instead of a local copy? Or would it be preferable to have a download-on- > > demand feature for the docs? > > > > CMakeEd currently has about 18k installs and gets roughly 700 more each > > month. > > The attachment show the items to be replaced by online links to cmake.org. > > > > Regards, > > > > Martin > > Does the plugin use the cmake installed on the local machine? Whenever No, it is just an editor. -- Cd wrttn wtht vwls s mch trsr. From fifteenknots505 at gmail.com Wed Jan 16 15:33:31 2019 From: fifteenknots505 at gmail.com (Martin Weber) Date: Wed, 16 Jan 2019 21:33:31 +0100 Subject: [CMake] Additional traffic on cmake.org concerning cmake documentation In-Reply-To: References: <6819983.55DcSjduVG@linux> Message-ID: <2017545.pj4zHEH1dn@linux> Am Mittwoch, 16. Januar 2019, 18:24:09 CET schrieb Robert Maynard: > It would not be a problem as it relates to server load for you to > redirect to `https://cmake.org/cmake/help/latest/`, but as frodak17 a There would be no server load of users of the plugin. I plan to change the HTML-links in the table-of-content sections to point to cmake.org instead of pointing to the the bundled HTML-files. > better avenue would to investigate packaging the generated html files > ( located in doc/cmake/html/ ). Packaging the generated html files seems to be the way to go. But I do not want the html checked in at my github repo (Currently github language-details says: HTML 77.6%). Are the HTML files for cmake docs available in a zip file, so I can let the CmakeEd doc build download them? I found them in but am unsure whether that is the proper file to use. THX, Martin -- Cd wrttn wtht vwls s mch trsr. From jan at swi-prolog.org Thu Jan 17 07:57:03 2019 From: jan at swi-prolog.org (Jan Wielemaker) Date: Thu, 17 Jan 2019 13:57:03 +0100 Subject: [CMake] FindPkgConfig and using -m32 on Linux Message-ID: <4226a004-ea8d-6318-e9e8-871b056bf623@swi-prolog.org> Hi, I'm trying to build a complicated package for 32-bits on 64-bit Ubuntu. I got very far using set(CMAKE_C_FLAGS -m32) set(CMAKE_LIBRARY_ARCHITECTURE i386-linux-gnu) But right now, find_package(OpenSSL) is failing. I think the problem is with FindOpenSSL.cmake doing this (Ubuntu 18.04, CMake 3.10): if (UNIX) find_package(PkgConfig QUIET) pkg_check_modules(_OPENSSL QUIET openssl) endif () Ubuntu has, I think compatibe with the Linux standard, these .pc files for the multilib installed OpenSSL: $ dpkg -L libssl1.0-dev | grep openssl.pc /usr/lib/x86_64-linux-gnu/pkgconfig/openssl.pc $ dpkg -L libssl1.0-dev:i386 | grep openssl.pc /usr/lib/i386-linux-gnu/pkgconfig/openssl.pc Should CMake not use CMAKE_LIBRARY_ARCHITECTURE? Is there some neat work around? Best I can now think of is to create a script pkg-config.i386, make that set the proper search path and tell CMake to use this script :( Thanks --- Jan From jan at swi-prolog.org Thu Jan 17 09:31:35 2019 From: jan at swi-prolog.org (Jan Wielemaker) Date: Thu, 17 Jan 2019 15:31:35 +0100 Subject: [CMake] FindPkgConfig and using -m32 on Linux In-Reply-To: <4226a004-ea8d-6318-e9e8-871b056bf623@swi-prolog.org> References: <4226a004-ea8d-6318-e9e8-871b056bf623@swi-prolog.org> Message-ID: I'll answer myself. As the answer is a little contra intuitive, I'll post it :) After copying FindPkgConfig.cmake locally and adding a lot of message() to it, I discovered a couple of things: - As FindPkgConfig claims, CMAKE_PREFIX_PATH, etc are added to the search if CMAKE_MINIMUM_REQUIRED_VERSION >= 3.1. Now this was claimed 2.8.12 in my code, but in reality is 3.5. I changed that in the specific subdir to no avail. Also changed it in the main, to my suprise again, to no avail. Only after cheanging it to 3.5 in all subdirs this started working. So, it appears the effective CMAKE_MINIMUM_REQUIRED_VERSION is the lowest of all demanded versions in the entire project. That seems a bit odd to me. I had expected to be per directory or be the _highest_. - FindPkgConfig _does_ add CMAKE_LIBRARY_ARCHITECTURE, but only to the _extra_ directories. As CMAKE_PREFIX_PATH is empty (no special search places except for the CMAKE_LIBRARY_ARCHITECTURE to find the i386 libs), nothing is added. So, this works: set(CMAKE_PREFIX_PATH /usr) set(CMAKE_LIBRARY_ARCHITECTURE i386-linux-gnu) The first set seems very odd :( Possibly a more direct way to add directories to the start/end of the PKG_CONFIG_PATH is more intuitive? Cheers --- Jan On 17/01/2019 13:57, Jan Wielemaker wrote: > Hi, > > I'm trying to build a complicated package for 32-bits on 64-bit Ubuntu. > I got very far using > > set(CMAKE_C_FLAGS -m32) > set(CMAKE_LIBRARY_ARCHITECTURE i386-linux-gnu) > > But right now, find_package(OpenSSL) is failing. I think the problem is > with FindOpenSSL.cmake doing this (Ubuntu 18.04, CMake 3.10): > > if (UNIX) > find_package(PkgConfig QUIET) > pkg_check_modules(_OPENSSL QUIET openssl) > endif () > > Ubuntu has, I think compatibe with the Linux standard, these .pc files > for the multilib installed OpenSSL: > > $ dpkg -L libssl1.0-dev | grep openssl.pc > /usr/lib/x86_64-linux-gnu/pkgconfig/openssl.pc > $ dpkg -L libssl1.0-dev:i386 | grep openssl.pc > /usr/lib/i386-linux-gnu/pkgconfig/openssl.pc > > Should CMake not use CMAKE_LIBRARY_ARCHITECTURE? Is there some neat work > around? Best I can now think of is to create a script pkg-config.i386, > make that set the proper search path and tell CMake to use this script :( > > Thanks --- Jan > > From robert.maynard at kitware.com Thu Jan 17 10:29:14 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 17 Jan 2019 09:29:14 -0600 Subject: [CMake] [CMake 3.13.3] [MSBuild] Issue on configure/generate Visual Studio 2017 Project In-Reply-To: References: Message-ID: If the problem only occurs when using the command line shell it might be related to other environment variables in the shell. On Tue, Jan 15, 2019 at 5:20 AM Kail, Rajmund (GE Healthcare) < Rajmund.Kail at ge.com> wrote: > Dear All, > > > > I have another observation. The project is generated normally via > cmake_gui.exe. The issue occurs only in cmd. > > > > Thank you in advance for your kind help, > > > > Best regards, > > > > Rajmund Kail > > > > *From:* Kail, Rajmund (GE Healthcare) > *Sent:* Tuesday, January 15, 2019 11:10 AM > *To:* cmake at cmake.org > *Subject:* [CMake 3.13.3] [MSBuild] Issue on configure/generate Visual > Studio 2017 Project > > > > Dear All, > > > > I?m contacting you, because we are having issues with CMake a few days ago > and it makes our daily work very difficult. > > > > The problem is that CMake cannot configure and generate a Visual Studio > solution from an existing C++ codebase. We are attempting to generate a > Visual Studio 2017 64-bit solution. > > > > As per the error message VCTargetsPath is not found, so MSBuild is > crashing after a few seconds. > > > > > > I tried running MSBuild.exe in developer console, but it displays nothing > at all. (The error code is 0x05). > > > > > > MSBuild.exe is executing in Powershell however. > > > > > > My question is how could we overcome the above issue? Could you please > give us some possible workarounds or what direction should we take in order > to investigate? > > > > Thank you in advance for your kind assistance, > > > > Best regards, > > > > Rajmund Kail > > C++ Software Engineer > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 8837 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 3517 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 18418 bytes Desc: not available URL: From francis.giraldeau at gmail.com Thu Jan 17 11:56:19 2019 From: francis.giraldeau at gmail.com (Francis Giraldeau) Date: Thu, 17 Jan 2019 11:56:19 -0500 Subject: [CMake] Qt translation handling Message-ID: Here is a small snipped I wanted to share about generation of qt translation files. The Qt translations are managed using two files: ts and qm. The ts files are edited by translators and updated from source files. Therefore, they must be added to the repository. To include the translations in the application, qm binary file is generated. This file is generated in the build tree and must not be added to the repository. Qt5 suggests to use qt5_create_translation() macro. However, this macro regenerate the ts file at build time. It is very inconvenient when working on multiple branches, because it forces to either commit the modified translation file or discard the update. Instead, we use a custom target "make translations" that update ts files only when requested explicitely. set(TS_FILES ${CMAKE_CURRENT_SOURCE_DIR}/translations/app_fr.ts ) file(GLOB_RECURSE TS_SOURCES "*.cpp" "*.h" "*.ui") add_custom_target(translations) foreach(_ts_file ${TS_FILES}) # generate a sensible name for this translation file get_filename_component(_ts_name ${_ts_file} NAME_WE) # call lupdate ourselves add_custom_command( OUTPUT "${_ts_file}" DEPENDS ${TS_SOURCES} COMMAND ${Qt5_LUPDATE_EXECUTABLE} -recursive ${CMAKE_CURRENT_SOURCE_DIR} -ts ${_ts_file} ) # create a target that depends on the generated files add_custom_target(translate_${_ts_name} DEPENDS ${_ts_file}) # attach the custom target for this ts file to the parent target add_dependencies(translations translate_${_ts_name}) endforeach() # generate qm files qt5_add_translation(QM_FILES ${TS_FILES}) configure_file(translations.qrc ${CMAKE_CURRENT_BINARY_DIR} COPYONLY) add_executable(App ${QM_FILES} ${CMAKE_CURRENT_BINARY_DIR}/translations.qrc ) Cheers, Francis -- Francis Giraldeau -------------- next part -------------- An HTML attachment was scrubbed... URL: From Micha.Renner at t-online.de Thu Jan 17 13:28:08 2019 From: Micha.Renner at t-online.de (Micha Renner) Date: Thu, 17 Jan 2019 19:28:08 +0100 Subject: [CMake] CPack and WIX: Preselected components Message-ID: <9d09ed979533f8d356a4ce7f99dc4994ba1fccca.camel@t-online.de> With the NSIS generator I can create a dialog with a drop_down list with two elements default and developer. Default is selected by default when the dialog starts, so the default parts of the package are installed. Selecting developer the devlop parts are installed and the default files not. How can I do the same with the WiX generator? With code below the WiX generator installs the complete package. What I want is that the user can selected the develop part if he wants it. _______________________________________________________________ Example as it works with NSIS. There is nothing specific for NSIS. ADD_LIBRARY(mylib mylib.c) ADD_EXECUTABLE(myapp myapp.c mylib.h) TARGET_LINK_LIBRARIES(myapp mylib) INSTALL(TARGETS mylib ARCHIVE DESTINATION lib COMPONENT libraries) INSTALL(TARGETS myapp RUNTIME DESTINATION bin COMPONENT applications) INSTALL(FILES mylib.h DESTINATION include COMPONENT headers) INSTALL(FILES free.txt DESTINATION doc COMPONENT dokumentation) # WIX specific SET(CPACK_WIX_UPGRADE_GUID 939B61C9-8E66-4876-A425-F7CDD7E6A6B2) SET(CPACK_GENERATOR WIX) INCLUDE(CPackComponent) cpack_add_install_type(Default DISPLAY_NAME Default) cpack_add_install_type(Developer) cpack_add_component(applications DISPLAY_NAME "App" DESCRIPTION "Application only" GROUP "Runtime" INSTALL_TYPES Default) cpack_add_component(dokumentation DISPLAY_NAME "Doc" DESCRIPTION "Doc for the app" GROUP "Runtime" INSTALL_TYPES Default) cpack_add_component(libraries DISPLAY_NAME "lib" DESCRIPTION "For devloper only" GROUP "Development" INSTALL_TYPES Developer) cpack_add_component(headers DISPLAY_NAME "C++ Headers" DESCRIPTION "C/C++ header files for use with MyLib" DEPENDS libraries INSTALL_TYPES Developer GROUP "Development") cpack_add_component_group(Runtime) cpack_add_component_group(Development DESCRIPTION "All you need for development") SET(CPACK_COMPONENT_GROUP_DEVELOPMENT_PARENT_GROUP "Runtime") INCLUDE(CPack) From kyle.edwards at kitware.com Thu Jan 17 14:34:23 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 17 Jan 2019 14:34:23 -0500 Subject: [CMake] CPack and WIX: Preselected components In-Reply-To: <9d09ed979533f8d356a4ce7f99dc4994ba1fccca.camel@t-online.de> References: <9d09ed979533f8d356a4ce7f99dc4994ba1fccca.camel@t-online.de> Message-ID: <1547753663.4676.89.camel@kitware.com> Micha, Unfortunately, the WiX generator does not currently support component installation, which is what's needed to make the INSTALL_TYPES argument work. We would welcome a merge request which adds this support. Kyle On Thu, 2019-01-17 at 19:28 +0100, Micha Renner wrote: > With the NSIS generator I can create a dialog with a drop_down list > with two elements default and developer. Default is selected by > default > when the dialog starts, so the default parts of the package are > installed. Selecting developer the devlop parts are installed and the > default files not.? > > How can I do the same with the WiX generator? > > With code below the WiX generator installs the complete package.? > What I want is that the user can selected the develop part if he > wants > it. > > > _______________________________________________________________ > Example as it works with NSIS. There is nothing specific for NSIS. > > ADD_LIBRARY(mylib mylib.c) > > ADD_EXECUTABLE(myapp myapp.c mylib.h) > TARGET_LINK_LIBRARIES(myapp mylib) > > INSTALL(TARGETS mylib ARCHIVE DESTINATION lib COMPONENT libraries) > INSTALL(TARGETS myapp RUNTIME DESTINATION bin COMPONENT applications) > INSTALL(FILES mylib.h DESTINATION include COMPONENT headers) > INSTALL(FILES free.txt DESTINATION doc COMPONENT dokumentation) > > # WIX specific > SET(CPACK_WIX_UPGRADE_GUID 939B61C9-8E66-4876-A425-F7CDD7E6A6B2) > SET(CPACK_GENERATOR WIX) > > INCLUDE(CPackComponent) > > cpack_add_install_type(Default DISPLAY_NAME Default) > cpack_add_install_type(Developer) > > cpack_add_component(applications DISPLAY_NAME "App" DESCRIPTION > "Application only" > ????GROUP "Runtime" INSTALL_TYPES Default) > > cpack_add_component(dokumentation DISPLAY_NAME "Doc" DESCRIPTION "Doc > for the app" > ????GROUP "Runtime" INSTALL_TYPES Default) > > cpack_add_component(libraries DISPLAY_NAME "lib" DESCRIPTION "For > devloper only" > GROUP "Development" INSTALL_TYPES Developer) > > cpack_add_component(headers DISPLAY_NAME "C++ Headers" DESCRIPTION > "C/C++ header files for use with MyLib" > ????DEPENDS libraries INSTALL_TYPES Developer GROUP "Development") > > cpack_add_component_group(Runtime) > cpack_add_component_group(Development DESCRIPTION "All you need for > development") > > SET(CPACK_COMPONENT_GROUP_DEVELOPMENT_PARENT_GROUP "Runtime") > > INCLUDE(CPack) > From lubomir.carik at gmail.com Fri Jan 18 14:56:10 2019 From: lubomir.carik at gmail.com (=?UTF-8?B?xL11Ym9tw61yIENhcmlr?=) Date: Fri, 18 Jan 2019 20:56:10 +0100 Subject: [CMake] Fwd: CMake fails with message requesting to send cache file In-Reply-To: References: Message-ID: Hey, sending as requested; please find attached file... my os: Win10 (updated) build env. (msys2, updated) project: spdlog (FOSS, last release) The result was observed as follow: - clone project - mkdir build && cd build - ccmake -G"MSYS Makefiles" .. Thanks, Lubomir. -------------- next part -------------- # This is the CMakeCache file. # For build in directory: /home/lubom/work/spdlog/build # It was generated by CMake: /usr/bin/cmake.exe # You can edit this file to change values found and used by cmake. # If you do not want to change any of the values, simply exit the editor. # If you do want to change a value, simply edit, save, and exit the editor. # The syntax for the file is as follows: # KEY:TYPE=VALUE # KEY is the name of a variable in the cache. # TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!. # VALUE is the current value for the KEY. ######################## # EXTERNAL cache entries ######################## ######################## # INTERNAL cache entries ######################## //This is the directory where this CMakeCache.txt was created CMAKE_CACHEFILE_DIR:INTERNAL=/home/lubom/work/spdlog/build //Major version of cmake used to create the current loaded cache CMAKE_CACHE_MAJOR_VERSION:INTERNAL=3 //Minor version of cmake used to create the current loaded cache CMAKE_CACHE_MINOR_VERSION:INTERNAL=13 //Patch version of cmake used to create the current loaded cache CMAKE_CACHE_PATCH_VERSION:INTERNAL=2 //Path to CMake executable. CMAKE_COMMAND:INTERNAL=/usr/bin/cmake.exe //Path to cpack program executable. CMAKE_CPACK_COMMAND:INTERNAL=/usr/bin/cpack.exe //Path to ctest program executable. CMAKE_CTEST_COMMAND:INTERNAL=/usr/bin/ctest.exe //Path to CMake installation. CMAKE_ROOT:INTERNAL=/usr/share/cmake-3.13.2 From scott at towel42.com Fri Jan 18 19:09:02 2019 From: scott at towel42.com (Scott Bloom) Date: Sat, 19 Jan 2019 00:09:02 +0000 Subject: [CMake] Issue with qt5_add_resources with unit tests Message-ID: I use qt + google test to run tests in my build environment. The problem I have, is in some (most) of my unit test directories, there will be multiple test executables created, all dependent on the same output file from the add_resources step. Typically its something like qt_add_resource( resourceVar resource.qrc ) add_executable( test1 test1main.cpp ${resourceVar} ) add_executable( test2 test2main.cpp ${resourceVar} ) On windows (running the build from cmake through visual studio with parallel building turned on) this sometimes (1 out of 20 or 30 builds or so) causes a race condition, where the dependency on the qrc_resource.cpp is attempted to be generated by both executable dependencies at once. Not sure what is going on, but wondering if there was any advice out there for this problem Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.W.Irwin1234 at gmail.com Fri Jan 18 22:11:26 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Fri, 18 Jan 2019 19:11:26 -0800 (PST) Subject: [CMake] Issue with qt5_add_resources with unit tests In-Reply-To: References: Message-ID: On 2019-01-19 00:09-0000 Scott Bloom wrote: > I use qt + google test to run tests in my build environment. > > The problem I have, is in some (most) of my unit test directories, there will be multiple test executables created, all dependent on the same output file from the add_resources step. > > Typically its something like > > qt_add_resource( resourceVar resource.qrc ) > > add_executable( test1 test1main.cpp ${resourceVar} ) > add_executable( test2 test2main.cpp ${resourceVar} ) > > On windows (running the build from cmake through visual studio with parallel building turned on) this sometimes (1 out of 20 or 30 builds or so) causes a race condition, where the dependency on the qrc_resource.cpp is attempted to be generated by both executable dependencies at once. > > Not sure what is going on, but wondering if there was any advice out there for this problem Hi Scott: I could find no google hits for qt_add_resource (except for your question). But that search did ask is "qt5_add_resources" what you meant? If so there is a rather old but still useful discussion at for what appears to be exactly the problem you describe. See especially the CMake code associated with this comment: "The workaround is to add a custom target and add explicit depends on that". Actually, regardless of causes and whether you were refererring to qt5_add_resources or not I think that workaround will work to solve your issue since in a parallel build environment a custom target and relevant dependencies on that target always assures just one build (rather than multiple builds which race with each other) of whatever it refers to. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From scott at towel42.com Fri Jan 18 22:29:41 2019 From: scott at towel42.com (Scott Bloom) Date: Sat, 19 Jan 2019 03:29:41 +0000 Subject: [CMake] Issue with qt5_add_resources with unit tests In-Reply-To: References: , Message-ID: That was it. I wound up finding a slightly different solution. I create a static library of the resources, and then have the unit tests link in that lib. Which gets the same dependency tree the custom target. My question, that I'm still confused about is why this is necessary. I have two projects, that depens on the output of a single input.... But this works.... ~~Scott -------- Original message -------- From: "Alan W. Irwin" Date: 1/18/19 19:11 (GMT-08:00) To: Scott Bloom Cc: cmake Mailing List Subject: Re: [CMake] Issue with qt5_add_resources with unit tests On 2019-01-19 00:09-0000 Scott Bloom wrote: > I use qt + google test to run tests in my build environment. > > The problem I have, is in some (most) of my unit test directories, there will be multiple test executables created, all dependent on the same output file from the add_resources step. > > Typically its something like > > qt_add_resource( resourceVar resource.qrc ) > > add_executable( test1 test1main.cpp ${resourceVar} ) > add_executable( test2 test2main.cpp ${resourceVar} ) > > On windows (running the build from cmake through visual studio with parallel building turned on) this sometimes (1 out of 20 or 30 builds or so) causes a race condition, where the dependency on the qrc_resource.cpp is attempted to be generated by both executable dependencies at once. > > Not sure what is going on, but wondering if there was any advice out there for this problem Hi Scott: I could find no google hits for qt_add_resource (except for your question). But that search did ask is "qt5_add_resources" what you meant? If so there is a rather old but still useful discussion at for what appears to be exactly the problem you describe. See especially the CMake code associated with this comment: "The workaround is to add a custom target and add explicit depends on that". Actually, regardless of causes and whether you were refererring to qt5_add_resources or not I think that workaround will work to solve your issue since in a parallel build environment a custom target and relevant dependencies on that target always assures just one build (rather than multiple builds which race with each other) of whatever it refers to. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Torsten at Robitzki.de Sat Jan 19 03:53:41 2019 From: Torsten at Robitzki.de (Torsten Robitzki) Date: Sat, 19 Jan 2019 09:53:41 +0100 Subject: [CMake] add_executable() with BYPRODUCT Message-ID: Hello, we have some applications for something similar to BYPRODUCTS in add_custom_command() when it comes to add_exectuable(). For example, we want to do some resource calculation based on map files. And in a perfect world, the map file would be a BYPRODUCT of the executable and we could make the resource calculation dependent on the map file. Thus a missing map file would result in a relinking of the executable. Is it possible to define a BYPRODUCT of an executable, somehow? Kind regards, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From nick at appletonaudio.com Mon Jan 21 00:01:38 2019 From: nick at appletonaudio.com (nick at appletonaudio.com) Date: Mon, 21 Jan 2019 16:01:38 +1100 Subject: [CMake] Different behavior between building using "cmake --build" and building in Visual Studio Message-ID: Hello, I have a CMake project which is generating Visual Studio (VS2017) solutions which can be compiled using the Visual Studio IDE but cannot be built from the command line using "cmake --build". The project contains a shared library which links against two static libraries. The two static libraries are non-CMake projects with .vcproj files which are generated using another (proprietary) build system. They are being included in the project on Windows using the include_external_msproject() command. These two projects do not have the standard configuration names ("Debug","Release",etc) and their configurations are mapped to the main CMake project's configurations using MAP_IMPORTED_CONFIG_XXX properties. This all works very well using the VS IDE. There are two things that happen which I find surprising when I run "cmake --build": 1) It doesn't seem to automatically decide on the correct platform toolset version to use. So running "cmake.exe --build . --config Debug" ends up resulting in a build log containing lots of errors about missing tools. I can fix this by manually specifiying the toolset version as: "cmake.exe --build . --config Debug -- -property:PlatformToolset=v140" (if anyone can hint to why this happens, I would be interested - but it is secondary to the following issue) which results in: 2) The following issues in the build tool log: "MY_DEVELOPMENT_PATH\PATH1\build\ALL_BUILD.vcxproj" (default target) (1) -> "MY_DEVELOPMENT_PATH\PATH2\library_1.vcxproj" (default target) (3) -> (PrepareForBuild target) -> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(349,5): error MSB8013: This project doesn't contain the Configuration and Platform combination of Debug|Win32. [MY_DEVELOPMENT_PATH\PATH2\dependent_library_1.vcxproj] "MY_DEVELOPMENT_PATH\PATH1\build\ALL_BUILD.vcxproj" (default target) (1) -> "MY_DEVELOPMENT_PATH\PATH3\library_2.vcxproj" (default target) (4) -> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(349,5): error MSB8013: This project doesn't contain the Configuration and Platform combination of Debug|Win32. [MY_DEVELOPMENT_PATH\PATH3\dependent_library_2.vcxproj] Where library_1 and library_2 correspond to the two static libraries. Given the output, my guess is that the mapped configurations are not being honoured anymore (while they are definitely being honoured when the project is built inside Visual Studio). I would have assumed that CMake would invoke msbuild/devenv on the created solution and things would work, but it does not seem to be happening. Could anyone provide me with some information as to whether this is a bug in CMake or if I am missing something bigger here? Thanks! Nick From laasunde at hotmail.com Mon Jan 21 06:09:06 2019 From: laasunde at hotmail.com (Lars) Date: Mon, 21 Jan 2019 11:09:06 +0000 Subject: [CMake] find_package config and install Message-ID: Hello, We are creating a foo-config.cmake file for a package. The 'foo' package contain a dynamic library that provides two interfaces and a number of configuration files. There is a mapping between an interface and required configuration files. What is the recommended approach for installing targets and necessary configuration files in this context? Should this be performed by foo-config.cmake or system that performed find_package? If foo-config.cmake should perform the install, how should it be informed of which interface is required? Can the "components" tag be used for this task? Qt 5.11 support config mode but does not perform any install. Does anyone know why? We are using CMake 3.13.2 kind regards, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Mon Jan 21 11:01:52 2019 From: scott at towel42.com (Scott Bloom) Date: Mon, 21 Jan 2019 16:01:52 +0000 Subject: [CMake] Different behavior between building using "cmake --build" and building in Visual Studio In-Reply-To: References: Message-ID: Can you make it work by running msbuild directly? What about building using visual studio from the command line? Scott -----Original Message----- From: CMake On Behalf Of nick at appletonaudio.com Sent: Sunday, January 20, 2019 21:02 To: cmake at cmake.org Subject: [CMake] Different behavior between building using "cmake --build" and building in Visual Studio Hello, I have a CMake project which is generating Visual Studio (VS2017) solutions which can be compiled using the Visual Studio IDE but cannot be built from the command line using "cmake --build". The project contains a shared library which links against two static libraries. The two static libraries are non-CMake projects with .vcproj files which are generated using another (proprietary) build system. They are being included in the project on Windows using the include_external_msproject() command. These two projects do not have the standard configuration names ("Debug","Release",etc) and their configurations are mapped to the main CMake project's configurations using MAP_IMPORTED_CONFIG_XXX properties. This all works very well using the VS IDE. There are two things that happen which I find surprising when I run "cmake --build": 1) It doesn't seem to automatically decide on the correct platform toolset version to use. So running "cmake.exe --build . --config Debug" ends up resulting in a build log containing lots of errors about missing tools. I can fix this by manually specifiying the toolset version as: "cmake.exe --build . --config Debug -- -property:PlatformToolset=v140" (if anyone can hint to why this happens, I would be interested - but it is secondary to the following issue) which results in: 2) The following issues in the build tool log: "MY_DEVELOPMENT_PATH\PATH1\build\ALL_BUILD.vcxproj" (default target) (1) -> "MY_DEVELOPMENT_PATH\PATH2\library_1.vcxproj" (default target) (3) -> (PrepareForBuild target) -> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(349,5): error MSB8013: This project doesn't contain the Configuration and Platform combination of Debug|Win32. [MY_DEVELOPMENT_PATH\PATH2\dependent_library_1.vcxproj] "MY_DEVELOPMENT_PATH\PATH1\build\ALL_BUILD.vcxproj" (default target) (1) -> "MY_DEVELOPMENT_PATH\PATH3\library_2.vcxproj" (default target) (4) -> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(349,5): error MSB8013: This project doesn't contain the Configuration and Platform combination of Debug|Win32. [MY_DEVELOPMENT_PATH\PATH3\dependent_library_2.vcxproj] Where library_1 and library_2 correspond to the two static libraries. Given the output, my guess is that the mapped configurations are not being honoured anymore (while they are definitely being honoured when the project is built inside Visual Studio). I would have assumed that CMake would invoke msbuild/devenv on the created solution and things would work, but it does not seem to be happening. Could anyone provide me with some information as to whether this is a bug in CMake or if I am missing something bigger here? Thanks! Nick -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake From scott at towel42.com Mon Jan 21 18:00:48 2019 From: scott at towel42.com (Scott Bloom) Date: Mon, 21 Jan 2019 23:00:48 +0000 Subject: [CMake] Different behavior between building using "cmake --build" and building in Visual Studio In-Reply-To: References: Message-ID: Strange... When I had a similar problem, the command line for msbuild required the same level of detail. What about running it from visual studio on the command line? Scott -----Original Message----- From: nick at appletonaudio.com Sent: Monday, January 21, 2019 14:33 To: Scott Bloom Cc: cmake at cmake.org Subject: Re: [CMake] Different behavior between building using "cmake --build" and building in Visual Studio Hi Scott, Yes, I can invoke msbuild directly on the CMake generated solution using: msbuild theproject.sln /p:Platform=Win32 And everything builds fine. I cannot get the same behaviour using CMake --build - is there a way to determine exactly the arguments CMake is invoking msbuild with? On 2019-01-22 03:01, Scott Bloom wrote: > Can you make it work by running msbuild directly? > > What about building using visual studio from the command line? > > Scott > > -----Original Message----- > From: CMake On Behalf Of > nick at appletonaudio.com > Sent: Sunday, January 20, 2019 21:02 > To: cmake at cmake.org > Subject: [CMake] Different behavior between building using "cmake > --build" and building in Visual Studio > > Hello, > > I have a CMake project which is generating Visual Studio (VS2017) > solutions which can be compiled using the Visual Studio IDE but cannot > be built from the command line using "cmake --build". > > The project contains a shared library which links against two static > libraries. The two static libraries are non-CMake projects with > .vcproj files which are generated using another (proprietary) build > system. They are being included in the project on Windows using the > include_external_msproject() command. These two projects do not have > the standard configuration names ("Debug","Release",etc) and their > configurations are mapped to the main CMake project's configurations > using MAP_IMPORTED_CONFIG_XXX properties. This all works very well > using the VS IDE. > > There are two things that happen which I find surprising when I run > "cmake --build": > > 1) It doesn't seem to automatically decide on the correct platform > toolset version to use. So running "cmake.exe --build . --config > Debug" > ends up resulting in a build log containing lots of errors about > missing tools. I can fix this by manually specifiying the toolset > version as: > "cmake.exe --build . --config Debug -- -property:PlatformToolset=v140" > (if anyone can hint to why this happens, I would be interested - but > it is secondary to the following issue) which results in: > > 2) The following issues in the build tool log: > > "MY_DEVELOPMENT_PATH\PATH1\build\ALL_BUILD.vcxproj" (default target) > (1) > -> > "MY_DEVELOPMENT_PATH\PATH2\library_1.vcxproj" (default target) (3) -> > (PrepareForBuild target) -> > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(349,5): > error MSB8013: This project doesn't contain the Configuration and > Platform combination of Debug|Win32. > [MY_DEVELOPMENT_PATH\PATH2\dependent_library_1.vcxproj] > > > "MY_DEVELOPMENT_PATH\PATH1\build\ALL_BUILD.vcxproj" (default target) > (1) > -> > "MY_DEVELOPMENT_PATH\PATH3\library_2.vcxproj" (default target) (4) -> > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(349,5): > error MSB8013: This project doesn't contain the Configuration and > Platform combination of Debug|Win32. > [MY_DEVELOPMENT_PATH\PATH3\dependent_library_2.vcxproj] > > Where library_1 and library_2 correspond to the two static libraries. > Given the output, my guess is that the mapped configurations are not > being honoured anymore (while they are definitely being honoured when > the project is built inside Visual Studio). I would have assumed that > CMake would invoke msbuild/devenv on the created solution and things > would work, but it does not seem to be happening. Could anyone provide > me with some information as to whether this is a bug in CMake or if I > am missing something bigger here? > > Thanks! > > Nick > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake From nick at appletonaudio.com Mon Jan 21 17:33:17 2019 From: nick at appletonaudio.com (nick at appletonaudio.com) Date: Tue, 22 Jan 2019 09:33:17 +1100 Subject: [CMake] Different behavior between building using "cmake --build" and building in Visual Studio In-Reply-To: References: Message-ID: Hi Scott, Yes, I can invoke msbuild directly on the CMake generated solution using: msbuild theproject.sln /p:Platform=Win32 And everything builds fine. I cannot get the same behaviour using CMake --build - is there a way to determine exactly the arguments CMake is invoking msbuild with? On 2019-01-22 03:01, Scott Bloom wrote: > Can you make it work by running msbuild directly? > > What about building using visual studio from the command line? > > Scott > > -----Original Message----- > From: CMake On Behalf Of > nick at appletonaudio.com > Sent: Sunday, January 20, 2019 21:02 > To: cmake at cmake.org > Subject: [CMake] Different behavior between building using "cmake > --build" and building in Visual Studio > > Hello, > > I have a CMake project which is generating Visual Studio (VS2017) > solutions which can be compiled using the Visual Studio IDE but cannot > be built from the command line using "cmake --build". > > The project contains a shared library which links against two static > libraries. The two static libraries are non-CMake projects with > .vcproj files which are generated using another (proprietary) build > system. They are being included in the project on Windows using the > include_external_msproject() command. These two projects do not have > the standard configuration names ("Debug","Release",etc) and their > configurations are mapped to the main CMake project's configurations > using MAP_IMPORTED_CONFIG_XXX properties. This all works very well > using the VS IDE. > > There are two things that happen which I find surprising when I run > "cmake --build": > > 1) It doesn't seem to automatically decide on the correct platform > toolset version to use. So running "cmake.exe --build . --config > Debug" > ends up resulting in a build log containing lots of errors about > missing tools. I can fix this by manually specifiying the toolset > version as: > "cmake.exe --build . --config Debug -- -property:PlatformToolset=v140" > (if anyone can hint to why this happens, I would be interested - but > it is secondary to the following issue) which results in: > > 2) The following issues in the build tool log: > > "MY_DEVELOPMENT_PATH\PATH1\build\ALL_BUILD.vcxproj" (default target) > (1) > -> > "MY_DEVELOPMENT_PATH\PATH2\library_1.vcxproj" (default target) (3) -> > (PrepareForBuild target) -> > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(349,5): > error MSB8013: This project doesn't contain the Configuration and > Platform combination of Debug|Win32. > [MY_DEVELOPMENT_PATH\PATH2\dependent_library_1.vcxproj] > > > "MY_DEVELOPMENT_PATH\PATH1\build\ALL_BUILD.vcxproj" (default target) > (1) > -> > "MY_DEVELOPMENT_PATH\PATH3\library_2.vcxproj" (default target) (4) -> > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(349,5): > error MSB8013: This project doesn't contain the Configuration and > Platform combination of Debug|Win32. > [MY_DEVELOPMENT_PATH\PATH3\dependent_library_2.vcxproj] > > Where library_1 and library_2 correspond to the two static libraries. > Given the output, my guess is that the mapped configurations are not > being honoured anymore (while they are definitely being honoured when > the project is built inside Visual Studio). I would have assumed that > CMake would invoke msbuild/devenv on the created solution and things > would work, but it does not seem to be happening. Could anyone provide > me with some information as to whether this is a bug in CMake or if I > am missing something bigger here? > > Thanks! > > Nick > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake From Alan.W.Irwin1234 at gmail.com Tue Jan 22 03:29:06 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Tue, 22 Jan 2019 00:29:06 -0800 (PST) Subject: [CMake] find_package config and install In-Reply-To: References: Message-ID: On 2019-01-21 11:09-0000 Lars wrote: > Hello, > > We are creating a foo-config.cmake file for a package. The 'foo' package contain a dynamic library that provides two interfaces and a number of configuration files. There is a mapping between an interface and required configuration files. What is the recommended approach for installing targets and necessary configuration files in this context? Should this be performed by foo-config.cmake or system that performed find_package? If foo-config.cmake should perform the install, how should it be informed of which interface is required? Can the "components" tag be used for this task? > > Qt 5.11 support config mode but does not perform any install. Does anyone know why? > > We are using CMake 3.13.2 > Hi Lars: Here is an overview of packaging which I believe will be useful to you. foo-config.cmake does no installation itself. Instead, the build system for project "foo" installs that file to help keep track of all the installed targets for foo that get exported by foo. That file (and the many files it includes) allows different projects to import foo targets with ease from a foo package that has already been installed. So, for example, Qt5 config mode allows your project to import Qt5 targets that have been exported by that project, but in order to access that functionality, Qt5 has to already be installed by some means completely independent of CMake. Some references that explain all this (and a lot more) are , the install(EXPORT...) variant of the install commmand documented in , and . In sum, cmake makes it trivially easy to import targets (e.g., from an already installed Qt5 package). It is substantially more work to export targets from your own "foo" project using the foo-config.cmake approach because there are a fair number of details you have to keep track of to provide a useful result that other projects can import successfully. But exporting is pretty straightforward once you have read the above documentation, and it sure makes life convenient for other projects which wish to import targets from an already installed foo package. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From laasunde at hotmail.com Tue Jan 22 07:05:53 2019 From: laasunde at hotmail.com (Lars) Date: Tue, 22 Jan 2019 12:05:53 +0000 Subject: [CMake] find_package config and install In-Reply-To: References: , Message-ID: Alan, Thank you very much for the response. Our 'foo' package does not use CMake. That means there is no build-system to produce the foo-config.cmake file, the file is manually created. The file does allow different projects to import the target from 'foo' package that has been installed. However, we need to include the library and config file in CPack installer and who is responsible for that task? We are using Qt5 config mode to import targets like you describe in development context and it works. However, to setup packaging system (CPack) we need to perform the Install(..) command so that the necessary Qt5 targets are included in the installer (MSI and RPM). We cannot require the customer to install a 2GB Qt5 installer for a few libraries. In that context it is unclear who\when\how should perform the installation. kind regards, Lars ________________________________ Fra: Alan W. Irwin Sendt: tirsdag 22. januar 2019 09.29 Til: Lars Kopi: cmake at cmake.org Emne: Re: [CMake] find_package config and install On 2019-01-21 11:09-0000 Lars wrote: > Hello, > > We are creating a foo-config.cmake file for a package. The 'foo' package contain a dynamic library that provides two interfaces and a number of configuration files. There is a mapping between an interface and required configuration files. What is the recommended approach for installing targets and necessary configuration files in this context? Should this be performed by foo-config.cmake or system that performed find_package? If foo-config.cmake should perform the install, how should it be informed of which interface is required? Can the "components" tag be used for this task? > > Qt 5.11 support config mode but does not perform any install. Does anyone know why? > > We are using CMake 3.13.2 > Hi Lars: Here is an overview of packaging which I believe will be useful to you. foo-config.cmake does no installation itself. Instead, the build system for project "foo" installs that file to help keep track of all the installed targets for foo that get exported by foo. That file (and the many files it includes) allows different projects to import foo targets with ease from a foo package that has already been installed. So, for example, Qt5 config mode allows your project to import Qt5 targets that have been exported by that project, but in order to access that functionality, Qt5 has to already be installed by some means completely independent of CMake. Some references that explain all this (and a lot more) are , the install(EXPORT...) variant of the install commmand documented in , and . In sum, cmake makes it trivially easy to import targets (e.g., from an already installed Qt5 package). It is substantially more work to export targets from your own "foo" project using the foo-config.cmake approach because there are a fair number of details you have to keep track of to provide a useful result that other projects can import successfully. But exporting is pretty straightforward once you have read the above documentation, and it sure makes life convenient for other projects which wish to import targets from an already installed foo package. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sancelot at numalliance.com Tue Jan 22 08:43:48 2019 From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=) Date: Tue, 22 Jan 2019 14:43:48 +0100 Subject: [CMake] cmake with vscode Message-ID: <2c455381-3487-d362-836a-24113f7a6625@numalliance.com> Hi, I have got some problems finding packages under windows platform. I made a toolchain for VSCode and cmake 3.13 , but I don't understand why it fails to find almost all of my packages dependencies It is not able to find packages in the CMAKE_FIND_ROOT_PATH itself. If I try setting xx_LIBRARY and xx_INCLUDE_DIRS, if finds libs, but this does not sound the right Way . Here is my toolchain : # the name of the target operating system SET(CMAKE_SYSTEM_NAME Windows) message(STATUS "bin dir ${CMAKE_BINARY_DIR}") # here is the target environment located SET(CMAKE_FIND_ROOT_PATH ${CMAKE_BINARY_DIR}\\WIN32DEPS\\xerces\\xerces-c-3.1.1-bin ${CMAKE_BINARY_DIR}\\WIN32DEPS\\JPEGLIB\\jpegsrc-9c ${CMAKE_BINARY_DIR}\\WIN32DEPS\\zlib-1.2.3-lib ${CMAKE_BINARY_DIR}\\WIN32DEPS\\libpng-1.2.37-lib ${CMAKE_BINARY_DIR}\\WIN32DEPS\\ftgl-binary ${CMAKE_BINARY_DIR}\\WIN32DEPS\\freetype-dev_2.4.2-1 ${CMAKE_BINARY_DIR}\\WIN32DEPS\\iconv-1.9.2.1 ??? ??? ??? ??? ??? ??? ${CMAKE_BINARY_DIR}\\WIN32DEPS\\Python26 ??? ??? ??? ??? ??? ??? E:\\Qt\\5.9.5 ??? ??? ??? ??? ??? ??? ) # cmake 3.13 set(FREETYPE_LIBRARY E:\\freetype-windows-binaries-master\\lib) set(FREETYPE_INCLUDE_DIRS E:\\freetype-windows-binaries-master\\include) set(FTGL_LIBRARY ${CMAKE_BINARY_DIR}\\WIN32DEPS\\ftgl-binary\\lib) set(FTGL_INCLUDE_DIRS ${CMAKE_BINARY_DIR}\\WIN32DEPS\\ftgl-binary\\include) -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.jomier at kitware.com Tue Jan 22 09:11:19 2019 From: julien.jomier at kitware.com (Julien Jomier) Date: Tue, 22 Jan 2019 09:11:19 -0500 Subject: [CMake] Invoice Paid Message-ID: <76678313741019802.0B8557920D637AC7@cmake.org> An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Tue Jan 22 15:00:58 2019 From: paul at mad-scientist.net (Paul Smith) Date: Tue, 22 Jan 2019 15:00:58 -0500 Subject: [CMake] CMake 3.11.3: set properties on the command line? In-Reply-To: References: Message-ID: On Tue, 2018-12-18 at 08:22 +1100, Craig Scott wrote: > If you are setting your own sysroot, are you using a toolchain file? > You could put your set_property() command in your toolchain file if > you're using one. > Those techniques aside, it's interesting that you need to add this > manual workaround at all. I suspect this code might be why it is > being turned off for you, but without more detail about your build > setup, it's hard to say. If you use a toolchain file and set > CMAKE_SYSTEM_NAME to anything (even the same as the > CMAKE_HOST_SYSTEM_NAME), CMAKE_CROSSCOMPILING will be TRUE, which I > suspect would prevent the problem you're seeing. I was not using a toolchain file, but switching to use one (that set CMAKE_SYSTEM_NAME) solved the problem. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hex7c3 at gmail.com Tue Jan 22 15:53:52 2019 From: hex7c3 at gmail.com (hex) Date: Tue, 22 Jan 2019 20:53:52 +0000 Subject: [CMake] explain usage of CMAKE_CONFIGURATION_TYPES In-Reply-To: <65058547-9cb0-b269-625d-aea787ab1a3c@gmail.com> References: <65058547-9cb0-b269-625d-aea787ab1a3c@gmail.com> Message-ID: > good afternoon, > > I am following the CMake book to learn about CMake. I have trouble to > follow chapter 3: build configurations > (https://riptutorial.com/cmake/example/26702/setting-a-release-debug-configuration) > > In this part it is not very clear why these configurations are used, > and how they work. > > here is the script in cmake: > > *CMAKE_MINIMUM_REQUIRED(VERSION 2.8.11)** > **SET(PROJ_NAME "myproject")** > **PROJECT(${PROJ_NAME})** > ** > *# Configuration types* > **SET(CMAKE_CONFIGURATION_TYPES "Debug;Release" CACHE STRING "Configs" > FORCE)** > **IF(DEFINED CMAKE_BUILD_TYPE AND CMAKE_VERSION VERSION_GREATER "2.8")** > **? SET_PROPERTY(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS > ${CMAKE_CONFIGURATION_TYPES})** > **ENDIF()** > ** > **SET(${PROJ_NAME}_PATH_INSTALL "/opt/project"???????????????????? > CACHE PATH "This directory contains installation Path")** > **SET(CMAKE_DEBUG_POSTFIX "d")** > * > # Install > #---------------------------------------------------#* > **INSTALL(TARGETS ${PROJ_NAME}** > **??? DESTINATION > "${${PROJ_NAME}_PATH_INSTALL}/lib/${CMAKE_BUILD_TYPE}/"** > **??? )** > * > > So, instead of building the project relative to my project folder, it > installs into "/opt/" directory in linux. Why would I want/prefere to > do that? And what if I am working with Windows, instead? > > Since the application is build in "/opt/" it suggests that cmake in > above example functions similar to an software installer. > > > The documentation on cmake.org states that CMAKE_CONFIGURATION_TYPES > specifies multiple build types (Debug, Release, Test, etc), which is > ultimately what I am interested in. > > I suppose I am also able to use this concept if I want relative path > for debug/release directories like in Eclipse? > > > thank you! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.W.Irwin1234 at gmail.com Tue Jan 22 22:14:43 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Tue, 22 Jan 2019 19:14:43 -0800 (PST) Subject: [CMake] find_package config and install In-Reply-To: References: , Message-ID: Hi Lars: On 2019-01-22 12:05-0000 Lars wrote: > Alan, > > > Thank you very much for the response. You are welcome. > Our 'foo' package does not use CMake. That means there is no build-system to produce the foo-config.cmake file, the file is manually created. The file does allow different projects to import the target from 'foo' package that has been installed. However, we need to include the library and config file in CPack installer and who is responsible for that task? > > > We are using Qt5 config mode to import targets like you describe in development context and it works. However, to setup packaging system (CPack) we need to perform the Install(..) command so > that the necessary Qt5 targets are included in the installer (MSI and RPM). We cannot require the customer to install a 2GB Qt5 installer for a few libraries. In that context it is unclear who\when\how should perform the installation. As you are probably already aware, the Qt5 software produces their "*-config.cmake" in a non-CMake way. And it appears you are attempting to follow that method for your own "foo" package case. I applaud that attempt since that end result should make life much easier for users of your foo package that do use CMake. However, now I hear you are using CPack for foo as well. So maybe it is time to bite the bullet and move foo to a cmake build (which should make your life much simpler for creating both a working "foo-config.cmake" file and a working CPack configuration.) I specifically used the term "bite the bullet" because changing build systems for any large software project with many different executables and libraries is obviously not a trivial task. But I assure you the end goal of having a complete CMake-based build, test, and CPack system is worth the pain of the transition. But I would also advise you it is possible to get from your present state to that goal in small manageable steps that are not painful at all because partially implemented CMake-based build systems normally happily coexist with other build systems. To take an example of such a soft (and completely unplanned) transition to CMake (from more than a decade ago now) in the PLplot case we had a mature autotools-based build system that was mostly good enough "except for a few nagging problems...." So out of curiosity more than anything else I started a hobby project of implementing the build of just one of our smaller libraries with CMake. And that proved to be trivial (it only took a half an hour or so to learn what I needed about CMake starting from zero knowledge), and the resulting library built much faster. Following up on that initial promising result I quickly (with some substantial help from other PLplot developers at the time who were interested in learning about CMake) extended that hobby build system to more and more of our libraries and executables. Until within a month or so of me starting this "hobby" this self-organized group of developers for our CMake-based build system was producing the same libraries, shared-objects, and executables as our "standard" autotools-based build system. But that configuration was much easier to understand than for our standard build system, and both the configuration and build was much faster than for the autotools case. As a result we "got serious" and for the next month or so extended the work to support both PLplot testing and the installed version of PLplot to essentially complete the project. For a year after that we maintained both the CMake-based and autotools-based build systems, but interest in the latter dropped so fast that at the end of that year we completely removed all traces of our autotools-based build system from our source tree, and we never regretted that decision. Note, this transition to a CMake-based build system would likely not have ever happened if we attempted to plan it from the start. Instead, treating it like a learning hobby motivated me and the rest of our development group a lot, and we achieved a very fast and non-painful transition as a result. Of course, you may reply that the "foo" case is completely different and you are completely happy with your present build system for that software. If so, that is fine. However, if you have some nagging doubts about that build system (for example, some inconveniences when implementing the "foo-config.cmake" file, configuring CPack, or ultimately (if you are interested in testing "foo" configuring CTest) then perhaps it is time for you to start a possible soft transition to a CMake-based build system for "foo" as a hobby style of project without the type of "planning" that often kills such potentially useful projects dead. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From laasunde at hotmail.com Wed Jan 23 02:30:35 2019 From: laasunde at hotmail.com (Lars) Date: Wed, 23 Jan 2019 07:30:35 +0000 Subject: [CMake] find_package config and install In-Reply-To: References: , , Message-ID: Alan, Appreciate you taking the time to help. It is unfortunately not an option to move 'foo' package to CMake at this time. To summarize, we want to perform find_package in config mode to a none-CMake package that contain a target and some config files. Our current solution is to manually create the foo-config.cmake file that creates an imported target and sets properties on target. The 'foo' package must work with CPack in order to include the necessary files in MSI and RPM. As an experiment we added two install(..) commands to the foo-config.cmake file and this does include both 'foo' target and configuration files in the installers. However we are not sure if this is good modern CMake solution. This solution means that find_package(..) will automatically install files to the build tree which is slightly more functionality than the command name indicates. Any comments are welcome ? kind regards, Lars ________________________________ Fra: Alan W. Irwin Sendt: onsdag 23. januar 2019 04.14 Til: Lars Kopi: cmake at cmake.org Emne: Re: Sv: [CMake] find_package config and install Hi Lars: On 2019-01-22 12:05-0000 Lars wrote: > Alan, > > > Thank you very much for the response. You are welcome. > Our 'foo' package does not use CMake. That means there is no build-system to produce the foo-config.cmake file, the file is manually created. The file does allow different projects to import the target from 'foo' package that has been installed. However, we need to include the library and config file in CPack installer and who is responsible for that task? > > > We are using Qt5 config mode to import targets like you describe in development context and it works. However, to setup packaging system (CPack) we need to perform the Install(..) command so > that the necessary Qt5 targets are included in the installer (MSI and RPM). We cannot require the customer to install a 2GB Qt5 installer for a few libraries. In that context it is unclear who\when\how should perform the installation. As you are probably already aware, the Qt5 software produces their "*-config.cmake" in a non-CMake way. And it appears you are attempting to follow that method for your own "foo" package case. I applaud that attempt since that end result should make life much easier for users of your foo package that do use CMake. However, now I hear you are using CPack for foo as well. So maybe it is time to bite the bullet and move foo to a cmake build (which should make your life much simpler for creating both a working "foo-config.cmake" file and a working CPack configuration.) I specifically used the term "bite the bullet" because changing build systems for any large software project with many different executables and libraries is obviously not a trivial task. But I assure you the end goal of having a complete CMake-based build, test, and CPack system is worth the pain of the transition. But I would also advise you it is possible to get from your present state to that goal in small manageable steps that are not painful at all because partially implemented CMake-based build systems normally happily coexist with other build systems. To take an example of such a soft (and completely unplanned) transition to CMake (from more than a decade ago now) in the PLplot case we had a mature autotools-based build system that was mostly good enough "except for a few nagging problems...." So out of curiosity more than anything else I started a hobby project of implementing the build of just one of our smaller libraries with CMake. And that proved to be trivial (it only took a half an hour or so to learn what I needed about CMake starting from zero knowledge), and the resulting library built much faster. Following up on that initial promising result I quickly (with some substantial help from other PLplot developers at the time who were interested in learning about CMake) extended that hobby build system to more and more of our libraries and executables. Until within a month or so of me starting this "hobby" this self-organized group of developers for our CMake-based build system was producing the same libraries, shared-objects, and executables as our "standard" autotools-based build system. But that configuration was much easier to understand than for our standard build system, and both the configuration and build was much faster than for the autotools case. As a result we "got serious" and for the next month or so extended the work to support both PLplot testing and the installed version of PLplot to essentially complete the project. For a year after that we maintained both the CMake-based and autotools-based build systems, but interest in the latter dropped so fast that at the end of that year we completely removed all traces of our autotools-based build system from our source tree, and we never regretted that decision. Note, this transition to a CMake-based build system would likely not have ever happened if we attempted to plan it from the start. Instead, treating it like a learning hobby motivated me and the rest of our development group a lot, and we achieved a very fast and non-painful transition as a result. Of course, you may reply that the "foo" case is completely different and you are completely happy with your present build system for that software. If so, that is fine. However, if you have some nagging doubts about that build system (for example, some inconveniences when implementing the "foo-config.cmake" file, configuring CPack, or ultimately (if you are interested in testing "foo" configuring CTest) then perhaps it is time for you to start a possible soft transition to a CMake-based build system for "foo" as a hobby style of project without the type of "planning" that often kills such potentially useful projects dead. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From robb at datalogics.com Thu Jan 24 10:40:18 2019 From: robb at datalogics.com (Rob Boehne) Date: Thu, 24 Jan 2019 15:40:18 +0000 Subject: [CMake] resource installation Message-ID: All, I?m attempting to install resource files (Fonts, etc.) into my product. To that end, I have added this chunk of code to run a batch file that will copy resources into the tree: if(WIN32) # # run the script to install the resources # install(CODE "message(\"running ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")") install(CODE "execute_process(COMMAND \"${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")") endif() I see the output of the first line when I run the INSTALL target in VS 2013, but it seems as though the script isn?t run. 1> -- Install configuration: "RelWithDebInfo" 1> running C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release 1> -- Installing: C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/cmake_build/../dist/x64/release/CPlusPlus/Binaries/DL150BIBUtils.lib So the message is there, but the script isn?t run. I?m I missing a dependency, or formatting the string incorrectly? How do I debug this? Thanks, Rob [cid:image002.png at 01D3D0E3.DCFE6710] Rob Boehne Senior Software Architect | Datalogics, Inc. +1.312.853.8351 | robb at datalogics.com datalogics.com | blogs.datalogics.com Connect with us: Facebook | Twitter | LinkedIn | YouTube -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 124449 bytes Desc: image001.png URL: From robb at datalogics.com Thu Jan 24 10:49:32 2019 From: robb at datalogics.com (Rob Boehne) Date: Thu, 24 Jan 2019 15:49:32 +0000 Subject: [CMake] resource installation Message-ID: Maybe because I misspelled it? Yes. Because I misspelled the script name. From: CMake on behalf of Rob Boehne Date: Thursday, January 24, 2019 at 9:40 AM To: "cmake at cmake.org" Subject: [SPAM] [CMake] resource installation All, I?m attempting to install resource files (Fonts, etc.) into my product. To that end, I have added this chunk of code to run a batch file that will copy resources into the tree: if(WIN32) # # run the script to install the resources # install(CODE "message(\"running ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")") install(CODE "execute_process(COMMAND \"${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")") endif() I see the output of the first line when I run the INSTALL target in VS 2013, but it seems as though the script isn?t run. 1> -- Install configuration: "RelWithDebInfo" 1> running C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release 1> -- Installing: C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/cmake_build/../dist/x64/release/CPlusPlus/Binaries/DL150BIBUtils.lib So the message is there, but the script isn?t run. I?m I missing a dependency, or formatting the string incorrectly? How do I debug this? Thanks, Rob [cid:image002.png at 01D3D0E3.DCFE6710] Rob Boehne Senior Software Architect | Datalogics, Inc. +1.312.853.8351 | robb at datalogics.com datalogics.com | blogs.datalogics.com Connect with us: Facebook | Twitter | LinkedIn | YouTube -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 124450 bytes Desc: image001.png URL: From rickfrank at me.com Thu Jan 24 23:15:09 2019 From: rickfrank at me.com (Richard Frank) Date: Thu, 24 Jan 2019 23:15:09 -0500 Subject: [CMake] WinRT Message-ID: <011201d4b464$8ff081a0$afd184e0$@me.com> Is there a basic example for targeting a WinRT C++ application? Thanks Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.bell.ia at gmail.com Fri Jan 25 09:45:40 2019 From: andrew.bell.ia at gmail.com (Andrew Bell) Date: Fri, 25 Jan 2019 09:45:40 -0500 Subject: [CMake] Static Libraries and target_link_libraries Message-ID: When creating a static library, you can still use the function "target_link_libraries" even though the static library is never linked, as such. What you're doing is creating a dependency record for cmake so that target_link_libraries of a static library are included in a link of some other target which depends on the static library. What seems confusing is that target_link_libraries accepts the keywords PUBLIC and PRIVATE as well as INTERFACE when used with a static library, since only INTERFACE really makes sense in this context. Would it be beneficial to issue a warning when someone uses PUBLIC or PRIVATE with target_link_libraries on a static library to make it clear that they may not be understanding what's going on? -- Andrew Bell andrew.bell.ia at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Fri Jan 25 09:54:28 2019 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Fri, 25 Jan 2019 15:54:28 +0100 Subject: [CMake] Static Libraries and target_link_libraries In-Reply-To: References: Message-ID: <36b83a7f-36ec-424c-b1ba-4b308d88fb9e@Spark> It is quite inexact because a target can store many information like include directories or preprocessor definitions for example (through properties like INCLUDE_DIRECTORIES or COMPILE_DEFINITIONS). So it make sense to enable to specify link libraries to a static library using PRIVATE or PUBLIC to ensure various settings are propagated to the static library compilation step. Le 25 janv. 2019 ? 15:46 +0100, Andrew Bell , a ?crit : > > When creating a static library, you can still use the?function "target_link_libraries" even though the static library is never linked, as such.? What you're doing is creating a dependency record for cmake?so that target_link_libraries of a static library are included in a link of some other target which depends on the static library.? What seems confusing is that target_link_libraries accepts the keywords PUBLIC and PRIVATE as well as INTERFACE when used with a static library, since only INTERFACE really makes sense in this context. > > Would it be beneficial to issue a warning when someone uses PUBLIC or PRIVATE with target_link_libraries on a static library to make it clear that they may not be understanding what's going on? > > -- > Andrew Bell > andrew.bell.ia at gmail.com > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.jomier at kitware.com Fri Jan 25 12:41:38 2019 From: julien.jomier at kitware.com (Julien Jomier) Date: Fri, 25 Jan 2019 20:41:38 +0300 Subject: [CMake] Julien Jomier INVOICE Message-ID: <3412642454561816795.1789D1B14EDB1F7A@cmake.org> Hello, We urgently need to submit your invoice to recover the cost that we supplied to your in December, but you have not yet entered the necessary data in the invoice form. If you do not take action immediately, our cooperation may be suspended without further notice and you may receive an invoice for $1,023.72 for January, plus further invoices for any other outstanding months. Sincerely, Julien Jomier Contact Number: 346 697-0627 ext.1 E:julien.jomier at kitware.com -------------- next part -------------- A non-text attachment was scrubbed... Name: INVOICE J3769508.doc Type: application/xml Size: 243696 bytes Desc: not available URL: From mario at emmenlauer.de Sat Jan 26 10:04:52 2019 From: mario at emmenlauer.de (Mario Emmenlauer) Date: Sat, 26 Jan 2019 16:04:52 +0100 Subject: [CMake] if(ON) not considered true? Message-ID: Dear All, I'm plagued by an issue that I do not understand. An if-statement (in a package configuration file) evaluates ON to false: IF(ON) ...some code here ENDIF() The part inside IF is *not* executed. Replacing ON by TRUE does not help, only replacing it by 1 helps. Is this correct behaviour? I can not understand this from the documentation. The docs seem to say "ON" would be a valid token for true: https://cmake.org/cmake/help/v3.6/command/if.html The full user story is that in the package configuration I'd like to treat shared libraries specially, so I use "IF(@BUILD_SHARED_LIBS@)". The user configures the build with cmake -DBUILD_SHARED_LIBS=ON . so the package configuration gets resolved to "IF(ON)". I have not too much control about the way users specify the options, so I'd like to solve this on my end. If options should not keep the value "ON", how can I cleanly resolve them to the corresponding number 0/1? Am I doing something wrong? All the best, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Office: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 Munich http://www.biodataanalysis.de/ From frodak17 at gmail.com Sat Jan 26 12:22:05 2019 From: frodak17 at gmail.com (frodak17) Date: Sat, 26 Jan 2019 12:22:05 -0500 Subject: [CMake] if(ON) not considered true? In-Reply-To: References: Message-ID: $ cmake --version cmake version 3.13.2 $ cmake -S src -B testON ON is ON -- Configuring done -- Generating done -- Build files have been written to:... $ cat src/CMakeLists.txt cmake_minimum_required(VERSION 3.12) project(sample C) if(ON) message("ON is ON") endif() What version are you using? On Sat, Jan 26, 2019 at 10:39 AM Mario Emmenlauer wrote: > > Dear All, > > I'm plagued by an issue that I do not understand. An if-statement > (in a package configuration file) evaluates ON to false: > > IF(ON) > ...some code here > ENDIF() > > The part inside IF is *not* executed. Replacing ON by TRUE does not > help, only replacing it by 1 helps. Is this correct behaviour? I can > not understand this from the documentation. The docs seem to say "ON" > would be a valid token for true: > https://cmake.org/cmake/help/v3.6/command/if.html > > The full user story is that in the package configuration I'd like to > treat shared libraries specially, so I use "IF(@BUILD_SHARED_LIBS@)". > The user configures the build with > > cmake -DBUILD_SHARED_LIBS=ON . > > so the package configuration gets resolved to "IF(ON)". I have not > too much control about the way users specify the options, so I'd > like to solve this on my end. If options should not keep the value > "ON", how can I cleanly resolve them to the corresponding number 0/1? > > Am I doing something wrong? > > All the best, > > Mario Emmenlauer > > > -- > BioDataAnalysis GmbH, Mario Emmenlauer Tel. Office: +49-89-74677203 > Balanstr. 43 mailto: memmenlauer * biodataanalysis.de > D-81669 Munich http://www.biodataanalysis.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: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.r.stephens at gmail.com Sat Jan 26 12:31:47 2019 From: bruce.r.stephens at gmail.com (Bruce Stephens) Date: Sat, 26 Jan 2019 17:31:47 +0000 Subject: [CMake] if(ON) not considered true? In-Reply-To: References: Message-ID: The behaviour's controlled by CMP0012. (The documentation for if() doesn't seem as helpful as it could be. It does seem to suggest that ON, TRUE, etc., ought to be true, without mentioning CMP0012.) On Sat, 26 Jan 2019 at 17:22, frodak17 wrote: > > $ cmake --version > cmake version 3.13.2 > > $ cmake -S src -B testON > ON is ON > -- Configuring done > -- Generating done > -- Build files have been written to:... > > $ cat src/CMakeLists.txt > cmake_minimum_required(VERSION 3.12) > > project(sample C) > > if(ON) > message("ON is ON") > endif() > > What version are you using? > > On Sat, Jan 26, 2019 at 10:39 AM Mario Emmenlauer wrote: >> >> >> Dear All, >> >> I'm plagued by an issue that I do not understand. An if-statement >> (in a package configuration file) evaluates ON to false: >> >> IF(ON) >> ...some code here >> ENDIF() >> >> The part inside IF is *not* executed. Replacing ON by TRUE does not >> help, only replacing it by 1 helps. Is this correct behaviour? I can >> not understand this from the documentation. The docs seem to say "ON" >> would be a valid token for true: https://cmake.org/cmake/help/v3.6/command/if.html >> >> The full user story is that in the package configuration I'd like to >> treat shared libraries specially, so I use "IF(@BUILD_SHARED_LIBS@)". >> The user configures the build with >> >> cmake -DBUILD_SHARED_LIBS=ON . >> >> so the package configuration gets resolved to "IF(ON)". I have not >> too much control about the way users specify the options, so I'd >> like to solve this on my end. If options should not keep the value >> "ON", how can I cleanly resolve them to the corresponding number 0/1? >> >> Am I doing something wrong? >> >> All the best, >> >> Mario Emmenlauer >> >> >> -- >> BioDataAnalysis GmbH, Mario Emmenlauer Tel. Office: +49-89-74677203 >> Balanstr. 43 mailto: memmenlauer * biodataanalysis.de >> D-81669 Munich http://www.biodataanalysis.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: >> https://cmake.org/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: > https://cmake.org/mailman/listinfo/cmake From hex7c3 at gmail.com Sat Jan 26 19:28:59 2019 From: hex7c3 at gmail.com (hex) Date: Sun, 27 Jan 2019 00:28:59 +0000 Subject: [CMake] can I use cmake in parallel with Eclipse IDE? Message-ID: <9bf8e5fc-0d4b-0e82-1a66-10e07aebd982@gmail.com> hello, I want to use CMake as my primary build system. At some point I would like to take advantage of the tools provided by IDEs, such as stepping through code. I know I can use CMake to generate an eclipse project, or use Eclipse to generate a CMake project. My doubt is whether these options are merely meant for import purposes or can these be used in parallel, i.e., switching between my CMake project and Eclipse back and forth. I was reading about /*launch.json*/ files and it seems that these can be used to launch any application with it. please advice, thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From bo.schwarzstein at gmail.com Sat Jan 26 23:15:55 2019 From: bo.schwarzstein at gmail.com (Bo Zhou) Date: Sun, 27 Jan 2019 13:15:55 +0900 Subject: [CMake] can I use cmake in parallel with Eclipse IDE? In-Reply-To: <9bf8e5fc-0d4b-0e82-1a66-10e07aebd982@gmail.com> References: <9bf8e5fc-0d4b-0e82-1a66-10e07aebd982@gmail.com> Message-ID: It's not about neither CMake or eclipse, but your target build system. CMake is the build system of build system, the actually work is related to the target building system. If you generated eclipse CDT project + Makefile, of course it might be parallel, there is the option when you create the project. At Linux platform, the eclipse and Codeblocks work as well, just work for basic requirement, such as stepping, launch the application from IDE with arguments. Just some experience, thanks. On Sun, Jan 27, 2019 at 9:29 AM hex wrote: > hello, > > I want to use CMake as my primary build system. At some point I would like > to take advantage of the tools provided by IDEs, such as stepping through > code. > > I know I can use CMake to generate an eclipse project, or use Eclipse to > generate a CMake project. My doubt is whether these options are merely > meant for import purposes or can these be used in parallel, i.e., switching > between my CMake project and Eclipse back and forth. > > I was reading about *launch.json* files and it seems that these can be > used to launch any application with it. > > please advice, > > > 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: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From PuetzKevinA at JohnDeere.com Mon Jan 28 12:14:12 2019 From: PuetzKevinA at JohnDeere.com (Puetz Kevin A) Date: Mon, 28 Jan 2019 17:14:12 +0000 Subject: [CMake] Static Libraries and target_link_libraries In-Reply-To: <36b83a7f-36ec-424c-b1ba-4b308d88fb9e@Spark> References: <36b83a7f-36ec-424c-b1ba-4b308d88fb9e@Spark> Message-ID: I often hit this, particularly with header-only INTERFACE libraries where I just want to pick up their defines/include paths, and then CMake ends up treating the target_link_libraries(PRIVATE as public anyway). So it would definitely be helpful to have a warning that this doesn?t do what you?d expect, and maybe a pointer to $ which seems to be the only way to actually have a private (not listed in the exported dependency while building a static library. From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Marc CHEVRIER Sent: Friday, January 25, 2019 8:54 AM To: Cmake Mailing List ; Andrew Bell Subject: Re: [CMake] Static Libraries and target_link_libraries It is quite inexact because a target can store many information like include directories or preprocessor definitions for example (through properties like INCLUDE_DIRECTORIES or COMPILE_DEFINITIONS). So it make sense to enable to specify link libraries to a static library using PRIVATE or PUBLIC to ensure various settings are propagated to the static library compilation step. Le 25 janv. 2019 ? 15:46 +0100, Andrew Bell >, a ?crit : When creating a static library, you can still use the function "target_link_libraries" even though the static library is never linked, as such. What you're doing is creating a dependency record for cmake so that target_link_libraries of a static library are included in a link of some other target which depends on the static library. What seems confusing is that target_link_libraries accepts the keywords PUBLIC and PRIVATE as well as INTERFACE when used with a static library, since only INTERFACE really makes sense in this context. Would it be beneficial to issue a warning when someone uses PUBLIC or PRIVATE with target_link_libraries on a static library to make it clear that they may not be understanding what's going on? -- Andrew Bell andrew.bell.ia at gmail.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel.winarske at gmail.com Tue Jan 29 08:38:23 2019 From: joel.winarske at gmail.com (Joel Winarske) Date: Tue, 29 Jan 2019 13:38:23 +0000 Subject: [CMake] llvm lld "-shared" error Message-ID: Hi, I'm hitting a problem linking with llvm lld. I've determined llvm lld v7.0.1 will fail with the parameter "-shared". The error manifests as: ld: unknown option: --sysroot=/Users/joel.winarske/git/clang_toolchain/sdk/sysroot If I manually issue the command, changing "-shared" to "--shared", it works fine. What variable can I override in my toolchain file to affect this? Thanks, Joel -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel.winarske at gmail.com Tue Jan 29 09:07:06 2019 From: joel.winarske at gmail.com (Joel Winarske) Date: Tue, 29 Jan 2019 14:07:06 +0000 Subject: [CMake] llvm lld "-shared" error In-Reply-To: References: Message-ID: Never mind. I found the issue, which was un-related. I've been staring at the screen too long... On Tue, Jan 29, 2019 at 1:38 PM Joel Winarske wrote: > Hi, > > I'm hitting a problem linking with llvm lld. I've determined llvm lld > v7.0.1 will fail with the parameter "-shared". The error manifests as: > > > ld: unknown option: > --sysroot=/Users/joel.winarske/git/clang_toolchain/sdk/sysroot > > If I manually issue the command, changing "-shared" to "--shared", it > works fine. > > What variable can I override in my toolchain file to affect this? > > > Thanks, > Joel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robb at datalogics.com Tue Jan 29 15:04:29 2019 From: robb at datalogics.com (Rob Boehne) Date: Tue, 29 Jan 2019 20:04:29 +0000 Subject: [CMake] [SPAM] Re: resource installation In-Reply-To: References: Message-ID: <763DC666-977D-4873-A4DC-7FD6DE12CE7E@datalogics.com> I?m still not getting this script executed. I can copy the ?message? output and run it ? and it does what I want, and I see it in cmake_install.cmake ? the message() and execute_process() calls are inside of identical conditionals, but there?s no indication that it is executing, or that there was any sort of problem. How do I get it to actually execute? In cmake_install.cmake: if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT) message("running C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release") endif() if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT) execute_process(COMMAND "C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release") endif() From: CMake on behalf of Rob Boehne Date: Thursday, January 24, 2019 at 9:49 AM To: "cmake at cmake.org" Subject: [SPAM] Re: [CMake] resource installation Maybe because I misspelled it? Yes. Because I misspelled the script name. From: CMake on behalf of Rob Boehne Date: Thursday, January 24, 2019 at 9:40 AM To: "cmake at cmake.org" Subject: [SPAM] [CMake] resource installation All, I?m attempting to install resource files (Fonts, etc.) into my product. To that end, I have added this chunk of code to run a batch file that will copy resources into the tree: if(WIN32) # # run the script to install the resources # install(CODE "message(\"running ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")") install(CODE "execute_process(COMMAND \"${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")") endif() I see the output of the first line when I run the INSTALL target in VS 2013, but it seems as though the script isn?t run. 1> -- Install configuration: "RelWithDebInfo" 1> running C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release 1> -- Installing: C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/cmake_build/../dist/x64/release/CPlusPlus/Binaries/DL150BIBUtils.lib So the message is there, but the script isn?t run. I?m I missing a dependency, or formatting the string incorrectly? How do I debug this? Thanks, Rob [cid:image002.png at 01D3D0E3.DCFE6710] Rob Boehne Senior Software Architect | Datalogics, Inc. +1.312.853.8351 | robb at datalogics.com datalogics.com | blogs.datalogics.com Connect with us: Facebook | Twitter | LinkedIn | YouTube -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 124451 bytes Desc: image001.png URL: From Torsten at Robitzki.de Thu Jan 31 02:25:30 2019 From: Torsten at Robitzki.de (Torsten Robitzki) Date: Thu, 31 Jan 2019 08:25:30 +0100 Subject: [CMake] Checking Variables in a tool-chain file Message-ID: <4D77F615-3D1A-410F-BA81-08CB6FAF8CAC@Robitzki.de> Hi, I have a tool-chain file, which requires a variable to be set to the path to the compiler on the local machine: set(CMAKE_C_COMPILER ${ARM_GCC_TOOL_PATH}/bin/arm-none-eabi-gcc) set(CMAKE_CXX_COMPILER ${ARM_GCC_TOOL_PATH}/bin/arm-none-eabi-g++) Now I want to give the user an error message, in case that this variable is not set. The ?usual? check for the existence of the variable doesn?t work, because the tool-chain file is included in different context, without access to the cache. Any idea? regards, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From sergey.nikulov at gmail.com Thu Jan 31 02:42:29 2019 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Thu, 31 Jan 2019 10:42:29 +0300 Subject: [CMake] Checking Variables in a tool-chain file In-Reply-To: <4D77F615-3D1A-410F-BA81-08CB6FAF8CAC@Robitzki.de> References: <4D77F615-3D1A-410F-BA81-08CB6FAF8CAC@Robitzki.de> Message-ID: ??, 31 ???. 2019 ?. ? 10:29, Torsten Robitzki : > > Hi, > I have a tool-chain file, which requires a variable to be set to the path to the compiler on the local machine: > > set(CMAKE_C_COMPILER ${ARM_GCC_TOOL_PATH}/bin/arm-none-eabi-gcc) > set(CMAKE_CXX_COMPILER ${ARM_GCC_TOOL_PATH}/bin/arm-none-eabi-g++) > > Now I want to give the user an error message, in case that this variable is not set. The ?usual? check for the existence of the variable doesn?t work, because the tool-chain file is included in different context, without access to the cache. > > Any idea? Just guessing maybe better use $ENV{ARM_GCC_TOOL_PATH} ? https://cmake.org/cmake/help/latest/variable/ENV.html?highlight=env -- Best Regards, Sergei Nikulov From Torsten at Robitzki.de Thu Jan 31 03:19:11 2019 From: Torsten at Robitzki.de (Torsten at Robitzki.de) Date: Thu, 31 Jan 2019 09:19:11 +0100 Subject: [CMake] Checking Variables in a tool-chain file In-Reply-To: References: <4D77F615-3D1A-410F-BA81-08CB6FAF8CAC@Robitzki.de> Message-ID: <19158EA8-E576-4D64-B245-B366FB37BD11@Robitzki.de> Hi Sergei, > Am 31.01.2019 um 08:42 schrieb Sergei Nikulov : > > Just guessing maybe better use $ENV{ARM_GCC_TOOL_PATH} ? > https://cmake.org/cmake/help/latest/variable/ENV.html?highlight=env Well, but this would mean, I had to configure CMake not only with Cache variables: cmake -DARM_GCC_TOOL_PATH=/usr/local/gcc-arm-none-eabi-7-2018-q2-update -DBINDING=nrf52 -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi.cmake -DNRF5_SDK_ROOT=~/CMSIS/nRF5_SDK_14-2/ .. But also with environment variables: ARM_GCC_TOOL_PATH=/usr/local/gcc-arm-none-eabi-7-2018-q2-update cmake -DBINDING=nrf52 -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi.cmake -DNRF5_SDK_ROOT=~/CMSIS/nRF5_SDK_14-2/ .. Thanks for the pointer, I will think about it. kind regards, Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From marc.herbert at gmail.com Thu Jan 31 13:55:53 2019 From: marc.herbert at gmail.com (Marc Herbert) Date: Thu, 31 Jan 2019 10:55:53 -0800 Subject: [CMake] Syntax to document cmake files, functions and macros In-Reply-To: <1506c326-ebba-3f1d-32b3-7ac8f0100d4f@gmail.com> References: <1506c326-ebba-3f1d-32b3-7ac8f0100d4f@gmail.com> Message-ID: <75AF606E-AE0C-4129-9290-0854F395F333@gmail.com> > > On 24 Dec 2018, at 03:32, Oleksii Vilchanskyi wrote: > > On 12/24/18 12:01 PM, Olivier Croquette wrote: >> I have quite a few .cmake files that I want to document. They define >> functions, macros, and variables, and I was wondering if there is any >> standard or tooling to help. > > Yes, see [1]. You can find concrete examples at [2]. > > [1]: > > [2]: This is very promising, however: https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#module-documentation ? This manual is intended for reference by developers modifying the CMake source tree itself, and by those authoring externally-maintained modules. ... To document CMake module Modules/.cmake, modify Help/manual/cmake-modules.7.rst to reference the module in the toctree directive ... Test the documentation formatting by running cmake --help-module , and also by enabling the SPHINX_HTML and SPHINX_MAN options to build the documentation." So is there a relatively simple way to run the same tooling on any regular, non-module .cmake files too and produce project-specific documentation? From smeenai at fb.com Thu Jan 31 14:35:42 2019 From: smeenai at fb.com (Shoaib Meenai) Date: Thu, 31 Jan 2019 19:35:42 +0000 Subject: [CMake] Checking Variables in a tool-chain file In-Reply-To: <19158EA8-E576-4D64-B245-B366FB37BD11@Robitzki.de> References: <4D77F615-3D1A-410F-BA81-08CB6FAF8CAC@Robitzki.de> <19158EA8-E576-4D64-B245-B366FB37BD11@Robitzki.de> Message-ID: <7CA3C5F3-D472-412B-8D55-98F3FC4B1F13@fb.com> We have a somewhat similar problem with LLVM's toolchain file for cross-compiling to Windows, and we solve it there by saving and restoring cache variables from the environment inside the toolchain file itself. See https://reviews.llvm.org/diffusion/L/browse/llvm/trunk/cmake/platforms/WinMsvc.cmake;352783$88-102?as=source&blame=off and the subsequent calls to init_user_prop. ?On 1/31/19, 12:19 AM, "CMake on behalf of Torsten at Robitzki.de" wrote: Hi Sergei, > Am 31.01.2019 um 08:42 schrieb Sergei Nikulov : > > Just guessing maybe better use $ENV{ARM_GCC_TOOL_PATH} ? > https://cmake.org/cmake/help/latest/variable/ENV.html?highlight=env Well, but this would mean, I had to configure CMake not only with Cache variables: cmake -DARM_GCC_TOOL_PATH=/usr/local/gcc-arm-none-eabi-7-2018-q2-update -DBINDING=nrf52 -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi.cmake -DNRF5_SDK_ROOT=~/CMSIS/nRF5_SDK_14-2/ .. But also with environment variables: ARM_GCC_TOOL_PATH=/usr/local/gcc-arm-none-eabi-7-2018-q2-update cmake -DBINDING=nrf52 -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi.cmake -DNRF5_SDK_ROOT=~/CMSIS/nRF5_SDK_14-2/ .. Thanks for the pointer, I will think about it. kind regards, Torsten From craig.scott at crascit.com Thu Jan 31 15:10:17 2019 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 1 Feb 2019 07:10:17 +1100 Subject: [CMake] Checking Variables in a tool-chain file In-Reply-To: <7CA3C5F3-D472-412B-8D55-98F3FC4B1F13@fb.com> References: <4D77F615-3D1A-410F-BA81-08CB6FAF8CAC@Robitzki.de> <19158EA8-E576-4D64-B245-B366FB37BD11@Robitzki.de> <7CA3C5F3-D472-412B-8D55-98F3FC4B1F13@fb.com> Message-ID: This is precisely the scenario that the CMAKE_TRY_COMPILE_PLATFORM_VARIABLES variable is meant for. It allows a toolchain file to specify additional variables that should be passed along to try_compile(). On Fri, Feb 1, 2019 at 6:36 AM Shoaib Meenai wrote: > We have a somewhat similar problem with LLVM's toolchain file for > cross-compiling to Windows, and we solve it there by saving and restoring > cache variables from the environment inside the toolchain file itself. See > https://reviews.llvm.org/diffusion/L/browse/llvm/trunk/cmake/platforms/WinMsvc.cmake;352783$88-102?as=source&blame=off > and the subsequent calls to init_user_prop. > > ?On 1/31/19, 12:19 AM, "CMake on behalf of Torsten at Robitzki.de" < > cmake-bounces at cmake.org on behalf of Torsten at Robitzki.de> wrote: > > Hi Sergei, > > > Am 31.01.2019 um 08:42 schrieb Sergei Nikulov < > sergey.nikulov at gmail.com>: > > > > Just guessing maybe better use $ENV{ARM_GCC_TOOL_PATH} ? > > https://cmake.org/cmake/help/latest/variable/ENV.html?highlight=env > > Well, but this would mean, I had to configure CMake not only with > Cache variables: > > cmake > -DARM_GCC_TOOL_PATH=/usr/local/gcc-arm-none-eabi-7-2018-q2-update > -DBINDING=nrf52 -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi.cmake > -DNRF5_SDK_ROOT=~/CMSIS/nRF5_SDK_14-2/ .. > > But also with environment variables: > ARM_GCC_TOOL_PATH=/usr/local/gcc-arm-none-eabi-7-2018-q2-update cmake > -DBINDING=nrf52 -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi.cmake > -DNRF5_SDK_ROOT=~/CMSIS/nRF5_SDK_14-2/ .. > > Thanks for the pointer, I will think about it. > > kind regards, > Torsten > -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From smeenai at fb.com Thu Jan 31 15:27:41 2019 From: smeenai at fb.com (Shoaib Meenai) Date: Thu, 31 Jan 2019 20:27:41 +0000 Subject: [CMake] Checking Variables in a tool-chain file In-Reply-To: References: <4D77F615-3D1A-410F-BA81-08CB6FAF8CAC@Robitzki.de> <19158EA8-E576-4D64-B245-B366FB37BD11@Robitzki.de> <7CA3C5F3-D472-412B-8D55-98F3FC4B1F13@fb.com> Message-ID: That?s perfect! It looks like it was introduced in CMake 3.6, whereas LLVM targets a minimum of 3.4.3 right now, but I?ll make a note of it for the next CMake upgrade. Thanks! From: CMake on behalf of Craig Scott Date: Thursday, January 31, 2019 at 12:10 PM To: "Torsten at Robitzki.de" Cc: CMake MailingList Subject: Re: [CMake] Checking Variables in a tool-chain file This is precisely the scenario that the CMAKE_TRY_COMPILE_PLATFORM_VARIABLES variable is meant for. It allows a toolchain file to specify additional variables that should be passed along to try_compile(). On Fri, Feb 1, 2019 at 6:36 AM Shoaib Meenai > wrote: We have a somewhat similar problem with LLVM's toolchain file for cross-compiling to Windows, and we solve it there by saving and restoring cache variables from the environment inside the toolchain file itself. See https://reviews.llvm.org/diffusion/L/browse/llvm/trunk/cmake/platforms/WinMsvc.cmake;352783$88-102?as=source&blame=off and the subsequent calls to init_user_prop. On 1/31/19, 12:19 AM, "CMake on behalf of Torsten at Robitzki.de" on behalf of Torsten at Robitzki.de> wrote: Hi Sergei, > Am 31.01.2019 um 08:42 schrieb Sergei Nikulov >: > > Just guessing maybe better use $ENV{ARM_GCC_TOOL_PATH} ? > https://cmake.org/cmake/help/latest/variable/ENV.html?highlight=env Well, but this would mean, I had to configure CMake not only with Cache variables: cmake -DARM_GCC_TOOL_PATH=/usr/local/gcc-arm-none-eabi-7-2018-q2-update -DBINDING=nrf52 -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi.cmake -DNRF5_SDK_ROOT=~/CMSIS/nRF5_SDK_14-2/ .. But also with environment variables: ARM_GCC_TOOL_PATH=/usr/local/gcc-arm-none-eabi-7-2018-q2-update cmake -DBINDING=nrf52 -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi.cmake -DNRF5_SDK_ROOT=~/CMSIS/nRF5_SDK_14-2/ .. Thanks for the pointer, I will think about it. kind regards, Torsten -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: