Re: [CMake] getting compiler's include paths
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 \ > > >
Re: [CMake] getting compiler's include paths
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 \ >
Re: [CMake] getting compiler's include paths
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
Re: [CMake] getting compiler's include paths
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 \ > >
Re: [CMake] getting compiler's include paths
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 \ >
Re: [CMake] getting compiler's include paths
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
Re: [CMake] getting compiler's include paths
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
--
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
