On Monday, March 30, 2015 19:04:10 Anton Makeev wrote: > > On 24 Mar 2015, at 00:54, Stephen Kelly <steve...@gmail.com> wrote: > > > > Tobias Hunger wrote: > >> How about include_directories, compile_definitions and compile_flags? > >> > >> So something along the lines of: > >> > >> "include_directories" : ["/foo", "/opt"] > >> "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"] > >> "compile_flags": [ "-c" ] > > > > Quoting Anton: > > > > Anton Makeev wrote: > >> The other thing that seems troubling to me is that since file, target, > >> language compiler options are split into different parts of metadata, the > >> IDE need to know exactly how to assemble them back into the compiler’s > >> command line (e.g. what flags go first file’s or language’s), duplicating > >> CMake's logic that may be different from version to version and from > >> compiler to compiler. The exact command line is needed to get the actual > >> and precise defines, include search paths etc. from the compiler. > > > > Maybe he can chime in with more. I don't really know why the entire > > command > > line is needed instead of separate "include_directories" and > > "compile_definitions" arrays as you and I suggested. Perhaps because that > > would not include -fPIC for example, which causes __PIC__ to be defined. > > > > Another item of note is that CMake does not know the compile flags as a > > sequential container of individual flags currently, but it knows them as a > > string (that's also why it appears as a string in my generated json > > currently). > > 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 > * quote include directories are not distinguishable > * compiler definition do not include compiler-defined(built-in) definitions > etc.
Code for detecting the built-in include dirs and definitions is in CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake. This is used currently by CMakeFindCodeBlocks.cmake and CMakeFindEclipseCDT4.cmake, i.e. the respective extra-generators, and the information is generated into the eclipse/codeblocks project files. This could be used here too. I don't really understand your second point. Can you elaborate ? Alex P.S. Actually I still fail to understand why this generic json generator will be implemented differently then the other extra-generators. Those could also be changed to be variable-activated, instead of generator-activated, if this is preferred. Without checking the code, I don't think there is a technical reason not to do 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: http://public.kitware.com/mailman/listinfo/cmake-developers
