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. > * quote include directories are not distinguishable CMake does not currently generate -iquote as a result of a user writing an include_directories() call. Are you asking for that as an option? That would be an independent feature request. I'd suggest filing it in the tracker. Otherwise, the only way CMake currently would pass such options to the compiler is if the user specified them in CMAKE_CXX_FLAGS or add_compile_options() or similar. CMake does not attempt to parse CMAKE_CXX_FLAGS for things which look like include directories. That variable is just an opaque string of data from the point of view of CMake. It is not clear to me whether you are suggesting that CMake should do that. If you do want to suggest that, please file an issue in the tracker. Similarly, CMake does not attempt to analyse the meaning of options specified in add_compile_options(). Again, it's not clear to me whether you are suggesting a new feature for CMake. If you are, please file it in the tracker. To avoid misunderstandings, please post snippets of CMake code together with a description of what information you want CMake to determine from the snippet and what metadata it should generate. > * 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, 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. I think I understand what you're saying. However, it would help if you related what you write to existing CMake features and snippets of CMake code. I assume that you are medium-to-very familiar with CMake features already, given what you are working on? > we’ll need to call the compiler with the correct > command-line to get some more info like specific compiler features, but I > guess CMake could do it instead of the IDE). I don't know what you are refering to, but if you want CMake to record more compiler features than what it already does: http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html then please file an issue in the tracker. The information gathered using the above feature can be added to the metadata file. > Though I don’t this it’s a > way to go for CMake generation, since the compiler should be called for > every unique command-line flags and undoubtedly make generation way > longer. It's not completely clear to me what you are suggesting here. Maybe you know something I don't know. Can you be clear about what you are suggesting CMake would have to do for each unique command line? I know you are not proposing that CMake should do it (you said the IDE should do it lazily instead), but what action are you actually talking about? What should the IDE do lazily instead of CMake doing it? Invoke the compiler to determine the compiler-defined/built-in include directories and definitions? They will always be the same, right? Or are you talking about the "-I-" GCC option here and how that clears the built-ins? Please be more specific. 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