[cmake-developers] daemon-mode: Project structure

Milian Wolff mail at milianw.de
Thu Jun 9 06:32:19 EDT 2016


On Donnerstag, 9. Juni 2016 09:47:44 CEST Tobias Hunger wrote:
> Hello everybody,

Hey Tobias,

> 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.

First of all, many thanks for stepping up and working on this. I for one 
greatly appreciate this! Sadly, I don't have the time to help you out :'(

> Here is the format that is currently reported (with comments;-):
> 
> [== CMake MetaMagic ==[
> {
>   # Reply header:
>   "cookie":"",
>   "type":"reply"
>   "inReplyTo":"project",
>   
>   # Data:
>   "projects":
>   [
>     {
>       "configurations":
>       [
>         {
>           "name":"",

Can you enlighten me what these configurations are? Probably a CMake feature I 
haven't used. Maybe it's for Windows to have release and debug builds in one 
go? How would it look like there? 

>           "targets":
>           [
>             {
>               "fullName":"test",
>               "name":"test",
>               "type":"GLOBAL_TARGET"
>             },

A nice-to-have would be a pointer to where the target got created, is that 
feasible? That would allow an IDE to add a context menu to the target list to 
jump to the CMakeLists.txt to edit the target.

>             # <snip>
>             {
>               "buildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/fo
> rm",
>               "fullName":"libcmForm.a",
>               "linkerLanguage":"C",
>               "name":"cmForm",
>               # "sysroot": "/some/path", if set...
>               "sourceGroups": # Just groups files with similar settings
>                               # together to save space

good idea

>               [
>                 {
>                   "compileFlags":"  -std=gnu11",
>                   "defines":
>                   [
>                     "CURL_STATICLIB",
>                     # <snip>
>                     "LIBARCHIVE_STATIC"

Setters with values would then look like `FOO=1` I assume?

>                   ],
>                   "includePath":
>                   [
>                     "/tmp/cmake-build-test/Utilities",
>                     # <snip>
>                     "/home/code/src/cmake/Source/CursesDialog/form"
>                   ],
>                   "lanugage":"C",
>                   "sources":
>                   [
>                     "fld_arg.c",
>                     # <snip>
>                     "fty_regex.c"
>                   ]
>                 }
>               ],
>               "type":"STATIC_LIBRARY"
>             },
>             # <snip>
>             {
>               "fullName":"install",
>               "name":"install",
>               "type":"GLOBAL_TARGET"
>             }
>           ] # end of tragets list
>         } # end of one configuration object
>       ], # end of configurations list
>       "currentBuildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/for
> m",
> "currentSourceDirectory":"/home/code/src/cmake/Source/CursesDialog/form",

why is this the "current" source director", shouldn't this be just 
"sourceDirectory"? The project's source directory cannot change by fiddling 
with the configuration after all, it's part of the source file structure? I 
know that in CMake you have ${CMAKE_CURRENT_SOURCE_DIR}, but we don't need to 
follow that naming for this purpose here, or?

> "name":"CMAKE_FORM"
>     }, # end of one project object
>     # <snip>
>   ] # end of project list
> }
> ]== CMake MetaMagic ==]
> 
> Is this the information you need for IDE integration?

I think so, yes. We get all targets and their defines and includes with 
associated files. Additionally to what we where capably of before, we also get 
the project structure, which is nice. And your format is way more efficient by 
grouping sources with common include/define settings together, good choice.

> Do you cmake developers feel comfortable to expose this information?
> 
> The total of the project data from the cmake project is ~102KiB of raw JSON
> data.
> 
> What is not listed is the build system file list and the CMakeCache. I want
> to keep these two separate: I can think of some use cases where that
> information is not at all necessary:-)

What do you mean by "build system file list" - generated source files? Or 
binary object files? Or CMakeLists.txt?

Great work, thanks a lot!
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160609/eb7388ce/attachment.sig>


More information about the cmake-developers mailing list