[cmake-developers] daemon-mode: Project structure

[Brad King]

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