[Qt-creator] [cmake-developers] CMake daemon for user tools

[Milian Wolff]

On Montag, 11. Januar 2016 15:54:05 CET Brad King wrote:
> On 01/11/2016 09:59 AM, Aleix Pol wrote:
> > I'm unsure of the feasibility of the project though. Getting any
> > changes in cmake takes forever (this initiative started almost 2 years
> > ago already and it hasn't had any impact yet)
> 
> This particular change will establish a much wider contract between
> CMake and IDEs than we have now, and it has never been clear what
> the best approach should be.  That is why this change is taking so
> long.  It was unfortunate that your (Aleix's) first iteration I
> reviewed and guided last year got so far and took you so much of your
> time before others came forward with criticisms of the approach, but
> I think in the long run we can do something better.
> 
> > and we still need to proof the approach and make sure it has mechanisms
> > to provide retro-compatibility. At least to some extent.
> > 
> > At the very least, I'd like to see cmake maintainers committing to the
> > initiative, to make sure I don't waste more of my time.
> 
> Stephen's cmState refactoring has been a fantastic cleanup and improvement
> of the organization of CMake's implementation.  It is a major step toward
> separating the configuration and generation steps and will be useful for
> many future directions of CMake.
> 
> However, after needing to make fixes between 3.4.0 and 3.4.1 like these:
> 
>  cmState: Avoid accumulating policy stack storage for short-lived scopes
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f21dc4a8
> 
>  cmState: Avoid accumulating snapshot storage for short-lived scopes
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5f860ebb
> 
> I'm concerned that the memory usage of a daemon implementing the proposed
> capabilities may be too large to be practical (at least without a major
> redesign of certain structures that tend to duplicate substrings, or
> some kind of out-of-core approach).

This sounds like optimizations to that daemon will benefit CMake. Also, I'm 
pretty sure we can optimize something if it turns out to be slow or hug up too 
much memory. Also, how much do you have in mind here? A common IDE easily hogs 
up ~1GB+ of memory. If there's another 100MB or so for CMake in there, I don't 
think it will hurt anyone, esp. if it brings useful features on the plate.

> The proposed daemon could help IDEs integrate with the CMake language
> without re-implementing it, but we may not need such heavy infrastructure
> for IDEs just to list targets and sources and allow users to edit them.
> The current need for it is due to the fact that the build specification
> is in an imperative language instead of a declarative format.  I think
> a better approach forward is that discussed in this thread:
> 
>  CMake alternative language
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focu
> s=15374
> 
> Over there I propose moving the majority of the specification into a
> stateless format that IDEs could more easily load, edit, and save.
> 
> While the daemon proposed here may have value, I think we should first
> resolve discussion of the approach proposed in the other thread.

The last time a new language for CMake was proposed it didn't go anywhere. I 
severely doubt we'll see CMake officially endorsing a new language *and* 
having all people out there rewriting their code in a short timeframe.

With Steve's approach otoh, I hope that with some help from others we can get 
a working solution this year.

Please, let's try to solve this problem ASAP instead of continuing the endless 
debates of potential solutions...

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20160111/fdae7009/attachment.sig>