<p dir="ltr">Hi Stephen,</p>
<p dir="ltr">Am 10.06.2016 20:53 schrieb "Stephen Kelly" <<a href="mailto:steveire@gmail.com">steveire@gmail.com</a>>:<br>
> > [== CMake MetaMagic ==[<br>
> > {<br>
> > # Reply header:<br>
> > "cookie":"",<br>
> > "type":"reply"<br>
> > "inReplyTo":"project",<br>
><br>
> Part of the design of the daemon is that messages that it sends can be<br>
> 'spontaneous' - it watches for filesystem changes and can tell clients to<br>
> re-read the buildsystem information.</p>
<p dir="ltr">That is currently not done or needed, but can be added.</p>
<p dir="ltr">> The inReplyTo does not fit that model.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> Additionally, it appears to be<br>
> redundant if you have a 'cookie'?</p>
<p dir="ltr">No, cookies are to attach user data to requests and that is entirely orthogonal to what inReplyTo does.</p>
<p dir="ltr">> ><br>
> > # Data:<br>
> > "projects":<br>
><br>
> What you call 'projects' appear to be 'targets' in CMake vocabulary. Is that<br>
> correct? Note that a project is something different in CMake vocabulary (see<br>
> the project command).</p>
<p dir="ltr">Actually that is exactly what is returned here.</p>
<p dir="ltr">> Note also that in CMake, targets (libraries, executables etc) have a project<br>
> name.  Conceptualizing this as 'a project is a group of targets' doesn't<br>
> work well because of how CMake deals with multiple project() commands and<br>
> the VS and Xcode structures it generates. See<br>
><br>
>  cmGlobalGenerator::FillProjectMap()<br>
><br>
> and how the result of that method is used. It is important that the daemon<br>
> does not create a new claim of truth in this regard - the structure from the<br>
> daemon should be the same as the structure generated for those ide projects.</p>
<p dir="ltr">Why?</p>
<p dir="ltr">I want the structure that *CMake* sees. What some unrelated program generates out of that structure is irrelevant.</p>
<p dir="ltr"><snip></p>
<p dir="ltr">> > Is this the information you need for IDE integration?<br>
><br>
> You might be packing too much into one protocol verb. Try this on LLVM and<br>
> VTK for example to see how much data it is. Perhaps then compare with the<br>
> gradual approach in my branch.</p>
<p dir="ltr">CMake itself is way below 100KiB.</p>
<p dir="ltr">A typical developer machine should be able to handle several 10MiB of JSON data just fine. So I do not expect a problem there.</p>
<p dir="ltr">> In my branch I have<br>
><br>
> * `buildsystem` - Get the targets (name, type, project) and backtraces<br>
> * `target_info` - Get buildsystem properties for a target<br>
> * `file_info` - Get buildsystem properties for a file in a target</p>
<p dir="ltr">I know. I did not like that, so I did it differently.</p>
<p dir="ltr">Basically I do want the really important information in one go instead of requesting a little bit, iterate over the data, request some more, ...</p>
<p dir="ltr">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.</p>
<p dir="ltr">> Getting the backtraces (instead of the location) for targets is important -</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">A tool to run a static analyzer over all C++ files in a project will not need backtraces ever.</p>
<p dir="ltr">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.</p>
<p dir="ltr"><snip><br></p>
<p dir="ltr">The biggest part of your mail is about the history of the patch set and how to collaborate further.</p>
<p dir="ltr">My cmake-daemon branch on github documents how I got from your branch to mine.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Then I proceeded to add the Process* methods and other functionality back in.</p>
<p dir="ltr">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.</p>
<p dir="ltr">This is why I wonder how working through your branch is supposed to function within the resource limits on your side?</p>
<p dir="ltr">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!</p>
<p dir="ltr">Best Regards,<br>
Tobias</p>