[cmake-developers] daemon-mode: Project structure

[Tobias Hunger]

Hi Milian,

great that you have found the time to look over this! It is greatly appreciated!

On Do, 2016-06-09 at 12:32 +0200, Milian Wolff wrote:
> > [== 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? 

Apparently you can have build systems that can produce debug/release/whatnot
builds in one one. In these systems you would get several entries here: One for
each of the build configurations you can build.

This seems to apply only to VisualStudio and XCode generators. All others should
have just one configuration.

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

Stephen's work has lots of debugging features. It should be straight forward to
figure out the location with those. So I am not sure it makes sense to add this
here. Users sometimes define their targets in ways that are way too challenging
to figure out with the little information available here (think macros and
whatnot).

> >               [
> >                 {
> >                   "compileFlags":"  -std=gnu11",
> >                   "defines":
> >                   [
> >                     "CURL_STATICLIB",
> >                     # <snip>
> >                     "LIBARCHIVE_STATIC"
> 
> Setters with values would then look like `FOO=1` I assume?

Yes, exactly.

<snip>

> >           ] # 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?

Good point. I'll just use sourceDirectory and buildDirectory in the next push.

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

Thanks!

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

I want a list of all the CMakeLists.txt files (and .cmake files and .in files
and whatnot). All the files that would need watching to know when to ask the
user to re-run cmake again since something might have changed.

As an IDE you will want to list these files, too.

Right now this can be 

> Great work, thanks a lot!

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B