Hi Stephen,
Am 10.06.2016 20:53 schrieb "Stephen Kelly" <steve...@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
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
