[cmake-developers] daemon-mode: Project structure
Brad King
brad.king at kitware.com
Thu Jun 9 08:43:48 EDT 2016
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
More information about the cmake-developers
mailing list