[cmake-developers] daemon-mode meeting last Tuesday

[Brad King]

On 06/23/2016 08:27 AM, Tobias Hunger wrote:
> Stephen Kelly and me met last Tuesday to talk about the daemon-mode patch we
> both have been working on. It was a very productive meeting: We managed to
> resolve almost all the differences of opinion we had.

Great!  Thanks for the detailed summary of the meeting and status of the design.

>   * Some names could be improved. Suggestions welcome.

We'll cover these in more detail during review.  The most important name is
the name of the feature, and IMO "daemon" is not an accurate description of
it (it is never re-parented to 'init' and has a lifetime tied to the client).
I think "server" would be better but am open to other suggestions.  Even if
it later really becomes a daemon the name "server" will still be appropriate.

As you said before there has been a lot of PR with the name "daemon", but I
don't think it is too late to change it.  Those interested in the features
will see the new name when it appears in release notes and should easily be
able to recognize it.

>   * Clients should talk to daemon mode via a socket (libuv supports that),
>     but we also want to support stdin/stdout at least for a "debug mode"
>      * There should be a separate command line switch to start stdin/out mode
>        and for socket mode
>      * This is needed before it makes sense to merge the patch set.

Given the noise we have on stdout it makes sense to offer a dedicated
communication path for clients.

>   * Currently a reply (and error and all other messages in response to a
>     request) contain a "inReplyTo" with the type string from the request
>     triggering the reply.
>     
>     Stephen thinks that is not necessary and argues anything that is not
>     strictly necessary should not be in the first version of the protocol.
>     
>     I like having this as it makes it helps to identify what a reply/error is
>     related to. I often paste a whole string of requests into the daemon and
>     if there is an error it is really easy to see how for things got.

Would each type of query have a known type of response?  Shouldn't the response
objects have a type too?  Also, doesn't the cookie allow the query/response
pairs to be matched?

>   * Should we have a split between header (cookie/type/inReplyTo) and data?
>   
>     Stephen suggested passing all data that is from/for the client in a
>     "body" attribute to make messages more uniform.
>     
>     I think that is just adding one more level into the JSON file for no
>     real benefit.

I agree with Tobias that there is no reason to put the body fields in
a sub-object.  However, I think the header fields should go in a sub-object
named by a "header" field.  That will isolate the header field names from
the body fields (good for sorted views, future addition of headers, etc.).

>   * This is currently used to set sourcedirectory, builddirectory and
>     generator.
>     
>     These three should be passed in via the command line instead, again
>     to avoid trouble with users switching to different build directories/etc.
>     while the daemon is running, which might trigger problems with state
>     cleanup, etc.

Currently cmake-gui supports switching generators, build trees, etc., so
there is some precedent for such switching within a single process.  If
we have (re-)initialization bugs they should simply be fixed.

>   * Figure out whether a PDB file is actually going to be build. Currently
>     the PDB file is added to the list of artifacts whenever there is a .lib
>     file, which is probably wrong. Brad: Do you have an idea how to
>     get this information?

I'm not sure we have that information.  IIRC CMake only adds settings to the
generated build system to tell the tools where to put the .pdb and what to
call it if it happens to be created.  We don't have install rules for them
so there has never been a need to know whether they will actually be created.
Perhaps our format for the list of artifacts needs a way to indicate whether
an artifact is optionally present.

>   2.8 buildsystem (return cmake files)
>   
>   * Return a list of cmake files (CMakeLists.txt, etc.) in different categories
>     (in source directory/in build directory/in the system).
>     
>   * Stephen suggested to rename this to "cmake_rerun_depends". I am not sure
>     that name is much better than what is currently used.

"cmake_rerun_depends" describes the current use case for these.  I don't think
the name "buildsystem" is clear though.  Other ideas:

* cmake_files
* cmake_inputs
* input_files

-Brad