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