Dominik Haumann wrote: > 1. Wouldn't it make sense you have a developer sprint ASAP for this?
Yes totally! I had the same idea as many people who could be interested are in Berlin or can get there easily. I'm not aware of there ever having been a developer sprint for cmake (particularly for community/non-Kitware employees). It's just not part of the development culture/community of cmake the way it is for KDE. If there are interested participants I would try to organize one in Berlin making use of KDE infrastructure like sprints.kde.org. > 2. Reading about this deamon approach, rtags comes to my mind: Interesting: https://github.com/Andersbakken/rtags I could imagine it having at least solve similar problems which we could learn from. Other prior art includes * https://github.com/Valloric/YouCompleteMe (which is the result of the 'clang server' design I linked to previously: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=13004) * vim netbeans: http://vimdoc.sourceforge.net/htmldoc/netbeans.html > the good > thing is, even for newer C/C++ revisions (C++17 etc), if rtags is > adapted, things will just work on the client side Yes, the cmake daemon has a similar design principle that clients don't need to store a list of (version specific) information such as what commands and properties are built into cmake. A newer version of cmake with newer commands and properties then still gets ideal code completion. > Given this background, I can see a lot of benefits in a cmake deamon > that provides all sorts of infos... Yep! I have already proven the concept by creating a cmake project/debugger plugin for kate. Thanks, Steve. _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
