From bill.hoffman at kitware.com Mon Jul 1 12:15:04 2019 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon, 1 Jul 2019 12:15:04 -0400 Subject: [CMake] HP-UX ia64 (32bit) port In-Reply-To: References: Message-ID: Can you run a nightly dashboard for CMake on this HW?? It would be the only way these changes would continue to work into the future. On 6/28/2019 6:24 PM, Earle Lowe wrote: > I have made an HP-UX port for CMAKE 3.15 > > It's not entirely optimal, because I took a small shortcut on fsevents > in libuv by using the "no events" source also used by cygwin. HP-UX > does have /dev/poll, so I think the AIX code could be used as a > template for a proper implementation. > > It runs --version, but I haven't tried to use it to make itself again, > or any other tests. > > HP-UX B.11.31 ia64 using GCC 9.4.3 > > The binaries are 32-bit > > I didn't do this quite correctly because I didn't fork master and I > don't have a PR prepared. > > If the community wants though, I can make a proper merge request > > I'll note, getting GCC 9.4.3 working on HP-UX is actually harder than > porting cmake. This version of GCC has a fairly robust implementation > of C++11 > > -Earle From abhiugeshreddy at gmail.com Tue Jul 2 08:18:07 2019 From: abhiugeshreddy at gmail.com (ugesh reddy) Date: Tue, 2 Jul 2019 14:18:07 +0200 Subject: [CMake] cmake - two targets that depends on single static library that should be compiled based on the target that is being built Message-ID: Hello, I couldn't find any solution's for this problem even after posting the question on Reddit/stack overflow, so I am posting it here. My question is as follows: I have a static library and two target executables, let's call them **libA**, **EXE1**, **EXE2**. **libA** has pre-processor macros which needs to be enabled or disabled and another static library which needs to be linked or ignored based on the target executable that I am building. Let's say, if I am building EXE1. Then I need to enable the macros in libA and link another static library to it. If I am building EXE2, I need to disabled the macros in libA and don't link to another library. I don't want to create two targets with same source files. I am confused on how to solve this issue. Please kindly help in solving this issue. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Tue Jul 2 09:44:32 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Tue, 02 Jul 2019 09:44:32 -0400 Subject: [CMake] cmake - two targets that depends on single static library that should be compiled based on the target that is being built In-Reply-To: References: Message-ID: <1562075072.3852.2.camel@kitware.com> On Tue, 2019-07-02 at 14:18 +0200, ugesh reddy wrote: > Hello, > > I couldn't find any solution's for this problem even after posting > the question on Reddit/stack overflow, so I am posting it here. > > My question is as follows: > > I have a static library and two target executables, let's call them > **libA**, **EXE1**, **EXE2**. > > **libA** has pre-processor macros which needs to be enabled or > disabled and another static library which needs to be linked or > ignored based on the target executable that I am building. > > Let's say, if I am building EXE1. Then I need to enable the macros in > libA and link another static library to it. > > If I am building EXE2, I need to disabled the macros in libA and > don't link to another library. > > I don't want to create two targets with same source files. I'm sorry to say it, but creating two targets is actually exactly what you want to do here. If your concern is code duplication, you can make the code much shorter by using variables. Example: set(libA_SRCS ? src1.c ? src2.c ? src3.c ? # lots of other sources... ? ) add_library(libA1 STATIC ${libA_SRCS}) target_link_libraries(libA1 otherlib) add_library(libA2 STATIC ${libA_SRCS}) Kyle From abhiugeshreddy at gmail.com Tue Jul 2 10:09:07 2019 From: abhiugeshreddy at gmail.com (ugesh reddy) Date: Tue, 2 Jul 2019 16:09:07 +0200 Subject: [CMake] cmake - two targets that depends on single static library that should be compiled based on the target that is being built In-Reply-To: <1562075072.3852.2.camel@kitware.com> References: <1562075072.3852.2.camel@kitware.com> Message-ID: Ok, seems there is no other way then. Thank you for the clarification. On Tue, Jul 2, 2019 at 3:44 PM Kyle Edwards wrote: > On Tue, 2019-07-02 at 14:18 +0200, ugesh reddy wrote: > > Hello, > > > > I couldn't find any solution's for this problem even after posting > > the question on Reddit/stack overflow, so I am posting it here. > > > > My question is as follows: > > > > I have a static library and two target executables, let's call them > > **libA**, **EXE1**, **EXE2**. > > > > **libA** has pre-processor macros which needs to be enabled or > > disabled and another static library which needs to be linked or > > ignored based on the target executable that I am building. > > > > Let's say, if I am building EXE1. Then I need to enable the macros in > > libA and link another static library to it. > > > > If I am building EXE2, I need to disabled the macros in libA and > > don't link to another library. > > > > I don't want to create two targets with same source files. > > I'm sorry to say it, but creating two targets is actually exactly what > you want to do here. If your concern is code duplication, you can make > the code much shorter by using variables. Example: > > set(libA_SRCS > src1.c > src2.c > src3.c > # lots of other sources... > ) > add_library(libA1 STATIC ${libA_SRCS}) > target_link_libraries(libA1 otherlib) > add_library(libA2 STATIC ${libA_SRCS}) > > Kyle > -- Ugesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinay.kotegowder at gmail.com Tue Jul 2 11:14:18 2019 From: vinay.kotegowder at gmail.com (vinay kumar Kotegowder) Date: Tue, 2 Jul 2019 20:44:18 +0530 Subject: [CMake] Combining two static libraries into one Message-ID: Hi Everyone, I have a requirement on combining two static library into one. Can anyone tell me how can I achieve this? Regards, Vinay From kyle.edwards at kitware.com Tue Jul 2 11:18:51 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Tue, 02 Jul 2019 11:18:51 -0400 Subject: [CMake] Combining two static libraries into one In-Reply-To: References: Message-ID: <1562080731.3852.6.camel@kitware.com> On Tue, 2019-07-02 at 20:44 +0530, vinay kumar Kotegowder wrote: > Hi Everyone, > > I have a requirement on combining two static library into one. > Can anyone tell me how can I achieve this? > > Regards, > Vinay If you just want to make a library such that linking against that library links against your two static libraries, you could use an interface library. Example: add_library(lib1 STATIC lib1.c) add_library(lib2 STATIC lib2.c) add_library(lib1_2 INTERFACE) target_link_libraries(lib1_2 INTERFACE lib1 lib2) Note that with this strategy, lib1 and lib2 will still exist as separate files, but linking against lib1_2 will link against both of these libraries. Kyle From cristian.adam at gmail.com Tue Jul 2 11:29:54 2019 From: cristian.adam at gmail.com (Cristian Adam) Date: Tue, 2 Jul 2019 17:29:54 +0200 Subject: [CMake] Combining two static libraries into one In-Reply-To: References: Message-ID: On Tue, Jul 2, 2019 at 5:14 PM vinay kumar Kotegowder < vinay.kotegowder at gmail.com> wrote: > Hi Everyone, > > I have a requirement on combining two static library into one. > Can anyone tell me how can I achieve this? > > Regards, > Vinay > > If your compiler is GCC or Visual C++, you can use this as a base: https://cristianadam.eu/20190501/bundling-together-static-libraries-with-cmake/ Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kai.germaschewski at gmail.com Tue Jul 2 14:19:20 2019 From: kai.germaschewski at gmail.com (Kai Germaschewski) Date: Tue, 2 Jul 2019 14:19:20 -0400 Subject: [CMake] compiling .cpp/.cxx with CUDA compiler Message-ID: For background, a bunch of projects help writing portable C++ code that can be compiled into CUDA device code as one option, e.g. hemi, kokkos, RAJA ( https://devblogs.nvidia.com/simple-portable-parallel-c-hemi-2/). As a consequence, if available those source files need to be compiled with the CUDA compiler, but with the regular C++ compiler otherwise. I'm wondering whether there is a clean way to support this in a cmake build. Renaming my source files to `.cu` is bad if I'm on the system without CUDA. I figured out that I can set the LANGUAGE property on a given .cpp/.cxx source file to CUDA to have it compiled with CMAKE_CUDA_COMPILER, but that's quite a hassle to do for every source file. Kokkos instead creates a `nvcc_wrapper` script which one is supposed to use as CMAKE_CXX_COMPILER, but that definitely seems like a kludge to me (and giving me troubles). Things would probably be much better for me if there was a way to change the default language for .cxx / .cpp extensions. Is there a way to do this? --Kai -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Jul 2 14:47:57 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 2 Jul 2019 14:47:57 -0400 Subject: [CMake] compiling .cpp/.cxx with CUDA compiler In-Reply-To: References: Message-ID: In general I go with the source property approach, since you can pass it a collection of files to be marked as CUDA. If you are aware of when all sources have been added to a target you can easily mark them all as cuda with: get_target_property(source_files SOURCES) set_source_files_properties(${source_files} PROPERTIES LANGUAGE CUDA) As far as changing the mapping of file extensions to languages, as far as I am aware that is currently unsupported. On Tue, Jul 2, 2019 at 2:19 PM Kai Germaschewski wrote: > > For background, a bunch of projects help writing portable C++ code that can be compiled into CUDA device code as one option, e.g. hemi, kokkos, RAJA (https://devblogs.nvidia.com/simple-portable-parallel-c-hemi-2/). As a consequence, if available those source files need to be compiled with the CUDA compiler, but with the regular C++ compiler otherwise. > > I'm wondering whether there is a clean way to support this in a cmake build. Renaming my source files to `.cu` is bad if I'm on the system without CUDA. I figured out that I can set the LANGUAGE property on a given .cpp/.cxx source file to CUDA to have it compiled with CMAKE_CUDA_COMPILER, but that's quite a hassle to do for every source file. Kokkos instead creates a `nvcc_wrapper` script which one is supposed to use as CMAKE_CXX_COMPILER, but that definitely seems like a kludge to me (and giving me troubles). > > Things would probably be much better for me if there was a way to change the default language for .cxx / .cpp extensions. Is there a way to do this? > > --Kai > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 dmitry at parallel-computing.pro Tue Jul 2 14:52:19 2019 From: dmitry at parallel-computing.pro (Dmitry Mikushin) Date: Tue, 2 Jul 2019 20:52:19 +0200 Subject: [CMake] compiling .cpp/.cxx with CUDA compiler In-Reply-To: References: Message-ID: Compiling C++ code with CUDA compiler practically means only to implicitly include a bunch of CUDA-specific headers like cuda_runtime_api.h. Other than that, it's the same as compiling with the host C++ compiler. Thus, you can get the desired behavior by explicitly including those headers in case of C++-compilation and letting CMake include_directories to know where to search for them. Kind regards, - Dmitry. ??, 2 ???. 2019 ?. ? 20:19, Kai Germaschewski : > For background, a bunch of projects help writing portable C++ code that > can be compiled into CUDA device code as one option, e.g. hemi, kokkos, > RAJA (https://devblogs.nvidia.com/simple-portable-parallel-c-hemi-2/). As > a consequence, if available those source files need to be compiled with the > CUDA compiler, but with the regular C++ compiler otherwise. > > I'm wondering whether there is a clean way to support this in a cmake > build. Renaming my source files to `.cu` is bad if I'm on the system > without CUDA. I figured out that I can set the LANGUAGE property on a given > .cpp/.cxx source file to CUDA to have it compiled with CMAKE_CUDA_COMPILER, > but that's quite a hassle to do for every source file. Kokkos instead > creates a `nvcc_wrapper` script which one is supposed to use as > CMAKE_CXX_COMPILER, but that definitely seems like a kludge to me (and > giving me troubles). > > Things would probably be much better for me if there was a way to change > the default language for .cxx / .cpp extensions. Is there a way to do this? > > --Kai > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 kai.germaschewski at gmail.com Tue Jul 2 15:43:59 2019 From: kai.germaschewski at gmail.com (Kai Germaschewski) Date: Tue, 2 Jul 2019 15:43:59 -0400 Subject: [CMake] compiling .cpp/.cxx with CUDA compiler In-Reply-To: References: Message-ID: On Tue, Jul 2, 2019 at 2:48 PM Robert Maynard wrote: > get_target_property(source_files SOURCES) > set_source_files_properties(${source_files} PROPERTIES LANGUAGE CUDA) > Thanks, that'll work for the time being, I can put this into a function/macro and it'll look alright. --Kai -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinay.kotegowder at gmail.com Wed Jul 3 02:19:14 2019 From: vinay.kotegowder at gmail.com (vinay kumar Kotegowder) Date: Wed, 3 Jul 2019 11:49:14 +0530 Subject: [CMake] Moving build artifacts to custom directory Message-ID: Hi Everyone, How do I move the build artifacts(ELFs, Static libraries, custom intermediate files) to custom folder at the build of "cmake --build ." ? Also does "cmake --build . -- clean" takes care of cleaning these build artifacts from the directory to which they previously moved? Regards, Vinay From marc.chevrier at gmail.com Wed Jul 3 03:22:26 2019 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Wed, 3 Jul 2019 09:22:26 +0200 Subject: [CMake] Moving build artifacts to custom directory In-Reply-To: References: Message-ID: <9242511e-ef4c-4226-a00f-f8e25f8e04a7@Spark> Have a look at variables ?CMAKE_*_OUTPUT_DIRECTORY? (Like CMAKE_ARCHIVE_OUTPUT_DIRECTORY. See?https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html)?and target properties ?*_OUTPUT_DIRECTORY? (Like ARCHIVE_OUTPUT_DIRECTORY. See?https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html). Le 3 juil. 2019 ? 08:19 +0200, vinay kumar Kotegowder , a ?crit : > Hi Everyone, > > How do I move the build artifacts(ELFs, Static libraries, custom > intermediate files) to custom folder at the build of "cmake --build ." > ? > > Also does "cmake --build . -- clean" takes care of cleaning these > build artifacts from the directory to which they previously moved? > > Regards, > Vinay > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 rainer.poisel at gmail.com Wed Jul 3 08:47:45 2019 From: rainer.poisel at gmail.com (Rainer Poisel) Date: Wed, 3 Jul 2019 14:47:45 +0200 Subject: [CMake] Combining two static libraries into one In-Reply-To: References: Message-ID: I think there is no platform-independent way to solve this. Maybe you could create two OBJECT libraries that are "linked" together into one static lib. Best regards, Rainer On Tue, Jul 2, 2019 at 5:30 PM Cristian Adam wrote: > > > On Tue, Jul 2, 2019 at 5:14 PM vinay kumar Kotegowder wrote: >> >> Hi Everyone, >> >> I have a requirement on combining two static library into one. >> Can anyone tell me how can I achieve this? >> >> Regards, >> Vinay >> > > If your compiler is GCC or Visual C++, you can use this as a base: > https://cristianadam.eu/20190501/bundling-together-static-libraries-with-cmake/ > > Cheers, > Cristian. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 vinay.kotegowder at gmail.com Wed Jul 3 09:23:33 2019 From: vinay.kotegowder at gmail.com (vinay kumar Kotegowder) Date: Wed, 3 Jul 2019 18:53:33 +0530 Subject: [CMake] Combining two static libraries into one In-Reply-To: <1562080731.3852.6.camel@kitware.com> References: <1562080731.3852.6.camel@kitware.com> Message-ID: I want to build lib2 static array with pre-built lib1 static array. Does this work? add_library(lib1 STATIC lib1.c) add_library(lib2 STATIC lib2.c) target_link_libraries(lib2 INTERFACE lib1) Also, Kyle said linking against lib2 will link against both lib1 and lib2. Is there a static way of checking the relation between lib1 and lib2 ? Separately and after using INTERFACE option with lib1 and lib2 Regards, Vinay On Tue, Jul 2, 2019 at 8:48 PM Kyle Edwards wrote: > > On Tue, 2019-07-02 at 20:44 +0530, vinay kumar Kotegowder wrote: > > Hi Everyone, > > > > I have a requirement on combining two static library into one. > > Can anyone tell me how can I achieve this? > > > > Regards, > > Vinay > > If you just want to make a library such that linking against that > library links against your two static libraries, you could use an > interface library. Example: > > add_library(lib1 STATIC lib1.c) > add_library(lib2 STATIC lib2.c) > add_library(lib1_2 INTERFACE) > target_link_libraries(lib1_2 INTERFACE lib1 lib2) > > Note that with this strategy, lib1 and lib2 will still exist as > separate files, but linking against lib1_2 will link against both of > these libraries. > > Kyle From vinay.kotegowder at gmail.com Wed Jul 3 09:25:52 2019 From: vinay.kotegowder at gmail.com (vinay kumar Kotegowder) Date: Wed, 3 Jul 2019 18:55:52 +0530 Subject: [CMake] Combining two static libraries into one In-Reply-To: <1562080731.3852.6.camel@kitware.com> References: <1562080731.3852.6.camel@kitware.com> Message-ID: I want to build lib2 static library with pre-built lib1 static library. Does this work? add_library(lib1 STATIC lib1.c) add_library(lib2 STATIC lib2.c) target_link_libraries(lib2 INTERFACE lib1) Also, Kyle said linking against lib2 will link against both lib1 and lib2. Is there a static way of checking the relation between lib1 and lib2 ? Separately and after using INTERFACE option with lib1 and lib2. - Vinay On Tue, Jul 2, 2019 at 8:48 PM Kyle Edwards wrote: > > On Tue, 2019-07-02 at 20:44 +0530, vinay kumar Kotegowder wrote: > > Hi Everyone, > > > > I have a requirement on combining two static library into one. > > Can anyone tell me how can I achieve this? > > > > Regards, > > Vinay > > If you just want to make a library such that linking against that > library links against your two static libraries, you could use an > interface library. Example: > > add_library(lib1 STATIC lib1.c) > add_library(lib2 STATIC lib2.c) > add_library(lib1_2 INTERFACE) > target_link_libraries(lib1_2 INTERFACE lib1 lib2) > > Note that with this strategy, lib1 and lib2 will still exist as > separate files, but linking against lib1_2 will link against both of > these libraries. > > Kyle From kyle.edwards at kitware.com Wed Jul 3 09:29:39 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Wed, 03 Jul 2019 09:29:39 -0400 Subject: [CMake] Combining two static libraries into one In-Reply-To: References: <1562080731.3852.6.camel@kitware.com> Message-ID: <1562160579.3713.3.camel@kitware.com> On Wed, 2019-07-03 at 18:55 +0530, vinay kumar Kotegowder wrote: > ?I want to build lib2 static library with pre-built lib1 static > library. > ?Does this work? > > ?add_library(lib1 STATIC lib1.c) > ?add_library(lib2 STATIC lib2.c) > ?target_link_libraries(lib2 INTERFACE lib1) Yes, this will work. > ?Also, Kyle said linking against lib2 will link against both lib1 and > lib2. Is there a static way of checking the relation between lib1 and > ?lib2 ? Separately and after using INTERFACE option with lib1 and > lib2. Asking "does lib1 link against lib2" has long been a requested feature of CMake, but unfortunately, the existence of generator expressions precludes this hypothetical feature. Because target_link_libraries() supports generator expressions, which means the linking could change based on the configuration (Debug, Release, etc.), we don't actually know if lib1 links against lib2 until generate time, at which point it's too late to do anything in configure time. Kyle From kai.germaschewski at gmail.com Wed Jul 3 09:29:37 2019 From: kai.germaschewski at gmail.com (Kai Germaschewski) Date: Wed, 3 Jul 2019 09:29:37 -0400 Subject: [CMake] compiling .cpp/.cxx with CUDA compiler In-Reply-To: References: Message-ID: Thank. Yeah, I've seen BLT through it's use in RAJA. You're right, it'd work, but I'm reluctant to stray away from "vanilla" cmake too much, since other people will have to deal with this code, and cmake itself is already quite a step up from the regular Makefiles that they're used to. --Kai On Tue, Jul 2, 2019 at 4:14 PM David Poliakoff wrote: > Kai, > > If you're game to use a framework, back at LLNL I used a CMake system > called BLT a lot (https://github.com/LLNL/blt ). I believe it uses > something similar to what you've been recommended (get_target_property, > set_source_files_properties), but it has a mechanism where you say targets > "depend on" things, and if a target "depends_on" CUDA it uses the CUDA > compiler (and behaves similarly for MPI). > > I know frameworks are a big shift, but it always saved me more effort than > it cost me in similar problems, and if you're looking at things like RAJA > and Kokkos it's probably going to be up your alley. > > Best, > > David P > > Opinions in this email are my own, not those of my employer > > On Tue, Jul 2, 2019 at 12:44 PM Kai Germaschewski < > kai.germaschewski at gmail.com> wrote: > >> >> On Tue, Jul 2, 2019 at 2:48 PM Robert Maynard >> wrote: >> >>> get_target_property(source_files SOURCES) >>> set_source_files_properties(${source_files} PROPERTIES LANGUAGE CUDA) >>> >> >> Thanks, that'll work for the time being, I can put this into a >> function/macro and it'll look alright. >> >> --Kai >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/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 >> > > > -- > Thanks, > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Jul 3 10:51:45 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 3 Jul 2019 10:51:45 -0400 Subject: [CMake] getting compiler's include paths In-Reply-To: References: Message-ID: I completely forgot that the Makefiles based generators in CMake have a separate heuristic for determining system headers. If you use the Ninja generator I see the expected behavior: ~/W/t/nbuild $ sudo touch /usr/include/c++/7/array ~/W/t/nbuild $ ninja -d explain -v ninja explain: output test/CMakeFiles/ProjTest.dir/test.cpp.o older than most recent input /usr/include/c++/7/array (1562165327 vs 1562165329) ninja explain: test/CMakeFiles/ProjTest.dir/test.cpp.o is dirty ninja explain: test/ProjTest is dirty [1/2] /usr/bin/c++ -I../my_lib/include -std=gnu++1z -MD -MT test/CMakeFiles/ProjTest.dir/test.cpp.o -MF test/CMakeFiles/ProjTest.dir/test.cpp.o.d -o test/CMakeFiles/ProjTest.dir/test.cpp.o -c ../test/test.cpp [2/2] : && /usr/bin/c++ test/CMakeFiles/ProjTest.dir/test.cpp.o -o test/ProjTest && : I will need to spend some more time figuring out the extra include caching logic for the Makefile based generators, and will report back. On Thu, Jun 27, 2019 at 8:59 AM jl forums wrote: > > thanks for the anwer.... > quite not... I'm using cmake 3.14.2 (so, far away from 3.6....) and have a look, in main.cpp, there is #include : > > $ find /usr/include/ -name filesystem > /usr/include/c++/5/experimental/filesystem > /usr/include/c++/7/experimental/filesystem > /usr/include/c++/8/filesystem > /usr/include/c++/8/experimental/filesystem > $ sudo touch /usr/include/c++/5/experimental/filesystem /usr/include/c++/7/experimental/filesystem /usr/include/c++/8/filesystem /usr/include/c++/8/experimental/filesystem > $ make > [100%] Built target FileSync > $ touch ../main.cxx > $ make > Scanning dependencies of target FileSync > [ 50%] Building CXX object CMakeFiles/FileSync.dir/main.cxx.o > [100%] Linking CXX executable FileSync > [100%] Built target FileSync > > > => cmake don't create "full include dependency" which IS a mistake.... updating system g++ can just assume the target is uptodate and in fact just create a broken build... > > in cmake cxx.includecache > > #IncludeRegexLine: ^[ ]*[#%][ ]*(include|import)[ ]*[<"]([^">]+)([">]) > #IncludeRegexScan: ^.*$ > #IncludeRegexComplain: ^$ > #IncludeRegexTransform: > /home/orange/crypt/Devel/projets/FileSync/main.cxx > cstdio > - > io.h > - > fcntl.h > - > locale > - > clocale > - > fstream > - > iostream > - > filesystem > - > > $ /usr/bin/gcc-8 -M ../main.cxx > main.o: ../main.cxx /usr/x86_64-linux-gnu/include/stdc-predef.h \ > /usr/include/c++/8/cstdio \ > /usr/include/x86_64-linux-gnu/c++/8/bits/c++config.h \ > /usr/include/x86_64-linux-gnu/c++/8/bits/os_defines.h \ > /usr/x86_64-linux-gnu/include/features.h \ > /usr/x86_64-linux-gnu/include/sys/cdefs.h \ > /usr/x86_64-linux-gnu/include/bits/wordsize.h \ > /usr/x86_64-linux-gnu/include/bits/long-double.h \ > /usr/x86_64-linux-gnu/include/gnu/stubs.h \ > /usr/x86_64-linux-gnu/include/gnu/stubs-64.h \ > /usr/include/x86_64-linux-gnu/c++/8/bits/cpu_defines.h \ > /usr/x86_64-linux-gnu/include/stdio.h \ > /usr/x86_64-linux-gnu/include/bits/libc-header-start.h \ > /usr/lib/gcc/x86_64-linux-gnu/8/include/stddef.h \ > /usr/x86_64-linux-gnu/include/bits/types.h \ > /usr/x86_64-linux-gnu/include/bits/typesizes.h \ > /usr/x86_64-linux-gnu/include/bits/types/__FILE.h \ > /usr/x86_64-linux-gnu/include/bits/types/FILE.h \ > /usr/x86_64-linux-gnu/include/bits/libio.h \ > /usr/x86_64-linux-gnu/include/bits/_G_config.h \ > /usr/x86_64-linux-gnu/include/bits/types/__mbstate_t.h \ > /usr/lib/gcc/x86_64-linux-gnu/8/include/stdarg.h \ > /usr/x86_64-linux-gnu/include/bits/stdio_lim.h \ > /usr/x86_64-linux-gnu/include/bits/sys_errlist.h \ > /usr/include/c++/8/locale /usr/include/c++/8/bits/localefwd.h \ > /usr/include/x86_64-linux-gnu/c++/8/bits/c++locale.h \ > /usr/include/c++/8/clocale /usr/x86_64-linux-gnu/include/locale.h \ > /usr/x86_64-linux-gnu/include/bits/locale.h \ > /usr/x86_64-linux-gnu/include/bits/types/locale_t.h \ > /usr/x86_64-linux-gnu/include/bits/types/__locale_t.h \ > /usr/include/c++/8/iosfwd /usr/include/c++/8/bits/stringfwd.h \ > /usr/include/c++/8/bits/memoryfwd.h /usr/include/c++/8/bits/postypes.h \ > /usr/include/c++/8/cwchar /usr/x86_64-linux-gnu/include/wchar.h \ > /usr/x86_64-linux-gnu/include/bits/floatn.h \ > /usr/x86_64-linux-gnu/include/bits/floatn-common.h \ > /usr/x86_64-linux-gnu/include/bits/wchar.h \ > /usr/x86_64-linux-gnu/include/bits/types/wint_t.h \ > /usr/x86_64-linux-gnu/include/bits/types/mbstate_t.h \ > /usr/include/c++/8/cctype /usr/x86_64-linux-gnu/include/ctype.h \ > /usr/x86_64-linux-gnu/include/endian.h \ > /usr/x86_64-linux-gnu/include/bits/endian.h \ > /usr/x86_64-linux-gnu/include/bits/byteswap.h \ > /usr/x86_64-linux-gnu/include/bits/byteswap-16.h \ > /usr/x86_64-linux-gnu/include/bits/uintn-identity.h \ > /usr/include/c++/8/bits/locale_classes.h /usr/include/c++/8/string \ > /usr/include/c++/8/bits/char_traits.h \ > /usr/include/c++/8/bits/stl_algobase.h \ > /usr/include/c++/8/bits/functexcept.h \ > /usr/include/c++/8/bits/exception_defines.h \ > /usr/include/c++/8/bits/cpp_type_traits.h \ > /usr/include/c++/8/ext/type_traits.h \ > /usr/include/c++/8/ext/numeric_traits.h \ > /usr/include/c++/8/bits/stl_pair.h /usr/include/c++/8/bits/move.h \ > /usr/include/c++/8/bits/concept_check.h /usr/include/c++/8/type_traits \ > /usr/include/c++/8/bits/stl_iterator_base_types.h \ > /usr/include/c++/8/bits/stl_iterator_base_funcs.h \ > /usr/include/c++/8/debug/assertions.h \ > /usr/include/c++/8/bits/stl_iterator.h \ > /usr/include/c++/8/bits/ptr_traits.h /usr/include/c++/8/debug/debug.h \ > /usr/include/c++/8/bits/predefined_ops.h /usr/include/c++/8/cstdint \ > /usr/lib/gcc/x86_64-linux-gnu/8/include/stdint.h \ > /usr/x86_64-linux-gnu/include/stdint.h \ > /usr/x86_64-linux-gnu/include/bits/stdint-intn.h \ > /usr/x86_64-linux-gnu/include/bits/stdint-uintn.h \ > /usr/include/c++/8/bits/allocator.h \ > /usr/include/x86_64-linux-gnu/c++/8/bits/c++allocator.h \ > /usr/include/c++/8/ext/new_allocator.h /usr/include/c++/8/new \ > /usr/include/c++/8/exception /usr/include/c++/8/bits/exception.h \ > /usr/include/c++/8/bits/exception_ptr.h \ > /usr/include/c++/8/bits/cxxabi_init_exception.h \ > /usr/include/c++/8/typeinfo /usr/include/c++/8/bits/hash_bytes.h \ > /usr/include/c++/8/bits/nested_exception.h \ > /usr/include/c++/8/bits/ostream_insert.h \ > /usr/include/c++/8/bits/cxxabi_forced.h \ > /usr/include/c++/8/bits/stl_function.h \ > /usr/include/c++/8/backward/binders.h \ > /usr/include/c++/8/bits/range_access.h \ > /usr/include/c++/8/initializer_list \ > /usr/include/c++/8/bits/basic_string.h \ > /usr/include/c++/8/ext/atomicity.h \ > /usr/include/x86_64-linux-gnu/c++/8/bits/gthr.h \ > /usr/include/x86_64-linux-gnu/c++/8/bits/gthr-default.h \ > /usr/x86_64-linux-gnu/include/pthread.h \ > /usr/x86_64-linux-gnu/include/sched.h \ > /usr/x86_64-linux-gnu/include/bits/types/time_t.h \ > /usr/x86_64-linux-gnu/include/bits/types/struct_timespec.h \ > /usr/x86_64-linux-gnu/include/bits/sched.h \ > /usr/x86_64-linux-gnu/include/bits/cpu-set.h \ > /usr/x86_64-linux-gnu/include/time.h \ > /usr/x86_64-linux-gnu/include/bits/time.h \ > /usr/x86_64-linux-gnu/include/bits/timex.h \ > /usr/x86_64-linux-gnu/include/bits/types/struct_timeval.h \ > /usr/x86_64-linux-gnu/include/bits/types/clock_t.h \ > /usr/x86_64-linux-gnu/include/bits/types/struct_tm.h \ > /usr/x86_64-linux-gnu/include/bits/types/clockid_t.h \ > /usr/x86_64-linux-gnu/include/bits/types/timer_t.h \ > /usr/x86_64-linux-gnu/include/bits/types/struct_itimerspec.h \ > /usr/x86_64-linux-gnu/include/bits/pthreadtypes.h \ > /usr/x86_64-linux-gnu/include/bits/thread-shared-types.h \ > /usr/x86_64-linux-gnu/include/bits/pthreadtypes-arch.h \ > /usr/x86_64-linux-gnu/include/bits/setjmp.h \ > /usr/include/x86_64-linux-gnu/c++/8/bits/atomic_word.h \ > /usr/include/c++/8/ext/alloc_traits.h \ > /usr/include/c++/8/bits/alloc_traits.h \ > /usr/include/c++/8/ext/string_conversions.h /usr/include/c++/8/cstdlib \ > /usr/x86_64-linux-gnu/include/stdlib.h \ > /usr/x86_64-linux-gnu/include/bits/waitflags.h \ > /usr/x86_64-linux-gnu/include/bits/waitstatus.h \ > /usr/x86_64-linux-gnu/include/sys/types.h \ > /usr/x86_64-linux-gnu/include/sys/select.h \ > /usr/x86_64-linux-gnu/include/bits/select.h \ > /usr/x86_64-linux-gnu/include/bits/types/sigset_t.h \ > /usr/x86_64-linux-gnu/include/bits/types/__sigset_t.h \ > /usr/x86_64-linux-gnu/include/sys/sysmacros.h \ > /usr/x86_64-linux-gnu/include/bits/sysmacros.h \ > /usr/x86_64-linux-gnu/include/alloca.h \ > /usr/x86_64-linux-gnu/include/bits/stdlib-float.h \ > /usr/include/c++/8/bits/std_abs.h /usr/include/c++/8/cerrno \ > /usr/x86_64-linux-gnu/include/errno.h \ > /usr/x86_64-linux-gnu/include/bits/errno.h \ > /usr/x86_64-linux-gnu/include/linux/errno.h \ > /usr/x86_64-linux-gnu/include/asm/errno.h \ > /usr/x86_64-linux-gnu/include/asm-generic/errno.h \ > /usr/x86_64-linux-gnu/include/asm-generic/errno-base.h \ > /usr/include/c++/8/bits/functional_hash.h \ > /usr/include/c++/8/bits/basic_string.tcc \ > /usr/include/c++/8/bits/locale_classes.tcc \ > /usr/include/c++/8/bits/locale_facets.h /usr/include/c++/8/cwctype \ > /usr/x86_64-linux-gnu/include/wctype.h \ > /usr/x86_64-linux-gnu/include/bits/wctype-wchar.h \ > /usr/include/x86_64-linux-gnu/c++/8/bits/ctype_base.h \ > /usr/include/c++/8/bits/ios_base.h /usr/include/c++/8/system_error \ > /usr/include/x86_64-linux-gnu/c++/8/bits/error_constants.h \ > /usr/include/c++/8/stdexcept /usr/include/c++/8/streambuf \ > /usr/include/c++/8/bits/streambuf.tcc \ > /usr/include/c++/8/bits/streambuf_iterator.h \ > /usr/include/x86_64-linux-gnu/c++/8/bits/ctype_inline.h \ > /usr/include/c++/8/bits/locale_facets.tcc \ > /usr/include/c++/8/bits/locale_facets_nonio.h /usr/include/c++/8/ctime \ > /usr/include/x86_64-linux-gnu/c++/8/bits/time_members.h \ > /usr/include/x86_64-linux-gnu/c++/8/bits/messages_members.h \ > /usr/x86_64-linux-gnu/include/libintl.h \ > /usr/include/c++/8/bits/codecvt.h \ > /usr/include/c++/8/bits/locale_facets_nonio.tcc \ > /usr/include/c++/8/bits/locale_conv.h \ > /usr/include/c++/8/bits/unique_ptr.h /usr/include/c++/8/utility \ > /usr/include/c++/8/bits/stl_relops.h /usr/include/c++/8/tuple \ > /usr/include/c++/8/array /usr/include/c++/8/bits/uses_allocator.h \ > /usr/include/c++/8/bits/invoke.h /usr/include/c++/8/fstream \ > /usr/include/c++/8/istream /usr/include/c++/8/ios \ > /usr/include/c++/8/bits/basic_ios.h \ > /usr/include/c++/8/bits/basic_ios.tcc /usr/include/c++/8/ostream \ > /usr/include/c++/8/bits/ostream.tcc /usr/include/c++/8/bits/istream.tcc \ > /usr/include/x86_64-linux-gnu/c++/8/bits/basic_file.h \ > /usr/include/x86_64-linux-gnu/c++/8/bits/c++io.h \ > /usr/include/c++/8/bits/fstream.tcc /usr/include/c++/8/iostream \ > /usr/include/c++/8/filesystem > > > amazing, no? cmake find only 9 dependencies against 100+ real ones (and I don't even speak of errors that can be caused in parsing if some -D option is changed.... > > thanks and regards > JLM > > > Le lun. 24 juin 2019 ? 14:14, Robert Maynard a ?crit : >> >> It look that starting with CMake 3.6 modification of system headers >> will cause CMake to recompile projects. What version of CMake and your >> compiler are you using? >> >> On Mon, Jun 17, 2019 at 9:40 AM jl forums wrote: >> > >> > Hi, >> > I want to create a full tag file and for this require to know the compiler full include path... there is a way to had custom includes path but didn't found any variables for the include path.... >> > for example : >> > $ gcc-8 -v -x c -E /dev/null >> > Using built-in specs. >> > [....] >> > ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" >> > #include "..." search starts here: >> > #include <...> search starts here: >> > /usr/lib/gcc/x86_64-linux-gnu/8/include >> > /usr/local/include >> > /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed >> > /usr/x86_64-linux-gnu/include >> > /usr/include/x86_64-linux-gnu >> > /usr/include >> > End of search list. >> > [...] >> > >> > $ gcc -v -x c -E /dev/null >> > Using built-in specs. >> > [...] >> > ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" >> > #include "..." search starts here: >> > #include <...> search starts here: >> > /usr/lib/gcc/x86_64-linux-gnu/7/include >> > /usr/local/include >> > /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed >> > /usr/x86_64-linux-gnu/include >> > /usr/include/x86_64-linux-gnu >> > /usr/include >> > End of search list. >> > [...] >> > >> > I tried to >> > >> > >> > get_target_property(moggle_interface_includes FileSync INTERFACE_INCLUDE_DIRECTORIES) >> > message("Moggle interface includes: ${moggle_interface_includes}") >> > >> > get_target_property(motor_includes FileSync INCLUDE_DIRECTORIES) >> > message("MOTOR includes ${motor_includes}") >> > >> > but I get >> > >> > Moggle interface includes: moggle_interface_includes-NOTFOUND >> > MOTOR includes motor_includes-NOTFOUND >> > >> > >> > there is also some issue because cmake strip dependencies from system's include, which means that updating a system software won't cause rebuild and consider that the build is uptodate, causing unexpected results >> > seems that there is ways to workaround this : https://stackoverflow.com/questions/7461000/handling-header-files-dependencies-with-cmake but this is ugly... would be better to let the user choose with an option >> > >> > thanks and regards >> > JLM >> > -- >> > >> > Powered by www.kitware.com >> > >> > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> > >> > Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> > >> > CMake Support: http://cmake.org/cmake/help/support.html >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> > CMake Training Courses: http://cmake.org/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 Wed Jul 3 11:24:17 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Wed, 03 Jul 2019 11:24:17 -0400 Subject: [CMake] CMake APT Repository Signing Key Message-ID: <1562167457.3713.9.camel@kitware.com> All, The new 2020 signing key for the APT repository (https://apt.kitware.com/) has been generated for 2020, with fingerprint A8E5EF3A02600268.?The 2019 key, with fingerprint C1F34CDD40CD72DA, will remain in effect until the beginning of 2020, at which point the 2020 key will go into effect. The ?The 2018 key, with fingerprint?461FD00B2DB57A2D, has been retired, and will see no further use. As a reminder, we recommend that you install the kitware-archive- keyring package from the APT repository, which will ensure that your keyring always stays up to date as we rotate our keys. The kitware- archive-keyring package has been updated to reflect these changes. The new version is 2019.07.03. Kyle From dmitigr at gmail.com Wed Jul 3 17:25:49 2019 From: dmitigr at gmail.com (Dmitry Igrishin) Date: Thu, 4 Jul 2019 00:25:49 +0300 Subject: [CMake] Shared, static and header-only versions of library side by side. Message-ID: Hello, The libraries I developing can be used as a shared libraries, static libraries or header-only libraries. I want to let the users to: - install all three variants side by side; - choice what variant of library to use for linkage. I see 2 options here: 1. use different config files. For example, foo-config.cmake (corresponds to shared library "foo"), foo_static-config.cmake (corresponds to static library "foo"), foo_interface-config.cmake (corresponds to header-only library "foo"). In this case users can consume appropriate variant of "foo" by using find_package(foo CONFIGS ) and then target_link_libraries(bar foo) or target_link_libraries(bar foo_static) or target_link_libraries(bar INTERFACE foo_interface); 2. use different packages. For example, "foo", "foo_static", "for_interface". In this case users can consume libraries by using find_package(foo) or find_package(foo_static) or find_package(foo_interface) and then target_link_libraries(bar foo) or target_link_libraries(bar INTERFACE foo). What option is preferable? Or is there are any other options available? From fifteenknots505 at gmail.com Sat Jul 6 12:42:10 2019 From: fifteenknots505 at gmail.com (Martin Weber) Date: Sat, 06 Jul 2019 18:42:10 +0200 Subject: [CMake] FYI: Where do users of CMake with Eclipse work? Message-ID: <8357599.5nC0yktNr8@linux> Hi all, found some interesting download stats for Eclipse plugins that integrate CMake. Just click the globe icon to the right to see downloads by country. Martin -- There are only two hard problems in Computer Science: cache invalidation, naming things, and off-by-one errors. From jlmxyz.forums at gmail.com Sun Jul 7 10:26:46 2019 From: jlmxyz.forums at gmail.com (jl forums) Date: Sun, 7 Jul 2019 16:26:46 +0200 Subject: [CMake] getting compiler's include paths In-Reply-To: References: Message-ID: ok, thanks by the way what about my ctags rule? how can i get the include path of an app? so that i can pass it to ctags and have my tags produced? thanks and regards jlm Le mer. 3 juil. 2019 ? 16:52, Robert Maynard a ?crit : > I completely forgot that the Makefiles based generators in CMake have > a separate heuristic for determining system headers. > > If you use the Ninja generator I see the expected behavior: > ~/W/t/nbuild $ sudo touch /usr/include/c++/7/array > ~/W/t/nbuild $ ninja -d explain -v > ninja explain: output test/CMakeFiles/ProjTest.dir/test.cpp.o older > than most recent input /usr/include/c++/7/array (1562165327 vs > 1562165329) > ninja explain: test/CMakeFiles/ProjTest.dir/test.cpp.o is dirty > ninja explain: test/ProjTest is dirty > [1/2] /usr/bin/c++ -I../my_lib/include -std=gnu++1z -MD -MT > test/CMakeFiles/ProjTest.dir/test.cpp.o -MF > test/CMakeFiles/ProjTest.dir/test.cpp.o.d -o > test/CMakeFiles/ProjTest.dir/test.cpp.o -c ../test/test.cpp > [2/2] : && /usr/bin/c++ test/CMakeFiles/ProjTest.dir/test.cpp.o > -o test/ProjTest && : > > > I will need to spend some more time figuring out the extra include > caching logic for the Makefile based generators, and will report back. > > On Thu, Jun 27, 2019 at 8:59 AM jl forums wrote: > > > > thanks for the anwer.... > > quite not... I'm using cmake 3.14.2 (so, far away from 3.6....) and have > a look, in main.cpp, there is #include : > > > > $ find /usr/include/ -name filesystem > > /usr/include/c++/5/experimental/filesystem > > /usr/include/c++/7/experimental/filesystem > > /usr/include/c++/8/filesystem > > /usr/include/c++/8/experimental/filesystem > > $ sudo touch /usr/include/c++/5/experimental/filesystem > /usr/include/c++/7/experimental/filesystem /usr/include/c++/8/filesystem > /usr/include/c++/8/experimental/filesystem > > $ make > > [100%] Built target FileSync > > $ touch ../main.cxx > > $ make > > Scanning dependencies of target FileSync > > [ 50%] Building CXX object CMakeFiles/FileSync.dir/main.cxx.o > > [100%] Linking CXX executable FileSync > > [100%] Built target FileSync > > > > > > => cmake don't create "full include dependency" which IS a mistake.... > updating system g++ can just assume the target is uptodate and in fact just > create a broken build... > > > > in cmake cxx.includecache > > > > #IncludeRegexLine: ^[ ]*[#%][ ]*(include|import)[ ]*[<"]([^">]+)([">]) > > #IncludeRegexScan: ^.*$ > > #IncludeRegexComplain: ^$ > > #IncludeRegexTransform: > > /home/orange/crypt/Devel/projets/FileSync/main.cxx > > cstdio > > - > > io.h > > - > > fcntl.h > > - > > locale > > - > > clocale > > - > > fstream > > - > > iostream > > - > > filesystem > > - > > > > $ /usr/bin/gcc-8 -M ../main.cxx > > main.o: ../main.cxx /usr/x86_64-linux-gnu/include/stdc-predef.h \ > > /usr/include/c++/8/cstdio \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/c++config.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/os_defines.h \ > > /usr/x86_64-linux-gnu/include/features.h \ > > /usr/x86_64-linux-gnu/include/sys/cdefs.h \ > > /usr/x86_64-linux-gnu/include/bits/wordsize.h \ > > /usr/x86_64-linux-gnu/include/bits/long-double.h \ > > /usr/x86_64-linux-gnu/include/gnu/stubs.h \ > > /usr/x86_64-linux-gnu/include/gnu/stubs-64.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/cpu_defines.h \ > > /usr/x86_64-linux-gnu/include/stdio.h \ > > /usr/x86_64-linux-gnu/include/bits/libc-header-start.h \ > > /usr/lib/gcc/x86_64-linux-gnu/8/include/stddef.h \ > > /usr/x86_64-linux-gnu/include/bits/types.h \ > > /usr/x86_64-linux-gnu/include/bits/typesizes.h \ > > /usr/x86_64-linux-gnu/include/bits/types/__FILE.h \ > > /usr/x86_64-linux-gnu/include/bits/types/FILE.h \ > > /usr/x86_64-linux-gnu/include/bits/libio.h \ > > /usr/x86_64-linux-gnu/include/bits/_G_config.h \ > > /usr/x86_64-linux-gnu/include/bits/types/__mbstate_t.h \ > > /usr/lib/gcc/x86_64-linux-gnu/8/include/stdarg.h \ > > /usr/x86_64-linux-gnu/include/bits/stdio_lim.h \ > > /usr/x86_64-linux-gnu/include/bits/sys_errlist.h \ > > /usr/include/c++/8/locale /usr/include/c++/8/bits/localefwd.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/c++locale.h \ > > /usr/include/c++/8/clocale /usr/x86_64-linux-gnu/include/locale.h \ > > /usr/x86_64-linux-gnu/include/bits/locale.h \ > > /usr/x86_64-linux-gnu/include/bits/types/locale_t.h \ > > /usr/x86_64-linux-gnu/include/bits/types/__locale_t.h \ > > /usr/include/c++/8/iosfwd /usr/include/c++/8/bits/stringfwd.h \ > > /usr/include/c++/8/bits/memoryfwd.h /usr/include/c++/8/bits/postypes.h \ > > /usr/include/c++/8/cwchar /usr/x86_64-linux-gnu/include/wchar.h \ > > /usr/x86_64-linux-gnu/include/bits/floatn.h \ > > /usr/x86_64-linux-gnu/include/bits/floatn-common.h \ > > /usr/x86_64-linux-gnu/include/bits/wchar.h \ > > /usr/x86_64-linux-gnu/include/bits/types/wint_t.h \ > > /usr/x86_64-linux-gnu/include/bits/types/mbstate_t.h \ > > /usr/include/c++/8/cctype /usr/x86_64-linux-gnu/include/ctype.h \ > > /usr/x86_64-linux-gnu/include/endian.h \ > > /usr/x86_64-linux-gnu/include/bits/endian.h \ > > /usr/x86_64-linux-gnu/include/bits/byteswap.h \ > > /usr/x86_64-linux-gnu/include/bits/byteswap-16.h \ > > /usr/x86_64-linux-gnu/include/bits/uintn-identity.h \ > > /usr/include/c++/8/bits/locale_classes.h /usr/include/c++/8/string \ > > /usr/include/c++/8/bits/char_traits.h \ > > /usr/include/c++/8/bits/stl_algobase.h \ > > /usr/include/c++/8/bits/functexcept.h \ > > /usr/include/c++/8/bits/exception_defines.h \ > > /usr/include/c++/8/bits/cpp_type_traits.h \ > > /usr/include/c++/8/ext/type_traits.h \ > > /usr/include/c++/8/ext/numeric_traits.h \ > > /usr/include/c++/8/bits/stl_pair.h /usr/include/c++/8/bits/move.h \ > > /usr/include/c++/8/bits/concept_check.h /usr/include/c++/8/type_traits \ > > /usr/include/c++/8/bits/stl_iterator_base_types.h \ > > /usr/include/c++/8/bits/stl_iterator_base_funcs.h \ > > /usr/include/c++/8/debug/assertions.h \ > > /usr/include/c++/8/bits/stl_iterator.h \ > > /usr/include/c++/8/bits/ptr_traits.h /usr/include/c++/8/debug/debug.h \ > > /usr/include/c++/8/bits/predefined_ops.h /usr/include/c++/8/cstdint \ > > /usr/lib/gcc/x86_64-linux-gnu/8/include/stdint.h \ > > /usr/x86_64-linux-gnu/include/stdint.h \ > > /usr/x86_64-linux-gnu/include/bits/stdint-intn.h \ > > /usr/x86_64-linux-gnu/include/bits/stdint-uintn.h \ > > /usr/include/c++/8/bits/allocator.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/c++allocator.h \ > > /usr/include/c++/8/ext/new_allocator.h /usr/include/c++/8/new \ > > /usr/include/c++/8/exception /usr/include/c++/8/bits/exception.h \ > > /usr/include/c++/8/bits/exception_ptr.h \ > > /usr/include/c++/8/bits/cxxabi_init_exception.h \ > > /usr/include/c++/8/typeinfo /usr/include/c++/8/bits/hash_bytes.h \ > > /usr/include/c++/8/bits/nested_exception.h \ > > /usr/include/c++/8/bits/ostream_insert.h \ > > /usr/include/c++/8/bits/cxxabi_forced.h \ > > /usr/include/c++/8/bits/stl_function.h \ > > /usr/include/c++/8/backward/binders.h \ > > /usr/include/c++/8/bits/range_access.h \ > > /usr/include/c++/8/initializer_list \ > > /usr/include/c++/8/bits/basic_string.h \ > > /usr/include/c++/8/ext/atomicity.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/gthr.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/gthr-default.h \ > > /usr/x86_64-linux-gnu/include/pthread.h \ > > /usr/x86_64-linux-gnu/include/sched.h \ > > /usr/x86_64-linux-gnu/include/bits/types/time_t.h \ > > /usr/x86_64-linux-gnu/include/bits/types/struct_timespec.h \ > > /usr/x86_64-linux-gnu/include/bits/sched.h \ > > /usr/x86_64-linux-gnu/include/bits/cpu-set.h \ > > /usr/x86_64-linux-gnu/include/time.h \ > > /usr/x86_64-linux-gnu/include/bits/time.h \ > > /usr/x86_64-linux-gnu/include/bits/timex.h \ > > /usr/x86_64-linux-gnu/include/bits/types/struct_timeval.h \ > > /usr/x86_64-linux-gnu/include/bits/types/clock_t.h \ > > /usr/x86_64-linux-gnu/include/bits/types/struct_tm.h \ > > /usr/x86_64-linux-gnu/include/bits/types/clockid_t.h \ > > /usr/x86_64-linux-gnu/include/bits/types/timer_t.h \ > > /usr/x86_64-linux-gnu/include/bits/types/struct_itimerspec.h \ > > /usr/x86_64-linux-gnu/include/bits/pthreadtypes.h \ > > /usr/x86_64-linux-gnu/include/bits/thread-shared-types.h \ > > /usr/x86_64-linux-gnu/include/bits/pthreadtypes-arch.h \ > > /usr/x86_64-linux-gnu/include/bits/setjmp.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/atomic_word.h \ > > /usr/include/c++/8/ext/alloc_traits.h \ > > /usr/include/c++/8/bits/alloc_traits.h \ > > /usr/include/c++/8/ext/string_conversions.h /usr/include/c++/8/cstdlib \ > > /usr/x86_64-linux-gnu/include/stdlib.h \ > > /usr/x86_64-linux-gnu/include/bits/waitflags.h \ > > /usr/x86_64-linux-gnu/include/bits/waitstatus.h \ > > /usr/x86_64-linux-gnu/include/sys/types.h \ > > /usr/x86_64-linux-gnu/include/sys/select.h \ > > /usr/x86_64-linux-gnu/include/bits/select.h \ > > /usr/x86_64-linux-gnu/include/bits/types/sigset_t.h \ > > /usr/x86_64-linux-gnu/include/bits/types/__sigset_t.h \ > > /usr/x86_64-linux-gnu/include/sys/sysmacros.h \ > > /usr/x86_64-linux-gnu/include/bits/sysmacros.h \ > > /usr/x86_64-linux-gnu/include/alloca.h \ > > /usr/x86_64-linux-gnu/include/bits/stdlib-float.h \ > > /usr/include/c++/8/bits/std_abs.h /usr/include/c++/8/cerrno \ > > /usr/x86_64-linux-gnu/include/errno.h \ > > /usr/x86_64-linux-gnu/include/bits/errno.h \ > > /usr/x86_64-linux-gnu/include/linux/errno.h \ > > /usr/x86_64-linux-gnu/include/asm/errno.h \ > > /usr/x86_64-linux-gnu/include/asm-generic/errno.h \ > > /usr/x86_64-linux-gnu/include/asm-generic/errno-base.h \ > > /usr/include/c++/8/bits/functional_hash.h \ > > /usr/include/c++/8/bits/basic_string.tcc \ > > /usr/include/c++/8/bits/locale_classes.tcc \ > > /usr/include/c++/8/bits/locale_facets.h /usr/include/c++/8/cwctype \ > > /usr/x86_64-linux-gnu/include/wctype.h \ > > /usr/x86_64-linux-gnu/include/bits/wctype-wchar.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/ctype_base.h \ > > /usr/include/c++/8/bits/ios_base.h /usr/include/c++/8/system_error \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/error_constants.h \ > > /usr/include/c++/8/stdexcept /usr/include/c++/8/streambuf \ > > /usr/include/c++/8/bits/streambuf.tcc \ > > /usr/include/c++/8/bits/streambuf_iterator.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/ctype_inline.h \ > > /usr/include/c++/8/bits/locale_facets.tcc \ > > /usr/include/c++/8/bits/locale_facets_nonio.h /usr/include/c++/8/ctime \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/time_members.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/messages_members.h \ > > /usr/x86_64-linux-gnu/include/libintl.h \ > > /usr/include/c++/8/bits/codecvt.h \ > > /usr/include/c++/8/bits/locale_facets_nonio.tcc \ > > /usr/include/c++/8/bits/locale_conv.h \ > > /usr/include/c++/8/bits/unique_ptr.h /usr/include/c++/8/utility \ > > /usr/include/c++/8/bits/stl_relops.h /usr/include/c++/8/tuple \ > > /usr/include/c++/8/array /usr/include/c++/8/bits/uses_allocator.h \ > > /usr/include/c++/8/bits/invoke.h /usr/include/c++/8/fstream \ > > /usr/include/c++/8/istream /usr/include/c++/8/ios \ > > /usr/include/c++/8/bits/basic_ios.h \ > > /usr/include/c++/8/bits/basic_ios.tcc /usr/include/c++/8/ostream \ > > /usr/include/c++/8/bits/ostream.tcc /usr/include/c++/8/bits/istream.tcc > \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/basic_file.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/c++io.h \ > > /usr/include/c++/8/bits/fstream.tcc /usr/include/c++/8/iostream \ > > /usr/include/c++/8/filesystem > > > > > > amazing, no? cmake find only 9 dependencies against 100+ real ones (and > I don't even speak of errors that can be caused in parsing if some -D > option is changed.... > > > > thanks and regards > > JLM > > > > > > Le lun. 24 juin 2019 ? 14:14, Robert Maynard > a ?crit : > >> > >> It look that starting with CMake 3.6 modification of system headers > >> will cause CMake to recompile projects. What version of CMake and your > >> compiler are you using? > >> > >> On Mon, Jun 17, 2019 at 9:40 AM jl forums > wrote: > >> > > >> > Hi, > >> > I want to create a full tag file and for this require to know the > compiler full include path... there is a way to had custom includes path > but didn't found any variables for the include path.... > >> > for example : > >> > $ gcc-8 -v -x c -E /dev/null > >> > Using built-in specs. > >> > [....] > >> > ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" > >> > #include "..." search starts here: > >> > #include <...> search starts here: > >> > /usr/lib/gcc/x86_64-linux-gnu/8/include > >> > /usr/local/include > >> > /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed > >> > /usr/x86_64-linux-gnu/include > >> > /usr/include/x86_64-linux-gnu > >> > /usr/include > >> > End of search list. > >> > [...] > >> > > >> > $ gcc -v -x c -E /dev/null > >> > Using built-in specs. > >> > [...] > >> > ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" > >> > #include "..." search starts here: > >> > #include <...> search starts here: > >> > /usr/lib/gcc/x86_64-linux-gnu/7/include > >> > /usr/local/include > >> > /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed > >> > /usr/x86_64-linux-gnu/include > >> > /usr/include/x86_64-linux-gnu > >> > /usr/include > >> > End of search list. > >> > [...] > >> > > >> > I tried to > >> > > >> > > >> > get_target_property(moggle_interface_includes FileSync > INTERFACE_INCLUDE_DIRECTORIES) > >> > message("Moggle interface includes: ${moggle_interface_includes}") > >> > > >> > get_target_property(motor_includes FileSync INCLUDE_DIRECTORIES) > >> > message("MOTOR includes ${motor_includes}") > >> > > >> > but I get > >> > > >> > Moggle interface includes: moggle_interface_includes-NOTFOUND > >> > MOTOR includes motor_includes-NOTFOUND > >> > > >> > > >> > there is also some issue because cmake strip dependencies from > system's include, which means that updating a system software won't cause > rebuild and consider that the build is uptodate, causing unexpected results > >> > seems that there is ways to workaround this : > https://stackoverflow.com/questions/7461000/handling-header-files-dependencies-with-cmake > but this is ugly... would be better to let the user choose with an option > >> > > >> > thanks and regards > >> > JLM > >> > -- > >> > > >> > Powered by www.kitware.com > >> > > >> > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > >> > > >> > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > >> > > >> > CMake Support: http://cmake.org/cmake/help/support.html > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> > CMake Training Courses: http://cmake.org/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 hex7c3 at gmail.com Mon Jul 8 09:07:56 2019 From: hex7c3 at gmail.com (hex) Date: Mon, 8 Jul 2019 14:07:56 +0100 Subject: [CMake] externalproject fails on submodule Message-ID: hello CMake community, I am using a private git repository with SSH URL with two different git remote server. The repository on github is using an git submodule on bitbucket. /include( ExternalProject )// // //ExternalProject_Add(test// //??? GIT_REPOSITORY git at github.com:myuser/myprivaterepo.git// //??? GIT_REMOTE_NAME origin// //)/ 1. Cloning the repository 'origin/master' is successful 2. Cloning into the submodule fails: it is unable to check out a git commit 3. To test my SSH connection I tried above CMake commands cloning solely the submodule, which is successful (see below with different URL) /include( ExternalProject )// //// //ExternalProject_Add(test// //??? GIT_REPOSITORY git at bitbucket.org:myusername/mysubmodule.git// //??? GIT_REMOTE_NAME origin// //)/ The complete error message from first example is given below: Scanning dependencies of target test [ 12%] Creating directories for 'test' [ 25%] Performing download step (git clone) for 'test' Cloning into 'test'... Already on 'master' Your branch is up-to-date with 'origin/master'. Submodule 'mysubmodule' (git at bitbucket.org:myusername/mysubmodule.git) registered for path 'mysubmodule' Cloning into 'mysubmodule'... fatal: reference is not a tree: 6a0b950ed42ce225cc2df0 Unable to checkout '6a0b950ed42ce225cc2df0' in submodule path 'mysubmodule' CMake Error at /home/user/testing/build/test-prefix/tmp/test-gitclone.cmake:49 (message): ? Failed to update submodules in: ? '/home/user/testing/build/test-prefix/src/test' How can I use the repository with submodules? thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From hex7c3 at gmail.com Mon Jul 8 09:16:53 2019 From: hex7c3 at gmail.com (hex) Date: Mon, 8 Jul 2019 14:16:53 +0100 Subject: [CMake] externalproject fails on submodule In-Reply-To: References: Message-ID: <5fb78be9-5847-caae-1be9-18de3c6f9230@gmail.com> there was a merge conflict on the submodule. Fixing the issue resolved the problem. From kyle.edwards at kitware.com Mon Jul 8 10:00:20 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Mon, 08 Jul 2019 10:00:20 -0400 Subject: [CMake] Shared, static and header-only versions of library side by side. In-Reply-To: References: Message-ID: <1562594420.21331.4.camel@kitware.com> On Thu, 2019-07-04 at 00:25 +0300, Dmitry Igrishin wrote: > Hello, > > The libraries I developing can be used as a shared libraries, static > libraries or header-only libraries. > I want to let the users to: > ? - install all three variants side by side; > ? - choice what variant of library to use for linkage. > I see 2 options here: > ? 1. use different config files. For example, foo-config.cmake > (corresponds to shared library "foo"), foo_static-config.cmake > (corresponds to static library "foo"), foo_interface-config.cmake > (corresponds to header-only library "foo"). In this case users can > consume appropriate variant of "foo" by using find_package(foo > CONFIGS > ) and then target_link_libraries(bar foo) or > target_link_libraries(bar foo_static) or target_link_libraries(bar > INTERFACE foo_interface); > ? 2. use different packages. For example, "foo", "foo_static", > "for_interface". In this case users can consume libraries by using > find_package(foo) or find_package(foo_static) or > find_package(foo_interface) and then target_link_libraries(bar foo) > or > target_link_libraries(bar INTERFACE foo). > > What option is preferable? Or is there are any other options > available? There is another option: create different targets, each with the same output name. For example, you would find_package(foo), which would yield targets foo_shared, foo_static, and foo_interface. You could then use target_link_libraries() for each of these. Keep in mind that they don't have to have foo_shared and foo_static in their filenames. You can set the OUTPUT_NAME property on each target: https://cmake.org/cmake/help/v3.15/prop_tgt/OUTPUT_NAME.html This would allow them to still be called libfoo.a and libfoo.so. Kyle From dmitigr at gmail.com Mon Jul 8 15:27:48 2019 From: dmitigr at gmail.com (Dmitry Igrishin) Date: Mon, 8 Jul 2019 22:27:48 +0300 Subject: [CMake] Shared, static and header-only versions of library side by side. In-Reply-To: <1562594420.21331.4.camel@kitware.com> References: <1562594420.21331.4.camel@kitware.com> Message-ID: ??, 8 ???. 2019 ?. ? 17:00, Kyle Edwards : > > On Thu, 2019-07-04 at 00:25 +0300, Dmitry Igrishin wrote: > > Hello, > > > > The libraries I developing can be used as a shared libraries, static > > libraries or header-only libraries. > > I want to let the users to: > > - install all three variants side by side; > > - choice what variant of library to use for linkage. > > I see 2 options here: > > 1. use different config files. For example, foo-config.cmake > > (corresponds to shared library "foo"), foo_static-config.cmake > > (corresponds to static library "foo"), foo_interface-config.cmake > > (corresponds to header-only library "foo"). In this case users can > > consume appropriate variant of "foo" by using find_package(foo > > CONFIGS > > ) and then target_link_libraries(bar foo) or > > target_link_libraries(bar foo_static) or target_link_libraries(bar > > INTERFACE foo_interface); > > 2. use different packages. For example, "foo", "foo_static", > > "for_interface". In this case users can consume libraries by using > > find_package(foo) or find_package(foo_static) or > > find_package(foo_interface) and then target_link_libraries(bar foo) > > or > > target_link_libraries(bar INTERFACE foo). > > > > What option is preferable? Or is there are any other options > > available? > > There is another option: create different targets, each with the same > output name. For example, you would find_package(foo), which would > yield targets foo_shared, foo_static, and foo_interface. You could then > use target_link_libraries() for each of these. Thanks for the point! Another option is to use multiple targets, components and aliasing. For each target an alias can be created: add_library(bar_shared ALIAS foo::bar) add_library(baz_interface ALIAS foo::baz) To use library we run find_package(foo COMPONENTS bar_shared baz_interface). In foo-config.cmake the corresponding configs for bar_shared and baz_interface included. And then users can use "bar" and "baz" with target_link_libraries(): target_link_libraries(app foo::bar foo::baz) # using shared foo::bar and header-only foo::baz Thoughts? > Keep in mind that they don't have to have foo_shared and foo_static in > their filenames. You can set the OUTPUT_NAME property on each target: > > https://cmake.org/cmake/help/v3.15/prop_tgt/OUTPUT_NAME.html > > This would allow them to still be called libfoo.a and libfoo.so. Unfortunately, on Windows shared library foo represented by foo.lib and foo.dll that conflicts with static library represented by foo.lib :-( From hex7c3 at gmail.com Tue Jul 9 07:30:15 2019 From: hex7c3 at gmail.com (hex) Date: Tue, 9 Jul 2019 12:30:15 +0100 Subject: [CMake] how to set current source directory relative to external project Message-ID: <89c38bb9-3652-d736-b215-9e667cfd29ef@gmail.com> hello CMake community, I am experimenting with external projects. I have documentation in an external project which is generated in `${CMAKE_CURRENT_SOURCE_DIR}`. When I add the external project, however, it is using `${CMAKE_CURRENT_SOURCE_DIR}` of the "super build". I need `${CMAKE_CURRENT_SOURCE_DIR}` to be equal to `${SOURCE_DIR}`, where the former is seen by the external project and the latter by the "super build". Example: message("${CMAKE_CURRENT_SOURCE_DIR} = /home/user/super") ExternalProject_Add(ext1 ??? # directory options ??? SOURCE_DIR????? "${CMAKE_CURRENT_SOURCE_DIR}/ext1" ) ${CMAKE_CURRENT_SOURCE_DIR}/ext1/CMakeLists.txt: message("${CMAKE_CURRENT_SOURCE_DIR} = /home/user/super/ext1") From hex7c3 at gmail.com Tue Jul 9 08:35:19 2019 From: hex7c3 at gmail.com (hex) Date: Tue, 9 Jul 2019 13:35:19 +0100 Subject: [CMake] how to set current source directory relative to external project In-Reply-To: <89c38bb9-3652-d736-b215-9e667cfd29ef@gmail.com> References: <89c38bb9-3652-d736-b215-9e667cfd29ef@gmail.com> Message-ID: <46cd942b-9ed8-4700-76e9-3d5ee916dbca@gmail.com> hello CMake community, I am experimenting with external projects. I have some files in an external project which are generated in `${CMAKE_SOURCE_DIR}`. When I add the external project, however, it is using `${CMAKE_SOURCE_DIR}` of the external project. I need `${CMAKE_SOURCE_DIR}` to be relative to the "super build", instead of the external project path. Example: /message("${CMAKE_SOURCE_DIR} = /home/user/super")// // //ExternalProject_Add(ext1// //??? # directory options// //??? SOURCE_DIR????? "${CMAKE_SOURCE_DIR}/ext1"// //)/ ${CMAKE_SOURCE_DIR}/ext1/CMakeLists.txt: /message("${CMAKE_SOURCE_DIR} = /home/user/super/ext1")/ The desired outcome would be to have the path /home/user/super in both messages. How can I do this? thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Tue Jul 9 09:26:37 2019 From: d3ck0r at gmail.com (J Decker) Date: Tue, 9 Jul 2019 06:26:37 -0700 Subject: [CMake] how to set current source directory relative to external project In-Reply-To: <46cd942b-9ed8-4700-76e9-3d5ee916dbca@gmail.com> References: <89c38bb9-3652-d736-b215-9e667cfd29ef@gmail.com> <46cd942b-9ed8-4700-76e9-3d5ee916dbca@gmail.com> Message-ID: On Tue, Jul 9, 2019 at 5:35 AM hex wrote: > hello CMake community, > > > I am experimenting with external projects. I have some files in an > external project which are generated in `${CMAKE_SOURCE_DIR}`. > > > When I add the external project, however, it is using > `${CMAKE_SOURCE_DIR}` of the external project. > > > I need `${CMAKE_SOURCE_DIR}` to be relative to the "super build", instead > of the external project path. > > > Example: > > *message("${CMAKE_SOURCE_DIR} = /home/user/super")* > > *ExternalProject_Add(ext1* > * # directory options* > * SOURCE_DIR "${CMAKE_SOURCE_DIR}/ext1"* > *)* > > > ${CMAKE_SOURCE_DIR}/ext1/CMakeLists.txt: > > > *message("${CMAKE_SOURCE_DIR} = /home/user/super/ext1")* > *message("${CMAKE_SOURCE_DIR}/.. = /home/user/super/ext1/..")* which == /home/user/super > > > > The desired outcome would be to have the path /home/user/super in both > messages. > How can I do this? > > > 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 ldalessa at uw.edu Tue Jul 9 10:22:15 2019 From: ldalessa at uw.edu (Luke D'Alessandro) Date: Tue, 9 Jul 2019 10:22:15 -0400 Subject: [CMake] FindBLAS + MKL + Ctest fails on MacOS (SIP) Message-ID: Hi all, I have one of those complex interactions that results in an issue where it?s not clear to me which component is responsible. I have unit tests written using CTest that depend on Intel's MKL BLAS implementation. I use find_package(BLAS) and link the test executables to ${BLAS_LIBRARIES}. The test executables depend on the DYLD_LIBRARY_PATH to find the mkl libraries, rather than an embedded LC_RPATH. Unfortunately, because of Apple?s SIP, the DYLD_LIBRARY_PATH is not propagated to the ctest environment, so when it tries to run the tests it fails to link the MKL libraries. I need to get CMake to embed an external LC_PATH for test executables in the build directory. Here's a basic test executable (test.cpp) > #include > > int main() { > return &cblas_dgemm != nullptr; > } and here is the associated CMakeLists.txt > cmake_minimum_required(VERSION 3.14.5) > > project(blas LANGUAGES CXX) > include(CTest) > > set(BLA_VENDOR Intel10_64lp_seq) > find_package(BLAS REQUIRED) > > add_executable(test_blas test.cpp) > target_link_libraries(test_blas ${BLAS_LIBRARIES}) > > add_test(NAME test_direct COMMAND test_blas) This finds MKL and builds and links the executable without any problem, and I can run it manually from my shell. But when I run with CTest I have the SIP issue because MacOS won?t propagate the necessary DYLD_LIBRARY_PATH into CTest?s environment. > Lukes-MacBook:test ldalessa$ make test > Running tests... > Test project /Users/ldalessa/test > Start 1: test_direct > 1/1 Test #1: test_direct ......................Child aborted***Exception: 0.01 sec > > 0% tests passed, 1 tests failed out of 1 > > Total Test time (real) = 0.01 sec > > The following tests FAILED: > 1 - test_direct (Child aborted) > Errors while running CTest > make: *** [test] Error 8 > Lukes-MacBook:test ldalessa$ cat Testing/Temporary/LastTest.log > Start testing: Jun 10 03:35 PDT > ---------------------------------------------------------- > 1/1 Testing: test_direct > 1/1 Test: test_direct > Command: "/Users/ldalessa/test/test_blas" > Directory: /Users/ldalessa/test > "test_direct" start time: Jun 10 03:35 PDT > Output: > ---------------------------------------------------------- > dyld: Library not loaded: @rpath/libmkl_intel_lp64.dylib > Referenced from: /Users/ldalessa/test/test_blas > Reason: image not found > > Test time = 0.01 sec > ---------------------------------------------------------- > Test Failed. > "test_direct" end time: Jun 10 03:35 PDT > "test_direct" time elapsed: 00:00:00 > ---------------------------------------------------------- > > End testing: Jun 10 03:35 PDT > Lukes-MacBook:test ldalessa$ My temporary workaround for this is currently to use Apple's Accelerate framework instead of MKL, which links using an embedded LC_PATH properly. The reason this isn?t adequate is that it is an intrusive solution. Intel's MKL uses different headers (mkl_blas.h, mkl_lapack.h) and symbol names which are explicitly used in the source code, so I have to have extra configure-time and configured header changes to adapt the code base to Accelerate. We also don?t (and won?t) have verified and validated code with Accelerate so it?s not a long term solution to our issues. Disabling SIP is also a non-starter. Thanks, Luke (https://stackoverflow.com/questions/56524774/how-to-use-ctest-on-macos-without-disabling-sip-no-lc-path-is-set ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hex7c3 at gmail.com Tue Jul 9 12:38:07 2019 From: hex7c3 at gmail.com (hex) Date: Tue, 9 Jul 2019 17:38:07 +0100 Subject: [CMake] how to set current source directory relative to external project In-Reply-To: References: <89c38bb9-3652-d736-b215-9e667cfd29ef@gmail.com> <46cd942b-9ed8-4700-76e9-3d5ee916dbca@gmail.com> Message-ID: <76c24e7c-b766-d620-98c6-58934033b7ba@gmail.com> thank you J Decker for your reply. Your suggestion does work but I want to preserve standalone use of the project, meaning that I want a reference to CMake source root directory. Assuming there is only 1 hierarchy I could add an option: if ( SUPERBUILD ) /message("${CMAKE_SOURCE_DIR}/.. = /home/user/super/ext1/..")/ /else ()/ ////message("${CMAKE_SOURCE_DIR} = /home/user/super/ext1")// endif () I think the better solution now is to make it relative to build directory and force out of source builds. On 09/07/2019 14:26, J Decker wrote: > > /message("${CMAKE_SOURCE_DIR}/.. = /home/user/super/ext1/..")/? which > == /home/user/super > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Tue Jul 9 13:25:02 2019 From: d3ck0r at gmail.com (J Decker) Date: Tue, 9 Jul 2019 10:25:02 -0700 Subject: [CMake] how to set current source directory relative to external project In-Reply-To: <76c24e7c-b766-d620-98c6-58934033b7ba@gmail.com> References: <89c38bb9-3652-d736-b215-9e667cfd29ef@gmail.com> <46cd942b-9ed8-4700-76e9-3d5ee916dbca@gmail.com> <76c24e7c-b766-d620-98c6-58934033b7ba@gmail.com> Message-ID: On Tue, Jul 9, 2019 at 9:38 AM hex wrote: > thank you J Decker for your reply. > > > Your suggestion does work but I want to preserve standalone use of the > project, meaning that I want a reference to CMake source root directory. > > Assuming there is only 1 hierarchy I could add an option: > > > if ( SUPERBUILD ) > > *message("${CMAKE_SOURCE_DIR}/.. = /home/user/super/ext1/..")* > > *else ()* > > *message("${CMAKE_SOURCE_DIR} = /home/user/super/ext1")* > > endif () > > > I think the better solution now is to make it relative to build directory > and force out of source builds. > > > +1 I think; You said it was generated? It should be in the build directory anyway :) And out of source always. (makes it easier to source version control) > On 09/07/2019 14:26, J Decker wrote: > > > > *message("${CMAKE_SOURCE_DIR}/.. = /home/user/super/ext1/..")* which == > /home/user/super > >> >> >> -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 hex7c3 at gmail.com Tue Jul 9 16:24:07 2019 From: hex7c3 at gmail.com (hex) Date: Tue, 9 Jul 2019 21:24:07 +0100 Subject: [CMake] how to set current source directory relative to external project In-Reply-To: References: <89c38bb9-3652-d736-b215-9e667cfd29ef@gmail.com> <46cd942b-9ed8-4700-76e9-3d5ee916dbca@gmail.com> <76c24e7c-b766-d620-98c6-58934033b7ba@gmail.com> Message-ID: <7cd82a98-28d7-e9c6-fc34-71ccda067d55@gmail.com> On 09/07/2019 18:25, J Decker wrote: > > On Tue, Jul 9, 2019 at 9:38 AM hex > wrote: > > > I think the better solution now is to make it relative to build > directory and force out of source builds. > > > +1 I think; You said it was generated?? It should be in the build > directory anyway :) > And out of source always.? (makes it easier to source version control) > Now that I look at it it seems very obvious. I still have doubts, though: I guess I am seeing the contents of a build directory as somewhat volatile. For most files I want that, to either clean the project or override the files. But what about files I want to archive, such as a tarball or zipped documentation: does it make sense to place them into the build directory? The files belong to the project, though are not source controlled but aren't install targets either. Another thing I noticed is that my CMAKE_GENERATOR are now buried in subfolders. To change that I set PREFIX "${CMAKE_BINARY_DIR}/workspaces". Now all external projects are using the same prefix and are therefore generated into the same directory 'workspaces'. I could even set PREFIX "${CMAKE_SOURCE_DIR}/workspaces" which I'd actually prefer. The default binary directory is per project so I'd also change this to BINARY_DIR=${CMAKE_BINARY_DIR} I'm not concerned about /how/ to do it but rather /if/ it should be done. The documentation recommends to stick with the defaults. Any thoughts on this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Tue Jul 9 16:34:11 2019 From: d3ck0r at gmail.com (J Decker) Date: Tue, 9 Jul 2019 13:34:11 -0700 Subject: [CMake] how to set current source directory relative to external project In-Reply-To: <7cd82a98-28d7-e9c6-fc34-71ccda067d55@gmail.com> References: <89c38bb9-3652-d736-b215-9e667cfd29ef@gmail.com> <46cd942b-9ed8-4700-76e9-3d5ee916dbca@gmail.com> <76c24e7c-b766-d620-98c6-58934033b7ba@gmail.com> <7cd82a98-28d7-e9c6-fc34-71ccda067d55@gmail.com> Message-ID: On Tue, Jul 9, 2019 at 1:24 PM hex wrote: > On 09/07/2019 18:25, J Decker wrote: > > > On Tue, Jul 9, 2019 at 9:38 AM hex wrote: > >> >> I think the better solution now is to make it relative to build directory >> and force out of source builds. >> >> >> +1 I think; You said it was generated? It should be in the build > directory anyway :) > And out of source always. (makes it easier to source version control) > > > Now that I look at it it seems very obvious. I still have doubts, though: > > I guess I am seeing the contents of a build directory as somewhat > volatile. For most files I want that, to either clean the project or > override the files. > > But what about files I want to archive, such as a tarball or zipped > documentation: does it make sense to place them into the build directory? > The files belong to the project, though are not source controlled but > aren't install targets either. > I don't know what sorts of files those are; they don't exist but they get created, they're not tracked, and not installed... They sounds like a build product, which is a target, (even it it's just part of a product, it's still a target) > Another thing I noticed is that my CMAKE_GENERATOR are now buried in > subfolders. To change that I set PREFIX "${CMAKE_BINARY_DIR}/workspaces". > Now all external projects are using the same prefix and are therefore > generated into the same directory 'workspaces'. > right ? > I could even set PREFIX "${CMAKE_SOURCE_DIR}/workspaces" which I'd > actually prefer. > that makes it an insource product, which, if it's not in source control shouldn't be in the source.... > The default binary directory is per project so I'd also change this to > BINARY_DIR=${CMAKE_BINARY_DIR} > there's CMAKE_CURRENT_BINARY_DIR and that's per project, otherwise CMAKE_BINARY_DIR is a constant for all things within a single cmake invocation. > I'm not concerned about *how* to do it but rather *if* it should be done. > The documentation recommends to stick with the defaults. > > > Any thoughts on this? > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hex7c3 at gmail.com Tue Jul 9 17:53:47 2019 From: hex7c3 at gmail.com (hex) Date: Tue, 9 Jul 2019 22:53:47 +0100 Subject: [CMake] how to set current source directory relative to external project In-Reply-To: References: <89c38bb9-3652-d736-b215-9e667cfd29ef@gmail.com> <46cd942b-9ed8-4700-76e9-3d5ee916dbca@gmail.com> <76c24e7c-b766-d620-98c6-58934033b7ba@gmail.com> <7cd82a98-28d7-e9c6-fc34-71ccda067d55@gmail.com> Message-ID: <88e48f0e-9100-ce5e-f44c-a1c913575d51@gmail.com> I don't know what sorts of files those are; they don't exist but they get created, they're not tracked, and not installed... They sounds like a build product, which is a target, (even it it's just part of a product, it's still a target) Exactly, these are mostly BYPRODUCTS, but also OUTPUT of build commands, i.e. targets. > Another thing I noticed is that my CMAKE_GENERATOR are now buried > in subfolders. To change that I set PREFIX > "${CMAKE_BINARY_DIR}/workspaces". Now all external projects are > using the same prefix and are therefore generated into the same > directory 'workspaces'. > > right ? Except for my generators, and I think I wasn't clear enough about this part. I am using -G"Eclipse 2 - Unix Makefiles" for each external project. Note that this leaves me with a Makefile for the "super build" containing *all* targets of all projects. It *additionally* creates a Makefile for each external project individually. So I can do stuff like: /*cd build/ && make* # /to build the entire project or */cd build/workspaces/src/ext1-build/ && make/* # to build a specific external project, /ext1./ This is what I am after -> a multi-workspace super build. By workspace here I mean an eclipse workspace, the terminology does not exist in CMake. Note that each project has its own root binary path, meaning that ${CMAKE_BINARY_DIR} = build # for super build and ${CMAKE_BINARY_DIR} = build/workspaces/src/ext1-build # for external project ext1 ${CMAKE_CURRENT_BINARY_DIR} is then relative to any of either ${CMAKE_BINARY_DIR}'s. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hex7c3 at gmail.com Tue Jul 9 17:59:32 2019 From: hex7c3 at gmail.com (hex) Date: Tue, 9 Jul 2019 22:59:32 +0100 Subject: [CMake] how to set current source directory relative to external project In-Reply-To: <88e48f0e-9100-ce5e-f44c-a1c913575d51@gmail.com> References: <89c38bb9-3652-d736-b215-9e667cfd29ef@gmail.com> <46cd942b-9ed8-4700-76e9-3d5ee916dbca@gmail.com> <76c24e7c-b766-d620-98c6-58934033b7ba@gmail.com> <7cd82a98-28d7-e9c6-fc34-71ccda067d55@gmail.com> <88e48f0e-9100-ce5e-f44c-a1c913575d51@gmail.com> Message-ID: <0990b29b-0b8d-b200-244e-7236f2b54047@gmail.com> >?? Except for my generators well, to be exact it's not /except for/ . I am using multiple generators which means multiple copies of build targets. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hex7c3 at gmail.com Tue Jul 9 23:02:21 2019 From: hex7c3 at gmail.com (Hex) Date: Tue, 9 Jul 2019 20:02:21 -0700 (MST) Subject: [CMake] how to set current source directory relative to external project In-Reply-To: <0990b29b-0b8d-b200-244e-7236f2b54047@gmail.com> References: <46cd942b-9ed8-4700-76e9-3d5ee916dbca@gmail.com> <76c24e7c-b766-d620-98c6-58934033b7ba@gmail.com> <7cd82a98-28d7-e9c6-fc34-71ccda067d55@gmail.com> <88e48f0e-9100-ce5e-f44c-a1c913575d51@gmail.com> <0990b29b-0b8d-b200-244e-7236f2b54047@gmail.com> Message-ID: <1562727741241-0.post@n2.nabble.com> When I use CMAKE_BINARY_DIR the problem remains. If I set( EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin ) in my external project the binary is placed in build/ext1-prefix/src/ext1-build/bin/. Wouldn't it be better to have all my binaries in a single location? Such as build/bin/ ? The only way I see to do this is to modify the paths in my external projects to the parent directories, as has already been suggested. Or copying them into that location after the build. I don't think variables are propagated from the CMake project to the external project. -- Sent from: http://cmake.3232098.n2.nabble.com/ From doenges at mvtec.com Wed Jul 10 04:42:37 2019 From: doenges at mvtec.com (Eric Doenges) Date: Wed, 10 Jul 2019 10:42:37 +0200 Subject: [CMake] FindBLAS + MKL + Ctest fails on MacOS (SIP) In-Reply-To: References: Message-ID: The simplest way to do this is to use the BUILD_RPATH and/or INSTALL_RPATH properties, i.e. something like: list(GET BLAS_LIBRARIES 0 _BLAS_FIRSTLIB) get_filename_component(_BLAS_LIBDIR "${_BLAS_FIRSTLIB}" DIRECTORY set_target_properties(test_blas PROPERTIES BUILD_RPATH "${_BLAS_LIBDIR}") This assumes BLAS_LIBRARIES is a list of libraries specified with absolute paths; if this assumption is incorrect, you must figure out the directory to specify to BUILD_RPATH some other way. If the tests are run using the installed binary (or you build your binaries using the install rpath from the start, like we do), then you must set INSTALL_RPATH instead of BUILD_RPATH. For a detailed description, see the CMake wiki page on RPATH handling . Also note that while I think this should work, I haven't actually tested it myself. Am 09.07.19 um 16:22 schrieb Luke D'Alessandro: > Hi all, > > I have one of those complex interactions that results in an issue > where it?s not clear to me which component is responsible. > > I have unit tests written using CTest that depend on Intel's MKL > BLAS?implementation. I use?find_package(BLAS)?and link the test > executables to?${BLAS_LIBRARIES}. The test executables depend on > the?DYLD_LIBRARY_PATH?to?find the?mkl?libraries, rather than an > embedded?LC_RPATH. > > Unfortunately, because of Apple?s?SIP, the?DYLD_LIBRARY_PATH?is not > propagated to the?ctest?environment, so when it tries to run the tests > it fails to link the?MKL?libraries. > > I need to get?CMake?to embed an external?LC_PATH?for test executables > in?the build directory. > > Here's a basic test executable (test.cpp) > >> |#includeintmain(){return&cblas_dgemm !=nullptr;}| > and here is the associated?CMakeLists.txt > >> |cmake_minimum_required(VERSION 3.14.5) project(blas LANGUAGES CXX) >> include(CTest) set(BLA_VENDOR Intel10_64lp_seq) find_package(BLAS >> REQUIRED) add_executable(test_blas test.cpp) >> target_link_libraries(test_blas ${BLAS_LIBRARIES}) add_test(NAME >> test_direct COMMAND test_blas)| > This finds MKL and builds and links the executable without any > problem, and I can run it manually from my shell. But when I run > with?CTest?I have the?SIP?issue because MacOS won?t propagate the > necessary DYLD_LIBRARY_PATH into CTest?s environment. > >> |Lukes-MacBook:test ldalessa$ make test Running tests... Test project >> /Users/ldalessa/test Start 1: test_direct 1/1 Test #1: test_direct >> ......................Child aborted***Exception: 0.01 sec 0% tests >> passed, 1 tests failed out of 1 Total Test time (real) = 0.01 sec The >> following tests FAILED: 1 - test_direct (Child aborted) Errors while >> running CTest make: *** [test] Error 8 | > >> |Lukes-MacBook:test ldalessa$ cat Testing/Temporary/LastTest.log >> Start testing: Jun 10 03:35 PDT >> ---------------------------------------------------------- 1/1 >> Testing: test_direct 1/1 Test: test_direct Command: >> "/Users/ldalessa/test/test_blas" Directory: /Users/ldalessa/test >> "test_direct" start time: Jun 10 03:35 PDT Output: >> ---------------------------------------------------------- dyld: >> Library not loaded: @rpath/libmkl_intel_lp64.dylib Referenced from: >> /Users/ldalessa/test/test_blas Reason: image not found > output> Test time = 0.01 sec >> ---------------------------------------------------------- Test >> Failed. "test_direct" end time: Jun 10 03:35 PDT "test_direct" time >> elapsed: 00:00:00 >> ---------------------------------------------------------- End >> testing: Jun 10 03:35 PDT Lukes-MacBook:test ldalessa$ | > My temporary workaround for this is currently to use Apple's > Accelerate framework instead of MKL, which links using an embedded > LC_PATH properly. The reason this isn?t adequate is that it is an > intrusive solution. Intel's MKL uses different headers (|mkl_blas.h|, > |mkl_lapack.h|) and symbol names which are explicitly used in the > source code, so I have to have extra configure-time and configured > header changes to adapt the code base to Accelerate. We also don?t > (and won?t) have verified and validated code with Accelerate so it?s > not a long term solution to our issues. Disabling SIP is also a > non-starter. > > Thanks, > Luke > > (https://stackoverflow.com/questions/56524774/how-to-use-ctest-on-macos-without-disabling-sip-no-lc-path-is-set) > > -- *Dr. Eric D?nges * Senior Software Engineer MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany doenges at mvtec.com | Tel: +49 89 457 695-0 | www.mvtec.com Sign up for our MVTec Newsletter! Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt Amtsgericht M?nchen HRB 114695 MVTec Software GmbH Logo -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Jul 10 08:57:58 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 10 Jul 2019 08:57:58 -0400 Subject: [CMake] getting compiler's include paths In-Reply-To: References: Message-ID: I am not an user of ctags. But CMake supports generating a `compile_commands.json` for the Makefile and Ninja generator ( https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html ). That will have all the include directories for each target. On Sun, Jul 7, 2019 at 10:27 AM jl forums wrote: > > ok, thanks > by the way what about my ctags rule? how can i get the include path of an app? so that i can pass it to ctags and have my tags produced? > thanks and regards > jlm > > Le mer. 3 juil. 2019 ? 16:52, Robert Maynard a ?crit : >> >> I completely forgot that the Makefiles based generators in CMake have >> a separate heuristic for determining system headers. >> >> If you use the Ninja generator I see the expected behavior: >> ~/W/t/nbuild $ sudo touch /usr/include/c++/7/array >> ~/W/t/nbuild $ ninja -d explain -v >> ninja explain: output test/CMakeFiles/ProjTest.dir/test.cpp.o older >> than most recent input /usr/include/c++/7/array (1562165327 vs >> 1562165329) >> ninja explain: test/CMakeFiles/ProjTest.dir/test.cpp.o is dirty >> ninja explain: test/ProjTest is dirty >> [1/2] /usr/bin/c++ -I../my_lib/include -std=gnu++1z -MD -MT >> test/CMakeFiles/ProjTest.dir/test.cpp.o -MF >> test/CMakeFiles/ProjTest.dir/test.cpp.o.d -o >> test/CMakeFiles/ProjTest.dir/test.cpp.o -c ../test/test.cpp >> [2/2] : && /usr/bin/c++ test/CMakeFiles/ProjTest.dir/test.cpp.o >> -o test/ProjTest && : >> >> >> I will need to spend some more time figuring out the extra include >> caching logic for the Makefile based generators, and will report back. >> >> On Thu, Jun 27, 2019 at 8:59 AM jl forums wrote: >> > >> > thanks for the anwer.... >> > quite not... I'm using cmake 3.14.2 (so, far away from 3.6....) and have a look, in main.cpp, there is #include : >> > >> > $ find /usr/include/ -name filesystem >> > /usr/include/c++/5/experimental/filesystem >> > /usr/include/c++/7/experimental/filesystem >> > /usr/include/c++/8/filesystem >> > /usr/include/c++/8/experimental/filesystem >> > $ sudo touch /usr/include/c++/5/experimental/filesystem /usr/include/c++/7/experimental/filesystem /usr/include/c++/8/filesystem /usr/include/c++/8/experimental/filesystem >> > $ make >> > [100%] Built target FileSync >> > $ touch ../main.cxx >> > $ make >> > Scanning dependencies of target FileSync >> > [ 50%] Building CXX object CMakeFiles/FileSync.dir/main.cxx.o >> > [100%] Linking CXX executable FileSync >> > [100%] Built target FileSync >> > >> > >> > => cmake don't create "full include dependency" which IS a mistake.... updating system g++ can just assume the target is uptodate and in fact just create a broken build... >> > >> > in cmake cxx.includecache >> > >> > #IncludeRegexLine: ^[ ]*[#%][ ]*(include|import)[ ]*[<"]([^">]+)([">]) >> > #IncludeRegexScan: ^.*$ >> > #IncludeRegexComplain: ^$ >> > #IncludeRegexTransform: >> > /home/orange/crypt/Devel/projets/FileSync/main.cxx >> > cstdio >> > - >> > io.h >> > - >> > fcntl.h >> > - >> > locale >> > - >> > clocale >> > - >> > fstream >> > - >> > iostream >> > - >> > filesystem >> > - >> > >> > $ /usr/bin/gcc-8 -M ../main.cxx >> > main.o: ../main.cxx /usr/x86_64-linux-gnu/include/stdc-predef.h \ >> > /usr/include/c++/8/cstdio \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/c++config.h \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/os_defines.h \ >> > /usr/x86_64-linux-gnu/include/features.h \ >> > /usr/x86_64-linux-gnu/include/sys/cdefs.h \ >> > /usr/x86_64-linux-gnu/include/bits/wordsize.h \ >> > /usr/x86_64-linux-gnu/include/bits/long-double.h \ >> > /usr/x86_64-linux-gnu/include/gnu/stubs.h \ >> > /usr/x86_64-linux-gnu/include/gnu/stubs-64.h \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/cpu_defines.h \ >> > /usr/x86_64-linux-gnu/include/stdio.h \ >> > /usr/x86_64-linux-gnu/include/bits/libc-header-start.h \ >> > /usr/lib/gcc/x86_64-linux-gnu/8/include/stddef.h \ >> > /usr/x86_64-linux-gnu/include/bits/types.h \ >> > /usr/x86_64-linux-gnu/include/bits/typesizes.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/__FILE.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/FILE.h \ >> > /usr/x86_64-linux-gnu/include/bits/libio.h \ >> > /usr/x86_64-linux-gnu/include/bits/_G_config.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/__mbstate_t.h \ >> > /usr/lib/gcc/x86_64-linux-gnu/8/include/stdarg.h \ >> > /usr/x86_64-linux-gnu/include/bits/stdio_lim.h \ >> > /usr/x86_64-linux-gnu/include/bits/sys_errlist.h \ >> > /usr/include/c++/8/locale /usr/include/c++/8/bits/localefwd.h \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/c++locale.h \ >> > /usr/include/c++/8/clocale /usr/x86_64-linux-gnu/include/locale.h \ >> > /usr/x86_64-linux-gnu/include/bits/locale.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/locale_t.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/__locale_t.h \ >> > /usr/include/c++/8/iosfwd /usr/include/c++/8/bits/stringfwd.h \ >> > /usr/include/c++/8/bits/memoryfwd.h /usr/include/c++/8/bits/postypes.h \ >> > /usr/include/c++/8/cwchar /usr/x86_64-linux-gnu/include/wchar.h \ >> > /usr/x86_64-linux-gnu/include/bits/floatn.h \ >> > /usr/x86_64-linux-gnu/include/bits/floatn-common.h \ >> > /usr/x86_64-linux-gnu/include/bits/wchar.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/wint_t.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/mbstate_t.h \ >> > /usr/include/c++/8/cctype /usr/x86_64-linux-gnu/include/ctype.h \ >> > /usr/x86_64-linux-gnu/include/endian.h \ >> > /usr/x86_64-linux-gnu/include/bits/endian.h \ >> > /usr/x86_64-linux-gnu/include/bits/byteswap.h \ >> > /usr/x86_64-linux-gnu/include/bits/byteswap-16.h \ >> > /usr/x86_64-linux-gnu/include/bits/uintn-identity.h \ >> > /usr/include/c++/8/bits/locale_classes.h /usr/include/c++/8/string \ >> > /usr/include/c++/8/bits/char_traits.h \ >> > /usr/include/c++/8/bits/stl_algobase.h \ >> > /usr/include/c++/8/bits/functexcept.h \ >> > /usr/include/c++/8/bits/exception_defines.h \ >> > /usr/include/c++/8/bits/cpp_type_traits.h \ >> > /usr/include/c++/8/ext/type_traits.h \ >> > /usr/include/c++/8/ext/numeric_traits.h \ >> > /usr/include/c++/8/bits/stl_pair.h /usr/include/c++/8/bits/move.h \ >> > /usr/include/c++/8/bits/concept_check.h /usr/include/c++/8/type_traits \ >> > /usr/include/c++/8/bits/stl_iterator_base_types.h \ >> > /usr/include/c++/8/bits/stl_iterator_base_funcs.h \ >> > /usr/include/c++/8/debug/assertions.h \ >> > /usr/include/c++/8/bits/stl_iterator.h \ >> > /usr/include/c++/8/bits/ptr_traits.h /usr/include/c++/8/debug/debug.h \ >> > /usr/include/c++/8/bits/predefined_ops.h /usr/include/c++/8/cstdint \ >> > /usr/lib/gcc/x86_64-linux-gnu/8/include/stdint.h \ >> > /usr/x86_64-linux-gnu/include/stdint.h \ >> > /usr/x86_64-linux-gnu/include/bits/stdint-intn.h \ >> > /usr/x86_64-linux-gnu/include/bits/stdint-uintn.h \ >> > /usr/include/c++/8/bits/allocator.h \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/c++allocator.h \ >> > /usr/include/c++/8/ext/new_allocator.h /usr/include/c++/8/new \ >> > /usr/include/c++/8/exception /usr/include/c++/8/bits/exception.h \ >> > /usr/include/c++/8/bits/exception_ptr.h \ >> > /usr/include/c++/8/bits/cxxabi_init_exception.h \ >> > /usr/include/c++/8/typeinfo /usr/include/c++/8/bits/hash_bytes.h \ >> > /usr/include/c++/8/bits/nested_exception.h \ >> > /usr/include/c++/8/bits/ostream_insert.h \ >> > /usr/include/c++/8/bits/cxxabi_forced.h \ >> > /usr/include/c++/8/bits/stl_function.h \ >> > /usr/include/c++/8/backward/binders.h \ >> > /usr/include/c++/8/bits/range_access.h \ >> > /usr/include/c++/8/initializer_list \ >> > /usr/include/c++/8/bits/basic_string.h \ >> > /usr/include/c++/8/ext/atomicity.h \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/gthr.h \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/gthr-default.h \ >> > /usr/x86_64-linux-gnu/include/pthread.h \ >> > /usr/x86_64-linux-gnu/include/sched.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/time_t.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/struct_timespec.h \ >> > /usr/x86_64-linux-gnu/include/bits/sched.h \ >> > /usr/x86_64-linux-gnu/include/bits/cpu-set.h \ >> > /usr/x86_64-linux-gnu/include/time.h \ >> > /usr/x86_64-linux-gnu/include/bits/time.h \ >> > /usr/x86_64-linux-gnu/include/bits/timex.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/struct_timeval.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/clock_t.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/struct_tm.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/clockid_t.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/timer_t.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/struct_itimerspec.h \ >> > /usr/x86_64-linux-gnu/include/bits/pthreadtypes.h \ >> > /usr/x86_64-linux-gnu/include/bits/thread-shared-types.h \ >> > /usr/x86_64-linux-gnu/include/bits/pthreadtypes-arch.h \ >> > /usr/x86_64-linux-gnu/include/bits/setjmp.h \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/atomic_word.h \ >> > /usr/include/c++/8/ext/alloc_traits.h \ >> > /usr/include/c++/8/bits/alloc_traits.h \ >> > /usr/include/c++/8/ext/string_conversions.h /usr/include/c++/8/cstdlib \ >> > /usr/x86_64-linux-gnu/include/stdlib.h \ >> > /usr/x86_64-linux-gnu/include/bits/waitflags.h \ >> > /usr/x86_64-linux-gnu/include/bits/waitstatus.h \ >> > /usr/x86_64-linux-gnu/include/sys/types.h \ >> > /usr/x86_64-linux-gnu/include/sys/select.h \ >> > /usr/x86_64-linux-gnu/include/bits/select.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/sigset_t.h \ >> > /usr/x86_64-linux-gnu/include/bits/types/__sigset_t.h \ >> > /usr/x86_64-linux-gnu/include/sys/sysmacros.h \ >> > /usr/x86_64-linux-gnu/include/bits/sysmacros.h \ >> > /usr/x86_64-linux-gnu/include/alloca.h \ >> > /usr/x86_64-linux-gnu/include/bits/stdlib-float.h \ >> > /usr/include/c++/8/bits/std_abs.h /usr/include/c++/8/cerrno \ >> > /usr/x86_64-linux-gnu/include/errno.h \ >> > /usr/x86_64-linux-gnu/include/bits/errno.h \ >> > /usr/x86_64-linux-gnu/include/linux/errno.h \ >> > /usr/x86_64-linux-gnu/include/asm/errno.h \ >> > /usr/x86_64-linux-gnu/include/asm-generic/errno.h \ >> > /usr/x86_64-linux-gnu/include/asm-generic/errno-base.h \ >> > /usr/include/c++/8/bits/functional_hash.h \ >> > /usr/include/c++/8/bits/basic_string.tcc \ >> > /usr/include/c++/8/bits/locale_classes.tcc \ >> > /usr/include/c++/8/bits/locale_facets.h /usr/include/c++/8/cwctype \ >> > /usr/x86_64-linux-gnu/include/wctype.h \ >> > /usr/x86_64-linux-gnu/include/bits/wctype-wchar.h \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/ctype_base.h \ >> > /usr/include/c++/8/bits/ios_base.h /usr/include/c++/8/system_error \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/error_constants.h \ >> > /usr/include/c++/8/stdexcept /usr/include/c++/8/streambuf \ >> > /usr/include/c++/8/bits/streambuf.tcc \ >> > /usr/include/c++/8/bits/streambuf_iterator.h \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/ctype_inline.h \ >> > /usr/include/c++/8/bits/locale_facets.tcc \ >> > /usr/include/c++/8/bits/locale_facets_nonio.h /usr/include/c++/8/ctime \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/time_members.h \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/messages_members.h \ >> > /usr/x86_64-linux-gnu/include/libintl.h \ >> > /usr/include/c++/8/bits/codecvt.h \ >> > /usr/include/c++/8/bits/locale_facets_nonio.tcc \ >> > /usr/include/c++/8/bits/locale_conv.h \ >> > /usr/include/c++/8/bits/unique_ptr.h /usr/include/c++/8/utility \ >> > /usr/include/c++/8/bits/stl_relops.h /usr/include/c++/8/tuple \ >> > /usr/include/c++/8/array /usr/include/c++/8/bits/uses_allocator.h \ >> > /usr/include/c++/8/bits/invoke.h /usr/include/c++/8/fstream \ >> > /usr/include/c++/8/istream /usr/include/c++/8/ios \ >> > /usr/include/c++/8/bits/basic_ios.h \ >> > /usr/include/c++/8/bits/basic_ios.tcc /usr/include/c++/8/ostream \ >> > /usr/include/c++/8/bits/ostream.tcc /usr/include/c++/8/bits/istream.tcc \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/basic_file.h \ >> > /usr/include/x86_64-linux-gnu/c++/8/bits/c++io.h \ >> > /usr/include/c++/8/bits/fstream.tcc /usr/include/c++/8/iostream \ >> > /usr/include/c++/8/filesystem >> > >> > >> > amazing, no? cmake find only 9 dependencies against 100+ real ones (and I don't even speak of errors that can be caused in parsing if some -D option is changed.... >> > >> > thanks and regards >> > JLM >> > >> > >> > Le lun. 24 juin 2019 ? 14:14, Robert Maynard a ?crit : >> >> >> >> It look that starting with CMake 3.6 modification of system headers >> >> will cause CMake to recompile projects. What version of CMake and your >> >> compiler are you using? >> >> >> >> On Mon, Jun 17, 2019 at 9:40 AM jl forums wrote: >> >> > >> >> > Hi, >> >> > I want to create a full tag file and for this require to know the compiler full include path... there is a way to had custom includes path but didn't found any variables for the include path.... >> >> > for example : >> >> > $ gcc-8 -v -x c -E /dev/null >> >> > Using built-in specs. >> >> > [....] >> >> > ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" >> >> > #include "..." search starts here: >> >> > #include <...> search starts here: >> >> > /usr/lib/gcc/x86_64-linux-gnu/8/include >> >> > /usr/local/include >> >> > /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed >> >> > /usr/x86_64-linux-gnu/include >> >> > /usr/include/x86_64-linux-gnu >> >> > /usr/include >> >> > End of search list. >> >> > [...] >> >> > >> >> > $ gcc -v -x c -E /dev/null >> >> > Using built-in specs. >> >> > [...] >> >> > ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" >> >> > #include "..." search starts here: >> >> > #include <...> search starts here: >> >> > /usr/lib/gcc/x86_64-linux-gnu/7/include >> >> > /usr/local/include >> >> > /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed >> >> > /usr/x86_64-linux-gnu/include >> >> > /usr/include/x86_64-linux-gnu >> >> > /usr/include >> >> > End of search list. >> >> > [...] >> >> > >> >> > I tried to >> >> > >> >> > >> >> > get_target_property(moggle_interface_includes FileSync INTERFACE_INCLUDE_DIRECTORIES) >> >> > message("Moggle interface includes: ${moggle_interface_includes}") >> >> > >> >> > get_target_property(motor_includes FileSync INCLUDE_DIRECTORIES) >> >> > message("MOTOR includes ${motor_includes}") >> >> > >> >> > but I get >> >> > >> >> > Moggle interface includes: moggle_interface_includes-NOTFOUND >> >> > MOTOR includes motor_includes-NOTFOUND >> >> > >> >> > >> >> > there is also some issue because cmake strip dependencies from system's include, which means that updating a system software won't cause rebuild and consider that the build is uptodate, causing unexpected results >> >> > seems that there is ways to workaround this : https://stackoverflow.com/questions/7461000/handling-header-files-dependencies-with-cmake but this is ugly... would be better to let the user choose with an option >> >> > >> >> > thanks and regards >> >> > JLM >> >> > -- >> >> > >> >> > Powered by www.kitware.com >> >> > >> >> > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> > >> >> > Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> > >> >> > CMake Support: http://cmake.org/cmake/help/support.html >> >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >> > CMake Training Courses: http://cmake.org/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 ldalessa at uw.edu Wed Jul 10 09:14:31 2019 From: ldalessa at uw.edu (Luke D'Alessandro) Date: Wed, 10 Jul 2019 09:14:31 -0400 Subject: [CMake] FindBLAS + MKL + Ctest fails on MacOS (SIP) In-Reply-To: References: Message-ID: <1828E7CF-C63B-415F-B83C-626B5A4E4C2E@uw.edu> > On Jul 10, 2019, at 4:42 AM, Eric Doenges wrote: > > The simplest way to do this is to use the BUILD_RPATH and/or INSTALL_RPATH properties, i.e. something like: > > list(GET BLAS_LIBRARIES 0 _BLAS_FIRSTLIB) > get_filename_component(_BLAS_LIBDIR "${_BLAS_FIRSTLIB}" DIRECTORY > set_target_properties(test_blas PROPERTIES BUILD_RPATH "${_BLAS_LIBDIR}") > > This assumes BLAS_LIBRARIES is a list of libraries specified with absolute paths; if this assumption is incorrect, you must figure out the directory to specify to BUILD_RPATH some other way. If the tests are run using the installed binary (or you build your binaries using the install rpath from the start, like we do), then you must set INSTALL_RPATH instead of BUILD_RPATH. For a detailed description, see the CMake wiki page on RPATH handling . > > Also note that while I think this should work, I haven't actually tested it myself. > Thank you Eric, this does work. I have a large number of test executables and more are always being added by users, so I appended the result to the CMAKE_BUILD_RPATH in the test root directory and this results in the expected behavior. Luke > Am 09.07.19 um 16:22 schrieb Luke D'Alessandro: >> Hi all, >> >> I have one of those complex interactions that results in an issue where it?s not clear to me which component is responsible. >> >> I have unit tests written using CTest that depend on Intel's MKL BLAS implementation. I use find_package(BLAS) and link the test executables to ${BLAS_LIBRARIES}. The test executables depend on the DYLD_LIBRARY_PATH to find the mkl libraries, rather than an embedded LC_RPATH. >> >> Unfortunately, because of Apple?s SIP, the DYLD_LIBRARY_PATH is not propagated to the ctest environment, so when it tries to run the tests it fails to link the MKL libraries. >> >> I need to get CMake to embed an external LC_PATH for test executables in the build directory. >> >> Here's a basic test executable (test.cpp) >> >>> #include >>> >>> int main() { >>> return &cblas_dgemm != nullptr; >>> } >> >> and here is the associated CMakeLists.txt >> >>> cmake_minimum_required(VERSION 3.14.5) >>> >>> project(blas LANGUAGES CXX) >>> include(CTest) >>> >>> set(BLA_VENDOR Intel10_64lp_seq) >>> find_package(BLAS REQUIRED) >>> >>> add_executable(test_blas test.cpp) >>> target_link_libraries(test_blas ${BLAS_LIBRARIES}) >>> >>> add_test(NAME test_direct COMMAND test_blas) >> This finds MKL and builds and links the executable without any problem, and I can run it manually from my shell. But when I run with CTest I have the SIP issue because MacOS won?t propagate the necessary DYLD_LIBRARY_PATH into CTest?s environment. >> >>> Lukes-MacBook:test ldalessa$ make test >>> Running tests... >>> Test project /Users/ldalessa/test >>> Start 1: test_direct >>> 1/1 Test #1: test_direct ......................Child aborted***Exception: 0.01 sec >>> >>> 0% tests passed, 1 tests failed out of 1 >>> >>> Total Test time (real) = 0.01 sec >>> >>> The following tests FAILED: >>> 1 - test_direct (Child aborted) >>> Errors while running CTest >>> make: *** [test] Error 8 >> >>> Lukes-MacBook:test ldalessa$ cat Testing/Temporary/LastTest.log >>> Start testing: Jun 10 03:35 PDT >>> ---------------------------------------------------------- >>> 1/1 Testing: test_direct >>> 1/1 Test: test_direct >>> Command: "/Users/ldalessa/test/test_blas" >>> Directory: /Users/ldalessa/test >>> "test_direct" start time: Jun 10 03:35 PDT >>> Output: >>> ---------------------------------------------------------- >>> dyld: Library not loaded: @rpath/libmkl_intel_lp64.dylib >>> Referenced from: /Users/ldalessa/test/test_blas >>> Reason: image not found >>> >>> Test time = 0.01 sec >>> ---------------------------------------------------------- >>> Test Failed. >>> "test_direct" end time: Jun 10 03:35 PDT >>> "test_direct" time elapsed: 00:00:00 >>> ---------------------------------------------------------- >>> >>> End testing: Jun 10 03:35 PDT >>> Lukes-MacBook:test ldalessa$ >> My temporary workaround for this is currently to use Apple's Accelerate framework instead of MKL, which links using an embedded LC_PATH properly. The reason this isn?t adequate is that it is an intrusive solution. Intel's MKL uses different headers (mkl_blas.h, mkl_lapack.h) and symbol names which are explicitly used in the source code, so I have to have extra configure-time and configured header changes to adapt the code base to Accelerate. We also don?t (and won?t) have verified and validated code with Accelerate so it?s not a long term solution to our issues. Disabling SIP is also a non-starter. >> >> Thanks, >> Luke >> >> (https://stackoverflow.com/questions/56524774/how-to-use-ctest-on-macos-without-disabling-sip-no-lc-path-is-set ) >> >> >> > -- > Dr. Eric D?nges > Senior Software Engineer > > MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany > doenges at mvtec.com | Tel: +49 89 457 695-0 | www.mvtec.com > Sign up for our MVTec Newsletter! > > Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt > Amtsgericht M?nchen HRB 114695 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Jul 10 15:29:06 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 10 Jul 2019 15:29:06 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.15.0-rc4 is ready for testing Message-ID: I am proud to announce the fourth CMake 3.15 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.15 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.15/release/3.15.html Some of the more significant changes in CMake 3.15 are: * The "CMAKE_MSVC_RUNTIME_LIBRARY" variable and "MSVC_RUNTIME_LIBRARY" target property were introduced to select the runtime library used by compilers targeting the MSVC ABI. See policy "CMP0091". * With MSVC-like compilers the value of "CMAKE__FLAGS" no longer contains warning flags like "/W3" by default. See policy "CMP0092". * The "Clang" compiler variant on Windows that targets the MSVC ABI but has a GNU-like command line is now supported. * Preliminary support for the "Swift" language was added to the "Ninja" generator. * The "$" generator expression was introduced to allow specification of compile options for target files based on the "CMAKE__COMPILER_ID" and "LANGUAGE" of each source file. * The "generator expressions" "C_COMPILER_ID", "CXX_COMPILER_ID", "CUDA_COMPILER_ID", "Fortran_COMPILER_ID", "COMPILE_LANGUAGE", "COMPILE_LANG_AND_ID", and "PLATFORM_ID" learned to support matching one value from a comma-separated list. * The "CMAKE_FIND_PACKAGE_PREFER_CONFIG" variable was added to tell "find_package()" calls to look for a package configuration file first even if a find module is available. * The "PUBLIC_HEADER" and "PRIVATE_HEADER" properties may now be set on Interface Libraries. The headers specified by those properties can be installed using the "install(TARGETS)" command by passing the "PUBLIC_HEADER" and "PRIVATE_HEADER" arguments respectively. * The "CMAKE_VS_JUST_MY_CODE_DEBUGGING" variable and "VS_JUST_MY_CODE_DEBUGGING" target property were added to enable the Just My Code feature of the Visual Studio Debugger when compiling with MSVC cl 19.05 and higher. * The "FindBoost" module was reworked to expose a more consistent user experience between its ?Config? and ?Module? modes and with other find modules in general. * The "message()" command learned new types: "NOTICE", "VERBOSE", "DEBUG" and "TRACE". * The "export(PACKAGE)" command now does nothing unless enabled via "CMAKE_EXPORT_PACKAGE_REGISTRY". See policy "CMP0090". * The "CMAKE_GENERATOR" environment variable was added to specify a default generator to use when "cmake(1)" is run without a "-G" option. Additionally, environment variables "CMAKE_GENERATOR_PLATFORM", "CMAKE_GENERATOR_TOOLSET", and "CMAKE_GENERATOR_INSTANCE" were created to configure the generator. * The "cmake(1)" command gained a new "--install" option. This may be used after building a project to run installation without using the generated build system or the native build tool. * The "cmake(1)" command learned a new CLI option "--loglevel". * The "cmake-server(7)" mode has been deprecated and will be removed from a future version of CMake. Please port clients to use the "cmake-file-api(7)" instead. CMake 3.15 Release Notes ************************ Changes made since CMake 3.14 include the following. New Features ============ Generators ---------- * The "Xcode" generator now supports per-target schemes. See the "CMAKE_XCODE_GENERATE_SCHEME" variable and "XCODE_GENERATE_SCHEME" target property. * The "Green Hills MULTI" generator has been updated: * It now supports the "add_custom_command()" and "add_custom_target()" commands. * It is now available on Linux. Languages --------- * Preliminary support for the "Swift" language was added to the "Ninja" generator: * Use the "SWIFTC" environment variable to specify a compiler. * The "Swift_DEPENDENCIES_FILE" target property and "Swift_DEPENDENCIES_FILE" source file property were added to customize dependency files. * The "Swift_MODULE_NAME" target property was added to customize the Swift module name. * The "Swift_DIAGNOSTICS_FILE" source property was added to indicate where to write the serialised Swift diagnostics. The Swift support is experimental, not considered stable, and may change in future releases of CMake. Compilers --------- * The "Clang" compiler variant on Windows that targets the MSVC ABI but has a GNU-like command line is now supported. * Support for the Clang-based ARM compiler was added with compiler id "ARMClang". * Support was added for the IAR compiler architectures Renesas RX, RL78, RH850 and Texas Instruments MSP430. * Support was added for the IAR compilers built for Linux (IAR BuildLx). Command-Line ------------ * The "CMAKE_GENERATOR" environment variable was added to specify a default generator to use when "cmake(1)" is run without a "-G" option. Additionally, environment variables "CMAKE_GENERATOR_PLATFORM", "CMAKE_GENERATOR_TOOLSET", and "CMAKE_GENERATOR_INSTANCE" were created to configure the generator. * The "cmake(1)" "--build" tool "--target" parameter gained support for multiple targets, e.g. "cmake --build . --target Library1 Library2". It now also has a short form "-t" alias, e.g. "cmake --build . -t Library1 Library2". * The "cmake(1)" command gained a new "--install" option. This may be used after building a project to run installation without using the generated build system or the native build tool. * The "cmake(1)" command learned a new CLI option "--loglevel". * The "cmake(1)" "-E remove_directory" command-line tool learned to support removing multiple directories. * The "cmake(1)" "-E tar" tool has been improved: * It now continues adding files to an archive even if some of the files are not readable. This behavior is more consistent with the classic "tar" tool. * It now parses all flags, and if an invalid flag was provided, a warning is issued. * It now displays an error if no action flag was specified, along with a list of possible actions: "t" (list), "c" (create) or "x" (extract). * It now supports extracting ("-x") or listing ("-t") only specific files or directories. * It now supports Zstandard compression with a "--zstd" option. Zstandard was designed to give a compression ratio comparable to that of the DEFLATE (zip) algorithm, but faster, especially for decompression. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands gained a new "JOB_POOL" option that works with the "Ninja" generator to set the pool variable on the build statement. * The "add_library()" command "ALIAS" option learned to support import libraries of the "UNKNOWN" type. * The "cmake_parse_arguments()" command gained an additional "_KEYWORDS_MISSING_VALUES" output variable to report keyword arguments that were given by the caller with no values. * The "execute_process()" command gained a "COMMAND_ECHO" option and supporting "CMAKE_EXECUTE_PROCESS_COMMAND_ECHO" variable to enable echoing of the command-line string before execution. * The "file(INSTALL)" command learned a new argument, "FOLLOW_SYMLINK_CHAIN", which can be used to recursively resolve and install symlinks. * "list()" learned new sub-commands: "PREPEND", "POP_FRONT" and "POP_BACK". * The "message()" command learned new types: "NOTICE", "VERBOSE", "DEBUG" and "TRACE". * The "string()" learned a new sub-command "REPEAT". Variables --------- * The "CMAKE_CROSSCOMPILING_EMULATOR" variable and corresponding "CROSSCOMPILING_EMULATOR" target property learned to support arguments to the emulator. * The "CMAKE_FIND_PACKAGE_PREFER_CONFIG" variable was added to tell "find_package()" calls to look for a package configuration file first even if a find module is available. * The "CMAKE_FRAMEWORK" variable was added to initialize the "FRAMEWORK" property on all targets. * The "CMAKE_VS_JUST_MY_CODE_DEBUGGING" variable and "VS_JUST_MY_CODE_DEBUGGING" target property were added to enable the Just My Code feature of the Visual Studio Debugger when compiling with MSVC cl 19.05 and higher. * The "CMAKE_MSVC_RUNTIME_LIBRARY" variable and "MSVC_RUNTIME_LIBRARY" target property were introduced to select the runtime library used by compilers targeting the MSVC ABI. See policy "CMP0091". * The "CMAKE_PROJECT_INCLUDE" and "CMAKE_PROJECT_INCLUDE_BEFORE" variables were added to allow injection of custom code at the sites of "project()" calls without knowing the project name a priori. Properties ---------- * The "ADDITIONAL_CLEAN_FILES" target property and "ADDITIONAL_CLEAN_FILES" directory property were added. They allow to register additional files that should be removed during the clean stage. * The "PUBLIC_HEADER" and "PRIVATE_HEADER" properties may now be set on Interface Libraries. The headers specified by those properties can be installed using the "install(TARGETS)" command by passing the "PUBLIC_HEADER" and "PRIVATE_HEADER" arguments respectively. * The "VS_PACKAGE_REFERENCES" target property was added to tell Visual Studio Generators to add references to "nuget" packages. * The "VS_PROJECT_IMPORT" target property was added to allow managed Visual Studio project files to import external ".props" files. * The "VS_NO_SOLUTION_DEPLOY" target property was added to tell Visual Studio Generators whether to deploy an artifact to the WinCE or Windows Phone target device. Modules ------- * The "FindBoost" module was reworked to expose a more consistent user experience between its ?Config? and ?Module? modes and with other find modules in general. * A new imported target "Boost::headers" is now defined (same as "Boost::boost"). * New output variables "Boost_VERSION_MACRO", "Boost_VERSION_MAJOR", "Boost_VERSION_MINOR", "Boost_VERSION_PATCH", and "Boost_VERSION_COUNT" were added. * The "QUIET" argument passed to "find_package()" is no longer ignored in config mode. Note that the CMake package shipped with Boost "1.70.0" ignores the "QUIET" argument passed to "find_package()". This is fixed in the next Boost release. * The input switch "Boost_DETAILED_FAILURE_MSG" was removed. * "Boost_VERSION" now reports the version in "x.y.z" format in module mode. See policy "CMP0093". * The "FindCups" module now provides imported targets. * The "FindEnvModules" module was added to use Lua- and TCL-based environment modules in CTest Scripts. * The "FindGLEW" module now provides an interface more consistent with what upstream GLEW provides in its own CMake package files. * The "FindPkgConfig" now populates "INTERFACE_LINK_OPTIONS" property of imported targets with other (non-library) linker flags. * The "FindPostgreSQL" module learned to find debug and release variants separately. * Modules "FindPython3", "FindPython2" and "FindPython" gained additional lookup strategies and controls, and a new default. See policy "CMP0094". * Modules "FindPython", "FindPython2" and "FindPython3" gain a new target (respectively "Python::Module", "Python2::Module" and "Python3::Module") which can be used to develop Python modules. * Modules "FindPython3", "FindPython2" and "FindPython" gain capability to control how virtual environments are handled. * The "UseSWIG" module learned to manage alternate library names by passing "-interface " for "python" language or "-dllimport " for "CSharp" language to the "SWIG" compiler. Generator Expressions --------------------- * The "generator expressions" "C_COMPILER_ID", "CXX_COMPILER_ID", "CUDA_COMPILER_ID", "Fortran_COMPILER_ID", "COMPILE_LANGUAGE", "COMPILE_LANG_AND_ID", and "PLATFORM_ID" learned to support matching one value from a comma-separated list. * The "$" and "$" "generator expressions" were added. * The "$" generator expression was introduced to allow specification of compile options for target files based on the "CMAKE__COMPILER_ID" and "LANGUAGE" of each source file. * A "$" "generator expression" has been added. * A "$" "generator expression" has been added. * The "$" "generator expression" gained support for a list of paths. * New "$" "generator expressions" were added to retrieve the prefix, base name, and suffix of the file names of various artifacts: * "$" * "$" * "$" * "$" * "$" * "$" * "$" * The "$" "generator expression" is now supported on "SHARED", "STATIC", "MODULE" libraries and executables. CTest ----- * The "ctest_submit()" command learned a new option: "BUILD_ID". This can be used to store the ID assigned to this build by CDash to a variable. * The "ctest_update()" command learned to honor a new variable: "CTEST_UPDATE_VERSION_OVERRIDE". This can be used to specify the current version of your source tree rather than using the update command to discover the current version that is checked out. CPack ----- * The "CPack IFW Generator" gained a new "CPACK_IFW_PACKAGE_STYLE_SHEET" variable to customize the installer stylesheet. Deprecated and Removed Features =============================== * The "cmake-server(7)" mode has been deprecated and will be removed from a future version of CMake. Please port clients to use the "cmake-file-api(7)" instead. * The "ADDITIONAL_MAKE_CLEAN_FILES" directory property is now deprecated. Use the "ADDITIONAL_CLEAN_FILES" directory property instead. * The variable "CMAKE_AUTOMOC_RELAXED_MODE" is considered deprecated. Support still exists but will be removed in future versions. * The "export(PACKAGE)" command now does nothing unless enabled via "CMAKE_EXPORT_PACKAGE_REGISTRY". See policy "CMP0090". * The "Xcode" generator now requires at least Xcode 5. * An explicit deprecation diagnostic was added for policy "CMP0066" ("CMP0065" and below were already deprecated). The "cmake- policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors. Other Changes ============= * CMake learned how to compile C++14 with the IBM AIX XL compiler and the SunPro compiler and to compile C++20 with the AppleClang compiler. * With MSVC-like compilers the value of "CMAKE__FLAGS" no longer contains warning flags like "/W3" by default. See policy "CMP0092". * IBM Clang-based XL compilers that define "__ibmxl__" now use the compiler id "XLClang" instead of "XL". See policy "CMP0089". * The "file(REMOVE)" and "file(REMOVE_RECURSE)" commands were changed to ignore empty arguments with a warning instead of treating them as a relative path and removing the contents of the current directory. ---------------------------------------------------------------------------- Changes made since CMake 3.15.0-rc3: Alex Turbov (1): list(POP_FRONT): Fix always assigning first item to output vars Brad King (4): expat: Update script to get Expat 2.2.7 FindPostgreSQL: Fix regression in computation of library directory cmGlobalGenerator: Do not persist alias targets across configures CMake 3.15.0-rc4 Chuck Atkins (1): Cray: Fix include parsing when the -hlist= flag is present Craig Scott (8): Help: Remove self-references from project() docs Help: move code injection vars to their own section Help: Clean up trivial typos and grammar Help: Improve formatting of list(TRANSFORM) sub-options Help: Add missing xref for CMAKE_EXECUTE_PROCESS_COMMAND_ECHO Help: Clarify how to provide multiple targets with cmake --target Help: Remove mention of CMAKE_INSTALL_DO_STRIP Help: Use consistent levels for cmake --loglevel and message() Expat Upstream (1): expat 2019-06-19 (d3b78b42) Frank Dana (1): message() help: Clarify how logs are displayed in various tools Oleg Chernovskiy (1): Help: Discourage using CMAKE_SOURCE_DIR in toolchain files Robert Maynard (2): CUDA: Do not device link if CUDA is not an enabled language CUDA: Restore device linking to imported static library targets Sebastian Holtermann (2): Tests: Autogen: Use valid rcc compression levels QtDialog: Use QPalette::WindowText instead of QPalette::Foreground Stefan Andersson (1): IAR: Add support for the RISC-V compiler From hex7c3 at gmail.com Thu Jul 11 07:55:56 2019 From: hex7c3 at gmail.com (hex) Date: Thu, 11 Jul 2019 12:55:56 +0100 Subject: [CMake] CMake guidelines and design patterns - recommendations? Message-ID: hello community, Does anyone have a book recommendation for modern CMake with focus on design patterns? thank you From mateusz at loskot.net Thu Jul 11 10:43:09 2019 From: mateusz at loskot.net (Mateusz Loskot) Date: Thu, 11 Jul 2019 15:43:09 +0100 Subject: [CMake] CMake guidelines and design patterns - recommendations? In-Reply-To: References: Message-ID: https://crascit.com/professional-cmake/ And search for Daniel Pfeifer's talk on YouTube Mateusz Loskot, mateusz at loskot.net (Sent from mobile, may suffer from top-posting) On Thu, 11 Jul 2019, 12:56 hex, wrote: > hello community, > > > Does anyone have a book recommendation for modern CMake with focus on > design patterns? > > > 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 mailsik at gmail.com Thu Jul 11 12:16:48 2019 From: mailsik at gmail.com (Sik) Date: Thu, 11 Jul 2019 18:16:48 +0200 Subject: [CMake] CMake guidelines and design patterns - recommendations? In-Reply-To: References: Message-ID: https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/ On Thu, Jul 11, 2019 at 1:56 PM hex wrote: > hello community, > > > Does anyone have a book recommendation for modern CMake with focus on > design patterns? > > > 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 dustyn at blasig.us Fri Jul 12 13:11:03 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Fri, 12 Jul 2019 12:11:03 -0500 Subject: [CMake] test_compile with compiler flags Message-ID: Hi All, I'm sure there is a way to do this, but I'm not seeing it. I need to test a compiler flag to know whether to enable it for our entire build. So I had planned on using test_compile(), but I don't see a way to pass additional compiler flags to test_compile() through CMAKE_FLAGS and there's no option to pass environment variables like CXXFLAGS with test_compile(). Also, when do the variables like CMAKE_CXX_FLAGS get set? I enable the CXX language and specify a required support for C++11, but if I dump CMAKE_CXX_FLAGS right after that there are no options such as -std=c++11 in the variable. I thought I could do something like .. try_compile(.. CMAKE_FLAGS -DCMAKE_CXX_FLAGS="${CMAKE_CXX_FLAGS} " ..) ... but CMAKE_CXX_FLAGS is empty as described above so I get errors about the compiler not supported C++11 features since -std=c++11 wasn't set. Is there an example of testing a compiler flag I could try? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.herbert at gmail.com Sun Jul 14 00:58:16 2019 From: marc.herbert at gmail.com (Marc Herbert) Date: Sat, 13 Jul 2019 21:58:16 -0700 Subject: [CMake] In add_subdirectory( binary_dir), binary_dir/ is just a decoy when there's no sub-target In-Reply-To: References: Message-ID: Filed new bug https://gitlab.kitware.com/cmake/cmake/issues/19475 Le jeu. 13 juin 2019 ? 11:06, Marc Herbert a ?crit : > Ping? > > I'd like to file a bug but I don't know what is the intended behavior: > 1. Should binary_dir work even when no target? > 2. Should CMake warn/error that binary_dir is not supported unless targets > are used? > > Marc > > Le mar. 4 juin 2019 ? 12:05, Marc Herbert a > ?crit : > >> tl;dr: should there be at least one target per CMakeLists.txt? >> >> https://cmake.org/cmake/help/v3.14/command/add_subdirectory.html >> > add_subdirectory(source_dir [binary_dir] ) >> > "The binary_dir specifies the directory in which to place the output >> files. [...] If binary_dir is not specified, the value of source_dir, >> before expanding any relative path, will be used (the typical usage)." >> >> I found this part of the documentation to be correct ONLY when the >> subdirectory defines and uses its own "sub-"target(s). If the subdirectory >> refers to higher main targets instead then binary_dir/ is just a decoy: the >> subdirectory build happens elsewhere. binary_dir is a decoy whether it's >> explicit or default. It exists but there are only totally generic and >> unused files there. >> >> Example: >> >> mainsrc/ >> ??? CMakeLists.txt >> ??? inmodule >> ? ??? CMakeLists.txt >> ? ??? infile.c >> ??? mainfile.c >> >> >> # mainsrc/CMakeLists.txt >> add_executable(mainexe mainfile.c) >> add_subdirectory(inmodule [ decoy_binary_dir ] ) >> >> # mainsrc/inmodule/CMakeLists.txt >> target_sources(mainexe PRIVATE infile.c) # <= direct reference, no >> sub-target >> >> >> cmake -GNinja -B build -S mainsrc && ninja -C build >> >> build >> ??? CMakeFiles >> ? ??? >> ? ??? mainexe.dir >> ? ? ??? >> ? ? ??? >> ? ? ??? inmodule <= ACTUAL binary_dir! >> ? ? ? ??? infile.c.o >> ? ? ??? mainfile.c.o >> ? ? ??? >> ? ? : >> ? ??? >> ? : >> ??? inmodule <= decoy with unused, boilerplate files and no >> reference to any code >> ? ??? CMakeFiles/ >> ? ??? cmake_install.cmake >> >> >> The midly irritating part is that cmake complains about the lack of a >> binary_dir argument if the module is an _out-of-tree_ subdirectory: >> >> CMake Error at CMakeLists.txt:5 (add_subdirectory): >> add_subdirectory not given a binary directory but the given source >> directory "~/cmake-test/outmodule" is not a subdirectory of >> "~/cmake-test/maindir". When specifying an out-of-tree source >> a binary directory must be explicitly specified. >> >> That request makes sense of course except... when given that binary_dir >> argument it requested, it's still becomes a decoy as described above. >> This is the actual (and funny) binary_dir /in this out-of-tree case: >> build >> ??? CMakeFiles >> ? ??? mainexe.dir >> ? ? ??? home >> ? ? ??? joe >> ? ? ??? cmake-test >> ? ? ??? outmodule >> ? ? ??? outfile.c.o >> >> >> >> Reproduced with cmake version 3.14.4. No difference between make and >> ninja. >> >> Researching the interwebs most people, tutorials and other documents seem >> to assume (at least) one target per CMakeLists.txt. Should such a >> recommendation be made more official to avoid the sort of confusion above? >> Could this recommendation avoid other, unrelated problems I haven't >> experienced? Yet? >> >> Marc >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.herbert at gmail.com Sun Jul 14 01:09:51 2019 From: marc.herbert at gmail.com (Marc Herbert) Date: Sat, 13 Jul 2019 22:09:51 -0700 Subject: [CMake] Better way than: SET(CMAKE_C_ARCHIVE_CREATE " my_flags ... ? In-Reply-To: References: Message-ID: > Additional issue with this CMAKE_C_ARCHIVE_CREATE hack: it's ignored and > reverts back to the default in link.txt when building a "pure assembly" > library without any .c file. Adding an empty.c file works around the problem > Much better than adding an empty .c file: CMAKE_ASM_ARCHIVE_CREATE (resp. CMAKE_CXX_ARCHIVE_CREATE). Eventually I used: foreach(lang ASM C CXX) SET(CMAKE_${lang}_CREATE_STATIC_LIBRARY For the more general issue 2. below I filed https://gitlab.kitware.com/cmake/cmake/issues/19474 > Is this expected? Reproduced with CMake 3.13 and 3.14.0. > > > Le lun. 25 f?vr. 2019 ? 11:41, Marc Herbert a > ?crit : > >> Hi, >> >> 1. I found the hack below in the list's archive. However it seems... >> hackish. Among others it can't _append_ a flag, it can only replace all >> flags. Any newer and better way to append some extra flags? >> >> 2. Bonus question: how would you query "ar" and append some extra flags >> *only* when ar/ranlib are new enough to support them? >> >> Thanks in advance, >> >> Marc >> >> SET(CMAKE_C_ARCHIVE_CREATE " -qcD >> ") >> SET(CMAKE_C_ARCHIVE_FINISH " -D ") >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.herbert at gmail.com Sun Jul 14 01:44:08 2019 From: marc.herbert at gmail.com (Marc Herbert) Date: Sat, 13 Jul 2019 22:44:08 -0700 Subject: [CMake] how to set current source directory relative to external project In-Reply-To: <7cd82a98-28d7-e9c6-fc34-71ccda067d55@gmail.com> References: <89c38bb9-3652-d736-b215-9e667cfd29ef@gmail.com> <46cd942b-9ed8-4700-76e9-3d5ee916dbca@gmail.com> <76c24e7c-b766-d620-98c6-58934033b7ba@gmail.com> <7cd82a98-28d7-e9c6-fc34-71ccda067d55@gmail.com> Message-ID: Le mar. 9 juil. 2019 ? 13:24, hex a ?crit : > Now that I look at it it seems very obvious. I still have doubts, though: > > I guess I am seeing the contents of a build directory as somewhat > volatile. For most files I want that, to either clean the project or > override the files. > > But what about files I want to archive, such as a tarball or zipped > documentation: does it make sense to place them into the build directory? > The files belong to the project, though are not source controlled but > aren't install targets either. > How would CMake know that these tarballs are in a somewhat final version that you want to archive as opposed to a state where they haven't passed the most basic tests yet? I would implement this outside CMake: wherever is the information that guides the decision to archive. When that decision is made then some script would simply "exfiltrate" the tarballs and whatever else from the build/ directory before it gets cleaned. Sounds like something CI does every day. This being said, CPack seems to have a ton of documented and undocumented (read: Stackoverflow) options, hopefully some of them do what you want. Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.herbert at gmail.com Sun Jul 14 02:03:24 2019 From: marc.herbert at gmail.com (Marc Herbert) Date: Sat, 13 Jul 2019 23:03:24 -0700 Subject: [CMake] How to support separate debug and release build directories? In-Reply-To: References: <7b2d439f47066596b5693479bf39737c543633d9.camel@endoframe.com> Message-ID: Le ven. 21 juin 2019 ? 11:40, Michael Jackson a ?crit : > > cd Foo > > mkdir Debug && cd Debug > > cmake -DCMAKE_BUILD_TYPE=Debug ../ > > make -j > > > > We have just created a Debug build in the Debug Directory. Now, the same > is analogous for the Release build. > > > > Cd Foo > > Mkdir Release && cd Release > > Cmake -DCMAKE_BUILD_TYPE=Release ../ > > Make -j > > > Or, from CMake 3.13, simpler: cd foo cmake -B release/ -DCMAKE_BUILD_TYPE=Release cmake -B debug/ -DCMAKE_BUILD_TYPE=Debug make -j -C build & make -j -C debug > I am not finding it easy to find 'patterns' for these sort of issues. I > would have thought that configuring a project with separate debug and > release directories would be quite typical. But it's hard to find the > recommended way of doing such things. > It is typical: https://gitlab.kitware.com/cmake/community/wikis/FAQ#what-is-an-out-of-source-build In this case CMake doesn't recommend anything because it assumes this is implemented outside/on top of CMake https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.herbert at gmail.com Sun Jul 14 02:27:57 2019 From: marc.herbert at gmail.com (Marc Herbert) Date: Sat, 13 Jul 2019 23:27:57 -0700 Subject: [CMake] How to support separate debug and release build directories? In-Reply-To: References: <7b2d439f47066596b5693479bf39737c543633d9.camel@endoframe.com> Message-ID: > > >> I am not finding it easy to find 'patterns' for these sort of issues. I >> would have thought that configuring a project with separate debug and >> release directories would be quite typical. But it's hard to find the >> recommended way of doing such things. >> > > It is typical: > https://gitlab.kitware.com/cmake/community/wikis/FAQ#what-is-an-out-of-source-build > > In this case CMake doesn't recommend anything because it assumes this is > implemented outside/on top of CMake > https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html > > Finally found it while looking for something else: https://gitlab.kitware.com/cmake/community/wikis/FAQ#how-can-i-build-multiple-modes-without-switching- -------------- next part -------------- An HTML attachment was scrubbed... URL: From benshadwick at gmail.com Mon Jul 15 13:15:33 2019 From: benshadwick at gmail.com (Benjamin Shadwick) Date: Mon, 15 Jul 2019 10:15:33 -0700 Subject: [CMake] Shortcomings with exporting and importing targets Message-ID: I'd like to discuss some shortcomings of CMake with regards to sharing targets among projects. Other people have brought this up on this mailing list in the past, but there has never been any useful feedback on it. I'm going to refer to two projects: - "Project A" produces some libraries - "Project B" depends on libraries and headers from Project A First I'll discuss the easier scenario: Project A is built and installed ahead of time, and is therefore already present as a complete installation before Project B is configured. In the case that some of Project A's libraries are produced via ExternalProject_Add() (e.g. due to the lack of a CMake build system, or because they are dependencies of Project A's core code), CMake's install(TARGETS ...) does not support re-exporting shared imported library targets+properties. I've worked around this by writing my own CMake functions that invoke file() to generate CMake modules containing target import and property set commands. I also use file() to generate a CMake package config that loads the target import module. I was careful to base everything on CMAKE_CURRENT_LIST_DIR, so that the installation is portable. This solution works great: Project B is able to do a find_package(ProjectA CONFIG) to get all the targets+properties for the libraries and headers in the Project A install, reducing Project B's build system dependence on Project A to a few target_link_libraries() commands referencing the imported targets. I don't even need to explicitly mention the Project A header directories anywhere in Project B, because CMake takes care of it via target properties. Of course, this is still non-optimal because I now have a wacky target re-export function to maintain in Project A. It would be better if CMake would just handle things for me via install(TARGETS ...) or similar. Now comes the more difficult case: I want to create a super-build Project X that builds both Project A and Project B. My first instinct is to use ExternalProject_Add() to build Project A, because developers of Project X and/or B don't care about its source code - they only care about the headers and libraries. Unfortunately this is a complete non-starter, because ExternalProject_Add() doesn't invoke any part of Project A's build system until the *build* step of Project X, which means that we'll never get the package config stuff in time for Project B's configure step. OK, so let's resign ourselves to the fact that we have to use add_subdirectory() to build Project A, polluting Project X both with Project A's source and its CMake cache variables. This is *still* not going to work (yet), because CMake bafflingly *only* flows first-class (add_library()/add_executable()) targets upwards from Project A to Project X & B and does *not* flow import targets upwards! I'm not sure this is documented anywhere, but I have convinced myself that it is absolutely the case in CMake 3.12.2. So we can't use the Project A's native import targets even though we're doing add_subdirectory() in Project X. What can we do? My approach was to modify Project A as follows: 1. Extend my import target + package config functions to support writing either build tree or install flavored modules. 2. Generate the install flavored modules with an "INSTALL-" prefix on their filenames, and have install() rename them on install. 3. Generate build flavored modules in the build tree during the CMake configure step. I then modified Project X to add the build directory to CMAKE_PREFIX_PATH, and Project B was able to load Package A's modules via find_package(ProjectA CONFIG). This almost got everything working, but there was one final bump: Parallel building fails with an error that Project B cannot find Project A's libraries! This is because Project B is now using a separate set of import targets defined by modules produced by Project A, which do not tie back to the *actual* targets being used to build Project A! Oof. Fortunately, it turns out that ExternalProject_Add() targets *do* flow upwards to Project X and back down to Project B, even though the imported library targets do not. This means I was able to modify Project A's target import module generator function to include add_dependencies() commands - in the build-flavored module only! - that tie the targets imported by Project B to the ExternalProject_Add() targets in Project A. This also means that Project B can use a pre-build+installed Project A without any changes to the former's build system. Now take a step back and look at how much text I just wrote, all because CMake has the following limitations that I had to overcome: 1. install() does not support re-exporting imported library targets+properties. 2. ExternalProject_Add() doesn't do anything until the build step (NOTE: I understand why this is the case, and also that there are ugly workarounds). 3. Sub-projects pulled in via add_subdirectory() do not flow imported library targets upwards, even though add_library(), add_executable(), and ExternalProject_Add() targets *do* flow upwards. 4. When a project creates imported library targets based on libraries produced by another project in the hierarchy, CMake is not smart enough to detect this and adjust the target dependency tree. It would be really nice if CMake could do something to address items 1 and 3. For item 2, it might be nice to get an option in ExternalProject_Add() that allows running its configure step during the configure step of the parent project. Item 4 could be rendered OBE by addressing the other items. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Jul 16 13:43:44 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 16 Jul 2019 13:43:44 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.14.6 available for download Message-ID: We are pleased to announce that CMake 3.14.6 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.14.6 since 3.14.5: Brad King (1): CMake 3.14.6 Brian Carlson (1): FindBISON: Fix CMP0088 NEW behavior for non-absolute input paths Chuck Atkins (1): Cray: Fix include parsing when the -hlist= flag is present Marc Chevrier (1): Android: ensure PIE behavior is consistent regardless CMP0083 policy From dustyn at blasig.us Tue Jul 16 22:58:46 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Tue, 16 Jul 2019 21:58:46 -0500 Subject: [CMake] FetchContent/ExternalProject and URL_HASH Message-ID: Hi All, We are pulling some artifacts from Artifactory which provides a checksum file along with the artifacts at .md5 or .sha256. If I do not include URL_HASH, does CMake automatically check to see if such a checksum file exists and use it's value for the hash check? Or is there a way to provide a URL for the checksum file rather than having to do file(DOWNLOAD ), file(STRING ), URL_HASH=? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hex7c3 at gmail.com Wed Jul 17 09:38:56 2019 From: hex7c3 at gmail.com (hex) Date: Wed, 17 Jul 2019 14:38:56 +0100 Subject: [CMake] question about version details in source code Message-ID: <034d2fb6-49d2-19bf-9c3b-1c088a5a8597@gmail.com> hello community, I am receiving a|fatal error: foobar_version.h: No such file or directory|for|foobar_version.h|. The reason is that the source file is generated in|${CMAKE_CURRENT_BINARY_DIR}/foobar_version.cpp|while the header file is in|${CMAKE_CURRENT_SOURCE_DIR}|as seen here: 1234|configure_file(foobar_version.cpp.in foobar_version.cpp @ONLY) # configure_file(foobar_version.h foobar_version.h @ONLY) add_library(foobar_version STATIC ${CMAKE_CURRENT_BINARY_DIR}/foobar_version.cpp) |// In the source I simply|#include "foobar_version.h"|but the file is in a different location. Why is this|CMakeLists.txt|file placing the files in different locations? What should I do about it? ------------------------------------------------------------------------ also, what is the purpose of|mylib.cpp|, I had to create it otherwise I receive:|No SOURCES given to target: fooToolkit|. The build is successful but my file is currently empty. Here are all build steps: 123456789|configure_file(foobar_version.cpp.in foobar_version.cpp @ONLY) configure_file(foobar_version.h foobar_version.h @ONLY) add_library(foobar_version STATIC ${CMAKE_CURRENT_BINARY_DIR}/foobar_version.cpp) add_executable(foobar main.cpp) target_link_libraries(foobar PRIVATE foobar_version) add_library(fooToolkit mylib.cpp) target_link_libraries(fooToolkit PRIVATE foobar_version) |// ------------------------------------------------------------------------ thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.herbert at gmail.com Wed Jul 17 10:38:05 2019 From: marc.herbert at gmail.com (Marc Herbert) Date: Wed, 17 Jul 2019 07:38:05 -0700 Subject: [CMake] cmake - two targets that depends on single static library that should be compiled based on the target that is being built In-Reply-To: References: Message-ID: > > > I have a static library and two target executables, let's call them > **libA**, **EXE1**, **EXE2**. > > If I am building EXE2, I need to disabled the macros in libA and don't > link to another library. > [...] > I don't want to create two targets with same source files. > I'm curious why you wanted two executable targets but not the corresponding two library targets, I don't think you said why. I would have thought you'd want A. either to be able to build both configurations at the same time, B. or one project configuration at a time. So why want A for executables but B for libraries? -------------- next part -------------- An HTML attachment was scrubbed... URL: From doenges at mvtec.com Wed Jul 17 10:44:16 2019 From: doenges at mvtec.com (Eric Doenges) Date: Wed, 17 Jul 2019 16:44:16 +0200 Subject: [CMake] question about version details in source code In-Reply-To: <034d2fb6-49d2-19bf-9c3b-1c088a5a8597@gmail.com> References: <034d2fb6-49d2-19bf-9c3b-1c088a5a8597@gmail.com> Message-ID: Am 17.07.19 um 15:38 schrieb hex: > > hello community, > > I am receiving a|fatal error: foobar_version.h: No such file or > directory|for|foobar_version.h|. The reason is that the source file is > generated in|${CMAKE_CURRENT_BINARY_DIR}/foobar_version.cpp|while the > header file is in|${CMAKE_CURRENT_SOURCE_DIR}|as seen here: > > 1234|configure_file(foobar_version.cpp.in foobar_version.cpp @ONLY) # > configure_file(foobar_version.h foobar_version.h @ONLY) > add_library(foobar_version STATIC > ${CMAKE_CURRENT_BINARY_DIR}/foobar_version.cpp) |// > > In the source I simply|#include "foobar_version.h"|but the file is in > a different location. > > Why is this|CMakeLists.txt|file placing the files in different > locations? What should I do about it? > Nothing. You really want to keep source and build directories seperate, which means you do not want to generate files into the source directory. Instead, add the CMAKE_CURRENT_SOURCE_DIR to the include search path of any target that needs to include foobar_version.h using any one of: 1) the include_directories command 2) the target_include_directories command 3) the CMAKE_INCLUDE_CURRENT_DIR variable > ------------------------------------------------------------------------ > > also, what is the purpose of|mylib.cpp|, I had to create it otherwise > I receive:|No SOURCES given to target: fooToolkit|. The build is > successful but my file is currently empty. Here are all build steps: > > 123456789|configure_file(foobar_version.cpp.in foobar_version.cpp > @ONLY) configure_file(foobar_version.h foobar_version.h @ONLY) > add_library(foobar_version STATIC > ${CMAKE_CURRENT_BINARY_DIR}/foobar_version.cpp) add_executable(foobar > main.cpp) target_link_libraries(foobar PRIVATE foobar_version) > add_library(fooToolkit mylib.cpp) target_link_libraries(fooToolkit > PRIVATE foobar_version) |// > ------------------------------------------------------------------------ I'm not sure what you are trying to accomplish with the fooToolkit target. If you want to create a library without sources for its properties (because you have a header-only library, for example), the correct way is to create an INTERFACE library, like so: add_library(fooToolkit INTERFACE) As a final note, I would strongly suggest you read the fine manual when you get errors from CMake - the documentation is actually pretty good when used as a reference and would have answered both of your questions. -- *Dr. Eric D?nges * Senior Software Engineer MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany doenges at mvtec.com | Tel: +49 89 457 695-0 | www.mvtec.com Sign up for our MVTec Newsletter! Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt Amtsgericht M?nchen HRB 114695 MVTec Software GmbH Logo -------------- next part -------------- An HTML attachment was scrubbed... URL: From hex7c3 at gmail.com Wed Jul 17 11:29:24 2019 From: hex7c3 at gmail.com (hex) Date: Wed, 17 Jul 2019 16:29:24 +0100 Subject: [CMake] relative path to toolchain does not work Message-ID: <023beb57-cd4e-7570-6d7d-607fb60f3f8e@gmail.com> I specified my toolchain like so: 1|cmake -DCMAKE_TOOLCHAIN_FILE=myToolchain.cmake .. |// and created a toolchain file in|project/myToolchain.cmake|. Using relative path CMake first looks relative to the top of the build directory, then if not found there, relative to the top of the source directory. What means ?the top of the source directory?? I placed the file in the source directory and receive: 1234|CMake Warning: Manually-specified variables were not used by the project: CMAKE_TOOLCHAIN_FILE| -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Jul 17 11:56:46 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 17 Jul 2019 11:56:46 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.15.0 available for download Message-ID: I am happy to announce that CMake 3.15.0 is now available for download at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.15 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.15/release/3.15.html Some of the more significant changes in CMake 3.15 are: * The "CMAKE_MSVC_RUNTIME_LIBRARY" variable and "MSVC_RUNTIME_LIBRARY" target property were introduced to select the runtime library used by compilers targeting the MSVC ABI. See policy "CMP0091". * With MSVC-like compilers the value of "CMAKE__FLAGS" no longer contains warning flags like "/W3" by default. See policy "CMP0092". * The "Clang" compiler variant on Windows that targets the MSVC ABI but has a GNU-like command line is now supported. * Preliminary support for the "Swift" language was added to the "Ninja" generator. * The "$" generator expression was introduced to allow specification of compile options for target files based on the "CMAKE__COMPILER_ID" and "LANGUAGE" of each source file. * The "generator expressions" "C_COMPILER_ID", "CXX_COMPILER_ID", "CUDA_COMPILER_ID", "Fortran_COMPILER_ID", "COMPILE_LANGUAGE", "COMPILE_LANG_AND_ID", and "PLATFORM_ID" learned to support matching one value from a comma-separated list. * The "CMAKE_FIND_PACKAGE_PREFER_CONFIG" variable was added to tell "find_package()" calls to look for a package configuration file first even if a find module is available. * The "PUBLIC_HEADER" and "PRIVATE_HEADER" properties may now be set on Interface Libraries. The headers specified by those properties can be installed using the "install(TARGETS)" command by passing the "PUBLIC_HEADER" and "PRIVATE_HEADER" arguments respectively. * The "CMAKE_VS_JUST_MY_CODE_DEBUGGING" variable and "VS_JUST_MY_CODE_DEBUGGING" target property were added to enable the Just My Code feature of the Visual Studio Debugger when compiling with MSVC cl 19.05 and higher. * The "FindBoost" module was reworked to expose a more consistent user experience between its ?Config? and ?Module? modes and with other find modules in general. * The "message()" command learned new types: "NOTICE", "VERBOSE", "DEBUG" and "TRACE". * The "export(PACKAGE)" command now does nothing unless enabled via "CMAKE_EXPORT_PACKAGE_REGISTRY". See policy "CMP0090". * The "CMAKE_GENERATOR" environment variable was added to specify a default generator to use when "cmake(1)" is run without a "-G" option. Additionally, environment variables "CMAKE_GENERATOR_PLATFORM", "CMAKE_GENERATOR_TOOLSET", and "CMAKE_GENERATOR_INSTANCE" were created to configure the generator. * The "cmake(1)" command gained a new "--install" option. This may be used after building a project to run installation without using the generated build system or the native build tool. * The "cmake(1)" command learned a new CLI option "--loglevel". * The "cmake-server(7)" mode has been deprecated and will be removed from a future version of CMake. Please port clients to use the "cmake-file-api(7)" instead. CMake 3.15 Release Notes ************************ Changes made since CMake 3.14 include the following. New Features ============ Generators ---------- * The "Xcode" generator now supports per-target schemes. See the "CMAKE_XCODE_GENERATE_SCHEME" variable and "XCODE_GENERATE_SCHEME" target property. * The "Green Hills MULTI" generator has been updated: * It now supports the "add_custom_command()" and "add_custom_target()" commands. * It is now available on Linux. Languages --------- * Preliminary support for the "Swift" language was added to the "Ninja" generator: * Use the "SWIFTC" environment variable to specify a compiler. * The "Swift_DEPENDENCIES_FILE" target property and "Swift_DEPENDENCIES_FILE" source file property were added to customize dependency files. * The "Swift_MODULE_NAME" target property was added to customize the Swift module name. * The "Swift_DIAGNOSTICS_FILE" source property was added to indicate where to write the serialised Swift diagnostics. The Swift support is experimental, not considered stable, and may change in future releases of CMake. Compilers --------- * The "Clang" compiler variant on Windows that targets the MSVC ABI but has a GNU-like command line is now supported. * Support for the Clang-based ARM compiler was added with compiler id "ARMClang". * Support was added for the IAR compiler architectures Renesas RX, RL78, RH850 and Texas Instruments MSP430. * Support was added for the IAR compilers built for Linux (IAR BuildLx). Command-Line ------------ * The "CMAKE_GENERATOR" environment variable was added to specify a default generator to use when "cmake(1)" is run without a "-G" option. Additionally, environment variables "CMAKE_GENERATOR_PLATFORM", "CMAKE_GENERATOR_TOOLSET", and "CMAKE_GENERATOR_INSTANCE" were created to configure the generator. * The "cmake(1)" "--build" tool "--target" parameter gained support for multiple targets, e.g. "cmake --build . --target Library1 Library2". It now also has a short form "-t" alias, e.g. "cmake --build . -t Library1 Library2". * The "cmake(1)" command gained a new "--install" option. This may be used after building a project to run installation without using the generated build system or the native build tool. * The "cmake(1)" command learned a new CLI option "--loglevel". * The "cmake(1)" "-E remove_directory" command-line tool learned to support removing multiple directories. * The "cmake(1)" "-E tar" tool has been improved: * It now continues adding files to an archive even if some of the files are not readable. This behavior is more consistent with the classic "tar" tool. * It now parses all flags, and if an invalid flag was provided, a warning is issued. * It now displays an error if no action flag was specified, along with a list of possible actions: "t" (list), "c" (create) or "x" (extract). * It now supports extracting ("-x") or listing ("-t") only specific files or directories. * It now supports Zstandard compression with a "--zstd" option. Zstandard was designed to give a compression ratio comparable to that of the DEFLATE (zip) algorithm, but faster, especially for decompression. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands gained a new "JOB_POOL" option that works with the "Ninja" generator to set the pool variable on the build statement. * The "add_library()" command "ALIAS" option learned to support import libraries of the "UNKNOWN" type. * The "cmake_parse_arguments()" command gained an additional "_KEYWORDS_MISSING_VALUES" output variable to report keyword arguments that were given by the caller with no values. * The "execute_process()" command gained a "COMMAND_ECHO" option and supporting "CMAKE_EXECUTE_PROCESS_COMMAND_ECHO" variable to enable echoing of the command-line string before execution. * The "file(INSTALL)" command learned a new argument, "FOLLOW_SYMLINK_CHAIN", which can be used to recursively resolve and install symlinks. * "list()" learned new sub-commands: "PREPEND", "POP_FRONT" and "POP_BACK". * The "message()" command learned new types: "NOTICE", "VERBOSE", "DEBUG" and "TRACE". * The "string()" learned a new sub-command "REPEAT". Variables --------- * The "CMAKE_CROSSCOMPILING_EMULATOR" variable and corresponding "CROSSCOMPILING_EMULATOR" target property learned to support arguments to the emulator. * The "CMAKE_FIND_PACKAGE_PREFER_CONFIG" variable was added to tell "find_package()" calls to look for a package configuration file first even if a find module is available. * The "CMAKE_FRAMEWORK" variable was added to initialize the "FRAMEWORK" property on all targets. * The "CMAKE_VS_JUST_MY_CODE_DEBUGGING" variable and "VS_JUST_MY_CODE_DEBUGGING" target property were added to enable the Just My Code feature of the Visual Studio Debugger when compiling with MSVC cl 19.05 and higher. * The "CMAKE_MSVC_RUNTIME_LIBRARY" variable and "MSVC_RUNTIME_LIBRARY" target property were introduced to select the runtime library used by compilers targeting the MSVC ABI. See policy "CMP0091". * The "CMAKE_PROJECT_INCLUDE" and "CMAKE_PROJECT_INCLUDE_BEFORE" variables were added to allow injection of custom code at the sites of "project()" calls without knowing the project name a priori. Properties ---------- * The "ADDITIONAL_CLEAN_FILES" target property and "ADDITIONAL_CLEAN_FILES" directory property were added. They allow to register additional files that should be removed during the clean stage. * The "PUBLIC_HEADER" and "PRIVATE_HEADER" properties may now be set on Interface Libraries. The headers specified by those properties can be installed using the "install(TARGETS)" command by passing the "PUBLIC_HEADER" and "PRIVATE_HEADER" arguments respectively. * The "VS_PACKAGE_REFERENCES" target property was added to tell Visual Studio Generators to add references to "nuget" packages. * The "VS_PROJECT_IMPORT" target property was added to allow managed Visual Studio project files to import external ".props" files. * The "VS_NO_SOLUTION_DEPLOY" target property was added to tell Visual Studio Generators whether to deploy an artifact to the WinCE or Windows Phone target device. Modules ------- * The "FindBoost" module was reworked to expose a more consistent user experience between its ?Config? and ?Module? modes and with other find modules in general. * A new imported target "Boost::headers" is now defined (same as "Boost::boost"). * New output variables "Boost_VERSION_MACRO", "Boost_VERSION_MAJOR", "Boost_VERSION_MINOR", "Boost_VERSION_PATCH", and "Boost_VERSION_COUNT" were added. * The "QUIET" argument passed to "find_package()" is no longer ignored in config mode. Note that the CMake package shipped with Boost "1.70.0" ignores the "QUIET" argument passed to "find_package()". This is fixed in the next Boost release. * The input switch "Boost_DETAILED_FAILURE_MSG" was removed. * "Boost_VERSION" now reports the version in "x.y.z" format in module mode. See policy "CMP0093". * The "FindCups" module now provides imported targets. * The "FindEnvModules" module was added to use Lua- and TCL-based environment modules in CTest Scripts. * The "FindGLEW" module now provides an interface more consistent with what upstream GLEW provides in its own CMake package files. * The "FindPkgConfig" now populates "INTERFACE_LINK_OPTIONS" property of imported targets with other (non-library) linker flags. * The "FindPostgreSQL" module learned to find debug and release variants separately. * Modules "FindPython3", "FindPython2" and "FindPython" gained additional lookup strategies and controls, and a new default. See policy "CMP0094". * Modules "FindPython", "FindPython2" and "FindPython3" gain a new target (respectively "Python::Module", "Python2::Module" and "Python3::Module") which can be used to develop Python modules. * Modules "FindPython3", "FindPython2" and "FindPython" gain capability to control how virtual environments are handled. * The "UseSWIG" module learned to manage alternate library names by passing "-interface " for "python" language or "-dllimport " for "CSharp" language to the "SWIG" compiler. Generator Expressions --------------------- * The "generator expressions" "C_COMPILER_ID", "CXX_COMPILER_ID", "CUDA_COMPILER_ID", "Fortran_COMPILER_ID", "COMPILE_LANGUAGE", "COMPILE_LANG_AND_ID", and "PLATFORM_ID" learned to support matching one value from a comma-separated list. * The "$" and "$" "generator expressions" were added. * The "$" generator expression was introduced to allow specification of compile options for target files based on the "CMAKE__COMPILER_ID" and "LANGUAGE" of each source file. * A "$" "generator expression" has been added. * A "$" "generator expression" has been added. * The "$" "generator expression" gained support for a list of paths. * New "$" "generator expressions" were added to retrieve the prefix, base name, and suffix of the file names of various artifacts: * "$" * "$" * "$" * "$" * "$" * "$" * "$" * The "$" "generator expression" is now supported on "SHARED", "STATIC", "MODULE" libraries and executables. CTest ----- * The "ctest_submit()" command learned a new option: "BUILD_ID". This can be used to store the ID assigned to this build by CDash to a variable. * The "ctest_update()" command learned to honor a new variable: "CTEST_UPDATE_VERSION_OVERRIDE". This can be used to specify the current version of your source tree rather than using the update command to discover the current version that is checked out. CPack ----- * The "CPack IFW Generator" gained a new "CPACK_IFW_PACKAGE_STYLE_SHEET" variable to customize the installer stylesheet. Deprecated and Removed Features =============================== * The "cmake-server(7)" mode has been deprecated and will be removed from a future version of CMake. Please port clients to use the "cmake-file-api(7)" instead. * The "ADDITIONAL_MAKE_CLEAN_FILES" directory property is now deprecated. Use the "ADDITIONAL_CLEAN_FILES" directory property instead. * The variable "CMAKE_AUTOMOC_RELAXED_MODE" is considered deprecated. Support still exists but will be removed in future versions. * The "export(PACKAGE)" command now does nothing unless enabled via "CMAKE_EXPORT_PACKAGE_REGISTRY". See policy "CMP0090". * The "Xcode" generator now requires at least Xcode 5. * An explicit deprecation diagnostic was added for policy "CMP0066" ("CMP0065" and below were already deprecated). The "cmake- policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors. Other Changes ============= * CMake learned how to compile C++14 with the IBM AIX XL compiler and the SunPro compiler and to compile C++20 with the AppleClang compiler. * With MSVC-like compilers the value of "CMAKE__FLAGS" no longer contains warning flags like "/W3" by default. See policy "CMP0092". * IBM Clang-based XL compilers that define "__ibmxl__" now use the compiler id "XLClang" instead of "XL". See policy "CMP0089". * The "file(REMOVE)" and "file(REMOVE_RECURSE)" commands were changed to ignore empty arguments with a warning instead of treating them as a relative path and removing the contents of the current directory. ---------------------------------------------------------------------------- Changes made since CMake 3.15.0-rc4: Brad King (2): VS: Fix SBCS support for object libraries CMake 3.15.0 Brian Carlson (1): FindBISON: Fix CMP0088 NEW behavior for non-absolute input paths Cristian Adam (1): find_package: Fix NO_MODULE under CMAKE_FIND_PACKAGE_PREFER_CONFIG Willem Deconinck (2): Fortran: Support compilers using no module prefix on submodule files Fortran: Add support for submodules on Cray From robert.maynard at kitware.com Wed Jul 17 13:12:43 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 17 Jul 2019 13:12:43 -0400 Subject: [CMake] relative path to toolchain does not work In-Reply-To: <023beb57-cd4e-7570-6d7d-607fb60f3f8e@gmail.com> References: <023beb57-cd4e-7570-6d7d-607fb60f3f8e@gmail.com> Message-ID: Is this with a clean build directory? The toolchain file is ignored once CMake has run and has done compiler detection. On Wed, Jul 17, 2019 at 11:29 AM hex wrote: > > I specified my toolchain like so: > > 1cmake -DCMAKE_TOOLCHAIN_FILE=myToolchain.cmake .. > > and created a toolchain file in project/myToolchain.cmake. > > Using relative path CMake first looks relative to the top of the build directory, then if not found there, relative to the top of the source directory. > > What means ?the top of the source directory?? I placed the file in the source directory and receive: > > 1234CMake Warning: > Manually-specified variables were not used by the project: > > CMAKE_TOOLCHAIN_FILE > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 elisha.sarkis at evolutionoptiks.com Wed Jul 17 13:17:58 2019 From: elisha.sarkis at evolutionoptiks.com (Elisha Sarkis) Date: Wed, 17 Jul 2019 13:17:58 -0400 Subject: [CMake] CMake (cmake-gui) silently crashes on Windows 10 Message-ID: After months of working correctly I've found that running CMake in GUI form on Windows 10 suddenly began silently crashing on every launch. It does not appear to be the fault of a recent Windows update given an associate of mine has experienced the same issue in an older version of Windows 10. I installed CMake 3.15.0-rc4 as well as the stable 3.14.6 release, uninstalled, and reinstalled them to no success. The same issue persists in launching Windows in safe mode, and still persists after performing registry fixes. Resetting my Windows 10 install solved the problem, at least for now. Has anyone experienced this issue, and if so have you found a solution that doesn't involve resetting the Windows 10 OS installation? Elisha Sarkis -------------- next part -------------- An HTML attachment was scrubbed... URL: From workbench at gmx.at Thu Jul 18 11:29:57 2019 From: workbench at gmx.at (Steven Truppe) Date: Thu, 18 Jul 2019 17:29:57 +0200 Subject: [CMake] Troubles with ExternalProject_Add and PATCH_COMMAND Message-ID: <860f827c-6cad-c150-9262-71bcd6aab0b6@gmx.at> Hi everyone, i try to patch a file from an externalprojects with the PATCH_COMMAND. The patch file looks like: --- project-config.jam??? 2019-07-18 17:21:44.008695808 +0200 +++ project-config.jam.tmp??? 2019-07-18 17:23:28.236474532 +0200 @@ -18,7 +18,7 @@ ?import python ; ?if ! [ python.configured ] ?{ -??? using python : 2.7 : /usr ; +??? using python : 3.7 : /usr ; ?} ?path-constant ICU_PATH : /usr ; When i try to apply the patch manualy with patch originalfile < patchfile it's working, but when i try it with the externalproject_add command: if(WITH_LIB_BOOST) ??? message(STATUS "Build WITH_LIB_BOOST.") ??? set(LIB_BOOST_INC_PATH ${OUTPUT_PATH}/libs/boost/include/) ??? set(LIB_BOOST_LIB_PATH ${OUTPUT_PATH}/libs/boost/lib) ??? set(LIB_BOOST_DEPS external_boost) ??? set(LIB_BOOST_STATIC_LIBS boost_python27) ??? ExternalProject_Add(external_boost ??? ??? PREFIX ${CMAKE_BINARY_DIR}/boost ??? ??? URL ${BOOST_URL} ??? ??? DOWNLOAD_DIR ${CMAKE_BINARY_DIR}/boost ??? ??? URL_HASH MD5=${BOOST_HASH} ??? ??? PATCH_COMMAND /usr/bin/patch ${CMAKE_BINARY_DIR}/boost/src/external_boost/project-config.jam < ${CMAKE_SOURCE_DIR}/tools/patches/boost_python3.7.patch ??? ??? CONFIGURE_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ && ??? ??? ??? ??? ??? ??? ./bootstrap.sh --prefix=${OUTPUT_PATH}/libs/boost/ --with-libraries=python ??? ??? BUILD_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ && ??? ??? ??? ??? ??? ? ./b2 ??? ??? INSTALL_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ && ./bjam && ./bjam install ??? ??? INSTALL_DIR ${OUTPUT_PATH}/boost ??? ) endif() But when running cmake i get the following output: patching file /home/stuv/projects/programming/bsEdit/build/boost/src/external_boost/project-config.jam Hunk #1 FAILED at 18. I have no idea what i'm doing wrong here, i hope someone here can help me out. best regards, Steven Truppe -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Jul 18 14:39:51 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 18 Jul 2019 14:39:51 -0400 Subject: [CMake] getting compiler's include paths In-Reply-To: References: Message-ID: The history behind the makefile generator and the custom dependency tracking logic was that it was written before the majority of compilers offered a robust way to generate the list of header dependencies. As it stands now we want to remove all this custom dependency scanning logic, not extend it to understand system headers ( As the naive approach would cause CMake to parse system headers, and slow down even more ). Luckily, C++20 modules also require us to drop the custom dependency scanning, so when we add C++20 module support to the Makefile generator this issue will be fixed as by product. On Wed, Jul 3, 2019 at 10:51 AM Robert Maynard wrote: > > I completely forgot that the Makefiles based generators in CMake have > a separate heuristic for determining system headers. > > If you use the Ninja generator I see the expected behavior: > ~/W/t/nbuild $ sudo touch /usr/include/c++/7/array > ~/W/t/nbuild $ ninja -d explain -v > ninja explain: output test/CMakeFiles/ProjTest.dir/test.cpp.o older > than most recent input /usr/include/c++/7/array (1562165327 vs > 1562165329) > ninja explain: test/CMakeFiles/ProjTest.dir/test.cpp.o is dirty > ninja explain: test/ProjTest is dirty > [1/2] /usr/bin/c++ -I../my_lib/include -std=gnu++1z -MD -MT > test/CMakeFiles/ProjTest.dir/test.cpp.o -MF > test/CMakeFiles/ProjTest.dir/test.cpp.o.d -o > test/CMakeFiles/ProjTest.dir/test.cpp.o -c ../test/test.cpp > [2/2] : && /usr/bin/c++ test/CMakeFiles/ProjTest.dir/test.cpp.o > -o test/ProjTest && : > > > I will need to spend some more time figuring out the extra include > caching logic for the Makefile based generators, and will report back. > > On Thu, Jun 27, 2019 at 8:59 AM jl forums wrote: > > > > thanks for the anwer.... > > quite not... I'm using cmake 3.14.2 (so, far away from 3.6....) and have a look, in main.cpp, there is #include : > > > > $ find /usr/include/ -name filesystem > > /usr/include/c++/5/experimental/filesystem > > /usr/include/c++/7/experimental/filesystem > > /usr/include/c++/8/filesystem > > /usr/include/c++/8/experimental/filesystem > > $ sudo touch /usr/include/c++/5/experimental/filesystem /usr/include/c++/7/experimental/filesystem /usr/include/c++/8/filesystem /usr/include/c++/8/experimental/filesystem > > $ make > > [100%] Built target FileSync > > $ touch ../main.cxx > > $ make > > Scanning dependencies of target FileSync > > [ 50%] Building CXX object CMakeFiles/FileSync.dir/main.cxx.o > > [100%] Linking CXX executable FileSync > > [100%] Built target FileSync > > > > > > => cmake don't create "full include dependency" which IS a mistake.... updating system g++ can just assume the target is uptodate and in fact just create a broken build... > > > > in cmake cxx.includecache > > > > #IncludeRegexLine: ^[ ]*[#%][ ]*(include|import)[ ]*[<"]([^">]+)([">]) > > #IncludeRegexScan: ^.*$ > > #IncludeRegexComplain: ^$ > > #IncludeRegexTransform: > > /home/orange/crypt/Devel/projets/FileSync/main.cxx > > cstdio > > - > > io.h > > - > > fcntl.h > > - > > locale > > - > > clocale > > - > > fstream > > - > > iostream > > - > > filesystem > > - > > > > $ /usr/bin/gcc-8 -M ../main.cxx > > main.o: ../main.cxx /usr/x86_64-linux-gnu/include/stdc-predef.h \ > > /usr/include/c++/8/cstdio \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/c++config.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/os_defines.h \ > > /usr/x86_64-linux-gnu/include/features.h \ > > /usr/x86_64-linux-gnu/include/sys/cdefs.h \ > > /usr/x86_64-linux-gnu/include/bits/wordsize.h \ > > /usr/x86_64-linux-gnu/include/bits/long-double.h \ > > /usr/x86_64-linux-gnu/include/gnu/stubs.h \ > > /usr/x86_64-linux-gnu/include/gnu/stubs-64.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/cpu_defines.h \ > > /usr/x86_64-linux-gnu/include/stdio.h \ > > /usr/x86_64-linux-gnu/include/bits/libc-header-start.h \ > > /usr/lib/gcc/x86_64-linux-gnu/8/include/stddef.h \ > > /usr/x86_64-linux-gnu/include/bits/types.h \ > > /usr/x86_64-linux-gnu/include/bits/typesizes.h \ > > /usr/x86_64-linux-gnu/include/bits/types/__FILE.h \ > > /usr/x86_64-linux-gnu/include/bits/types/FILE.h \ > > /usr/x86_64-linux-gnu/include/bits/libio.h \ > > /usr/x86_64-linux-gnu/include/bits/_G_config.h \ > > /usr/x86_64-linux-gnu/include/bits/types/__mbstate_t.h \ > > /usr/lib/gcc/x86_64-linux-gnu/8/include/stdarg.h \ > > /usr/x86_64-linux-gnu/include/bits/stdio_lim.h \ > > /usr/x86_64-linux-gnu/include/bits/sys_errlist.h \ > > /usr/include/c++/8/locale /usr/include/c++/8/bits/localefwd.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/c++locale.h \ > > /usr/include/c++/8/clocale /usr/x86_64-linux-gnu/include/locale.h \ > > /usr/x86_64-linux-gnu/include/bits/locale.h \ > > /usr/x86_64-linux-gnu/include/bits/types/locale_t.h \ > > /usr/x86_64-linux-gnu/include/bits/types/__locale_t.h \ > > /usr/include/c++/8/iosfwd /usr/include/c++/8/bits/stringfwd.h \ > > /usr/include/c++/8/bits/memoryfwd.h /usr/include/c++/8/bits/postypes.h \ > > /usr/include/c++/8/cwchar /usr/x86_64-linux-gnu/include/wchar.h \ > > /usr/x86_64-linux-gnu/include/bits/floatn.h \ > > /usr/x86_64-linux-gnu/include/bits/floatn-common.h \ > > /usr/x86_64-linux-gnu/include/bits/wchar.h \ > > /usr/x86_64-linux-gnu/include/bits/types/wint_t.h \ > > /usr/x86_64-linux-gnu/include/bits/types/mbstate_t.h \ > > /usr/include/c++/8/cctype /usr/x86_64-linux-gnu/include/ctype.h \ > > /usr/x86_64-linux-gnu/include/endian.h \ > > /usr/x86_64-linux-gnu/include/bits/endian.h \ > > /usr/x86_64-linux-gnu/include/bits/byteswap.h \ > > /usr/x86_64-linux-gnu/include/bits/byteswap-16.h \ > > /usr/x86_64-linux-gnu/include/bits/uintn-identity.h \ > > /usr/include/c++/8/bits/locale_classes.h /usr/include/c++/8/string \ > > /usr/include/c++/8/bits/char_traits.h \ > > /usr/include/c++/8/bits/stl_algobase.h \ > > /usr/include/c++/8/bits/functexcept.h \ > > /usr/include/c++/8/bits/exception_defines.h \ > > /usr/include/c++/8/bits/cpp_type_traits.h \ > > /usr/include/c++/8/ext/type_traits.h \ > > /usr/include/c++/8/ext/numeric_traits.h \ > > /usr/include/c++/8/bits/stl_pair.h /usr/include/c++/8/bits/move.h \ > > /usr/include/c++/8/bits/concept_check.h /usr/include/c++/8/type_traits \ > > /usr/include/c++/8/bits/stl_iterator_base_types.h \ > > /usr/include/c++/8/bits/stl_iterator_base_funcs.h \ > > /usr/include/c++/8/debug/assertions.h \ > > /usr/include/c++/8/bits/stl_iterator.h \ > > /usr/include/c++/8/bits/ptr_traits.h /usr/include/c++/8/debug/debug.h \ > > /usr/include/c++/8/bits/predefined_ops.h /usr/include/c++/8/cstdint \ > > /usr/lib/gcc/x86_64-linux-gnu/8/include/stdint.h \ > > /usr/x86_64-linux-gnu/include/stdint.h \ > > /usr/x86_64-linux-gnu/include/bits/stdint-intn.h \ > > /usr/x86_64-linux-gnu/include/bits/stdint-uintn.h \ > > /usr/include/c++/8/bits/allocator.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/c++allocator.h \ > > /usr/include/c++/8/ext/new_allocator.h /usr/include/c++/8/new \ > > /usr/include/c++/8/exception /usr/include/c++/8/bits/exception.h \ > > /usr/include/c++/8/bits/exception_ptr.h \ > > /usr/include/c++/8/bits/cxxabi_init_exception.h \ > > /usr/include/c++/8/typeinfo /usr/include/c++/8/bits/hash_bytes.h \ > > /usr/include/c++/8/bits/nested_exception.h \ > > /usr/include/c++/8/bits/ostream_insert.h \ > > /usr/include/c++/8/bits/cxxabi_forced.h \ > > /usr/include/c++/8/bits/stl_function.h \ > > /usr/include/c++/8/backward/binders.h \ > > /usr/include/c++/8/bits/range_access.h \ > > /usr/include/c++/8/initializer_list \ > > /usr/include/c++/8/bits/basic_string.h \ > > /usr/include/c++/8/ext/atomicity.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/gthr.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/gthr-default.h \ > > /usr/x86_64-linux-gnu/include/pthread.h \ > > /usr/x86_64-linux-gnu/include/sched.h \ > > /usr/x86_64-linux-gnu/include/bits/types/time_t.h \ > > /usr/x86_64-linux-gnu/include/bits/types/struct_timespec.h \ > > /usr/x86_64-linux-gnu/include/bits/sched.h \ > > /usr/x86_64-linux-gnu/include/bits/cpu-set.h \ > > /usr/x86_64-linux-gnu/include/time.h \ > > /usr/x86_64-linux-gnu/include/bits/time.h \ > > /usr/x86_64-linux-gnu/include/bits/timex.h \ > > /usr/x86_64-linux-gnu/include/bits/types/struct_timeval.h \ > > /usr/x86_64-linux-gnu/include/bits/types/clock_t.h \ > > /usr/x86_64-linux-gnu/include/bits/types/struct_tm.h \ > > /usr/x86_64-linux-gnu/include/bits/types/clockid_t.h \ > > /usr/x86_64-linux-gnu/include/bits/types/timer_t.h \ > > /usr/x86_64-linux-gnu/include/bits/types/struct_itimerspec.h \ > > /usr/x86_64-linux-gnu/include/bits/pthreadtypes.h \ > > /usr/x86_64-linux-gnu/include/bits/thread-shared-types.h \ > > /usr/x86_64-linux-gnu/include/bits/pthreadtypes-arch.h \ > > /usr/x86_64-linux-gnu/include/bits/setjmp.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/atomic_word.h \ > > /usr/include/c++/8/ext/alloc_traits.h \ > > /usr/include/c++/8/bits/alloc_traits.h \ > > /usr/include/c++/8/ext/string_conversions.h /usr/include/c++/8/cstdlib \ > > /usr/x86_64-linux-gnu/include/stdlib.h \ > > /usr/x86_64-linux-gnu/include/bits/waitflags.h \ > > /usr/x86_64-linux-gnu/include/bits/waitstatus.h \ > > /usr/x86_64-linux-gnu/include/sys/types.h \ > > /usr/x86_64-linux-gnu/include/sys/select.h \ > > /usr/x86_64-linux-gnu/include/bits/select.h \ > > /usr/x86_64-linux-gnu/include/bits/types/sigset_t.h \ > > /usr/x86_64-linux-gnu/include/bits/types/__sigset_t.h \ > > /usr/x86_64-linux-gnu/include/sys/sysmacros.h \ > > /usr/x86_64-linux-gnu/include/bits/sysmacros.h \ > > /usr/x86_64-linux-gnu/include/alloca.h \ > > /usr/x86_64-linux-gnu/include/bits/stdlib-float.h \ > > /usr/include/c++/8/bits/std_abs.h /usr/include/c++/8/cerrno \ > > /usr/x86_64-linux-gnu/include/errno.h \ > > /usr/x86_64-linux-gnu/include/bits/errno.h \ > > /usr/x86_64-linux-gnu/include/linux/errno.h \ > > /usr/x86_64-linux-gnu/include/asm/errno.h \ > > /usr/x86_64-linux-gnu/include/asm-generic/errno.h \ > > /usr/x86_64-linux-gnu/include/asm-generic/errno-base.h \ > > /usr/include/c++/8/bits/functional_hash.h \ > > /usr/include/c++/8/bits/basic_string.tcc \ > > /usr/include/c++/8/bits/locale_classes.tcc \ > > /usr/include/c++/8/bits/locale_facets.h /usr/include/c++/8/cwctype \ > > /usr/x86_64-linux-gnu/include/wctype.h \ > > /usr/x86_64-linux-gnu/include/bits/wctype-wchar.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/ctype_base.h \ > > /usr/include/c++/8/bits/ios_base.h /usr/include/c++/8/system_error \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/error_constants.h \ > > /usr/include/c++/8/stdexcept /usr/include/c++/8/streambuf \ > > /usr/include/c++/8/bits/streambuf.tcc \ > > /usr/include/c++/8/bits/streambuf_iterator.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/ctype_inline.h \ > > /usr/include/c++/8/bits/locale_facets.tcc \ > > /usr/include/c++/8/bits/locale_facets_nonio.h /usr/include/c++/8/ctime \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/time_members.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/messages_members.h \ > > /usr/x86_64-linux-gnu/include/libintl.h \ > > /usr/include/c++/8/bits/codecvt.h \ > > /usr/include/c++/8/bits/locale_facets_nonio.tcc \ > > /usr/include/c++/8/bits/locale_conv.h \ > > /usr/include/c++/8/bits/unique_ptr.h /usr/include/c++/8/utility \ > > /usr/include/c++/8/bits/stl_relops.h /usr/include/c++/8/tuple \ > > /usr/include/c++/8/array /usr/include/c++/8/bits/uses_allocator.h \ > > /usr/include/c++/8/bits/invoke.h /usr/include/c++/8/fstream \ > > /usr/include/c++/8/istream /usr/include/c++/8/ios \ > > /usr/include/c++/8/bits/basic_ios.h \ > > /usr/include/c++/8/bits/basic_ios.tcc /usr/include/c++/8/ostream \ > > /usr/include/c++/8/bits/ostream.tcc /usr/include/c++/8/bits/istream.tcc \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/basic_file.h \ > > /usr/include/x86_64-linux-gnu/c++/8/bits/c++io.h \ > > /usr/include/c++/8/bits/fstream.tcc /usr/include/c++/8/iostream \ > > /usr/include/c++/8/filesystem > > > > > > amazing, no? cmake find only 9 dependencies against 100+ real ones (and I don't even speak of errors that can be caused in parsing if some -D option is changed.... > > > > thanks and regards > > JLM > > > > > > Le lun. 24 juin 2019 ? 14:14, Robert Maynard a ?crit : > >> > >> It look that starting with CMake 3.6 modification of system headers > >> will cause CMake to recompile projects. What version of CMake and your > >> compiler are you using? > >> > >> On Mon, Jun 17, 2019 at 9:40 AM jl forums wrote: > >> > > >> > Hi, > >> > I want to create a full tag file and for this require to know the compiler full include path... there is a way to had custom includes path but didn't found any variables for the include path.... > >> > for example : > >> > $ gcc-8 -v -x c -E /dev/null > >> > Using built-in specs. > >> > [....] > >> > ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" > >> > #include "..." search starts here: > >> > #include <...> search starts here: > >> > /usr/lib/gcc/x86_64-linux-gnu/8/include > >> > /usr/local/include > >> > /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed > >> > /usr/x86_64-linux-gnu/include > >> > /usr/include/x86_64-linux-gnu > >> > /usr/include > >> > End of search list. > >> > [...] > >> > > >> > $ gcc -v -x c -E /dev/null > >> > Using built-in specs. > >> > [...] > >> > ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" > >> > #include "..." search starts here: > >> > #include <...> search starts here: > >> > /usr/lib/gcc/x86_64-linux-gnu/7/include > >> > /usr/local/include > >> > /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed > >> > /usr/x86_64-linux-gnu/include > >> > /usr/include/x86_64-linux-gnu > >> > /usr/include > >> > End of search list. > >> > [...] > >> > > >> > I tried to > >> > > >> > > >> > get_target_property(moggle_interface_includes FileSync INTERFACE_INCLUDE_DIRECTORIES) > >> > message("Moggle interface includes: ${moggle_interface_includes}") > >> > > >> > get_target_property(motor_includes FileSync INCLUDE_DIRECTORIES) > >> > message("MOTOR includes ${motor_includes}") > >> > > >> > but I get > >> > > >> > Moggle interface includes: moggle_interface_includes-NOTFOUND > >> > MOTOR includes motor_includes-NOTFOUND > >> > > >> > > >> > there is also some issue because cmake strip dependencies from system's include, which means that updating a system software won't cause rebuild and consider that the build is uptodate, causing unexpected results > >> > seems that there is ways to workaround this : https://stackoverflow.com/questions/7461000/handling-header-files-dependencies-with-cmake but this is ugly... would be better to let the user choose with an option > >> > > >> > thanks and regards > >> > JLM > >> > -- > >> > > >> > Powered by www.kitware.com > >> > > >> > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > >> > > >> > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > >> > > >> > CMake Support: http://cmake.org/cmake/help/support.html > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> > CMake Training Courses: http://cmake.org/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 loose at astron.nl Thu Jul 18 15:33:50 2019 From: loose at astron.nl (Marcel Loose) Date: Thu, 18 Jul 2019 21:33:50 +0200 Subject: [CMake] [DKIM: Failed] Troubles with ExternalProject_Add and PATCH_COMMAND In-Reply-To: <860f827c-6cad-c150-9262-71bcd6aab0b6@gmx.at> References: <860f827c-6cad-c150-9262-71bcd6aab0b6@gmx.at> Message-ID: <998d570b-8a80-5bea-76e2-dadc6772bd8e@astron.nl> Hi Steven, When you run patch manually, do you then supply the same absolute paths? Looking at the patch file I noticed that it contains a relative path. So maybe you should cd to ${CMAKE_BINARY_DIR}/boost/src/external_boost/project-config.jam before running the patch command. Cheers, Marcel. Op 18-07-19 om 17:29 schreef Steven Truppe: > > Hi everyone, > > i try to patch a file from an externalprojects with the PATCH_COMMAND. > > The patch file looks like: > > --- project-config.jam??? 2019-07-18 17:21:44.008695808 +0200 > +++ project-config.jam.tmp??? 2019-07-18 17:23:28.236474532 +0200 > @@ -18,7 +18,7 @@ > ?import python ; > ?if ! [ python.configured ] > ?{ > -??? using python : 2.7 : /usr ; > +??? using python : 3.7 : /usr ; > ?} > ? > ?path-constant ICU_PATH : /usr ; > > When i try to apply the patch manualy with patch originalfile < > patchfile it's working, but when i try it with the externalproject_add > command: > > if(WITH_LIB_BOOST) > ??? message(STATUS "Build WITH_LIB_BOOST.") > > ??? set(LIB_BOOST_INC_PATH ${OUTPUT_PATH}/libs/boost/include/) > ??? set(LIB_BOOST_LIB_PATH ${OUTPUT_PATH}/libs/boost/lib) > ??? set(LIB_BOOST_DEPS external_boost) > ??? set(LIB_BOOST_STATIC_LIBS boost_python27) > ? > ??? ExternalProject_Add(external_boost > ??? ??? PREFIX ${CMAKE_BINARY_DIR}/boost > ??? ??? URL ${BOOST_URL} > ??? ??? DOWNLOAD_DIR ${CMAKE_BINARY_DIR}/boost > ??? ??? URL_HASH MD5=${BOOST_HASH} > ??? ??? PATCH_COMMAND /usr/bin/patch ${CMAKE_BINARY_DIR}/boost/src/external_boost/project-config.jam < ${CMAKE_SOURCE_DIR}/tools/patches/boost_python3.7.patch > ??? ??? CONFIGURE_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ && > ??? ??? ??? ??? ??? ??? ./bootstrap.sh --prefix=${OUTPUT_PATH}/libs/boost/ --with-libraries=python > ??? ??? BUILD_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ && > ??? ??? ??? ??? ??? ? ./b2 > ??? ??? INSTALL_COMMAND cd ${CMAKE_BINARY_DIR}/boost/src/external_boost/ && ./bjam && ./bjam install > ??? ??? INSTALL_DIR ${OUTPUT_PATH}/boost > ??? ) > > endif() > > But when running cmake i get the following output: > > patching file /home/stuv/projects/programming/bsEdit/build/boost/src/external_boost/project-config.jam > Hunk #1 FAILED at 18. > > > I have no idea what i'm doing wrong here, i hope someone here can help > me out. > > > best regards, > > Steven Truppe > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hex7c3 at gmail.com Fri Jul 19 06:23:40 2019 From: hex7c3 at gmail.com (hex) Date: Fri, 19 Jul 2019 11:23:40 +0100 Subject: [CMake] relative path to toolchain does not work In-Reply-To: References: Message-ID: Yes, this was the problem. I was running cmake .. -LA to check the cache variables /before/ setting the toolchain. You can even see that the CMAKE_TOOLCHAIN_FILE is not set. It is working now, thank you. On 17/07/2019 18:12, Robert Maynard wrote: > Is this with a clean build directory? The toolchain file is ignored > once CMake has run and has done compiler detection. > > On Wed, Jul 17, 2019 at 11:29 AM hex wrote: >> I specified my toolchain like so: >> >> 1cmake -DCMAKE_TOOLCHAIN_FILE=myToolchain.cmake .. >> >> and created a toolchain file in project/myToolchain.cmake. >> >> Using relative path CMake first looks relative to the top of the build directory, then if not found there, relative to the top of the source directory. >> >> What means ?the top of the source directory?? I placed the file in the source directory and receive: >> >> 1234CMake Warning: >> Manually-specified variables were not used by the project: >> >> CMAKE_TOOLCHAIN_FILE >> >> -- >> >> Powered bywww.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at:http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support:http://cmake.org/cmake/help/support.html >> CMake Consulting:http://cmake.org/cmake/help/consulting.html >> CMake Training Courses:http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects athttp://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 geoffroy.jabouley at gmail.com Fri Jul 19 14:52:29 2019 From: geoffroy.jabouley at gmail.com (Geoffroy J) Date: Fri, 19 Jul 2019 20:52:29 +0200 Subject: [CMake] GHS - specify cpu option to CMake generator? Message-ID: Hello i have tried today to build a library using CMake Green Hills MULTI generator. It seemed to work quite well, but i end up not being able to configure the "-cpu" option for gbuild, which i need to set to "cortexa7". I've went through the CMake code, i think something similar to variable GHS_BSP_NAME would work, but does not seems available at the moment. Does it means it cannot be done at the moment? Do you know how to achieve this? Would using CFLAGS/LDFLAGS a viable solution? Thanks in advance for your answer Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From hex7c3 at gmail.com Fri Jul 19 16:30:22 2019 From: hex7c3 at gmail.com (hex) Date: Fri, 19 Jul 2019 21:30:22 +0100 Subject: [CMake] add my own language-name using standard functions Message-ID: <8c65d321-b48a-64a8-2954-7d8e2ee7d956@gmail.com> dear community, I want to make a module for a language that is not supported by CMake. are there any restrictions in using *add_executable* for any language other than C / C++, must the build be constructed very similar to C language? I was looking into Java module for reference and noted that it is defining its own functions for build. Since overriding standard CMake functions is discouraged and *add_executable* seems to be hard coded (not a CMake module) I believe that I have to create my own functions like add_verilog_configuration, target_link_verilog_library and alike. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Fri Jul 19 16:41:16 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Fri, 19 Jul 2019 16:41:16 -0400 Subject: [CMake] add my own language-name using standard functions In-Reply-To: <8c65d321-b48a-64a8-2954-7d8e2ee7d956@gmail.com> References: <8c65d321-b48a-64a8-2954-7d8e2ee7d956@gmail.com> Message-ID: <1563568876.3643.33.camel@kitware.com> On Fri, 2019-07-19 at 21:30 +0100, hex wrote: > dear community, > I want to make a module for a language that is not supported by > CMake.? > are there any restrictions in using add_executable for any language > other than C / C++,? > must the build be constructed very similar to C language? > I was looking into Java module for reference and noted that it is > defining its own functions for build. Since overriding standard CMake > functions is discouraged and add_executable seems to be hard coded > (not a CMake module) I believe that I have to create my own functions > like add_verilog_configuration, target_link_verilog_library and > alike.? All of the languages have different rules for building, linking, etc. and many of these rules are encoded in native C++ rather than in CMake script. If you would like to add Verilog support to CMake, please open an issue on GitLab so we can track the progress. Kyle From calebwherry at gmail.com Fri Jul 19 17:25:10 2019 From: calebwherry at gmail.com (J. Caleb Wherry) Date: Fri, 19 Jul 2019 17:25:10 -0400 Subject: [CMake] add my own language-name using standard functions In-Reply-To: <1563568876.3643.33.camel@kitware.com> References: <8c65d321-b48a-64a8-2954-7d8e2ee7d956@gmail.com> <1563568876.3643.33.camel@kitware.com> Message-ID: Also, I would not suggest using the Java language support as reference as it is not a first class supported language. As you said, it defines custom functions and macros to do everything. I would suggest you look at the C# support as it is a first class language (meaning: you can add it to your project statement along with C and CXX or use enable language). It is only supported for the Visual Studio Generator but it should give you a lot better starting point than the Java stuff. -Caleb On Fri, Jul 19, 2019 at 4:43 PM Kyle Edwards wrote: > On Fri, 2019-07-19 at 21:30 +0100, hex wrote: > > dear community, > > I want to make a module for a language that is not supported by > > CMake. > > are there any restrictions in using add_executable for any language > > other than C / C++, > > must the build be constructed very similar to C language? > > I was looking into Java module for reference and noted that it is > > defining its own functions for build. Since overriding standard CMake > > functions is discouraged and add_executable seems to be hard coded > > (not a CMake module) I believe that I have to create my own functions > > like add_verilog_configuration, target_link_verilog_library and > > alike. > > All of the languages have different rules for building, linking, etc. > and many of these rules are encoded in native C++ rather than in CMake > script. > > If you would like to add Verilog support to CMake, please open an issue > on GitLab so we can track the progress. > > 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 > -- Sent from my iPhone SE -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodak17 at gmail.com Fri Jul 19 20:13:17 2019 From: frodak17 at gmail.com (frodak17) Date: Fri, 19 Jul 2019 20:13:17 -0400 Subject: [CMake] GHS - specify cpu option to CMake generator? In-Reply-To: References: Message-ID: On Fri, Jul 19, 2019 at 2:52 PM Geoffroy J wrote: > Hello > > i have tried today to build a library using CMake Green Hills MULTI > generator. > > It seemed to work quite well, but i end up not being able to configure the > "-cpu" option for gbuild, which i need to set to "cortexa7". > > I've went through the CMake code, i think something similar to > variable GHS_BSP_NAME would work, but does not seems available at the > moment. Does it means it cannot be done at the moment? > > Do you know how to achieve this? Would using CFLAGS/LDFLAGS a viable > solution? > > Thanks in advance for your answer > Regards > > I see -cpu as an option for armcc not for gbuild. You should be able to pass the -cpu option per target like any other compiler option. So try using target_compile_options(). Some options are builder options so they don't start with a dash but with a colon but it still should work with target_compile_options(). However my experience has been that is handled by the BSP .bld files for the particular target / platform. If the BSP target file has the wrong cpu in it then it probably could just get updated and then it should "just work". For example some of the .bld files contain a ":arm_cputype=cortexa8". But I couldn't tell you exactly which files would need to be updated. -- F -------------- next part -------------- An HTML attachment was scrubbed... URL: From workbench at gmx.at Sat Jul 20 18:04:07 2019 From: workbench at gmx.at (Steven Truppe) Date: Sun, 21 Jul 2019 00:04:07 +0200 Subject: [CMake] Test example with list(FIND inside a macro. Message-ID: Hi everyone, i have the following code: nclude(CMakePrintHelpers) ## MACROS ########################################################### macro(bsIsInListBefore) ??? message(STATUS "bsIsInListBefore(): #${ARGV0}#${ARGV1}") ??? set(index1 0) ??? set(index2 0) ??? cmake_print_variables(ARG1) ??? list(FIND ${LIBS_TO_BUILD} ${ARGV1} index1) ??? cmake_print_variables(index1) ??? if(index1 GREATER -1) ??????? list(FIND ${LIBS_TO_BUILD} ${ARG2} index2) ??????? message(STATUS "index found") ??? elseif() ??????? message(STATUS "index NO found") ??? endif() endmacro() set(LIBS_TO_BUILD ??? glad ??? glfw ??? eigen ??? cppflags ??? python ??? boost ) ## Main ############################################################ cmake_print_variables(LIBS_TO_BUILD) bsIsInListBefore(${LIBS_TO_BUILD} glfw glad is_before) if(${is_before}) ??? message(STATUS "-------> glfw in in front of glad") endif() message(STATUS "YES glfw is before glad in the list !!!!") I've never use list(FIND and i never knoe if i should pass a variable with %{VAR} or VAR only.. best regards, Steven Truppe From craig.scott at crascit.com Sun Jul 21 04:48:54 2019 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 21 Jul 2019 18:48:54 +1000 Subject: [CMake] FetchContent/ExternalProject and URL_HASH In-Reply-To: References: Message-ID: On Wed, Jul 17, 2019 at 12:59 PM Dustyn Blasig wrote: > Hi All, > > We are pulling some artifacts from Artifactory which provides a checksum > file along with the artifacts at .md5 or .sha256. If I do not > include URL_HASH, does CMake automatically check to see if such a checksum > file exists and use it's value for the hash check? Or is there a way to > provide a URL for the checksum file rather than having to do file(DOWNLOAD > ), file(STRING ), URL_HASH=? > The point of the checksum file is to verify the file downloaded. It doesn't make a whole lot of sense to then download another file to provide that checksum, you'd just be moving the problem along one level of indirection. The assumption is when you provide the URL to be downloaded, if you want to use a checksum then you should also be able to provide that along with the URL. When the URL is being constructed on-the-fly though, this isn't typically true. In that case, you can't typically provide a checksum that isn't itself downloaded and therefore needs to be verified itself. To more directly answer your question, CMake doesn't offer any feature to automatically download a checksum file (that I'm aware of). The file command expects that actual checksum, not a location for where to retrieve it from for the reasons mentioned above. -- 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 jlmxyz.forums at gmail.com Sun Jul 21 18:54:29 2019 From: jlmxyz.forums at gmail.com (jl forums) Date: Mon, 22 Jul 2019 00:54:29 +0200 Subject: [CMake] getting compiler's include paths In-Reply-To: References: Message-ID: lol.... c++20 modules ?? IF users use them.... modules is just pain in the ass for developers.... I hope that real developers will simply ignore them.... headers are here for a good reason, and stupid languages like python that use modules are just.... stupid.... it will make more complicated for the developer to track dependencies, understand how the software is build.... or create system breakages (what if a C define change????)... instead of having a clean header which describes the API with comments, you get a raw processed? well that's sure an "improvement"... and you, you wants to "fix" this issue by dropping the dependency scanner ? ok.... i begin to think to not have chosen the right makefile generator.... I hope you revise your mind and write a fix thanks and regards Le jeu. 18 juil. 2019 ? 20:40, Robert Maynard a ?crit : > The history behind the makefile generator and the custom dependency > tracking logic was that it was written before > the majority of compilers offered a robust way to generate the list of > header dependencies. > > As it stands now we want to remove all this custom dependency scanning > logic, not extend it to understand system headers > ( As the naive approach would cause CMake to parse system headers, and > slow down even more ). Luckily, C++20 modules > also require us to drop the custom dependency scanning, so when we add > C++20 module support to the Makefile generator > this issue will be fixed as by product. > > On Wed, Jul 3, 2019 at 10:51 AM Robert Maynard > wrote: > > > > I completely forgot that the Makefiles based generators in CMake have > > a separate heuristic for determining system headers. > > > > If you use the Ninja generator I see the expected behavior: > > ~/W/t/nbuild $ sudo touch /usr/include/c++/7/array > > ~/W/t/nbuild $ ninja -d explain -v > > ninja explain: output test/CMakeFiles/ProjTest.dir/test.cpp.o older > > than most recent input /usr/include/c++/7/array (1562165327 vs > > 1562165329) > > ninja explain: test/CMakeFiles/ProjTest.dir/test.cpp.o is dirty > > ninja explain: test/ProjTest is dirty > > [1/2] /usr/bin/c++ -I../my_lib/include -std=gnu++1z -MD -MT > > test/CMakeFiles/ProjTest.dir/test.cpp.o -MF > > test/CMakeFiles/ProjTest.dir/test.cpp.o.d -o > > test/CMakeFiles/ProjTest.dir/test.cpp.o -c ../test/test.cpp > > [2/2] : && /usr/bin/c++ test/CMakeFiles/ProjTest.dir/test.cpp.o > > -o test/ProjTest && : > > > > > > I will need to spend some more time figuring out the extra include > > caching logic for the Makefile based generators, and will report back. > > > > On Thu, Jun 27, 2019 at 8:59 AM jl forums > wrote: > > > > > > thanks for the anwer.... > > > quite not... I'm using cmake 3.14.2 (so, far away from 3.6....) and > have a look, in main.cpp, there is #include : > > > > > > $ find /usr/include/ -name filesystem > > > /usr/include/c++/5/experimental/filesystem > > > /usr/include/c++/7/experimental/filesystem > > > /usr/include/c++/8/filesystem > > > /usr/include/c++/8/experimental/filesystem > > > $ sudo touch /usr/include/c++/5/experimental/filesystem > /usr/include/c++/7/experimental/filesystem /usr/include/c++/8/filesystem > /usr/include/c++/8/experimental/filesystem > > > $ make > > > [100%] Built target FileSync > > > $ touch ../main.cxx > > > $ make > > > Scanning dependencies of target FileSync > > > [ 50%] Building CXX object CMakeFiles/FileSync.dir/main.cxx.o > > > [100%] Linking CXX executable FileSync > > > [100%] Built target FileSync > > > > > > > > > => cmake don't create "full include dependency" which IS a mistake.... > updating system g++ can just assume the target is uptodate and in fact just > create a broken build... > > > > > > in cmake cxx.includecache > > > > > > #IncludeRegexLine: ^[ ]*[#%][ ]*(include|import)[ ]*[<"]([^">]+)([">]) > > > #IncludeRegexScan: ^.*$ > > > #IncludeRegexComplain: ^$ > > > #IncludeRegexTransform: > > > /home/orange/crypt/Devel/projets/FileSync/main.cxx > > > cstdio > > > - > > > io.h > > > - > > > fcntl.h > > > - > > > locale > > > - > > > clocale > > > - > > > fstream > > > - > > > iostream > > > - > > > filesystem > > > - > > > > > > $ /usr/bin/gcc-8 -M ../main.cxx > > > main.o: ../main.cxx /usr/x86_64-linux-gnu/include/stdc-predef.h \ > > > /usr/include/c++/8/cstdio \ > > > /usr/include/x86_64-linux-gnu/c++/8/bits/c++config.h \ > > > /usr/include/x86_64-linux-gnu/c++/8/bits/os_defines.h \ > > > /usr/x86_64-linux-gnu/include/features.h \ > > > /usr/x86_64-linux-gnu/include/sys/cdefs.h \ > > > /usr/x86_64-linux-gnu/include/bits/wordsize.h \ > > > /usr/x86_64-linux-gnu/include/bits/long-double.h \ > > > /usr/x86_64-linux-gnu/include/gnu/stubs.h \ > > > /usr/x86_64-linux-gnu/include/gnu/stubs-64.h \ > > > /usr/include/x86_64-linux-gnu/c++/8/bits/cpu_defines.h \ > > > /usr/x86_64-linux-gnu/include/stdio.h \ > > > /usr/x86_64-linux-gnu/include/bits/libc-header-start.h \ > > > /usr/lib/gcc/x86_64-linux-gnu/8/include/stddef.h \ > > > /usr/x86_64-linux-gnu/include/bits/types.h \ > > > /usr/x86_64-linux-gnu/include/bits/typesizes.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/__FILE.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/FILE.h \ > > > /usr/x86_64-linux-gnu/include/bits/libio.h \ > > > /usr/x86_64-linux-gnu/include/bits/_G_config.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/__mbstate_t.h \ > > > /usr/lib/gcc/x86_64-linux-gnu/8/include/stdarg.h \ > > > /usr/x86_64-linux-gnu/include/bits/stdio_lim.h \ > > > /usr/x86_64-linux-gnu/include/bits/sys_errlist.h \ > > > /usr/include/c++/8/locale /usr/include/c++/8/bits/localefwd.h \ > > > /usr/include/x86_64-linux-gnu/c++/8/bits/c++locale.h \ > > > /usr/include/c++/8/clocale /usr/x86_64-linux-gnu/include/locale.h \ > > > /usr/x86_64-linux-gnu/include/bits/locale.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/locale_t.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/__locale_t.h \ > > > /usr/include/c++/8/iosfwd /usr/include/c++/8/bits/stringfwd.h \ > > > /usr/include/c++/8/bits/memoryfwd.h > /usr/include/c++/8/bits/postypes.h \ > > > /usr/include/c++/8/cwchar /usr/x86_64-linux-gnu/include/wchar.h \ > > > /usr/x86_64-linux-gnu/include/bits/floatn.h \ > > > /usr/x86_64-linux-gnu/include/bits/floatn-common.h \ > > > /usr/x86_64-linux-gnu/include/bits/wchar.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/wint_t.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/mbstate_t.h \ > > > /usr/include/c++/8/cctype /usr/x86_64-linux-gnu/include/ctype.h \ > > > /usr/x86_64-linux-gnu/include/endian.h \ > > > /usr/x86_64-linux-gnu/include/bits/endian.h \ > > > /usr/x86_64-linux-gnu/include/bits/byteswap.h \ > > > /usr/x86_64-linux-gnu/include/bits/byteswap-16.h \ > > > /usr/x86_64-linux-gnu/include/bits/uintn-identity.h \ > > > /usr/include/c++/8/bits/locale_classes.h /usr/include/c++/8/string \ > > > /usr/include/c++/8/bits/char_traits.h \ > > > /usr/include/c++/8/bits/stl_algobase.h \ > > > /usr/include/c++/8/bits/functexcept.h \ > > > /usr/include/c++/8/bits/exception_defines.h \ > > > /usr/include/c++/8/bits/cpp_type_traits.h \ > > > /usr/include/c++/8/ext/type_traits.h \ > > > /usr/include/c++/8/ext/numeric_traits.h \ > > > /usr/include/c++/8/bits/stl_pair.h /usr/include/c++/8/bits/move.h \ > > > /usr/include/c++/8/bits/concept_check.h > /usr/include/c++/8/type_traits \ > > > /usr/include/c++/8/bits/stl_iterator_base_types.h \ > > > /usr/include/c++/8/bits/stl_iterator_base_funcs.h \ > > > /usr/include/c++/8/debug/assertions.h \ > > > /usr/include/c++/8/bits/stl_iterator.h \ > > > /usr/include/c++/8/bits/ptr_traits.h /usr/include/c++/8/debug/debug.h > \ > > > /usr/include/c++/8/bits/predefined_ops.h /usr/include/c++/8/cstdint \ > > > /usr/lib/gcc/x86_64-linux-gnu/8/include/stdint.h \ > > > /usr/x86_64-linux-gnu/include/stdint.h \ > > > /usr/x86_64-linux-gnu/include/bits/stdint-intn.h \ > > > /usr/x86_64-linux-gnu/include/bits/stdint-uintn.h \ > > > /usr/include/c++/8/bits/allocator.h \ > > > /usr/include/x86_64-linux-gnu/c++/8/bits/c++allocator.h \ > > > /usr/include/c++/8/ext/new_allocator.h /usr/include/c++/8/new \ > > > /usr/include/c++/8/exception /usr/include/c++/8/bits/exception.h \ > > > /usr/include/c++/8/bits/exception_ptr.h \ > > > /usr/include/c++/8/bits/cxxabi_init_exception.h \ > > > /usr/include/c++/8/typeinfo /usr/include/c++/8/bits/hash_bytes.h \ > > > /usr/include/c++/8/bits/nested_exception.h \ > > > /usr/include/c++/8/bits/ostream_insert.h \ > > > /usr/include/c++/8/bits/cxxabi_forced.h \ > > > /usr/include/c++/8/bits/stl_function.h \ > > > /usr/include/c++/8/backward/binders.h \ > > > /usr/include/c++/8/bits/range_access.h \ > > > /usr/include/c++/8/initializer_list \ > > > /usr/include/c++/8/bits/basic_string.h \ > > > /usr/include/c++/8/ext/atomicity.h \ > > > /usr/include/x86_64-linux-gnu/c++/8/bits/gthr.h \ > > > /usr/include/x86_64-linux-gnu/c++/8/bits/gthr-default.h \ > > > /usr/x86_64-linux-gnu/include/pthread.h \ > > > /usr/x86_64-linux-gnu/include/sched.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/time_t.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/struct_timespec.h \ > > > /usr/x86_64-linux-gnu/include/bits/sched.h \ > > > /usr/x86_64-linux-gnu/include/bits/cpu-set.h \ > > > /usr/x86_64-linux-gnu/include/time.h \ > > > /usr/x86_64-linux-gnu/include/bits/time.h \ > > > /usr/x86_64-linux-gnu/include/bits/timex.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/struct_timeval.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/clock_t.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/struct_tm.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/clockid_t.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/timer_t.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/struct_itimerspec.h \ > > > /usr/x86_64-linux-gnu/include/bits/pthreadtypes.h \ > > > /usr/x86_64-linux-gnu/include/bits/thread-shared-types.h \ > > > /usr/x86_64-linux-gnu/include/bits/pthreadtypes-arch.h \ > > > /usr/x86_64-linux-gnu/include/bits/setjmp.h \ > > > /usr/include/x86_64-linux-gnu/c++/8/bits/atomic_word.h \ > > > /usr/include/c++/8/ext/alloc_traits.h \ > > > /usr/include/c++/8/bits/alloc_traits.h \ > > > /usr/include/c++/8/ext/string_conversions.h > /usr/include/c++/8/cstdlib \ > > > /usr/x86_64-linux-gnu/include/stdlib.h \ > > > /usr/x86_64-linux-gnu/include/bits/waitflags.h \ > > > /usr/x86_64-linux-gnu/include/bits/waitstatus.h \ > > > /usr/x86_64-linux-gnu/include/sys/types.h \ > > > /usr/x86_64-linux-gnu/include/sys/select.h \ > > > /usr/x86_64-linux-gnu/include/bits/select.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/sigset_t.h \ > > > /usr/x86_64-linux-gnu/include/bits/types/__sigset_t.h \ > > > /usr/x86_64-linux-gnu/include/sys/sysmacros.h \ > > > /usr/x86_64-linux-gnu/include/bits/sysmacros.h \ > > > /usr/x86_64-linux-gnu/include/alloca.h \ > > > /usr/x86_64-linux-gnu/include/bits/stdlib-float.h \ > > > /usr/include/c++/8/bits/std_abs.h /usr/include/c++/8/cerrno \ > > > /usr/x86_64-linux-gnu/include/errno.h \ > > > /usr/x86_64-linux-gnu/include/bits/errno.h \ > > > /usr/x86_64-linux-gnu/include/linux/errno.h \ > > > /usr/x86_64-linux-gnu/include/asm/errno.h \ > > > /usr/x86_64-linux-gnu/include/asm-generic/errno.h \ > > > /usr/x86_64-linux-gnu/include/asm-generic/errno-base.h \ > > > /usr/include/c++/8/bits/functional_hash.h \ > > > /usr/include/c++/8/bits/basic_string.tcc \ > > > /usr/include/c++/8/bits/locale_classes.tcc \ > > > /usr/include/c++/8/bits/locale_facets.h /usr/include/c++/8/cwctype \ > > > /usr/x86_64-linux-gnu/include/wctype.h \ > > > /usr/x86_64-linux-gnu/include/bits/wctype-wchar.h \ > > > /usr/include/x86_64-linux-gnu/c++/8/bits/ctype_base.h \ > > > /usr/include/c++/8/bits/ios_base.h /usr/include/c++/8/system_error \ > > > /usr/include/x86_64-linux-gnu/c++/8/bits/error_constants.h \ > > > /usr/include/c++/8/stdexcept /usr/include/c++/8/streambuf \ > > > /usr/include/c++/8/bits/streambuf.tcc \ > > > /usr/include/c++/8/bits/streambuf_iterator.h \ > > > /usr/include/x86_64-linux-gnu/c++/8/bits/ctype_inline.h \ > > > /usr/include/c++/8/bits/locale_facets.tcc \ > > > /usr/include/c++/8/bits/locale_facets_nonio.h > /usr/include/c++/8/ctime \ > > > /usr/include/x86_64-linux-gnu/c++/8/bits/time_members.h \ > > > /usr/include/x86_64-linux-gnu/c++/8/bits/messages_members.h \ > > > /usr/x86_64-linux-gnu/include/libintl.h \ > > > /usr/include/c++/8/bits/codecvt.h \ > > > /usr/include/c++/8/bits/locale_facets_nonio.tcc \ > > > /usr/include/c++/8/bits/locale_conv.h \ > > > /usr/include/c++/8/bits/unique_ptr.h /usr/include/c++/8/utility \ > > > /usr/include/c++/8/bits/stl_relops.h /usr/include/c++/8/tuple \ > > > /usr/include/c++/8/array /usr/include/c++/8/bits/uses_allocator.h \ > > > /usr/include/c++/8/bits/invoke.h /usr/include/c++/8/fstream \ > > > /usr/include/c++/8/istream /usr/include/c++/8/ios \ > > > /usr/include/c++/8/bits/basic_ios.h \ > > > /usr/include/c++/8/bits/basic_ios.tcc /usr/include/c++/8/ostream \ > > > /usr/include/c++/8/bits/ostream.tcc > /usr/include/c++/8/bits/istream.tcc \ > > > /usr/include/x86_64-linux-gnu/c++/8/bits/basic_file.h \ > > > /usr/include/x86_64-linux-gnu/c++/8/bits/c++io.h \ > > > /usr/include/c++/8/bits/fstream.tcc /usr/include/c++/8/iostream \ > > > /usr/include/c++/8/filesystem > > > > > > > > > amazing, no? cmake find only 9 dependencies against 100+ real ones > (and I don't even speak of errors that can be caused in parsing if some -D > option is changed.... > > > > > > thanks and regards > > > JLM > > > > > > > > > Le lun. 24 juin 2019 ? 14:14, Robert Maynard < > robert.maynard at kitware.com> a ?crit : > > >> > > >> It look that starting with CMake 3.6 modification of system headers > > >> will cause CMake to recompile projects. What version of CMake and your > > >> compiler are you using? > > >> > > >> On Mon, Jun 17, 2019 at 9:40 AM jl forums > wrote: > > >> > > > >> > Hi, > > >> > I want to create a full tag file and for this require to know the > compiler full include path... there is a way to had custom includes path > but didn't found any variables for the include path.... > > >> > for example : > > >> > $ gcc-8 -v -x c -E /dev/null > > >> > Using built-in specs. > > >> > [....] > > >> > ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" > > >> > #include "..." search starts here: > > >> > #include <...> search starts here: > > >> > /usr/lib/gcc/x86_64-linux-gnu/8/include > > >> > /usr/local/include > > >> > /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed > > >> > /usr/x86_64-linux-gnu/include > > >> > /usr/include/x86_64-linux-gnu > > >> > /usr/include > > >> > End of search list. > > >> > [...] > > >> > > > >> > $ gcc -v -x c -E /dev/null > > >> > Using built-in specs. > > >> > [...] > > >> > ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" > > >> > #include "..." search starts here: > > >> > #include <...> search starts here: > > >> > /usr/lib/gcc/x86_64-linux-gnu/7/include > > >> > /usr/local/include > > >> > /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed > > >> > /usr/x86_64-linux-gnu/include > > >> > /usr/include/x86_64-linux-gnu > > >> > /usr/include > > >> > End of search list. > > >> > [...] > > >> > > > >> > I tried to > > >> > > > >> > > > >> > get_target_property(moggle_interface_includes FileSync > INTERFACE_INCLUDE_DIRECTORIES) > > >> > message("Moggle interface includes: ${moggle_interface_includes}") > > >> > > > >> > get_target_property(motor_includes FileSync INCLUDE_DIRECTORIES) > > >> > message("MOTOR includes ${motor_includes}") > > >> > > > >> > but I get > > >> > > > >> > Moggle interface includes: moggle_interface_includes-NOTFOUND > > >> > MOTOR includes motor_includes-NOTFOUND > > >> > > > >> > > > >> > there is also some issue because cmake strip dependencies from > system's include, which means that updating a system software won't cause > rebuild and consider that the build is uptodate, causing unexpected results > > >> > seems that there is ways to workaround this : > https://stackoverflow.com/questions/7461000/handling-header-files-dependencies-with-cmake > but this is ugly... would be better to let the user choose with an option > > >> > > > >> > thanks and regards > > >> > JLM > > >> > -- > > >> > > > >> > Powered by www.kitware.com > > >> > > > >> > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > >> > > > >> > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > >> > > > >> > CMake Support: http://cmake.org/cmake/help/support.html > > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > >> > CMake Training Courses: http://cmake.org/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 dustyn at blasig.us Sun Jul 21 20:37:01 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Sun, 21 Jul 2019 19:37:01 -0500 Subject: [CMake] FetchContent/ExternalProject and URL_HASH In-Reply-To: References: Message-ID: Thanks for the info, Craig. I'm not very familiar with the intricacies of network downloads. If the download itself guarantees the file was transferred correctly and the checksum is only be used to verify its authenticity, then we probably don't need it as we're only downloading these artifacts from trusted internal sources. However, if the checksums need to be used in some cases to verify the download was actually received and is in one correct piece then pulling the checksum file and basically failing if either is corrupted is fine for our use case. Can we assume the former, that CMake (and the underlying tools) will guarantee the file is downloaded successfully even in the event of a CTRL-C interruption or other signals? On Sun, Jul 21, 2019 at 3:49 AM Craig Scott wrote: > > > On Wed, Jul 17, 2019 at 12:59 PM Dustyn Blasig wrote: > >> Hi All, >> >> We are pulling some artifacts from Artifactory which provides a checksum >> file along with the artifacts at .md5 or .sha256. If I do not >> include URL_HASH, does CMake automatically check to see if such a checksum >> file exists and use it's value for the hash check? Or is there a way to >> provide a URL for the checksum file rather than having to do file(DOWNLOAD >> ), file(STRING ), URL_HASH=? >> > > The point of the checksum file is to verify the file downloaded. It > doesn't make a whole lot of sense to then download another file to provide > that checksum, you'd just be moving the problem along one level of > indirection. The assumption is when you provide the URL to be downloaded, > if you want to use a checksum then you should also be able to provide that > along with the URL. When the URL is being constructed on-the-fly though, > this isn't typically true. In that case, you can't typically provide a > checksum that isn't itself downloaded and therefore needs to be verified > itself. > > To more directly answer your question, CMake doesn't offer any feature to > automatically download a checksum file (that I'm aware of). The file > command expects that actual checksum, not a location for where to retrieve > it from for the reasons mentioned above. > > -- > 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 dustyn at blasig.us Sun Jul 21 23:23:56 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Sun, 21 Jul 2019 22:23:56 -0500 Subject: [CMake] Getting library name from library target to pass to legacy Makefile Message-ID: Hi All, I am integrating a legacy Makefile with our CMake flow, and need to pass the name of a CMake library target to the Makefile via add_custom_command(). The library uses the OUTPUT_NAME property to override the default. add_library(foo_lib SHARED ...) set_target_properties(foo_lib PROPERTIES OUTPUT_NAME foo) # Generates libfoo.so add_custom_command(... COMMAND make ... FOO_LIB_LINKER_NAME= ...) I need to be the value passed to -l of g++, namely -lfoo or -lfood for debug builds. I can't seem to find an expression/property that gives this shortened name. The generator expressions like TARGET_LINKER_FILE_NAME give libfoo.so. What is the appropriate way to get just the stem of the library with the configuration-specific suffix if needed? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Mon Jul 22 02:03:52 2019 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Mon, 22 Jul 2019 08:03:52 +0200 Subject: [CMake] Getting library name from library target to pass to legacy Makefile In-Reply-To: References: Message-ID: <127c8803-b1e0-49ba-879d-31a211f90972@Spark> You can use generator expression TARGET_FILE_BASE_NAME, available with version 3.15. Le 22 juil. 2019 ? 05:24 +0200, Dustyn Blasig , a ?crit : > Hi All, > > I am integrating a legacy Makefile with our CMake flow, and need to pass the name of a CMake library target to the Makefile via add_custom_command(). The library uses the OUTPUT_NAME property to override the default. > > add_library(foo_lib SHARED ...) > set_target_properties(foo_lib PROPERTIES OUTPUT_NAME foo) # Generates libfoo.so > add_custom_command(... COMMAND make ... FOO_LIB_LINKER_NAME= ...) > > I need to be the value passed to -l of g++, namely -lfoo or -lfood for debug builds. I can't seem to find an expression/property that gives this shortened name. The generator expressions like TARGET_LINKER_FILE_NAME give libfoo.so. > > What is the appropriate way to get just the stem of the library with the configuration-specific suffix if needed? > > Thanks! > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Mon Jul 22 06:58:20 2019 From: craig.scott at crascit.com (Craig Scott) Date: Mon, 22 Jul 2019 20:58:20 +1000 Subject: [CMake] FetchContent/ExternalProject and URL_HASH In-Reply-To: References: Message-ID: On Mon, Jul 22, 2019 at 10:37 AM Dustyn Blasig wrote: > Thanks for the info, Craig. > > I'm not very familiar with the intricacies of network downloads. If the > download itself guarantees the file was transferred correctly and the > checksum is only be used to verify its authenticity, then we probably don't > need it as we're only downloading these artifacts from trusted internal > sources. However, if the checksums need to be used in some cases to verify > the download was actually received and is in one correct piece then pulling > the checksum file and basically failing if either is corrupted is fine for > our use case. Can we assume the former, that CMake (and the underlying > tools) will guarantee the file is downloaded successfully even in the event > of a CTRL-C interruption or other signals? > I don't think it is realistic to expect CMake or the underlying tools to still give you a successful file download if you interrupt it. ;) One of the things the file(DOWNLOAD) command uses the checksum for is to check if it can avoid having to download the file already exists. Without the checksum, if there is already a file at the destination, CMake can't tell if it is the right file and will download it again each time. Something I hadn't considered in my previous reply was if the file to be downloaded is very big, then it may still end up being more efficient to download the separate checksum file each time and read the big file's checksum from it to avoid re-downloading the big file if you've already got it from a previous run. Another reason you might want to explicitly specify the checksum rather than download a checksum file is that after you've done a configure once, you won't need to do any network communication to get it for subsequent runs because the checksum can be used to confirm you already have the right file. This allows you to run configure while connected to the network, then disconnect and work offline thereafter (handy if you're on a laptop and travelling!). Another use for the checksum file is to ensure you are receiving the file you expect from the source. This can help catch things like man-in-the-middle attacks or other malicious acts where the download is intercepted and some other file substituted. If you have a trustworthy connection to the source, this is less likely to be a concern for you, but I'll leave that to your own judgement. > > > On Sun, Jul 21, 2019 at 3:49 AM Craig Scott > wrote: > >> >> >> On Wed, Jul 17, 2019 at 12:59 PM Dustyn Blasig wrote: >> >>> Hi All, >>> >>> We are pulling some artifacts from Artifactory which provides a checksum >>> file along with the artifacts at .md5 or .sha256. If I do not >>> include URL_HASH, does CMake automatically check to see if such a checksum >>> file exists and use it's value for the hash check? Or is there a way to >>> provide a URL for the checksum file rather than having to do file(DOWNLOAD >>> ), file(STRING ), URL_HASH=? >>> >> >> The point of the checksum file is to verify the file downloaded. It >> doesn't make a whole lot of sense to then download another file to provide >> that checksum, you'd just be moving the problem along one level of >> indirection. The assumption is when you provide the URL to be downloaded, >> if you want to use a checksum then you should also be able to provide that >> along with the URL. When the URL is being constructed on-the-fly though, >> this isn't typically true. In that case, you can't typically provide a >> checksum that isn't itself downloaded and therefore needs to be verified >> itself. >> >> To more directly answer your question, CMake doesn't offer any feature to >> automatically download a checksum file (that I'm aware of). The file >> command expects that actual checksum, not a location for where to retrieve >> it from for the reasons mentioned above. >> > -- 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 dustyn at blasig.us Mon Jul 22 11:51:09 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Mon, 22 Jul 2019 10:51:09 -0500 Subject: [CMake] FetchContent/ExternalProject and URL_HASH In-Reply-To: References: Message-ID: *"I don't think it is realistic to expect CMake or the underlying tools to still give you a successful file download if you interrupt it. ;)"* Sorry, I didn't word that well : ) I was curious if CMake uses handlers behind the scenes similar to GNU Make such that if a signal occurs it will cleanup any partially-written files so the next time you build it will retry those targets. In this case, if the download is interrupted, will CMake know it needs to redo the download? Are the checksum files used to verify the download was successful, or really only useful for authenticity like the man-in-the-middle attacks? I definitely like the download and configure once and reuse the download offline part, that is useful! On Mon, Jul 22, 2019 at 5:58 AM Craig Scott wrote: > > > On Mon, Jul 22, 2019 at 10:37 AM Dustyn Blasig wrote: > >> Thanks for the info, Craig. >> >> I'm not very familiar with the intricacies of network downloads. If the >> download itself guarantees the file was transferred correctly and the >> checksum is only be used to verify its authenticity, then we probably don't >> need it as we're only downloading these artifacts from trusted internal >> sources. However, if the checksums need to be used in some cases to verify >> the download was actually received and is in one correct piece then pulling >> the checksum file and basically failing if either is corrupted is fine for >> our use case. Can we assume the former, that CMake (and the underlying >> tools) will guarantee the file is downloaded successfully even in the event >> of a CTRL-C interruption or other signals? >> > > I don't think it is realistic to expect CMake or the underlying tools to > still give you a successful file download if you interrupt it. ;) > > One of the things the file(DOWNLOAD) command uses the checksum for is to > check if it can avoid having to download the file already exists. Without > the checksum, if there is already a file at the destination, CMake can't > tell if it is the right file and will download it again each time. > Something I hadn't considered in my previous reply was if the file to be > downloaded is very big, then it may still end up being more efficient to > download the separate checksum file each time and read the big file's > checksum from it to avoid re-downloading the big file if you've already got > it from a previous run. > > Another reason you might want to explicitly specify the checksum rather > than download a checksum file is that after you've done a configure once, > you won't need to do any network communication to get it for subsequent > runs because the checksum can be used to confirm you already have the right > file. This allows you to run configure while connected to the network, then > disconnect and work offline thereafter (handy if you're on a laptop and > travelling!). > > Another use for the checksum file is to ensure you are receiving the file > you expect from the source. This can help catch things like > man-in-the-middle attacks or other malicious acts where the download is > intercepted and some other file substituted. If you have a trustworthy > connection to the source, this is less likely to be a concern for you, but > I'll leave that to your own judgement. > > > >> >> >> On Sun, Jul 21, 2019 at 3:49 AM Craig Scott >> wrote: >> >>> >>> >>> On Wed, Jul 17, 2019 at 12:59 PM Dustyn Blasig wrote: >>> >>>> Hi All, >>>> >>>> We are pulling some artifacts from Artifactory which provides a >>>> checksum file along with the artifacts at .md5 or .sha256. If >>>> I do not include URL_HASH, does CMake automatically check to see if such a >>>> checksum file exists and use it's value for the hash check? Or is there a >>>> way to provide a URL for the checksum file rather than having to do >>>> file(DOWNLOAD ), file(STRING ), >>>> URL_HASH=? >>>> >>> >>> The point of the checksum file is to verify the file downloaded. It >>> doesn't make a whole lot of sense to then download another file to provide >>> that checksum, you'd just be moving the problem along one level of >>> indirection. The assumption is when you provide the URL to be downloaded, >>> if you want to use a checksum then you should also be able to provide that >>> along with the URL. When the URL is being constructed on-the-fly though, >>> this isn't typically true. In that case, you can't typically provide a >>> checksum that isn't itself downloaded and therefore needs to be verified >>> itself. >>> >>> To more directly answer your question, CMake doesn't offer any feature >>> to automatically download a checksum file (that I'm aware of). The file >>> command expects that actual checksum, not a location for where to retrieve >>> it from for the reasons mentioned above. >>> >> > -- > 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 dustyn at blasig.us Mon Jul 22 11:55:11 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Mon, 22 Jul 2019 10:55:11 -0500 Subject: [CMake] Getting library name from library target to pass to legacy Makefile In-Reply-To: <127c8803-b1e0-49ba-879d-31a211f90972@Spark> References: <127c8803-b1e0-49ba-879d-31a211f90972@Spark> Message-ID: Thanks, Marc. That is exactly what I need, but I'm stuck with 3.12.4 for the foreseeable future. Is there a way to get the equivalent behavior in older versions? On Mon, Jul 22, 2019 at 1:04 AM Marc CHEVRIER wrote: > You can use generator expression TARGET_FILE_BASE_NAME, available with > version 3.15. > Le 22 juil. 2019 ? 05:24 +0200, Dustyn Blasig , a ?crit > : > > Hi All, > > I am integrating a legacy Makefile with our CMake flow, and need to pass > the name of a CMake library target to the Makefile via > add_custom_command(). The library uses the OUTPUT_NAME property to override > the default. > > add_library(foo_lib SHARED ...) > set_target_properties(foo_lib PROPERTIES OUTPUT_NAME foo) # Generates > libfoo.so > add_custom_command(... COMMAND make ... FOO_LIB_LINKER_NAME= ...) > > I need to be the value passed to -l of g++, namely -lfoo or -lfood > for debug builds. I can't seem to find an expression/property that gives > this shortened name. The generator expressions like TARGET_LINKER_FILE_NAME > give libfoo.so. > > What is the appropriate way to get just the stem of the library with the > configuration-specific suffix if needed? > > Thanks! > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Mon Jul 22 13:51:48 2019 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Mon, 22 Jul 2019 19:51:48 +0200 Subject: [CMake] Getting library name from library target to pass to legacy Makefile In-Reply-To: References: <127c8803-b1e0-49ba-879d-31a211f90972@Spark> Message-ID: An alternate solution is to use generator expression TARGET_LINKER_FILE_NAME because the linker is also able to use full path names rather than radical names as library input. Le 22 juil. 2019 ? 17:55 +0200, Dustyn Blasig , a ?crit : > Thanks, Marc. That is exactly what I need, but I'm stuck with 3.12.4 for the foreseeable future. Is there a way to get the equivalent behavior in older versions? > > > On Mon, Jul 22, 2019 at 1:04 AM Marc CHEVRIER wrote: > > > You can use generator expression TARGET_FILE_BASE_NAME, available with version 3.15. > > > Le 22 juil. 2019 ? 05:24 +0200, Dustyn Blasig , a ?crit : > > > > Hi All, > > > > > > > > I am integrating a legacy Makefile with our CMake flow, and need to pass the name of a CMake library target to the Makefile via add_custom_command(). The library uses the OUTPUT_NAME property to override the default. > > > > > > > > add_library(foo_lib SHARED ...) > > > > set_target_properties(foo_lib PROPERTIES OUTPUT_NAME foo) # Generates libfoo.so > > > > add_custom_command(... COMMAND make ... FOO_LIB_LINKER_NAME= ...) > > > > > > > > I need to be the value passed to -l of g++, namely -lfoo or -lfood for debug builds. I can't seem to find an expression/property that gives this shortened name. The generator expressions like TARGET_LINKER_FILE_NAME give libfoo.so. > > > > > > > > What is the appropriate way to get just the stem of the library with the configuration-specific suffix if needed? > > > > > > > > Thanks! > > > > -- > > > > > > > > Powered by www.kitware.com > > > > > > > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > > > > > > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > > > > > > > CMake Support: http://cmake.org/cmake/help/support.html > > > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > > > > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > > > > > > > Follow this link to subscribe/unsubscribe: > > > > https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From fdk17 at ftml.net Mon Jul 22 14:16:21 2019 From: fdk17 at ftml.net (fdk17) Date: Mon, 22 Jul 2019 14:16:21 -0400 Subject: [CMake] FetchContent/ExternalProject and URL_HASH In-Reply-To: References: Message-ID: <3c085dde-8ad9-48d9-963c-d430c22aa978@www.fastmail.com> On Mon, Jul 22, 2019, at 11:51 AM, Dustyn Blasig wrote: > *"I don't think it is realistic to expect CMake or the underlying tools to still give you a successful file download if you interrupt it. ;)"* > > Sorry, I didn't word that well : ) > > I was curious if CMake uses handlers behind the scenes similar to GNU Make such that if a signal occurs it will cleanup any partially-written files so the next time you build it will retry those targets. In this case, if the download is interrupted, will CMake know it needs to redo the download? Are the checksum files used to verify the download was successful, or really only useful for authenticity like the man-in-the-middle attacks? > > I definitely like the download and configure once and reuse the download offline part, that is useful! > I recall FetchContent being smart enough to determine that it was interrupted by user. The time stamps typically don't get updated until after successfully completing the fetch and configure. So it?ll just redo the pieces that needs to be updated or didn?t run in the first place. The checksums are used to verify the download was successful. Typical Ethernet and TCP/IP is not robust enough to detect single bit errors in large downloads. It?s one of the reasons why md5sum accompanies ISO downloads. Less of an issue with small items but still can happen. One reason for not downloading checksum file is that you don?t know if package had an issue or if the checksum file had an issue. You wouldn?t want to download a large file because the checksum file had an error. I can see how having this feature would be beneficial to you but you may just be forced to download checksum independently and parse it first. Then use contents for the real item to be downloaded. ? F -------------- next part -------------- An HTML attachment was scrubbed... URL: From lisanhu2014 at hotmail.com Tue Jul 23 01:20:52 2019 From: lisanhu2014 at hotmail.com (=?utf-8?B?5p2OIOS4ieS5jg==?=) Date: Tue, 23 Jul 2019 05:20:52 +0000 Subject: [CMake] FindZLIB doesn't work for PGI compiler Message-ID: [https://tr.cloudmagic.com/h/v6/emailtag/tag/2.0/1563859234/288db9ab62ba963e3c33af4ebd3cc1bc/11/be623dafddc53423015ac812773b3c39/19c8011ecf80ea93f8a632d2fbd6f857/b453bc4819eacec2a20aaea0348ea875/newton.gif] Dear CMake Community, I?m here to report an error occurred when using PGI compiler. The readme for CMake asks me to ask question first in the mailing list, and here I am. I?ve installed zlib1g-dev to my system, but CMake cannot find the zlib library for me. Then I tested it on a singularity ubuntu image ( similar to docker image ), with the following settings: Ubuntu 19.04 amd64 PGI compiler community edition 19.04 CMake 3.14 CMakeLists.txt ``` project( none C CXX) find_package( ZLIB REQUIRED ) ``` If I use gcc or clang, it would create the makefile successfully, but when I use PGI compiler (pgcc, pgc++), it would report not able to find zlib. I think there might be some problem with the FindZLIB.cmake file but I couldn?t find out where is the problem. Also, when using CLion configured with PGI compiler, there would be a lot of error messages ( although we can still build the project ), the error messages are really annoying. I feel it?s because the support for PGI compiler is still not perfect yet. Really wish CMake would like to add more support for this compiler. Thank you very much for reading. Have a great day! ? Sanhu Li via Newton Mail -------------- next part -------------- An HTML attachment was scrubbed... URL: From geoffroy.jabouley at gmail.com Tue Jul 23 03:55:30 2019 From: geoffroy.jabouley at gmail.com (Geoffroy J) Date: Tue, 23 Jul 2019 09:55:30 +0200 Subject: [CMake] GHS - specify cpu option to CMake generator? In-Reply-To: References: Message-ID: In fact, while looking at a "project" file, i found the following: #!gbuild primaryTarget=arm_standalone.tgt #component top_level_project [Project] * -bsp generic* -object_dir=objs *-cpu=cortexa7* And when specifying the GHS_BSP_NAME, GHS generator ends-up adding the -bsp line into the generated project file. So i was somehow assuming that same behavior was needed for the -cpu flag Anyway, i changed the approach to just ask CMake to generate plain makefiles using a toolchain file listing all the required options for cxarm/ar. Thanks for your support ;) On Sat, 20 Jul 2019 at 02:13, frodak17 wrote: > > On Fri, Jul 19, 2019 at 2:52 PM Geoffroy J > wrote: > >> Hello >> >> i have tried today to build a library using CMake Green Hills MULTI >> generator. >> >> It seemed to work quite well, but i end up not being able to configure >> the "-cpu" option for gbuild, which i need to set to "cortexa7". >> >> I've went through the CMake code, i think something similar to >> variable GHS_BSP_NAME would work, but does not seems available at the >> moment. Does it means it cannot be done at the moment? >> >> Do you know how to achieve this? Would using CFLAGS/LDFLAGS a viable >> solution? >> >> Thanks in advance for your answer >> Regards >> >> > I see -cpu as an option for armcc not for gbuild. > > You should be able to pass the -cpu option per target like any other > compiler option. > So try using target_compile_options(). > Some options are builder options so they don't start with a dash but with > a colon but it still should work with target_compile_options(). > > However my experience has been that is handled by the BSP .bld files for > the particular target / platform. > If the BSP target file has the wrong cpu in it then it probably could just > get updated and then it should "just work". > For example some of the .bld files contain a ":arm_cputype=cortexa8". > But I couldn't tell you exactly which files would need to be updated. > > -- > F > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gordon.koefner at vires.com Tue Jul 23 04:55:04 2019 From: gordon.koefner at vires.com (Gordon Koefner) Date: Tue, 23 Jul 2019 10:55:04 +0200 Subject: [CMake] Excluding targets from install set Message-ID: Hi all! We have been migrating our buildsystem to CMake and are trying to use the `install` command to deploy different parts of the software. However `make install` also installs artifacts from our dependencies, internal as well as 3rd party, that are unnecessary/unwanted. Is there a native way to exclude certain subdirectories or build targets from the install set? The only solution I could think of is to manually add an option, e.g.:?? option(${TARGET_NAME}_INSTALL on "") # on by default if(${TARGET_NAME}_INSTALL) install(...) endif() Maybe the culprit is also that we are using find_path and add_subdirectory to add any internal dependencies we have to the build tree - I am starting to think that this is a mistake. I have read about ExternalProject - but I am unsure whether this is the correct way to go about it but it does allow modification of another build. How do you guys solve this issue, how can I define which dependencies I want installed? I really want to avoid writing a shellscript to filter out any unwanted stuff. Best Regards and thank you in advance! Gordon -- Gordon Koefner - Software Engineer VIRES Simulationstechnologie GmbH A Member of the MSC.Software Group of Companies Grassinger Strasse 8 ? 83043 Bad Aibling ? Germany Phone: +49.8061.939093-54 Fax: +49.8061.939093-13 Email: gordon.koefner at vires.com Internet: www.vires.com VIRES Simulationstechnologie GmbH, Firmensitz: Grassinger Strasse 8, D-83043 Bad Aibling Registergericht: Traunstein - HRB 10410, Gesch?ftsf?hrer: Marius Dupuis Email Disclaimer: https://vires.com/e-mail-disclaimer/ From hex7c3 at gmail.com Tue Jul 23 08:27:50 2019 From: hex7c3 at gmail.com (hex) Date: Tue, 23 Jul 2019 13:27:50 +0100 Subject: [CMake] import objects to CMake Message-ID: <8a69c574-5109-24a2-6fc7-82118216e5b3@gmail.com> hello community, Following an example on the usage of IMPORTED_OBJECTS from the book "Professional CMake" I receive the following error: /Error evaluating generator expression:// // //??? $// // //? Expression did not evaluate to a known generator expression/ I wonder if there is a mistake in the code snippet? I was able to make it work using TARGET_OBJECTS instead of TARGET_SOURCES (CMake 3.15). this is the original CMakeLists.txt: add_library(myObjLib OBJECT IMPORTED) set_target_properties(myObjLib PROPERTIES ?? IMPORTED_OBJECTS /some/path/obj1.obj ??????????????????? /some/path/obj2.obj ) add_executable(myExe $) -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Tue Jul 23 08:55:33 2019 From: craig.scott at crascit.com (Craig Scott) Date: Tue, 23 Jul 2019 22:55:33 +1000 Subject: [CMake] import objects to CMake In-Reply-To: <8a69c574-5109-24a2-6fc7-82118216e5b3@gmail.com> References: <8a69c574-5109-24a2-6fc7-82118216e5b3@gmail.com> Message-ID: On Tue, Jul 23, 2019 at 10:27 PM hex wrote: > hello community, > > Following an example on the usage of IMPORTED_OBJECTS from the book > "Professional CMake" > I'm happy to accept corrections and suggestions for the book at the following link (it's a more appropriate channel than here on this list): https://crascit.com/contact/ > I receive the following error: > > *Error evaluating generator expression:* > > * $* > > * Expression did not evaluate to a known generator expression* > > > I wonder if there is a mistake in the code snippet? I was able to make it > work using TARGET_OBJECTS instead of TARGET_SOURCES (CMake 3.15). > Yes it is an error, it should have been $. It will be corrected in the next update. Thanks. > this is the original CMakeLists.txt: > add_library(myObjLib OBJECT IMPORTED) > set_target_properties(myObjLib PROPERTIES > IMPORTED_OBJECTS /some/path/obj1.obj > /some/path/obj2.obj > ) > > add_executable(myExe $) > -- 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 jason.m.beach at gmail.com Wed Jul 24 07:29:06 2019 From: jason.m.beach at gmail.com (Jason Beach) Date: Wed, 24 Jul 2019 07:29:06 -0400 Subject: [CMake] add_subdirectory namespaces Message-ID: I've been reorganizing / updating our software cmake build. It currently uses a mixture of Externa Projects and normal target definitions that depend on the external projects (which has you probably know causes much sorrow and grief). One of my goals in the reorganization was to replace all the ExternalProjectAdd statements with FetchContent, however I soon discovered that some of the external projects declare targets with the same name (i.e. an uninstall target). These external projects are third party libraries that are not under our control. It appears there's been a suggestion to add namespaces to the add_subdirectory command: https://gitlab.kitware.com/cmake/cmake/issues/16414 Is that going anywhere? It seems like that would address FetchContent's main limitation. I guess for the time being I'll use ExternalProject for thirdparty libraries not under our control and FetchContent for libraries that are and do a true super build instead of the muddled sort of arrangement we have now. One other kind of not-so-random question-the documentation on the Project statement is fine if it's in the toplevel CMakeLists.txt (in which case it defines some project level variables, etc.) but it's silent about what happens if it's not in the top level CMakeLists.txt. i.e. if I add a library via add_subdirectory or FetchContent and that library's toplevel CMakeLists.txt has the project statement, what happens when it's executed? Is it silently ignored? Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristian.adam at gmail.com Wed Jul 24 11:36:01 2019 From: cristian.adam at gmail.com (Cristian Adam) Date: Wed, 24 Jul 2019 17:36:01 +0200 Subject: [CMake] Hunter [CMake/C++] Package Manager: To be or not to be Message-ID: Hi, For those of you who use Hunter for package management with CMake, its maintainer has issued a call for support to keep it alive or take over its maintainership: https://github.com/ruslo/hunter/issues/1921 Hunter is different than vcpkg and Conan, it uses only CMake to do the package management. It also uses more CMake features than the others. Let's take pcre2 package for example. Which has bzip2 and zlib as dependencies. pcre2 package has a peculiarity when it's built as a static library, it needs the PCRE2_STATIC definition. - Conan pcre2 package. - vcpkg pcre2 package. - Hunter pcre2 package. Conan is not using pcre2's CMake build system, instead the package is being build with the Conan Python infrastructure. I don't know if in the end you'll have CMake Module or CMake Config packages. vcpkg is using pcre2's CMake build system. It controls it from outside, and afterwards it does some patching to ensure PCRE2_STATIC works as expected. vcpkg is using CMake Module packages. In the vcpkg portfile the zlib and bzip2 dependencies are not mentioned. I assume they are somehow available in the vcpkg build environment prior to building pcre2. Hunter is using pcre2's CMake build system, and it does modify the pcre2's CMakeLists.txt to call the Hunter CMake API. It handles the dependencies, and then it properly installs / exports a CMake Config package. In the commit history you can see what it takes to import a package in the Hunter repository. At QTBUG-75578 there is a description on how to use Hunter to download / build / install the 3rd party dependencies of Qt6::Base module, in order to build it on Windows with MinGW. You only need to edit one CMakeLists.txt file. I would like to point out that Ruslan Baratov contributed the IPO/LTO functionality that landed in CMake 3.9. Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benshadwick at gmail.com Wed Jul 24 18:36:00 2019 From: benshadwick at gmail.com (Benjamin Shadwick) Date: Wed, 24 Jul 2019 15:36:00 -0700 Subject: [CMake] Shortcomings with exporting and importing targets Message-ID: As a followup to my previous email dated 7/15/19, I learned from a co-worker this week that if Project A's target_link_libraries() links against an explicit path+filename of an external library, a subsequent install(TARGETS ...) command will actually include that dependency in the exported target for Library A1, such that it will be picked up as a transitive dependency when later linking Library A1 into a binary in Project B. This makes me think that install(TARGETS ...) not supporting imported targets is likely an oversight by the CMake developers. This ought to be fixed, because it effectively discourages people from following the "modern CMake" approach of using targets wherever possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Jul 25 08:42:57 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 25 Jul 2019 08:42:57 -0400 Subject: [CMake] add_subdirectory namespaces In-Reply-To: References: Message-ID: Subsequent calls to project() from sub-directories is supported. For calls to project from sub-directories it does everything but set CMAKE_PROJECT_NAME. On Wed, Jul 24, 2019 at 7:29 AM Jason Beach wrote: > > I've been reorganizing / updating our software cmake build. It currently uses a mixture of Externa Projects and normal target definitions that depend on the external projects (which has you probably know causes much sorrow and grief). One of my goals in the reorganization was to replace all the ExternalProjectAdd statements with FetchContent, however I soon discovered that some of the external projects declare targets with the same name (i.e. an uninstall target). These external projects are third party libraries that are not under our control. > > It appears there's been a suggestion to add namespaces to the add_subdirectory command: > https://gitlab.kitware.com/cmake/cmake/issues/16414 > > Is that going anywhere? It seems like that would address FetchContent's main limitation. I guess for the time being I'll use ExternalProject for thirdparty libraries not under our control and FetchContent for libraries that are and do a true super build instead of the muddled sort of arrangement we have now. > > One other kind of not-so-random question-the documentation on the Project statement is fine if it's in the toplevel CMakeLists.txt (in which case it defines some project level variables, etc.) but it's silent about what happens if it's not in the top level CMakeLists.txt. i.e. if I add a library via add_subdirectory or FetchContent and that library's toplevel CMakeLists.txt has the project statement, what happens when it's executed? Is it silently ignored? > > Thanks, > Jason > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 Thu Jul 25 10:48:35 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 25 Jul 2019 10:48:35 -0400 Subject: [CMake] Shortcomings with exporting and importing targets In-Reply-To: References: Message-ID: target_link_libraries() when given an explicit path+filename as PUBLIC ( not PRIVATE ) will be part of the transitive dependencies. An explicit path+filename is not a target to CMake, nor will CMake compute that it maps to an existing target ( be it imported or a 'normal' target ). > This makes me think that install(TARGETS ...) not supporting imported targets is likely an oversight by the CMake developers When exporting targets CMake exports what import targets something it depends on. So if you have target_link_libraries(my_target PUBLIC ZLIB::ZLIB) CMake when exporting my_target will export it depends on ZLIB::ZLIB. It does this so that export information is machine relocatable. It is than up to each project to generate an Config module that does the required find_package calls to re-locate ZLIB. On Wed, Jul 24, 2019 at 6:36 PM Benjamin Shadwick wrote: > > As a followup to my previous email dated 7/15/19, I learned from a co-worker this week that if Project A's target_link_libraries() links against an explicit path+filename of an external library, a subsequent install(TARGETS ...) command will actually include that dependency in the exported target for Library A1, such that it will be picked up as a transitive dependency when later linking Library A1 into a binary in Project B. > > This makes me think that install(TARGETS ...) not supporting imported targets is likely an oversight by the CMake developers. This ought to be fixed, because it effectively discourages people from following the "modern CMake" approach of using targets wherever possible. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 i.zaufi at gmail.com Thu Jul 25 11:01:58 2019 From: i.zaufi at gmail.com (Alex Turbov) Date: Thu, 25 Jul 2019 18:01:58 +0300 Subject: [CMake] Shortcomings with exporting and importing targets In-Reply-To: References: Message-ID: > It is than up to each project to generate an Config module that does the required find_package calls to re-locate ZLIB. Problems begin when mentioned dependencies are wrapped into generator expressions (e.g. $ or smth even more complicated) -- how do I know what `find_packages` to include to my ` *-config.cmake`?? On Thu, Jul 25, 2019 at 5:49 PM Robert Maynard wrote: > target_link_libraries() when given an explicit path+filename as PUBLIC > ( not PRIVATE ) will be part of the transitive dependencies. An > explicit path+filename is not a target to CMake, nor will CMake > compute that it maps to an existing target ( be it imported or a > 'normal' target ). > > > This makes me think that install(TARGETS ...) not supporting imported > targets is likely an oversight by the CMake developers > > When exporting targets CMake exports what import targets something it > depends on. So if you have target_link_libraries(my_target PUBLIC > ZLIB::ZLIB) CMake when exporting my_target will export it depends on > ZLIB::ZLIB. It does this so that export information is machine > relocatable. > It is than up to each project to generate an Config module that does > the required find_package calls to re-locate ZLIB. > > On Wed, Jul 24, 2019 at 6:36 PM Benjamin Shadwick > wrote: > > > > As a followup to my previous email dated 7/15/19, I learned from a > co-worker this week that if Project A's target_link_libraries() links > against an explicit path+filename of an external library, a subsequent > install(TARGETS ...) command will actually include that dependency in the > exported target for Library A1, such that it will be picked up as a > transitive dependency when later linking Library A1 into a binary in > Project B. > > > > This makes me think that install(TARGETS ...) not supporting imported > targets is likely an oversight by the CMake developers. This ought to be > fixed, because it effectively discourages people from following the "modern > CMake" approach of using targets wherever possible. > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/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 robert.maynard at kitware.com Thu Jul 25 11:21:30 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 25 Jul 2019 11:21:30 -0400 Subject: [CMake] Shortcomings with exporting and importing targets In-Reply-To: References: Message-ID: In general you match every find_package call in your project with one in your generate config file. If you have complicated conditional dependencies you might be able to use file(GENERATE to determine which ones will be used. On Thu, Jul 25, 2019 at 11:02 AM Alex Turbov wrote: > > > It is than up to each project to generate an Config module that does > the required find_package calls to re-locate ZLIB. > > Problems begin when mentioned dependencies are wrapped into generator expressions (e.g. $ or smth even more complicated) -- how do I know what `find_packages` to include to my `*-config.cmake`?? > > On Thu, Jul 25, 2019 at 5:49 PM Robert Maynard wrote: >> >> target_link_libraries() when given an explicit path+filename as PUBLIC >> ( not PRIVATE ) will be part of the transitive dependencies. An >> explicit path+filename is not a target to CMake, nor will CMake >> compute that it maps to an existing target ( be it imported or a >> 'normal' target ). >> >> > This makes me think that install(TARGETS ...) not supporting imported targets is likely an oversight by the CMake developers >> >> When exporting targets CMake exports what import targets something it >> depends on. So if you have target_link_libraries(my_target PUBLIC >> ZLIB::ZLIB) CMake when exporting my_target will export it depends on >> ZLIB::ZLIB. It does this so that export information is machine >> relocatable. >> It is than up to each project to generate an Config module that does >> the required find_package calls to re-locate ZLIB. >> >> On Wed, Jul 24, 2019 at 6:36 PM Benjamin Shadwick wrote: >> > >> > As a followup to my previous email dated 7/15/19, I learned from a co-worker this week that if Project A's target_link_libraries() links against an explicit path+filename of an external library, a subsequent install(TARGETS ...) command will actually include that dependency in the exported target for Library A1, such that it will be picked up as a transitive dependency when later linking Library A1 into a binary in Project B. >> > >> > This makes me think that install(TARGETS ...) not supporting imported targets is likely an oversight by the CMake developers. This ought to be fixed, because it effectively discourages people from following the "modern CMake" approach of using targets wherever possible. >> > -- >> > >> > Powered by www.kitware.com >> > >> > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> > >> > Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> > >> > CMake Support: http://cmake.org/cmake/help/support.html >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> > CMake Training Courses: http://cmake.org/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 i.zaufi at gmail.com Thu Jul 25 11:50:26 2019 From: i.zaufi at gmail.com (Alex Turbov) Date: Thu, 25 Jul 2019 18:50:26 +0300 Subject: [CMake] Shortcomings with exporting and importing targets In-Reply-To: References: Message-ID: Unfortunately, your approach won't work %( - first of all to write a `*-config.cmake` file the user gonna use `configure_package_config_file` (which is end up w/ `configure_file`). there is no place to use `file(GENERATE...)` since its result appears too late... - Ok, I can imagine that in the middle of `*-config.cmake` one can do `include(genex-expanded-blah-blah.cmake)` which is the result of `file(GENERATE...)` from the CMake run. But, the next problem is to match imported targets (obviously generated as a list variable) to the package names, versions, and components suitable for `find_package`... - The next problem: some finders could be tuned via variables (e.g. `OPENSSL_USE_STATIC_LIBS`, `Boost_USE_MULTITHREADED`, &etc) or even worse -- finder was given a path hint to load particular build of the third-party dependency (e.g. `XXX_ROOT_DIR`)... So, I'd be happy if CMake could take care of imported targets (loaded via `find_package`) for me and allows me to easily generate an export targets file with required `find_packages` *really used* by my target... On Thu, Jul 25, 2019 at 6:22 PM Robert Maynard wrote: > In general you match every find_package call in your project with one > in your generate config file. If you have complicated conditional > dependencies you might be able to use file(GENERATE to determine which > ones will be used. > > > On Thu, Jul 25, 2019 at 11:02 AM Alex Turbov wrote: > > > > > It is than up to each project to generate an Config module that does > > the required find_package calls to re-locate ZLIB. > > > > Problems begin when mentioned dependencies are wrapped into generator > expressions (e.g. $ or smth even more > complicated) -- how do I know what `find_packages` to include to my > `*-config.cmake`?? > > > > On Thu, Jul 25, 2019 at 5:49 PM Robert Maynard < > robert.maynard at kitware.com> wrote: > >> > >> target_link_libraries() when given an explicit path+filename as PUBLIC > >> ( not PRIVATE ) will be part of the transitive dependencies. An > >> explicit path+filename is not a target to CMake, nor will CMake > >> compute that it maps to an existing target ( be it imported or a > >> 'normal' target ). > >> > >> > This makes me think that install(TARGETS ...) not supporting imported > targets is likely an oversight by the CMake developers > >> > >> When exporting targets CMake exports what import targets something it > >> depends on. So if you have target_link_libraries(my_target PUBLIC > >> ZLIB::ZLIB) CMake when exporting my_target will export it depends on > >> ZLIB::ZLIB. It does this so that export information is machine > >> relocatable. > >> It is than up to each project to generate an Config module that does > >> the required find_package calls to re-locate ZLIB. > >> > >> On Wed, Jul 24, 2019 at 6:36 PM Benjamin Shadwick < > benshadwick at gmail.com> wrote: > >> > > >> > As a followup to my previous email dated 7/15/19, I learned from a > co-worker this week that if Project A's target_link_libraries() links > against an explicit path+filename of an external library, a subsequent > install(TARGETS ...) command will actually include that dependency in the > exported target for Library A1, such that it will be picked up as a > transitive dependency when later linking Library A1 into a binary in > Project B. > >> > > >> > This makes me think that install(TARGETS ...) not supporting imported > targets is likely an oversight by the CMake developers. This ought to be > fixed, because it effectively discourages people from following the "modern > CMake" approach of using targets wherever possible. > >> > -- > >> > > >> > Powered by www.kitware.com > >> > > >> > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > >> > > >> > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > >> > > >> > CMake Support: http://cmake.org/cmake/help/support.html > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> > CMake Training Courses: http://cmake.org/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 ehn.bengt at gmail.com Fri Jul 26 07:28:37 2019 From: ehn.bengt at gmail.com (Bengt Ehn) Date: Fri, 26 Jul 2019 14:28:37 +0300 Subject: [CMake] Building cmake generated UWP windows desktop project results in error MC6000 (missing WindowsBase, ...) Message-ID: Hello, I created a simple windows UWP solution with windows visual studio 2019. I did not make any changes to it but closed visual studio. Then I wrote a simple cmake file for it. However, it fails in "cmake --build" like this: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.WinFx.targets(268,9): error MC6000: Project file must include the .NET Framework assembly 'WindowsBase, PresentationCore, PresentationFramework' in the reference list. [App1\out\App1.csproj] When I add the requested .NET files, three is a different error: App1\MainPage.xaml(9,5): error MC3074: The tag 'ThemeResource' does not exist in XML namespace 'http://schemas.microsoft.com/winfx/2006/xaml/presentation'. Line 9 Position 5. [App1\out\App1.csproj] I cannot overcome these problems. I generate and compile the solution like this: *cmake -G "Visual Studio 16 2019" -A x64 -DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION=10.0 -S . -B out* *cmake --build out* Cmake version is 3.14.19050301-MSVC_2. The source files are attached but also on google drive in case they vanish. Probably there is just a simple error but I cannot find it. Thank you in advance, Bengt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: App1_uwp.zip Type: application/x-zip-compressed Size: 21859 bytes Desc: not available URL: From chuck.atkins at kitware.com Fri Jul 26 12:09:00 2019 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Fri, 26 Jul 2019 12:09:00 -0400 Subject: [CMake] FindZLIB doesn't work for PGI compiler In-Reply-To: References: Message-ID: Hi Sanu, We test pgi pretty heavily so it should work okay. Can you show the output failure you get when trying to configure? - Chuck On Tue, Jul 23, 2019, 1:21 AM ? ?? wrote: > Dear CMake Community, > > I?m here to report an error occurred when using PGI compiler. The readme > for CMake asks me to ask question first in the mailing list, and here I am. > > I?ve installed zlib1g-dev to my system, but CMake cannot find the zlib > library for me. Then I tested it on a singularity ubuntu image ( similar to > docker image ), with the following settings: > > Ubuntu 19.04 amd64 > PGI compiler community edition 19.04 > CMake 3.14 > > CMakeLists.txt > ``` > project( none C CXX) > find_package( ZLIB REQUIRED ) > ``` > > If I use gcc or clang, it would create the makefile successfully, but when > I use PGI compiler (pgcc, pgc++), it would report not able to find zlib. I > think there might be some problem with the FindZLIB.cmake file but I > couldn?t find out where is the problem. > > Also, when using CLion configured with PGI compiler, there would be a lot > of error messages ( although we can still build the project ), the error > messages are really annoying. I feel it?s because the support for PGI > compiler is still not perfect yet. Really wish CMake would like to add more > support for this compiler. > > Thank you very much for reading. Have a great day! > > ? > Sanhu Li > > via Newton Mail > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 robert.maynard at kitware.com Fri Jul 26 13:30:00 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 26 Jul 2019 13:30:00 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.15.1 available for download Message-ID: We are pleased to announce that CMake 3.15.1 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.15.1 since 3.15.0: Betsy McPhail (1): CTest: Generate Done.xml before calculating its hash Brad King (7): VS: Place intermediate files in the "ASM List Location" next to objects MSVC: Document behavior when MSVC_RUNTIME_LIBRARY is not set Clang: For MSVC ABI do not use modes older than C++14 Tests: Revert "require C++14 for the Tutorial" Makefile: Fix regression in dependencies on relative includes Help: Add 3.15.1 release notes CMake 3.15.1 James Butler (2): IRSL: Fix typo in v143 toolset version check IRSL: Fix discovery of VS 2019 v141 toolset redistributables Marc Chevrier (1): FindPython: ensure interpreter is founded when cross-compiling Marek Antoniak (1): Fix allocation in CROSSCOMPILING_EMULATOR evaluation Robert Maynard (2): FindMPI: Updated to use INTERFACE_LINK_OPTIONS FindMPI: make sure computed link flags are not de-duplicated Saleem Abdulrasool (5): Support per-language library link flags Swift: Add library search paths for dependencies Swift: add rules for static linking Swift: support multithreaded compilation Swift: support SONAME on ELFish targets From davemilter at gmail.com Sun Jul 28 12:03:23 2019 From: davemilter at gmail.com (Dave Milter) Date: Sun, 28 Jul 2019 19:03:23 +0300 Subject: [CMake] cmake + ninja how to use several CPU cores? Message-ID: Hi, I heard that ninja has great feature it allows build continue without wainting full link. So if you have library Lib and executable App, source code of App may build in parallel with source code of Lib, and sync only link stage. While other build systems force build of Lib, and only then start build of any object files of App. But is it possible to use this feature with cmake? Here my cmake code to emulate bottleneck of our build: ``` cmake_minimum_required(VERSION 3.12 FATAL_ERROR) project(imported) set(EXTERN_LIB_FILE ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib/libextern.so) set(EXTERN_LIB_INCLUDES ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib/gen) add_custom_command(OUTPUT ${EXTERN_LIB_FILE} COMMAND sh ./lib_generator.sh WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib) add_custom_target(extern_lib_target DEPENDS ${EXTERN_LIB_FILE}) add_library(extern_lib SHARED IMPORTED GLOBAL) add_dependencies(extern_lib extern_lib_target) set_target_properties(extern_lib PROPERTIES IMPORTED_LOCATION ${EXTERN_LIB_FILE} INTERFACE_INCLUDE_DIRECTORIES ${EXTERN_LIB_INCLUDES}) add_executable(app main.cpp) target_link_libraries(app extern_lib) ``` we use not C/C++ library as part of our source tree, and it builds some time, so I expect that ninja can run "main.cpp" -> main.o compilation during "extern_lib" build, but this is not happens. Is cmake has problem with add_custom_command and ninja, or the whole idea is wrong, and cmake + ninja can not work in this way, and I should use some other project generator instead of cmake for this? From Alan.W.Irwin1234 at gmail.com Sun Jul 28 17:01:47 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Sun, 28 Jul 2019 14:01:47 -0700 (PDT) Subject: [CMake] cmake + ninja how to use several CPU cores? In-Reply-To: References: Message-ID: On 2019-07-28 19:03+0300 Dave Milter wrote: > Hi, > > I heard that ninja has great feature it allows build continue without > wainting full link. > > So if you have library Lib and executable App, > source code of App may build in parallel with source code of Lib, > and sync only link stage. While other build systems force build of Lib, > and only then start build of any object files of App. > > But is it possible to use this feature with cmake? > > Here my cmake code to emulate bottleneck of our build: > > ``` > cmake_minimum_required(VERSION 3.12 FATAL_ERROR) > project(imported) > > set(EXTERN_LIB_FILE ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib/libextern.so) > set(EXTERN_LIB_INCLUDES ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib/gen) > add_custom_command(OUTPUT ${EXTERN_LIB_FILE} > COMMAND sh ./lib_generator.sh > WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib) > add_custom_target(extern_lib_target DEPENDS ${EXTERN_LIB_FILE}) > add_library(extern_lib SHARED IMPORTED GLOBAL) > add_dependencies(extern_lib extern_lib_target) > > set_target_properties(extern_lib > PROPERTIES > IMPORTED_LOCATION ${EXTERN_LIB_FILE} > INTERFACE_INCLUDE_DIRECTORIES ${EXTERN_LIB_INCLUDES}) > add_executable(app main.cpp) > target_link_libraries(app extern_lib) > ``` > > we use not C/C++ library as part of our source tree, > and it builds some time, > so I expect that ninja can run "main.cpp" -> main.o compilation during > "extern_lib" build, > but this is not happens. > > Is cmake has problem with add_custom_command and ninja, > or the whole idea is wrong, and cmake + ninja can not work in this way, > and I should use some other project generator instead of cmake for this? Hi Dave: To help answer your question, I see no fundamental issues with your code above. The add_dependencies(extern_lib extern_lib_target) command in your above code means that the external project that is created by building the extern_lib_target target must be *entirely* completed before the extern_lib target is built. Furthermore, the target_link_libraries(app extern_lib) command means extern_lib must be built before the app is linked which, of course, is a complete necessity. However, I don't see anything in your CMake code that demands that the compilation of main.cpp must be delayed until extern_lib is built. So can you double-check that the bottleneck is not actually the (necessary until external_lib is built) delay of linking of app rather than some unneccessary delay in the compilation of main.cpp? If the latter is really true, that appears to me to be a CMake bug (although I cannot make the final judgement call on that since I am an experienced CMake user rather than a CMake developer). And if so, does that same problem (unnecessary delay in compilation rather than linking) occur for the following simplified case? cmake_minimum_required(VERSION 3.12 FATAL_ERROR) project(test_internal_library) # Delay 10 seconds so that it is obvious if main.cpp compilation is # being unnecessarily delayed. # You should introduce boolean CMake logic here to # use the equivalent (see # ) # "timeout 10" command for the Windows case. add_custom_target(delay COMMAND sleep 10 ) add_library(intern_lib SHARED ${) # Add a 10 second delay until intern_lib is built add_dependency(intern_lib delay) add_executable(app main.cpp) target_link_libraries(app intern_lib) Also, please organize both test cases as tarballs containing simple examples (including a simplified lib_generator.sh for the first case, a 10 second delay inserted in that case as well, and simplified source code for library (e.g., containing one function to return the "hello, world" string and a simplified app (a main routine to print out that string) for both cases). Such self-contained test projects make it much more convenient for others to confirm the issue you have discovered on the platforms they have access to. For example, if you supply such self-contained test cases, I would be happy to run both test cases here on my Linux platform for both ninja and make. (I have had a lot of success with parallel builds for the make case on Linux which is why I would like to also test make just in case it turns out you have found a ninja-only CMake bug.) 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.org); 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 davemilter at gmail.com Sun Jul 28 20:36:06 2019 From: davemilter at gmail.com (Dave Milter) Date: Mon, 29 Jul 2019 03:36:06 +0300 Subject: [CMake] cmake + ninja how to use several CPU cores? In-Reply-To: References: Message-ID: Hi, On Mon, Jul 29, 2019 at 12:01 AM Alan W. Irwin wrote: > > On 2019-07-28 19:03+0300 Dave Milter wrote: > > To help answer your question, I see no fundamental issues with your code above. > > If the latter is really true, that appears to me to be a CMake bug > (although I cannot make the final judgement call on that since I am an > experienced CMake user rather than a CMake developer). And if so, does that > same problem (unnecessary delay in compilation rather than linking) > occur for the following simplified case? > In fact my code in previous email is demo code. It already contains "sleep" inside lib_generator.sh to emulate real project. I am just not sure is this good idea to send attachment into this mailing list. See attachment, it is possible only to build on Linux/Mac, because of usage bash/gcc for lib_geneator.sh And I am pretty sure that problem in cmake (or my usage of cmake), because of build.ninja generated by cmake contains such rules: ``` build cmake_object_order_depends_target_app: phony || extern_lib_target build CMakeFiles/app.dir/main.cpp.o: CXX_COMPILER__app ../main.cpp || cmake_object_order_depends_target_app ``` "||" is "order-only dependencies" according to https://ninja-build.org/manual.html#_syntax_example . So cmake instruct ninja do not build main.cpp.o untill extern_lib_target build. -------------- next part -------------- A non-text attachment was scrubbed... Name: add_library_imported.tar.gz Type: application/gzip Size: 1046 bytes Desc: not available URL: From Alan.W.Irwin1234 at gmail.com Mon Jul 29 02:39:48 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Sun, 28 Jul 2019 23:39:48 -0700 (PDT) Subject: [CMake] cmake + ninja how to use several CPU cores? In-Reply-To: References: Message-ID: Hi to Dave and Brad: @Dave: As you are probably already aware Brad is one of the primary CMake developers so I think he should be in on this discussion. @Brad: Using Dave's simple test project I confirmed the compilation delay issue below in detail for both the -G"Ninja" case AND the -G"Unix Makefiles" case on Debian Buster. Would you please take a look at this simple test case to see if you can find the explanation for this issue? @Both: I also plan to look at whether this issue exists for the internal library case so more later when I get that corresponding simple test project implemented. More details below concerning the external library case .... On 2019-07-29 03:36+0300 Dave Milter wrote: > Hi, > > On Mon, Jul 29, 2019 at 12:01 AM Alan W. Irwin > wrote: >> >> On 2019-07-28 19:03+0300 Dave Milter wrote: >> >> To help answer your question, I see no fundamental issues with your code above. >> >> If the latter is really true, that appears to me to be a CMake bug >> (although I cannot make the final judgement call on that since I am an >> experienced CMake user rather than a CMake developer). And if so, does that >> same problem (unnecessary delay in compilation rather than linking) >> occur for the following simplified case? >> > > In fact my code in previous email is demo code. It already contains > "sleep" inside lib_generator.sh to emulate > real project. @Dave: Great minds think alike concerning clearly demonstrating this issue with the help of the sleep command. :-) > I am just not sure is this good idea to send attachment into this mailing list. Actually, for obvious reasons of convenience, gzipped tarball attachments should never be an issue on mailing lists (like the CMake ones) which are relevant to discussion of software. (There are typically mailing-list limits with regard to size, but they are normally quite generous so I have never run into this issue on the CMake mailing lists. Therefore, as expected, your attachment got through to me without issues. Also, I double-checked your description of that attachment which is critical for the input mail chains of some users. In your case that description (which you can configure with your mail software) was "application/GZIP" which is obviously fine for my input mail chain case and presumably most others on this list who want to look at that attachment. @Brad: have you had any trouble seeing that attachment without your input mail chain stripping it out? > See attachment, it is possible only to build on Linux/Mac, because of > usage bash/gcc for lib_geneator.sh > > And I am pretty sure that problem in cmake (or my usage of cmake), > because of build.ninja generated by cmake contains such rules: > ``` > build cmake_object_order_depends_target_app: phony || extern_lib_target > > build CMakeFiles/app.dir/main.cpp.o: CXX_COMPILER__app ../main.cpp || > cmake_object_order_depends_target_app > ``` > "||" is "order-only dependencies" according to > https://ninja-build.org/manual.html#_syntax_example . > So cmake instruct ninja do not build main.cpp.o untill extern_lib_target build. @Dave: Thanks very much for that simple test project. @Both: I configured and built it using the Debian Buster = Stable system versions of cmake (version 3.13.4) and ninja (version 1.8.2) using the following commands I. The -G"Ninja" case.... # Fresh start: # IMPORTANT: first cd to the top-level directory of the source tree. Then # Get rid of the previously generated external library (if any) to # insure the 5 second pause associated with that generation always # occurs. rm -f extern_lib/libextern.so # Start with an empty build tree rm -rf build_dir mkdir build_dir cd build_dir # Configure time cmake -G"Ninja" .. >& cmake.out ==> real 0m1.084s user 0m0.845s sys 0m0.232s # Just to be specific (although ninja normally figures this out for itself for parallel builds) # build with -j16 since I have 16-thread hardware. Also use -v option to create (slightly more) # verbose output. time ninja -j16 -v all ==> [1/3] cd /home/irwin/David.Milter/20190728/test_ninja/add_library_imported/extern_lib && sh ./lib_generator.sh Generating... Generating...DONE [2/3] /usr/bin/c++ -isystem ../extern_lib/gen -MD -MT CMakeFiles/app.dir/main.cpp.o -MF CMakeFiles/app.dir/main.cpp.o.d -o CMakeFiles/app.dir/main.cpp.o -c ../main.cpp [3/3] : && /usr/bin/c++ CMakeFiles/app.dir/main.cpp.o -o app -Wl,-rpath,/home/irwin/David.Milter/20190728/test_ninja/add_library_imported/extern_lib ../extern_lib/libextern.so && : real 0m5.354s user 0m0.281s sys 0m0.070s Most of that real time was due to the 5 second pause (generated by the sleep command) before the "Generating...DONE" message. And clearly these results show that main.cpp was generated after that 5 second pause, i.e., the delayed compile issue is completely and unambiguously confirmed by me and should be equally easy to confirm by Brad. I also obtained the following result: irwin at merlin> grep cmake_object_order_depends_target_app build.ninja build cmake_object_order_depends_target_app: phony || extern_lib_target build CMakeFiles/app.dir/main.cpp.o: CXX_COMPILER__app ../main.cpp || cmake_object_order_depends_target_app which I agree appears to be the reason for the delayed compilation issue in the ninja case. II. The -G"Unix Makefiles" case.... N.B. It turns out the issue also occurs for the -G"Unix Makefiles" case as well, i.e., # Fresh start: # IMPORTANT: first cd to the top-level directory of the source tree. Then # Get rid of the previously generated external library (if any) to # insure the 5 second pause associated with that generation always # occurs. rm -f extern_lib/libextern.so # Start with an empty build tree rm -rf build_dir mkdir build_dir cd build_dir # Configure time cmake -G"Unix Makefiles" .. >& cmake.out ==> real 0m1.470s user 0m1.152s sys 0m0.309s That's substantially slower (by ~0.4 seconds!) than the Ninja case which is part of the reason there is so much interest in Ninja these days compared to (GNU-)make. # (GNU-make requires a -j option to use parallel builds so make it # the same -j option as in the Ninja case) # build with -j16 since I have 16-thread hardware # Also to keep output simple, do not use VERBOSE=1 option. time make -j16 all ==> Scanning dependencies of target extern_lib_target [ 33%] Generating ../extern_lib/libextern.so Generating... Generating...DONE [ 33%] Built target extern_lib_target Scanning dependencies of target app [ 66%] Building CXX object CMakeFiles/app.dir/main.cpp.o [100%] Linking CXX executable app [100%] Built target app real 0m5.482s user 0m0.397s sys 0m0.082s Note, the 5 seconds part of this is due to the pause. Therefore, the fact this is ~0.1 seconds slower than the Ninja case is pretty significant, i.e., this confirms CMake -G"Ninja" provides more nimble builds than CMake -G"Unix Makefiles" (as expected from the Ninja simplistic design principles). More importantly these -G"Unix Makefiles" results confirms that the (compilation delay) issue also appears for the make case. I have looked at the various Makefile rules generated by CMake in this case. However, they are so complex I am having trouble figuring out why the compilation of main.cpp is delayed until after the external library is built. @Brad: I hope you will be able to satisfy my curiosity about that. More later for the internal library case. 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.org); 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 Alan.W.Irwin1234 at gmail.com Mon Jul 29 05:34:11 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Mon, 29 Jul 2019 02:34:11 -0700 (PDT) Subject: [CMake] cmake + ninja how to use several CPU cores? In-Reply-To: References: Message-ID: On 2019-07-28 23:39-0700 Alan W. Irwin wrote: > @Both: I also plan to look at whether this issue exists for > the internal library case so more later when I get that > corresponding simple test project implemented. @Brad and David: I have now implemented a simple test project for the internal library case. See the attached tarball (and please let me know if your input mail software chain allows you to receive that tarball). In general I think this test case improves somewhat on Dave's test project by making the sleep more explicit at the CMake level, generating the headers explicitly rather than including them in the tarball, generating all header and source code files and the library (internal in this case) within the build tree rather than source tree (which considerably simplifies making a clean start), and by allowing the user to specify the -DBUILD_SHARED_LIBS=ON (or OFF) cmake option to choose whether the library is built shared on static. (Of course, none of these improvements should affect the delayed compilation issue.) For this new simple test project, here are the results for the -G"Ninja" case (when -DBUILD_SHARED_LIBS=ON is specified): irwin at merlin> ninja -j16 -v app [1/10] cd /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir/lib && sh /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/lib/include_generator.sh [2/10] cd /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir/lib && sh /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/lib/lib_generator.sh [3/10] cd /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir && sleep 5 [4/10] /usr/bin/c++ -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib1.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -c lib/lib1.cpp [5/10] /usr/bin/c++ -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib3.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -c lib/lib3.cpp [6/10] /usr/bin/c++ -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib4.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -c lib/lib4.cpp [7/10] /usr/bin/c++ -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib2.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -c lib/lib2.cpp [8/10] : && /usr/bin/c++ -fPIC -shared -Wl,-soname,libinternal_lib.so -o libinternal_lib.so CMakeFiles/internal_lib.dir/lib/lib1.cpp.o CMakeFiles/internal_lib.dir/lib/lib2.cpp.o CMakeFiles/internal_lib.dir/lib/lib3.cpp.o CMakeFiles/internal_lib.dir/lib/lib4.cpp.o && : [9/10] /usr/bin/c++ -Ilib -MD -MT CMakeFiles/app.dir/main.cpp.o -MF CMakeFiles/app.dir/main.cpp.o.d -o CMakeFiles/app.dir/main.cpp.o -c ../main.cpp [10/10] : && /usr/bin/c++ CMakeFiles/app.dir/main.cpp.o -o app -Wl,-rpath,/home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir libinternal_lib.so && : Note that the build of main.cpp.o is (unreasonably in my opinion) delayed to step 9. And that build is similarly delayed in the -G"Unix Makefiles" case. That is this newly implemented test case for the internal library build shows exactly the same unexplained compilation delays for main.cpp for both -G"Ninja" and -G"Unix Makefiles" as David's test case for the external library build. @Brad and other CMake developers who might be lurking here: Can anybody explain why CMake has this delayed compilation "feature" for apps that depend on internal or external libraries, and if there is no compelling reason for it would it be straightforward to remove it? 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.org); 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 -------------- A non-text attachment was scrubbed... Name: add_internal_library.tar.gz Type: application/x-gtar-compressed Size: 1108 bytes Desc: tarball for newly implemented simple test case for internal library + app URL: From bruce.r.stephens at gmail.com Mon Jul 29 06:48:20 2019 From: bruce.r.stephens at gmail.com (Bruce Stephens) Date: Mon, 29 Jul 2019 11:48:20 +0100 Subject: [CMake] cmake + ninja how to use several CPU cores? In-Reply-To: References: Message-ID: You might find it interesting to look at build.ninja. By the looks of it there's a (phony) target guving the dependencies of the library. (That's called cmake_object_order_depends_target_internal_lib) and CMakeFiles/app.dir/main.cpp.o is depending on that. Presumably the idea is that there's no point trying to compile main.cpp before we could build the library, since (as in this case) that might require generated headers which main.cpp might need. If I get rid of the wait5 thing, then main.cpp gets compiled (using "ninja -v CMakeFiles/app.dir/main.cpp.o") without the library. Just the headers (and lib/lib1.cpp) get generated. I think it's reasonable for CMake/Ninja to require the headers be generated, especially since main.cpp does include one of them (though CMake/Ninja doesn't know that until later). lib/lib1.cpp is more arguable, but I imagine there's no real distinction made: main.cpp.o depends on all the dependencies of the libraries. On Mon, 29 Jul 2019 at 10:34, Alan W. Irwin wrote: > > On 2019-07-28 23:39-0700 Alan W. Irwin wrote: > > > @Both: I also plan to look at whether this issue exists for > > the internal library case so more later when I get that > > corresponding simple test project implemented. > > @Brad and David: > > I have now implemented a simple test project for the internal library > case. See the attached tarball (and please let me know if your input > mail software chain allows you to receive that tarball). In general I > think this test case improves somewhat on Dave's test project by > making the sleep more explicit at the CMake level, generating the > headers explicitly rather than including them in the tarball, > generating all header and source code files and the library (internal > in this case) within the build tree rather than source tree (which > considerably simplifies making a clean start), and by allowing the > user to specify the -DBUILD_SHARED_LIBS=ON (or OFF) cmake option to > choose whether the library is built shared on static. (Of course, > none of these improvements should affect the delayed compilation > issue.) > > For this new simple test project, here are the results for the -G"Ninja" case (when -DBUILD_SHARED_LIBS=ON is specified): > > irwin at merlin> ninja -j16 -v app > [1/10] cd /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir/lib && sh /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/lib/include_generator.sh > [2/10] cd /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir/lib && sh /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/lib/lib_generator.sh > [3/10] cd /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir && sleep 5 > [4/10] /usr/bin/c++ -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib1.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -c lib/lib1.cpp > [5/10] /usr/bin/c++ -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib3.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -c lib/lib3.cpp > [6/10] /usr/bin/c++ -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib4.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -c lib/lib4.cpp > [7/10] /usr/bin/c++ -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib2.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -c lib/lib2.cpp > [8/10] : && /usr/bin/c++ -fPIC -shared -Wl,-soname,libinternal_lib.so -o libinternal_lib.so CMakeFiles/internal_lib.dir/lib/lib1.cpp.o CMakeFiles/internal_lib.dir/lib/lib2.cpp.o CMakeFiles/internal_lib.dir/lib/lib3.cpp.o CMakeFiles/internal_lib.dir/lib/lib4.cpp.o && : > [9/10] /usr/bin/c++ -Ilib -MD -MT CMakeFiles/app.dir/main.cpp.o -MF CMakeFiles/app.dir/main.cpp.o.d -o CMakeFiles/app.dir/main.cpp.o -c ../main.cpp > [10/10] : && /usr/bin/c++ CMakeFiles/app.dir/main.cpp.o -o app -Wl,-rpath,/home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir libinternal_lib.so && : > > Note that the build of main.cpp.o is (unreasonably in my opinion) delayed to step 9. > > And that build is similarly delayed in the -G"Unix Makefiles" case. > That is this newly implemented test case for the internal library > build shows exactly the same unexplained compilation delays for > main.cpp for both -G"Ninja" and -G"Unix Makefiles" as David's test > case for the external library build. > > @Brad and other CMake developers who might be lurking here: > > Can anybody explain why CMake has this delayed compilation "feature" > for apps that depend on internal or external libraries, and if there > is no compelling reason for it would it be straightforward to remove > it? > > 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.org); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________-- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake From davemilter at gmail.com Mon Jul 29 11:50:01 2019 From: davemilter at gmail.com (Dave Milter) Date: Mon, 29 Jul 2019 18:50:01 +0300 Subject: [CMake] cmake + ninja how to use several CPU cores? In-Reply-To: References: Message-ID: On Mon, Jul 29, 2019 at 1:48 PM Bruce Stephens wrote: > > I think it's reasonable for CMake/Ninja to require the headers be > generated, especially since main.cpp does include one of them (though > CMake/Ninja doesn't know that until later). lib/lib1.cpp is more > arguable, but I imagine there's no real distinction made: main.cpp.o > depends on all the dependencies of the libraries. > In my initial example headers files are not generated in cmake scripts. Only source code are generated, so main.cpp -> main.cpp.o doesn't depend on anything. But generated by cmake build.ninja still require link of extern_lib before starting main.cpp -> main.cpp.o From brad.king at kitware.com Mon Jul 29 13:24:51 2019 From: brad.king at kitware.com (Brad King) Date: Mon, 29 Jul 2019 13:24:51 -0400 Subject: [CMake] cmake + ninja how to use several CPU cores? In-Reply-To: References: Message-ID: On 7/29/19 11:50 AM, Dave Milter wrote: > Only source code are generated, so main.cpp -> main.cpp.o doesn't > depend on anything. > But generated by cmake build.ninja still require link of extern_lib > before starting main.cpp -> main.cpp.o If there are any custom commands in any targets on which main.cpp's target depends then CMake must pessimistically assume that the custom commands may generate a header needed to compile `main.cpp`. Object libraries can be used to break the dependencies that lead to the assumption. CMake 3.9 made this much better than it used to be: https://gitlab.kitware.com/cmake/cmake/merge_requests/430 Since then all objects in a target can start compiling independently so long as that target does not depend on any targets with custom commands. -Brad From Alan.W.Irwin1234 at gmail.com Mon Jul 29 14:04:56 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Mon, 29 Jul 2019 11:04:56 -0700 (PDT) Subject: [CMake] cmake + ninja how to use several CPU cores? In-Reply-To: References: Message-ID: On 2019-07-29 18:50+0300 Dave Milter wrote: > On Mon, Jul 29, 2019 at 1:48 PM Bruce Stephens > wrote: >> >> I think it's reasonable for CMake/Ninja to require the headers be >> generated, especially since main.cpp does include one of them (though >> CMake/Ninja doesn't know that until later). lib/lib1.cpp is more >> arguable, but I imagine there's no real distinction made: main.cpp.o >> depends on all the dependencies of the libraries. >> > > In my initial example headers files are not generated in cmake scripts. > Only source code are generated, so main.cpp -> main.cpp.o doesn't > depend on anything. > But generated by cmake build.ninja still require link of extern_lib > before starting main.cpp -> main.cpp.o Thanks, Bruce, for spotting that issue with the first version of my simple example which I oversimplified. I have now corrected it (see attached tarball) to follow the use case of pre-existing headers and an app that links to a library (internal for my corrected test case, and external for David's test case). The issue (compilation of main.cpp is unreasonably delayed for parallel builds until after the library (internal or external) is built) still shows up in my corrected test case for both -G"Ninja" and -G"Unix Makefiles" just like happens for David's test case for an external library. So the question remains why does CMake constrain parallel builds this way (to the point that it is a bottlneck for David's real project with external libraries) for this general use case? 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.org); 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 -------------- A non-text attachment was scrubbed... Name: corrected_add_internal_library.tar.gz Type: application/x-gtar-compressed Size: 1087 bytes Desc: tarball containing corrected test case of app with pre-existing headers and internal library URL: From davemilter at gmail.com Mon Jul 29 15:22:35 2019 From: davemilter at gmail.com (Dave Milter) Date: Mon, 29 Jul 2019 22:22:35 +0300 Subject: [CMake] cmake + ninja how to use several CPU cores? In-Reply-To: References: Message-ID: On Mon, Jul 29, 2019 at 8:24 PM Brad King wrote: > > CMake 3.9 made this much better than it used to be: > > https://gitlab.kitware.com/cmake/cmake/merge_requests/430 > > Since then all objects in a target can start compiling independently > so long as that target does not depend on any targets with custom > commands. Is any way to tell cmake that add_custom_command is have no side effect, and OUTPUT is exactly what it produces? I see that there is Tests/RunCMake/Ninja/LooseObjectDepends.cmake in https://gitlab.kitware.com/cmake/cmake/merge_requests/430 is it negative test, or there is chance for fast compilation? From brad.king at kitware.com Mon Jul 29 15:32:04 2019 From: brad.king at kitware.com (Brad King) Date: Mon, 29 Jul 2019 15:32:04 -0400 Subject: [CMake] cmake + ninja how to use several CPU cores? In-Reply-To: References: Message-ID: <69033d7d-ab31-e158-f1d1-e1397c7350e5@kitware.com> On 7/29/19 3:22 PM, Dave Milter wrote: >> Since then all objects in a target can start compiling independently >> so long as that target does not depend on any targets with custom >> commands. See also https://gitlab.kitware.com/cmake/cmake/issues/17097 > Is any way to tell cmake that add_custom_command is have no side effect, > and OUTPUT is exactly what it produces? Even if we had that information we don't know what `main.cpp` includes until after compiling it, by which point it is too late. It could have `#include "anything.txt"` for example. CMake must add these pessimistic dependencies to ensure a correct build. The only way to avoid this is to tell CMake that there are no dependencies for compiling an object file by moving it to an object library that does not depend on any of the targets with custom commands. -Brad From Alan.W.Irwin1234 at gmail.com Mon Jul 29 16:20:08 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Mon, 29 Jul 2019 13:20:08 -0700 (PDT) Subject: [CMake] cmake + ninja how to use several CPU cores? In-Reply-To: References: Message-ID: On 2019-07-29 13:24-0400 Brad King wrote: > On 7/29/19 11:50 AM, Dave Milter wrote: >> Only source code are generated, so main.cpp -> main.cpp.o doesn't >> depend on anything. >> But generated by cmake build.ninja still require link of extern_lib >> before starting main.cpp -> main.cpp.o > > If there are any custom commands in any targets on which main.cpp's > target depends then CMake must pessimistically assume that the > custom commands may generate a header needed to compile `main.cpp`. Hi Brad: Thanks for that clarification. Clearly David's test case for an external library and my own recently corrected test case for an internal library are not consistent with that assumption which explains the bad results we get for them. However, I think there is still a problem when a project is consistent with that assumption. See the attached no_custom_add_internal_library.tar.gz which contains an extremely simple test project with no custom commands at all (i.e., no wait and headers and source are pre-existing in all cases). Yet for this project I get the following results with ninja. irwin at merlin> ninja -j16 -v app [1/7] /usr/bin/c++ -Dinternal_lib_EXPORTS -I../lib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib4.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -c ../lib/lib4.cpp [2/7] /usr/bin/c++ -Dinternal_lib_EXPORTS -I../lib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib1.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -c ../lib/lib1.cpp [3/7] /usr/bin/c++ -Dinternal_lib_EXPORTS -I../lib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib2.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -c ../lib/lib2.cpp [4/7] /usr/bin/c++ -Dinternal_lib_EXPORTS -I../lib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib3.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -c ../lib/lib3.cpp [5/7] : && /usr/bin/c++ -fPIC -shared -Wl,-soname,libinternal_lib.so -o libinternal_lib.so CMakeFiles/internal_lib.dir/lib/lib1.cpp.o CMakeFiles/internal_lib.dir/lib/lib2.cpp.o CMakeFiles/internal_lib.dir/lib/lib3.cpp.o CMakeFiles/internal_lib.dir/lib/lib4.cpp.o && : [6/7] /usr/bin/c++ -I../lib -MD -MT CMakeFiles/app.dir/main.cpp.o -MF CMakeFiles/app.dir/main.cpp.o.d -o CMakeFiles/app.dir/main.cpp.o -c ../main.cpp [7/7] : && /usr/bin/c++ CMakeFiles/app.dir/main.cpp.o -o app -Wl,-rpath,/home/irwin/David.Milter/20190728/test_ninja/no_gen_add_internal_library/build_dir libinternal_lib.so && : irwin at merlin> grep cmake_object_order_depends_target_app build.ninja build cmake_object_order_depends_target_app: phony || cmake_object_order_depends_target_internal_lib build CMakeFiles/app.dir/main.cpp.o: CXX_COMPILER__app ../main.cpp || cmake_object_order_depends_target_app 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.org); 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 davemilter at gmail.com Mon Jul 29 16:25:32 2019 From: davemilter at gmail.com (Dave Milter) Date: Mon, 29 Jul 2019 23:25:32 +0300 Subject: [CMake] cmake + ninja how to use several CPU cores? In-Reply-To: <69033d7d-ab31-e158-f1d1-e1397c7350e5@kitware.com> References: <69033d7d-ab31-e158-f1d1-e1397c7350e5@kitware.com> Message-ID: On Mon, Jul 29, 2019 at 10:32 PM Brad King wrote: > > Even if we had that information we don't know what `main.cpp` includes > until after compiling it, by which point it is too late. It could have > `#include "anything.txt"` for example. CMake must add these pessimistic > dependencies to ensure a correct build. > > The only way to avoid this is to tell CMake that there are no dependencies > for compiling an object file by moving it to an object library that does > not depend on any of the targets with custom commands. > But my custom command OUTPUT is shared library, and in my case it would be strange to '#include' it into some source file. So what about EXPLICIT_DEPENDS_ONLY mentioned https://gitlab.kitware.com/cmake/cmake/issues/17097 to mark something that no way to be included into source file? From Alan.W.Irwin1234 at gmail.com Mon Jul 29 16:27:17 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Mon, 29 Jul 2019 13:27:17 -0700 (PDT) Subject: [CMake] cmake + ninja how to use several CPU cores? In-Reply-To: <69033d7d-ab31-e158-f1d1-e1397c7350e5@kitware.com> References: <69033d7d-ab31-e158-f1d1-e1397c7350e5@kitware.com> Message-ID: On 2019-07-29 15:32-0400 Brad King wrote: > [...]We don't know what `main.cpp` includes > until after compiling it, by which point it is too late. It could have > `#include "anything.txt"` for example. CMake must add these pessimistic > dependencies to ensure a correct build. Is this the real reason why even the simplest no_custom_add_internal_library project (with nothing custom at all) still demonstrates the issue? 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.org); 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 dushara.jayasinghe at asdpl.com Tue Jul 30 01:39:15 2019 From: dushara.jayasinghe at asdpl.com (Dushara Jayasinghe) Date: Tue, 30 Jul 2019 15:39:15 +1000 Subject: [CMake] Segger Embedded Studio generator Message-ID: Hi all, I'm working on an embedded project where I'd like to use use cmake as the build system. At the same time, the Segger Embedded Studio IDE seems to have decent support for the target I'm working on (nice integration with toolchains as well as the JLink debugger). The downside with this tool is, it has its own XML based project format and doesn't support CMake or even Makefile based projects. So I was wondering if there's generator out there for this IDE? If not, I was thinking of creating a target rule to generate "an externally built project" referring to the binary generated by Ninja. Is this a good way to go about it? According to the seven year old SO answer here (https://stackoverflow.com/a/8314627), custom generators require changing the cmake sources. Is this still the case? Thanks. Dushara From kyle.edwards at kitware.com Tue Jul 30 09:46:15 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Tue, 30 Jul 2019 09:46:15 -0400 Subject: [CMake] Segger Embedded Studio generator In-Reply-To: References: Message-ID: <1564494375.3643.73.camel@kitware.com> On Tue, 2019-07-30 at 15:39 +1000, Dushara Jayasinghe wrote: > Hi all, > > I'm working on an embedded project where I'd like to use use cmake > as the build system. At the same time, the Segger Embedded Studio IDE > seems to have decent support for the target I'm working on (nice > integration with toolchains as well as the JLink debugger). The > downside with this tool is, it has its own XML based project format > and > doesn't support CMake or even Makefile based projects. So I was > wondering > if there's generator out there for this IDE? > > If not, I was thinking of creating a target rule to generate "an? > externally built project" referring to the binary generated by Ninja. > Is this a good way to go about it? > > According to the seven year old SO answer here (https://stackoverflow > .com/a/8314627), > custom generators require changing the cmake sources. Is this still > the case? Yes, new generators have to be written in CMake's C++ code. Kyle From gmstima at gmail.com Tue Jul 30 10:20:41 2019 From: gmstima at gmail.com (Roman Savchenko) Date: Tue, 30 Jul 2019 17:20:41 +0300 Subject: [CMake] include_directories SYSTEM and they propagation to target Message-ID: HI all, I will appreciate if you could help me with one question. >From manual: *include_directories:* *They are also added to the INCLUDE_DIRECTORIES target property for each target in the current CMakeLists file.* and *INTERFACE_SYSTEM_INCLUDE_DIRECTORIES:* * Targets may populate this property to publish the include directories which contain system headers, and therefore should not result in compiler warnings. * Does it mean that include_directories(SYSTEM ${PATH}) will be populated to INTERFACE_SYSTEM_INCLUDE_DIRECTORIES ? Regards, Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Tue Jul 30 14:19:54 2019 From: d3ck0r at gmail.com (J Decker) Date: Tue, 30 Jul 2019 11:19:54 -0700 Subject: [CMake] Cmake Path Please Message-ID: THere's (some) error messages that don't include the full path of the CMakeLists.txt, so I don't know what 'top level' is. It would be nice if CMakeLists.txt had the full ${CMAKE_SOURCE_DIR} (?) prepended to it. This is built as an external project of another top level project, which itself is built from some other top level cmakelists.txt. ``` [636/1094] Performing configure step for 'sack_vfs_command_portable' CMake Warning (dev) in CMakeLists.txt: No project() command is present. The top-level CMakeLists.txt file must contain a literal, direct call to the project() command. Add a line of code such as project(ProjectName) near the top of the file, but after cmake_minimum_required(). CMake is pretending there is a "project(Project)" command on the first line. ``` -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.menzel at gmail.com Wed Jul 31 02:20:51 2019 From: stephan.menzel at gmail.com (Stephan Menzel) Date: Wed, 31 Jul 2019 08:20:51 +0200 Subject: [CMake] find_file - strange behavior when using Android toolchain Message-ID: Hello all, I'm trying to adapt my CMake based toolchain to Android and I'm noticing very strange behavior that I'd like to ask about. My toolchain is C++ based with some dependencies such as Boost, OpenSSL or protobuf. So far it works on a variety of platforms such as Windows (MSVC), several Linuxes, including Raspbian on ARM. So I considered myself well prepared for Android, thinking it can't be that different. How wrong I was... I'm cross compiling from a Linux system, which is able to build the source in question just fine with clang and gcc. Most recent Android SDK and bundled NDK. As soon as I started building and finding my 3rd party dependencies I noticed that many commands in my own scripts or others that try to find a file (like a header) or a lib fail despite the file being there. Like here in this case for example (randomly taken from the AWS SDK installed CMake finders): find_file(AWSSDK_CORE_HEADER_FILE Aws.h "${AWSSDK_ROOT_DIR}/${AWSSDK_INSTALL_INCLUDEDIR}/aws/core" "${AWSSDK_DEFAULT_ROOT_DIR}/${AWSSDK_INSTALL_INCLUDEDIR}/aws/core" ) I have double checked many times that the file clearly is there in that exact position correct casing and the process has full read permissions. I can open it for reading and I can't see anything strange about it. Just some header. But AWSSDK_CORE_HEADER_FILE is NOTFOUND. The finders for Boost and OpenSSL have the same problem whenever they use find_file or similar and so have my own. So far I have worked around the issue by hard setting the variables in question before the script runs. In this case I would look at my directories, set AWSSDK_CORE_HEADER_FILE to the file path and run it again. Then the test will pass but that can't be it. Also, a huge library like the AWS SDK has so many such commands and variables that I cannot possibly override all of them. Why does that command fail at all? I looked at the docs for find_file but I cannot see any mention of cases where the file is not found because of some toolchain or cross compile settings I have tried with the CMake that comes bundled in the NDK as well, same results. And again, it works fine on ARM in general when the ndk toolchain is not involved. I can only assume something in "ndk-bundle/build/cmake/android.toolchain.cmake" sets some global CMake setting that disables find_file. But why would they do this? And why would such a breaking setting even exist? None of that makes sense to me. Anybody have some input please? Cheers, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From doenges at mvtec.com Wed Jul 31 03:16:29 2019 From: doenges at mvtec.com (Eric Doenges) Date: Wed, 31 Jul 2019 09:16:29 +0200 Subject: [CMake] find_file - strange behavior when using Android toolchain In-Reply-To: References: Message-ID: <2ba22eaf-e8de-1d17-bc80-9257618733b5@mvtec.com> Am 31.07.19 um 08:20 schrieb Stephan Menzel: > Hello all, > > I'm trying to adapt my CMake based toolchain to Android and I'm > noticing very strange behavior that I'd like to ask about. > My toolchain is C++ based with some dependencies such as Boost, > OpenSSL or protobuf. So far it works on a variety of platforms such as > Windows (MSVC), several Linuxes, including Raspbian on ARM. So I > considered myself well prepared for Android, thinking it can't be that > different. How wrong I was... I'm cross compiling from a Linux system, > which is able to build the source in question just fine with clang and > gcc. Most recent Android SDK and bundled NDK. > > As soon as I started building and finding my 3rd party dependencies I > noticed that many commands in my own scripts or others that try to > find a file (like a header) or a lib fail despite the file being there. > Like here in this case for example (randomly taken from the AWS SDK > installed CMake finders): My experience has been that find_file and friends behave in unexpected ways when you set CMAKE_SYSROOT. In our toolchain files, we set set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) as suggested in the cmake-toolchains(7) documentation. We then add the path to the top-level directory where we keep all our thirdparty dependencies to CMAKE_FIND_ROOT_PATH, as otherwise find_package and find_path cannot find anything even when we give them the absolute path where to search (the find_file documentation suggests that the elements of the CMAKE_FIND_ROOT_PATH are prepended to the paths specified in the find_file arguments, but that does not seem to happen if the search paths are subpaths of the CMAKE_FIND_ROOT_PATH). My guess would be that the NDK does something similar, meaning you would need to add the path where to look for AWS to CMAKE_FIND_ROOT_PATH. CMake feature request: it would be real nice to have a verbose mode for the find_XXX functions that tell you exactly where CMake is looking for stuff and why to help debug problems like this. With kind regards, Eric -- *Dr. Eric D?nges * Senior Software Engineer MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany doenges at mvtec.com | Tel: +49 89 457 695-0 | www.mvtec.com Sign up for our MVTec Newsletter! Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt Amtsgericht M?nchen HRB 114695 MVTec Software GmbH Logo -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhiugeshreddy at gmail.com Wed Jul 31 03:49:07 2019 From: abhiugeshreddy at gmail.com (ugesh reddy) Date: Wed, 31 Jul 2019 09:49:07 +0200 Subject: [CMake] find_file - strange behavior when using Android toolchain In-Reply-To: <2ba22eaf-e8de-1d17-bc80-9257618733b5@mvtec.com> References: <2ba22eaf-e8de-1d17-bc80-9257618733b5@mvtec.com> Message-ID: Hi, I also have the same issue with find_file/find_path/find_package when I use the Android NDK and Eric's explanation make sense. One way to solve this find_file(AWSSDK_CORE_HEADER_FILE Aws.h "${AWSSDK_ROOT_DIR}/${AWSSDK_INSTALL_INCLUDEDIR}/aws/core" "${AWSSDK_DEFAULT_ROOT_DIR}/${AWSSDK_INSTALL_INCLUDEDIR}/aws/core" * NO_CMAKE_FIND_ROOT_PATH* * NO_CMAKE_SYSROOT* ) Regards, Ugesh Gurram. On Wed, Jul 31, 2019 at 9:16 AM Eric Doenges wrote: > Am 31.07.19 um 08:20 schrieb Stephan Menzel: > > Hello all, > > I'm trying to adapt my CMake based toolchain to Android and I'm noticing > very strange behavior that I'd like to ask about. > My toolchain is C++ based with some dependencies such as Boost, OpenSSL or > protobuf. So far it works on a variety of platforms such as Windows (MSVC), > several Linuxes, including Raspbian on ARM. So I considered myself well > prepared for Android, thinking it can't be that different. How wrong I > was... I'm cross compiling from a Linux system, which is able to build the > source in question just fine with clang and gcc. Most recent Android SDK > and bundled NDK. > > As soon as I started building and finding my 3rd party dependencies I > noticed that many commands in my own scripts or others that try to find a > file (like a header) or a lib fail despite the file being there. > Like here in this case for example (randomly taken from the AWS SDK > installed CMake finders): > > My experience has been that find_file and friends behave in unexpected > ways when you set CMAKE_SYSROOT. In our toolchain files, we set > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) > set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) > > as suggested in the cmake-toolchains(7) documentation. We then add the > path to the top-level directory where we keep all our thirdparty > dependencies to CMAKE_FIND_ROOT_PATH, as otherwise find_package and > find_path cannot find anything even when we give them the absolute path > where to search (the find_file documentation suggests that the elements of > the CMAKE_FIND_ROOT_PATH are prepended to the paths specified in the > find_file arguments, but that does not seem to happen if the search paths > are subpaths of the CMAKE_FIND_ROOT_PATH). My guess would be that the NDK > does something similar, meaning you would need to add the path where to > look for AWS to CMAKE_FIND_ROOT_PATH. > > CMake feature request: it would be real nice to have a verbose mode for > the find_XXX functions that tell you exactly where CMake is looking for > stuff and why to help debug problems like this. > > With kind regards, > Eric > -- > > * Dr. Eric D?nges * > Senior Software Engineer > > MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany > doenges at mvtec.com | Tel: +49 89 457 695-0 | www.mvtec.com > > Sign up for our MVTec Newsletter! > > Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt > Amtsgericht M?nchen HRB 114695 > > > [image: MVTec Software GmbH Logo] > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/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 > -- Ugesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhiugeshreddy at gmail.com Wed Jul 31 04:15:26 2019 From: abhiugeshreddy at gmail.com (ugesh reddy) Date: Wed, 31 Jul 2019 10:15:26 +0200 Subject: [CMake] find_file - strange behavior when using Android toolchain In-Reply-To: References: <2ba22eaf-e8de-1d17-bc80-9257618733b5@mvtec.com> Message-ID: Hi, Sorry a small correction. There is no such thing as "NO_CMAKE_SYSROOT". find_file(AWSSDK_CORE_HEADER_FILE Aws.h "${AWSSDK_ROOT_DIR}/${AWSSDK_INSTALL_INCLUDEDIR}/aws/core" "${AWSSDK_DEFAULT_ROOT_DIR}/${AWSSDK_INSTALL_INCLUDEDIR}/aws/core" NO_CMAKE_FIND_ROOT_PATH * NO_CMAKE_SYSTEM_PATH* ) Regards, Ugesh On Wed, Jul 31, 2019 at 9:49 AM ugesh reddy wrote: > Hi, > > I also have the same issue with find_file/find_path/find_package when I > use the Android NDK and Eric's explanation make sense. > > One way to solve this > > find_file(AWSSDK_CORE_HEADER_FILE Aws.h > "${AWSSDK_ROOT_DIR}/${AWSSDK_INSTALL_INCLUDEDIR}/aws/core" > > "${AWSSDK_DEFAULT_ROOT_DIR}/${AWSSDK_INSTALL_INCLUDEDIR}/aws/core" > * NO_CMAKE_FIND_ROOT_PATH* > * NO_CMAKE_SYSROOT* > ) > > Regards, > Ugesh Gurram. > > On Wed, Jul 31, 2019 at 9:16 AM Eric Doenges wrote: > >> Am 31.07.19 um 08:20 schrieb Stephan Menzel: >> >> Hello all, >> >> I'm trying to adapt my CMake based toolchain to Android and I'm noticing >> very strange behavior that I'd like to ask about. >> My toolchain is C++ based with some dependencies such as Boost, OpenSSL >> or protobuf. So far it works on a variety of platforms such as Windows >> (MSVC), several Linuxes, including Raspbian on ARM. So I considered myself >> well prepared for Android, thinking it can't be that different. How wrong I >> was... I'm cross compiling from a Linux system, which is able to build the >> source in question just fine with clang and gcc. Most recent Android SDK >> and bundled NDK. >> >> As soon as I started building and finding my 3rd party dependencies I >> noticed that many commands in my own scripts or others that try to find a >> file (like a header) or a lib fail despite the file being there. >> Like here in this case for example (randomly taken from the AWS SDK >> installed CMake finders): >> >> My experience has been that find_file and friends behave in unexpected >> ways when you set CMAKE_SYSROOT. In our toolchain files, we set >> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) >> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) >> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) >> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) >> >> as suggested in the cmake-toolchains(7) documentation. We then add the >> path to the top-level directory where we keep all our thirdparty >> dependencies to CMAKE_FIND_ROOT_PATH, as otherwise find_package and >> find_path cannot find anything even when we give them the absolute path >> where to search (the find_file documentation suggests that the elements of >> the CMAKE_FIND_ROOT_PATH are prepended to the paths specified in the >> find_file arguments, but that does not seem to happen if the search paths >> are subpaths of the CMAKE_FIND_ROOT_PATH). My guess would be that the NDK >> does something similar, meaning you would need to add the path where to >> look for AWS to CMAKE_FIND_ROOT_PATH. >> >> CMake feature request: it would be real nice to have a verbose mode for >> the find_XXX functions that tell you exactly where CMake is looking for >> stuff and why to help debug problems like this. >> >> With kind regards, >> Eric >> -- >> >> * Dr. Eric D?nges * >> Senior Software Engineer >> >> MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany >> doenges at mvtec.com | Tel: +49 89 457 695-0 | www.mvtec.com >> >> Sign up for our MVTec Newsletter! >> >> Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt >> Amtsgericht M?nchen HRB 114695 >> >> >> [image: MVTec Software GmbH Logo] >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/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 >> > > > -- > Ugesh > -- Ugesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephan.menzel at gmail.com Wed Jul 31 05:18:52 2019 From: stephan.menzel at gmail.com (Stephan Menzel) Date: Wed, 31 Jul 2019 11:18:52 +0200 Subject: [CMake] find_file - strange behavior when using Android toolchain In-Reply-To: <2ba22eaf-e8de-1d17-bc80-9257618733b5@mvtec.com> References: <2ba22eaf-e8de-1d17-bc80-9257618733b5@mvtec.com> Message-ID: Thank you, Eric and Ugesh, Am Mi., 31. Juli 2019 um 09:16 Uhr schrieb Eric Doenges : > My experience has been that find_file and friends behave in unexpected > ways when you set CMAKE_SYSROOT. In our toolchain files, we set > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) > set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) > > as suggested in the cmake-toolchains(7) documentation. We then add the > path to the top-level directory where we keep all our thirdparty > dependencies to CMAKE_FIND_ROOT_PATH, as otherwise find_package and > find_path cannot find anything even when we give them the absolute path > where to search (the find_file documentation suggests that the elements of > the CMAKE_FIND_ROOT_PATH are prepended to the paths specified in the > find_file arguments, but that does not seem to happen if the search paths > are subpaths of the CMAKE_FIND_ROOT_PATH). My guess would be that the NDK > does something similar, meaning you would need to add the path where to > look for AWS to CMAKE_FIND_ROOT_PATH. > I have just looked that up and yes, it would explain what I'm seeing. CMAKE_SYSROOT is being set by the toolchain file and it would appear as this would make all search hints and paths implicitly relative. I'm now trying to restructure my 3rd party management for this target to enable me to install my dependencies into the subdirs set as sysroot, hoping that they will then be found. Thanks for the suggestion, that looks promising. I will get back with more info on if and how that turned out. > CMake feature request: it would be real nice to have a verbose mode for > the find_XXX functions that tell you exactly where CMake is looking for > stuff and why to help debug problems like this. > Seconded. I always insert debug message() statements all over the place and then often forget to clean them up. Also, this way I can only verify the search paths are correct but not why find_file fails. Cheers, Stephan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Wed Jul 31 05:47:23 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 31 Jul 2019 11:47:23 +0200 Subject: [CMake] find_file - strange behavior when using Android toolchain In-Reply-To: References: <2ba22eaf-e8de-1d17-bc80-9257618733b5@mvtec.com> Message-ID: Le mer. 31 juil. 2019 ? 11:19, Stephan Menzel a ?crit : > Thank you, Eric and Ugesh, > > Am Mi., 31. Juli 2019 um 09:16 Uhr schrieb Eric Doenges >: > >> My experience has been that find_file and friends behave in unexpected >> ways when you set CMAKE_SYSROOT. In our toolchain files, we set >> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) >> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) >> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) >> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) >> >> as suggested in the cmake-toolchains(7) documentation. We then add the >> path to the top-level directory where we keep all our thirdparty >> dependencies to CMAKE_FIND_ROOT_PATH, as otherwise find_package and >> find_path cannot find anything even when we give them the absolute path >> where to search (the find_file documentation suggests that the elements of >> the CMAKE_FIND_ROOT_PATH are prepended to the paths specified in the >> find_file arguments, but that does not seem to happen if the search paths >> are subpaths of the CMAKE_FIND_ROOT_PATH). My guess would be that the NDK >> does something similar, meaning you would need to add the path where to >> look for AWS to CMAKE_FIND_ROOT_PATH. >> > > I have just looked that up and yes, it would explain what I'm seeing. > CMAKE_SYSROOT is being set by the toolchain file and it would appear as > this would make all search hints and paths implicitly relative. > > I'm now trying to restructure my 3rd party management for this target to > enable me to install my dependencies into the subdirs set as sysroot, > hoping that they will then be found. > > Thanks for the suggestion, that looks promising. I will get back with more > info on if and how that turned out. > >> CMake feature request: it would be real nice to have a verbose mode for >> the find_XXX functions that tell you exactly where CMake is looking for >> stuff and why to help debug problems like this. >> > Seconded. > +1 > I always insert debug message() statements all over the place and then > often forget to clean them up. Also, this way I can only verify the search > paths are correct but not why find_file fails. > In CMake 3.15 message command learned DEBUG mode: https://cmake.org/cmake/help/v3.15/release/3.15.html and https://cmake.org/cmake/help/v3.15/command/message.html#command:message so that you my leave your message(DEBUG ...) message while not being displayed at default loglevel. You may use the --loglevel command line option to get them. The default level being displayed is STATUS. See: https://cmake.org/cmake/help/v3.15/manual/cmake.1.html -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From braden at endoframe.com Wed Jul 31 12:19:48 2019 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 31 Jul 2019 12:19:48 -0400 Subject: [CMake] find_program doesn't use the PATH Message-ID: <8fe9c23f412f9a3cc2abe0a97af86f4d938f6763.camel@endoframe.com> I was tempted to go ahead and file a bug on this; but it seems so basic that I figure I must be missing something. Per the documentation for find_program: If NO_DEFAULT_PATH is not specified, the search process is as follows: ? 5. Search the standard system environment variables. This can be skipped if NO_SYSTEM_ENVIRONMENT_PATH is an argument. * PATH That indicates to me that for "find_program(PROG_VAR NAME foo)", CMake ought to find "foo" if "foo" is in the PATH. That doesn't seem to be the case, though. A concrete example: cmake_minimum_required(VERSION 3.0) cmake_policy(SET CMP0048 NEW) project("hello" VERSION 0.1.0 LANGUAGES C) find_program(GETTEXT_MSGMERGE_EXECUTABLE NAME msgmerge) message(STATUS "GETTEXT_MSGMERGE_EXECUTABLE = ${GETTEXT_MSGMERGE_EXECUTABLE}") add_executable(hello hello.c) This outputs: $ cmake -G "Unix Makefiles" ~/src/hello -- GETTEXT_MSGMERGE_EXECUTABLE = GETTEXT_MSGMERGE_EXECUTABLE-NOTFOUND -- Configuring done -- Generating done -- Build files have been written to: /home/mcdanb/build/hello $ which msgmerge /usr/bin/msgmerge I am using CMake 3.14.5. Have I misunderstood the documentation on this point? -- Braden McDaniel From kornel at lyx.org Wed Jul 31 14:32:33 2019 From: kornel at lyx.org (Kornel Benko) Date: Wed, 31 Jul 2019 20:32:33 +0200 Subject: [CMake] find_program doesn't use the PATH In-Reply-To: <8fe9c23f412f9a3cc2abe0a97af86f4d938f6763.camel@endoframe.com> References: <8fe9c23f412f9a3cc2abe0a97af86f4d938f6763.camel@endoframe.com> Message-ID: <4224595.8qg8sgMYme@amd64> Am Mittwoch, 31. Juli 2019, 12:19:48 CEST schrieb Braden McDaniel: > I was tempted to go ahead and file a bug on this; but it seems so basic > that I figure I must be missing something. > > Per the documentation for find_program: > > If NO_DEFAULT_PATH is not specified, the search process is as > follows: > ? > 5. Search the standard system environment variables. This can be > skipped if NO_SYSTEM_ENVIRONMENT_PATH is an argument. > * PATH > That indicates to me that for "find_program(PROG_VAR NAME foo)", CMake > ought to find "foo" if "foo" is in the PATH. That doesn't seem to be > the case, though. A concrete example: > > cmake_minimum_required(VERSION 3.0) > cmake_policy(SET CMP0048 NEW) > project("hello" VERSION 0.1.0 LANGUAGES C) > find_program(GETTEXT_MSGMERGE_EXECUTABLE NAME msgmerge) The find_program() is searching something like "/usr/bin/NAME". "NAME" should be a placeholder. What you had in mind was probably the second form find_program(GETTEXT_MSGMERGE_EXECUTABLE NAMES msgmerge) Mark the string "NAMES". Kornel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From braden at endoframe.com Wed Jul 31 16:54:20 2019 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 31 Jul 2019 16:54:20 -0400 Subject: [CMake] find_program doesn't use the PATH In-Reply-To: <4224595.8qg8sgMYme@amd64> References: <8fe9c23f412f9a3cc2abe0a97af86f4d938f6763.camel@endoframe.com> <4224595.8qg8sgMYme@amd64> Message-ID: <2c4d6fa883e276c38b63cc48c43116f397badbf0.camel@endoframe.com> On Wed, 2019-07-31 at 20:32 +0200, Kornel Benko wrote: > The find_program() is searching something like "/usr/bin/NAME". > "NAME" should be a placeholder. > What you had in mind was probably the second form > find_program(GETTEXT_MSGMERGE_EXECUTABLE NAMES msgmerge) > Mark the string "NAMES". Oh, good grief. Sigh. Thanks for catching that. -- Braden McDaniel