Am 23.06.2016 22:46 schrieb "Brad King" <brad.k...@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
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers