On 03/25/2016 09:25 AM, Tobias Hunger wrote:
> I am personally rather unsure about how to proceed. I can help make
> this branch production/merge ready, but I do not want to maintain it
> indefinitely after it is merged. It touches to many CMake internals
> for me to be comfortable hacking on that
On 26-Jan-16 12:14 AM, Stephen Kelly wrote:
Vladimir Prus wrote:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=13004
Hi Stephen,
this sounds very much like what I has proposed for Boost.Build, see:
http://vladimirprus.com/talks/boosting-cdt-builds/
Yes,
On 10-Jan-16 2:10 PM, Stephen Kelly wrote:
Hello,
I've been working on adding a daemon mode for cmake to provide
information to user tools - such as IDEs - about the buildsystem.
Following the discussion about providing metadata for IDEs to consume
I proposed creating a long-running process
> -Original Message-
> From: Milian Wolff [mailto:m...@milianw.de]
> Sent: Saturday, January 23, 2016 15:41
> To: cmake-developers@cmake.org
> Cc: James Johnston
> Subject: Re: [cmake-developers] CMake daemon for user tools
>
> You are aware that modern std::strin
; > Cc: CMake Developers; Stephen Kelly
> > Subject: Re: [cmake-developers] CMake daemon for user tools
> >
> > > What do you think about string interning? I started a cmString class
> > > [2] that stores short strings inplace and puts long strings into a
>
> -Original Message-
> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
> On Behalf Of Milian Wolff
> Sent: Thursday, January 21, 2016 22:31
> To: Daniel Pfeifer
> Cc: CMake Developers; Stephen Kelly
> Subject: Re: [cmake-developers] CMake
On 01/20/2016 04:03 PM, Stephen Kelly wrote:
> FYI I merged a reduce-allocations branch to next for testing. It came from
> Milian here:
>
> https://github.com/steveire/CMake/pull/1
Very nice!
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake
On Wed, Jan 20, 2016 at 10:03 PM, Stephen Kelly wrote:
> Milian Wolff wrote:
>
>>> 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
Milian Wolff wrote:
>> 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
Tobias Hunger wrote:
> So could we please get a *documented* way that an IDE can *rely on to
> be available* that provides basic information on a
> project/configuration:
>
> * Source directory, build directory
> * Files that belong to the project (sources, headers, custom cmake
> modules,
On Tuesday, January 12, 2016 23:20:14 Milian Wolff wrote:
> On Montag, 11. Januar 2016 23:22:23 CET Alexander Neundorf wrote:
...
> > Stephens big approach will need some time until it is ready, while such a
> > (relatively) simple thing can probably be done within one release cycle
> > (but I
On Monday, January 11, 2016 15:59:35 Aleix Pol wrote:
...
>
> Hi Stephen, everyone,
> I've already discussed this in private with you. I think it's a good
> idea and I'd like to make sure we can benefit from this.
>
> I'm unsure of the feasibility of the project though.
you maybe remember that
On Sun, Jan 10, 2016 at 12:10 PM, Stephen Kelly wrote:
>
> Hello,
>
> I've been working on adding a daemon mode for cmake to provide
> information to user tools - such as IDEs - about the buildsystem.
>
> Following the discussion about providing metadata for IDEs to consume
>
Hello,
I've been working on adding a daemon mode for cmake to provide
information to user tools - such as IDEs - about the buildsystem.
Following the discussion about providing metadata for IDEs to consume
I proposed creating a long-running process which would provide a protocol
to access
14 matches
Mail list logo