Tobias Hunger wrote: > On Wed, Apr 1, 2015 at 12:41 AM, Stephen Kelly <steve...@gmail.com> wrote: >> Anton Makeev wrote: >> >>> The problem with the following format: >>> --- >>> "include_directories" : ["/foo", "/opt"] >>> "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"] >>> "compile_flags": [ "-c" ] >>> — >>> Is that it’s incomplete and cannot be used directly: >>> * include directories list misses compiler-defined search paths >> >> CMake gathers those during configure time, and we can add them to the >> metadata too. > > That is not necessary for QtC. Feel free to add this information if > somebody else needs it.
Ok. I have some ideas of how this could be useful, so I'll see about adding it later. > <snip> > >>> * compiler definition do not include compiler-defined(built-in) >>> definitions etc. >> >> CMake does not currently gather those during configure, as far as I know. >> That could be added though. > > That is not necessary for QtC. Feel free to add this information if > somebody else needs it. Ok, I think the conclusion is that this is not useful as the built-in defines are very likely to change with different compile flags, which are very likely to be set in the buildsystem *after* CMake would have checked them from the compiler. So, I don't think this will be added. > Creator will parse the compile_flags anyway, so it does not matter to > me whether some defines/includes end up being hidden in there, but I > would prefer to get as much of the information separately if possible. > So please keep the include_directories and compile_defines that cmake > knows about separate. That is so much nicer to parse than some command > line, especially when escaping starts to get necessary. Right. That sounds like an argument for the kind of 'duplication for different use cases/approaches' I just proposed: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=12879 >>> That is, to have the complete list of include directories and compiler >>> definitions, the IDE will have to call the compiler anyways. And here is >>> where it will need the actual compiler’s command line. >>> >>> Should we had the full list of include directories (split into groups >>> like: <>, quote, and frameworks) and the list of all compiler defines, >>> we would not need the compiler command-line at all. > > We do need to know the compiler *binary* (/usr/bin/gcc), but not > necessarily the complete command line that is run ("/usr/bin/gcc -c > -Dsomething -I/some/path something.cpp something.o"). We do of course > need to be sure that we have all the information to generate that > command line in the form of compile_flags, compile_definitions, > include_directories and whichever other flags may be relevant. Ok. > If you want to log the compiler-defined defines into the Json file, > then cmake obviously needs to query the compiler for those. > > These defines are heavily dependent on the command line flags you pass > (e.g. -std=c++11 will set some other defines than -std=c++98). There > is a long list of options that change the defines set by the compiler. Right, this is what I temporarily forgot :). > So that means cmake would need to run the compiler once for each > possible set of options passed to the compiler during the later build > steps, so that it can put this information into the meta-data file. > That seems a bit excessive to me, Agreed. > even though creator could probably > use that information if you did provide it. Currently our > projectmanagers just query for the compiler defines themselves. They > have to as currently none of the supported build system provides this > information. Right, because it's impractical for the buildsystem to provide it, as you wrote. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
