[cmake-developers] daemon-mode: Project structure

[Tobias Hunger]

Hi Stephen,

Am 10.06.2016 20:53 schrieb "Stephen Kelly" <steveire at gmail.com>:
> > [== 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.

That is currently not done or needed, but can be added.

> The inReplyTo does not fit that model.

It does. A filesystem change would be "type":"signal" or something instead
and will not have a inReplyTo (as it was not generated in reply to
something.

> Additionally, it appears to be
> redundant if you have a 'cookie'?

No, cookies are to attach user data to requests and that is entirely
orthogonal to what inReplyTo does.

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

Actually that is exactly what is returned here.

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

Why?

I want the structure that *CMake* sees. What some unrelated program
generates out of that structure is irrelevant.

<snip>

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

CMake itself is way below 100KiB.

A typical developer machine should be able to handle several 10MiB of JSON
data just fine. So I do not expect a problem there.

> 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

I know. I did not like that, so I did it differently.

Basically I do want the really important information in one go instead of
requesting a little bit, iterate over the data, request some more, ...

In the end that is a lots of needless round trips and you send more data
over the wire, too, with all the protocol overhead.

> Getting the backtraces (instead of the location) for targets is important
-

I am aware of the importance of backtraces, but I do not see any use case
where this information needs to be available at the point the project
structure is requested.

An IDE can for example request backtraces for a target when/if needed and
does not need it right away to set up a project tree and code model.

A tool to run a static analyzer over all C++ files in a project will not
need backtraces ever.

This is why that information is not contained in the project structure at
all. Yes, we need to provide a way to retrieve backtraces for targets (and
other symbols), but not here.

<snip>

The biggest part of your mail is about the history of the patch set and how
to collaborate further.

My cmake-daemon branch on github documents how I got from your branch to
mine.

I basically copied the cmServer* files from that branch on top of a fresh
CMake checkout when I started the new branch, removing all the Process*
functions and wiring up the server again. There was no change outside the
cmServer* files apart from the wiring to start the daemon.

Then I proceeded to add the Process* methods and other functionality back
in.

I did that to make review simpler for *other* reviewers. I had not expected
you to chime in at all. Don't get me wrong: I appreciate you experience,
your patience and your reviews! I just had not expected it. The impression
I got talking to you before is that you do not have the resources to push
this functionality forward at this time. In fact that is the *only* reason
I stepped up for this task.

This is why I wonder how working through your branch is supposed to
function within the resource limits on your side?

I do not want for this work to vanish into some obscure github branch
somewhere for weeks and month -- as it did so far. The CMake daemon is too
cool a feature for that!

Best Regards,
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160610/87e170be/attachment.html>