[cmake-developers] CMake daemon-mode

Brad King brad.king at kitware.com
Mon Jun 6 13:24:00 EDT 2016


On 06/06/2016 11:39 AM, Tobias Hunger wrote:
> This is why I started working on making Stephen's code merge-able and more
> robust. I will also volunteer to help maintain this code going forward.

Great, thanks!

Hopefully I will have time to look at this in more detail soon.  For now
here are a few responses.

> So far I copied over the daemon itself from Stephen. On top of that I added some
> nicer request/respond handling code (you get pretty similar messages from
> everything, you can set a cookie in a request, which will be handed back on
> response/error, there is a defined way to report a response or an error
> condition), progress reporting (directly hooked up to cmake), and a couple of
> basic commands to get started (reset, etc.), and some future-proofing by being
> able to support several versions of the daemon protocol.

Good.  I like the use of libuv.  I've been meaning to add the infrastructure
to make libuv available as something we can use in CMake upstream so that we
can port process execution away from KWSys and to libuv.  The daemon mode will
be a great client for libuv too.

> A big chunk of Stephen's work has not even landed in my branch yet. Since cmake
> reformated all the source in the meantime it is a bit tedious to apply patches
> from his tree and I have simply not yet needed the changes as I did not venture
> where he went yet.

See commit v3.6.0-rc1~54^2~2 (82df6deaaf).  Its commit message explains
how to rebase across the style transition.  If you rebase the original
"cmake-daemon" branch on that then we can rewrite the style to make
cherry-picking later easier.

> At this time I think I will need to duplicate a chunk of code from one of the
> generators to find the flags. Is that really necessary? If so: Which generator
> should I copy the code from?

We should be able to refactor things to share the flags computation.
Methods like

  cmLocalGenerator::GetTargetFlags
  cmLocalGenerator::GetIncludeDirectories

are meant to be used across multiple generators.  Due to historical
evolution in generator design not everything has been refactored to
cleanly share such infrastructure across all generators.  Stephen made
a lot of progress on that front, but there is still a way to go IIRC.

-Brad



More information about the cmake-developers mailing list