[cmake-developers] daemon-mode: Project structure

[Stephen Kelly]

Tobias Hunger wrote:

> Hello everybody,
> 
> 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.
> 
> Here is the format that is currently reported (with comments;-):
> 
> [== CMake MetaMagic ==[
> {
> # Reply header:
> "cookie":"",
> "type":"reply"
> "inReplyTo":"project",

Part of the design of the daemon is that messages that it sends can be 
'spontaneous' - it watches for filesystem changes and can tell clients to 
re-read the buildsystem information.

The inReplyTo does not fit that model. Additionally, it appears to be 
redundant if you have a 'cookie'?

> 
> # Data:
> "projects":

What you call 'projects' appear to be 'targets' in CMake vocabulary. Is that 
correct? Note that a project is something different in CMake vocabulary (see 
the project command). 

Note also that in CMake, targets (libraries, executables etc) have a project 
name.  Conceptualizing this as 'a project is a group of targets' doesn't 
work well because of how CMake deals with multiple project() commands and 
the VS and Xcode structures it generates. See 

 cmGlobalGenerator::FillProjectMap() 

and how the result of that method is used. It is important that the daemon 
does not create a new claim of truth in this regard - the structure from the 
daemon should be the same as the structure generated for those ide projects. 

You may need to understand that before you can create something final here.

Of course, my branch 

 https://github.com/steveire/CMake/commits/cmake-daemon-lite

is already 'correct' in this regard.

I think you need to understand my branch more. You're doing some different 
things, but you haven't compared and explained the differences I think. 
There should be comparison and convergence in the end.

> Is this the information you need for IDE integration?

You might be packing too much into one protocol verb. Try this on LLVM and 
VTK for example to see how much data it is. Perhaps then compare with the 
gradual approach in my branch.

In my branch I have 

* `buildsystem` - Get the targets (name, type, project) and backtraces
* `target_info` - Get buildsystem properties for a target
* `file_info` - Get buildsystem properties for a file in a target

Getting the backtraces (instead of the location) for targets is important - 
the location relevant to the user might be a macro invocation, not the 
inside of a macro. See:

 https://www.youtube.com/watch?v=BPgXuvPAl-8&t=870

In general I think you are missing a lot by not understanding my branch. My 
branch is created with the mindset of 'expose what is correct in CMake'. You 
are creating what you think QtCreator needs - that's good, but what is 
needed is convergence between the two. 

If you rebase your work on top of mine, then you can explain why you do 
that, and we can find out if you are exposing 'correct' information (I'm 
thinking again of the project stuff). For your convenience, I have pushed 
your work to my clone (after rebasing):

 https://github.com/steveire/CMake/commits/daemon-hunger

I suggest you continue your work from there. That way we can discuss your 
changes and converge on something correct.

Notice that some of your changes make some diffs needlessly big and 
therefore harder to understand. For example you rename member variables from 
mLoop to m_Loop, and you rename the cmMetadataServer class to cmServer. Both 
only make it harder to understand your patches. I recommend fixing up your 
patches to remove those differences. 

That way we can converge on the dual goals of exposing correct information, 
and exposing what QtCreator needs. 

You are currently diverging from my work without explaining the differences, 
leading to incorrectness in some cases, and you are missing out on the work 
that I have already done.

Thanks,

Steve.