On 06/09/2016 05:47 AM, Tobias Hunger wrote: > I made some progress with extracting project structure from cmake via the > daemon-mode. I am rather happy with the information and would love to get some > feedback from other interested parties.
For reference, some design work on a format like this was discussed in another thread a couple years ago: Extracting target metadata, IDE integration, 2014-09-19 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11000 > # Data: > "projects": To what does each "projects" entry correspond? > [ > { > "configurations": > [ > { > "name":"", > "targets": Should "configurations" be an array or a map? A map would guarantee at most one configuration of a given name. > [ > { > "fullName":"test", > "name":"test", > "type":"GLOBAL_TARGET" I've never liked the name "GLOBAL_TARGET" because it does not really represent what the type of target is. I think we should avoid exposing the internal enum names through the protocol (we already do in the TYPE target property, but the GLOBAL_TARGET type is never available there). Unfortunately I've never come up with a better name, so I'd welcome suggestions. The target type is used for CMake-generated targets that get separately generated in each build (sub)directory, like "make install" and "make test". Their effects are localized to each directory in generators that support that. > }, > # <snip> > { > > "buildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/form", > "fullName":"libcmForm.a", The build directory and the location of the library file may not be the same. Also, there may be more than one artifact per target. A .dll has its .lib import library. A .so may have versioned symlinks. This field could be an "artifacts" array or map. > "linkerLanguage":"C", > "name":"cmForm", > # "sysroot": "/some/path", if set... > "sourceGroups": # Just groups files with similar settings > # together to save space The name "source groups" already has a meaning in CMake. If the goal is just to combine sources with the same settings, please use a different name. > [ > { > "compileFlags":" -std=gnu11", The format could use the same breakdown that CMake does internally to separate target-wide flags from per-source flags. That would also save space, and it will be easy for clients to combine the flags. > "defines": > [ > "CURL_STATICLIB", > # <snip> > "LIBARCHIVE_STATIC" > ], While not shown in this example, in general the defines can have "=value". > "includePath": > [ > "/tmp/cmake-build-test/Utilities", > # <snip> > "/home/code/src/cmake/Source/CursesDialog/form" > ], Do we need some indication of whether each path is a "system" include dir? > "lanugage":"C", > "sources": > [ > "fld_arg.c", > # <snip> > "fty_regex.c" > ] If we split target flags as mentioned above then we may need an object (map) for each source so that it can have fields for per-source flags, defines, etc. > > "currentBuildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/form", > > "currentSourceDirectory":"/home/code/src/cmake/Source/CursesDialog/form", As Milian asked in a sibling response, why "current"? Thanks, -Brad -- 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
