[cmake-developers] daemon-mode meeting last Tuesday

[Tobias Hunger]

Am 23.06.2016 22:46 schrieb "Brad King" <brad.king at kitware.com>:
>
> On 06/23/2016 08:27 AM, Tobias Hunger wrote:
> Great!  Thanks for the detailed summary of the meeting and status of the
design.

You are welcome.

<snip>

> >   * 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.

I'll create a task to rename it to "server" then.

<snip>

> >   * 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?

It has a type: "reply" (or "error"). I so far use the inReplyTo field to
specify what the request a reply refers to. Stephen thinks that is not
necessary as there is always one request in flight and the client can just
figure things out without additional information.

> Also, doesn't the cookie allow the query/response
> pairs to be matched?

In theory yes. But a protocol should work without having to reply on
cookies.

A cookie is user data attached to an request. The idea is that e.g. an IDE
can run a request for some more details on some node in the project tree
view and pass some form of ID of the node the information is for along with
the query. That can simplify client code a lot.

> >   * 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.).

The header currently is the type, inReplyTo and the cookie. I did not see
the need to separate those.

> >   * 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.

So you think we should keep that? I do not have an opinion here and need to
follow the advise of people more knowledgeable about CMake code than I am.

> >   * 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.

I think CMake should know what is generated and should not leave decisions
like that up to generators.

> >   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

I like "cmakeInputs":-) I'll make a task to change it if nobody opposes
this suggestion.

Best Regards,
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160623/7239cc2d/attachment.html>