CMAKE-SERVER(7) CMake CMAKE-SERVER(7)
NAME
cmake-server - CMake Server
Deprecated since version 3.15: This will be removed from a future ver-
sion of CMake. Clients should use the cmake-file-api(7) instead.
INTRODUCTION
cmake(1) is capable of providing semantic information about CMake code
it executes to generate a buildsystem. If executed with the -E server
command line options, it starts in a long running mode and allows a
client to request the available information via a JSON protocol.
The protocol is designed to be useful to IDEs, refactoring tools, and
other tools which have a need to understand the buildsystem in en-
tirety.
A single cmake-buildsystem(7) may describe buildsystem contents and
build properties which differ based on generation-time context includ-
ing:
o The Platform (eg, Windows, APPLE, Linux).
o The build configuration (eg, Debug, Release, Coverage).
o The Compiler (eg, MSVC, GCC, Clang) and compiler version.
o The language of the source files compiled.
o Available compile features (eg CXX variadic templates).
o CMake policies.
The protocol aims to provide information to tooling to satisfy several
needs:
1. Provide a complete and easily parsed source of all information rele-
vant to the tooling as it relates to the source code. There should
be no need for tooling to parse generated buildsystems to access in-
clude directories or compile definitions for example.
2. Semantic information about the CMake buildsystem itself.
3. Provide a stable interface for reading the information in the CMake
cache.
4. Information for determining when cmake needs to be re-run as a re-
sult of file changes.
OPERATION
Start cmake(1) in the server command mode, supplying the path to the
build directory to process:
cmake -E server (--debug|--pipe=<NAMED_PIPE>)
The server will communicate using stdin/stdout (with the --debug param-
eter) or using a named pipe (with the --pipe=<NAMED_PIPE> parameter).
Note that named pipe refers to a local domain socket on Unix and to a
named pipe on Windows.
When connecting to the server (via named pipe or by starting it in
--debug mode), the server will reply with a hello message:
[== "CMake Server" ==[
{"supportedProtocolVersions":[{"major":1,"minor":0}],"type":"hello"}
]== "CMake Server" ==]
Messages sent to and from the process are wrapped in magic strings:
[== "CMake Server" ==[
{
... some JSON message ...
}
]== "CMake Server" ==]
The server is now ready to accept further requests via the named pipe
or stdin.
DEBUGGING
CMake server mode can be asked to provide statistics on execution
times, etc. or to dump a copy of the response into a file. This is
done passing a debug JSON object as a child of the request.
The debug object supports the showStats key, which takes a boolean and
makes the server mode return a zzzDebug object with stats as part of
its response. dumpToFile takes a string value and will cause the cmake
server to copy the response into the given filename.
This is a response from the cmake server with showStats set to true:
[== "CMake Server" ==[
{
"cookie":"",
"errorMessage":"Waiting for type \"handshake\".",
"inReplyTo":"unknown",
"type":"error",
"zzzDebug": {
"dumpFile":"/tmp/error.txt",
"jsonSerialization":0.011016,
"size":111,
"totalTime":0.025995
}
}
]== "CMake Server" ==]
The server has made a copy of this response into the file /tmp/er-
ror.txt and took 0.011 seconds to turn the JSON response into a string,
and it took 0.025 seconds to process the request in total. The reply
has a size of 111 bytes.
PROTOCOL API
General Message Layout
All messages need to have a type value, which identifies the type of
message that is passed back or forth. E.g. the initial message sent by
the server is of type hello. Messages without a type will generate an
response of type error.
All requests sent to the server may contain a cookie value. This value
will he handed back unchanged in all responses triggered by the re-
quest.
All responses will contain a value inReplyTo, which may be empty in
case of parse errors, but will contain the type of the request message
in all other cases.
Type reply
This type is used by the server to reply to requests.
The message may depending on the type of the original request contain
values.
Example:
[== "CMake Server" ==[
{"cookie":"zimtstern","inReplyTo":"handshake","type":"reply"}
]== "CMake Server" ==]
Type error
This type is used to return an error condition to the client. It will
contain an errorMessage.
Example:
[== "CMake Server" ==[
{"cookie":"","errorMessage":"Protocol version not supported.","inReplyTo":"handshake","type":"error"}
]== "CMake Server" ==]
Type progress
When the server is busy for a long time, it is polite to send back
replies of type progress to the client. These will contain a pro-
gressMessage with a string describing the action currently taking place
as well as progressMinimum, progressMaximum and progressCurrent with
integer values describing the range of progress.
Messages of type progress will be followed by more progress messages or
with a message of type reply or error that complete the request.
progress messages may not be emitted after the reply or error message
for the request that triggered the responses was delivered.
Type message
A message is triggered when the server processes a request and produces
some form of output that should be displayed to the user. A Message has
a message with the actual text to display as well as a title with a
suggested dialog box title.
Example:
[== "CMake Server" ==[
{"cookie":"","message":"Something happened.","title":"Title Text","inReplyTo":"handshake","type":"message"}
]== "CMake Server" ==]
Type signal
The server can send signals when it detects changes in the system
state. Signals are of type signal, have an empty cookie and inReplyTo
field and always have a name set to show which signal was sent.
Specific Signals
The cmake server may sent signals with the following names:
dirty Signal
The dirty signal is sent whenever the server determines that the con-
figuration of the project is no longer up-to-date. This happens when
any of the files that have an influence on the build system is changed.
The dirty signal may look like this:
[== "CMake Server" ==[
{
"cookie":"",
"inReplyTo":"",
"name":"dirty",
"type":"signal"}
]== "CMake Server" ==]
fileChange Signal
The fileChange signal is sent whenever a watched file is changed. It
contains the path that has changed a.
CMAKE-SERVER(7) CMake CMAKE-SERVER(7)
NAME
cmake-server - CMake Server
Deprecated since version 3.15: This will be removed from a future ver-
sion of CMake. Clients should use the cmake-file-api(7) instead.
INTRODUCTION
cmake(1) is capable of providing semantic information about CMake code
it executes to generate a buildsystem. If executed with the -E server
command line options, it starts in a long running mode and allows a
client to request the available information via a JSON protocol.
The protocol is designed to be useful to IDEs, refactoring tools, and
other tools which have a need to understand the buildsystem in en-
tirety.
A single cmake-buildsystem(7) may describe buildsystem contents and
build properties which differ based on generation-time context includ-
ing:
o The Platform (eg, Windows, APPLE, Linux).
o The build configuration (eg, Debug, Release, Coverage).
o The Compiler (eg, MSVC, GCC, Clang) and compiler version.
o The language of the source files compiled.
o Available compile features (eg CXX variadic templates).
o CMake policies.
The protocol aims to provide information to tooling to satisfy several
needs:
1. Provide a complete and easily parsed source of all information rele-
vant to the tooling as it relates to the source code. There should
be no need for tooling to parse generated buildsystems to access in-
clude directories or compile definitions for example.
2. Semantic information about the CMake buildsystem itself.
3. Provide a stable interface for reading the information in the CMake
cache.
4. Information for determining when cmake needs to be re-run as a re-
sult of file changes.
OPERATION
Start cmake(1) in the server command mode, supplying the path to the
build directory to process:
cmake -E server (--debug|--pipe=<NAMED_PIPE>)
The server will communicate using stdin/stdout (with the --debug param-
eter) or using a named pipe (with the --pipe=<NAMED_PIPE> parameter).
Note that named pipe refers to a local domain socket on Unix and to a
named pipe on Windows.
When connecting to the server (via named pipe or by starting it in
--debug mode), the server will reply with a hello message:
[== "CMake Server" ==[
{"supportedProtocolVersions":[{"major":1,"minor":0}],"type":"hello"}
]== "CMake Server" ==]
Messages sent to and from the process are wrapped in magic strings:
[== "CMake Server" ==[
{
... some JSON message ...
}
]== "CMake Server" ==]
The server is now ready to accept further requests via the named pipe
or stdin.
DEBUGGING
CMake server mode can be asked to provide statistics on execution
times, etc. or to dump a copy of the response into a file. This is
done passing a debug JSON object as a child of the request.
The debug object supports the showStats key, which takes a boolean and
makes the server mode return a zzzDebug object with stats as part of
its response. dumpToFile takes a string value and will cause the cmake
server to copy the response into the given filename.
This is a response from the cmake server with showStats set to true:
[== "CMake Server" ==[
{
"cookie":"",
"errorMessage":"Waiting for type \"handshake\".",
"inReplyTo":"unknown",
"type":"error",
"zzzDebug": {
"dumpFile":"/tmp/error.txt",
"jsonSerialization":0.011016,
"size":111,
"totalTime":0.025995
}
}
]== "CMake Server" ==]
The server has made a copy of this response into the file /tmp/er-
ror.txt and took 0.011 seconds to turn the JSON response into a string,
and it took 0.025 seconds to process the request in total. The reply
has a size of 111 bytes.
PROTOCOL API
General Message Layout
All messages need to have a type value, which identifies the type of
message that is passed back or forth. E.g. the initial message sent by
the server is of type hello. Messages without a type will generate an
response of type error.
All requests sent to the server may contain a cookie value. This value
will he handed back unchanged in all responses triggered by the re-
quest.
All responses will contain a value inReplyTo, which may be empty in
case of parse errors, but will contain the type of the request message
in all other cases.
Type reply
This type is used by the server to reply to requests.
The message may depending on the type of the original request contain
values.
Example:
[== "CMake Server" ==[
{"cookie":"zimtstern","inReplyTo":"handshake","type":"reply"}
]== "CMake Server" ==]
Type error
This type is used to return an error condition to the client. It will
contain an errorMessage.
Example:
[== "CMake Server" ==[
{"cookie":"","errorMessage":"Protocol version not supported.","inReplyTo":"handshake","type":"error"}
]== "CMake Server" ==]
Type progress
When the server is busy for a long time, it is polite to send back
replies of type progress to the client. These will contain a pro-
gressMessage with a string describing the action currently taking place
as well as progressMinimum, progressMaximum and progressCurrent with
integer values describing the range of progress.
Messages of type progress will be followed by more progress messages or
with a message of type reply or error that complete the request.
progress messages may not be emitted after the reply or error message
for the request that triggered the responses was delivered.
Type message
A message is triggered when the server processes a request and produces
some form of output that should be displayed to the user. A Message has
a message with the actual text to display as well as a title with a
suggested dialog box title.
Example:
[== "CMake Server" ==[
{"cookie":"","message":"Something happened.","title":"Title Text","inReplyTo":"handshake","type":"message"}
]== "CMake Server" ==]
Type signal
The server can send signals when it detects changes in the system
state. Signals are of type signal, have an empty cookie and inReplyTo
field and always have a name set to show which signal was sent.
Specific Signals
The cmake server may sent signals with the following names:
dirty Signal
The dirty signal is sent whenever the server determines that the con-
figuration of the project is no longer up-to-date. This happens when
any of the files that have an influence on the build system is changed.
The dirty signal may look like this:
[== "CMake Server" ==[
{
"cookie":"",
"inReplyTo":"",
"name":"dirty",
"type":"signal"}
]== "CMake Server" ==]
fileChange Signal
The fileChange signal is sent whenever a watched file is changed. It
contains the path that has changed a.
CMAKE-SERVER(7) CMake CMAKE-SERVER(7)
NAME
cmake-server - CMake Server
Deprecated since version 3.15: This will be removed from a future ver-
sion of CMake. Clients should use the cmake-file-api(7) instead.
INTRODUCTION
cmake(1) is capable of providing semantic information about CMake code
it executes to generate a buildsystem. If executed with the -E server
command line options, it starts in a long running mode and allows a
client to request the available information via a JSON protocol.
The protocol is designed to be useful to IDEs, refactoring tools, and
other tools which have a need to understand the buildsystem in en-
tirety.
A single cmake-buildsystem(7) may describe buildsystem contents and
build properties which differ based on generation-time context includ-
ing:
o The Platform (eg, Windows, APPLE, Linux).
o The build configuration (eg, Debug, Release, Coverage).
o The Compiler (eg, MSVC, GCC, Clang) and compiler version.
o The language of the source files compiled.
o Available compile features (eg CXX variadic templates).
o CMake policies.
The protocol aims to provide information to tooling to satisfy several
needs:
1. Provide a complete and easily parsed source of all information rele-
vant to the tooling as it relates to the source code. There should
be no need for tooling to parse generated buildsystems to access in-
clude directories or compile definitions for example.
2. Semantic information about the CMake buildsystem itself.
3. Provide a stable interface for reading the information in the CMake
cache.
4. Information for determining when cmake needs to be re-run as a re-
sult of file changes.
OPERATION
Start cmake(1) in the server command mode, supplying the path to the
build directory to process:
cmake -E server (--debug|--pipe=<NAMED_PIPE>)
The server will communicate using stdin/stdout (with the --debug param-
eter) or using a named pipe (with the --pipe=<NAMED_PIPE> parameter).
Note that named pipe refers to a local domain socket on Unix and to a
named pipe on Windows.
When connecting to the server (via named pipe or by starting it in
--debug mode), the server will reply with a hello message:
[== "CMake Server" ==[
{"supportedProtocolVersions":[{"major":1,"minor":0}],"type":"hello"}
]== "CMake Server" ==]
Messages sent to and from the process are wrapped in magic strings:
[== "CMake Server" ==[
{
... some JSON message ...
}
]== "CMake Server" ==]
The server is now ready to accept further requests via the named pipe
or stdin.
DEBUGGING
CMake server mode can be asked to provide statistics on execution
times, etc. or to dump a copy of the response into a file. This is
done passing a debug JSON object as a child of the request.
The debug object supports the showStats key, which takes a boolean and
makes the server mode return a zzzDebug object with stats as part of
its response. dumpToFile takes a string value and will cause the cmake
server to copy the response into the given filename.
This is a response from the cmake server with showStats set to true:
[== "CMake Server" ==[
{
"cookie":"",
"errorMessage":"Waiting for type \"handshake\".",
"inReplyTo":"unknown",
"type":"error",
"zzzDebug": {
"dumpFile":"/tmp/error.txt",
"jsonSerialization":0.011016,
"size":111,
"totalTime":0.025995
}
}
]== "CMake Server" ==]
The server has made a copy of this response into the file /tmp/er-
ror.txt and took 0.011 seconds to turn the JSON response into a string,
and it took 0.025 seconds to process the request in total. The reply
has a size of 111 bytes.
PROTOCOL API
General Message Layout
All messages need to have a type value, which identifies the type of
message that is passed back or forth. E.g. the initial message sent by
the server is of type hello. Messages without a type will generate an
response of type error.
All requests sent to the server may contain a cookie value. This value
will he handed back unchanged in all responses triggered by the re-
quest.
All responses will contain a value inReplyTo, which may be empty in
case of parse errors, but will contain the type of the request message
in all other cases.
Type reply
This type is used by the server to reply to requests.
The message may depending on the type of the original request contain
values.
Example:
[== "CMake Server" ==[
{"cookie":"zimtstern","inReplyTo":"handshake","type":"reply"}
]== "CMake Server" ==]
Type error
This type is used to return an error condition to the client. It will
contain an errorMessage.
Example:
[== "CMake Server" ==[
{"cookie":"","errorMessage":"Protocol version not supported.","inReplyTo":"handshake","type":"error"}
]== "CMake Server" ==]
Type progress
When the server is busy for a long time, it is polite to send back
replies of type progress to the client. These will contain a pro-
gressMessage with a string describing the action currently taking place
as well as progressMinimum, progressMaximum and progressCurrent with
integer values describing the range of progress.
Messages of type progress will be followed by more progress messages or
with a message of type reply or error that complete the request.
progress messages may not be emitted after the reply or error message
for the request that triggered the responses was delivered.
Type message
A message is triggered when the server processes a request and produces
some form of output that should be displayed to the user. A Message has
a message with the actual text to display as well as a title with a
suggested dialog box title.
Example:
[== "CMake Server" ==[
{"cookie":"","message":"Something happened.","title":"Title Text","inReplyTo":"handshake","type":"message"}
]== "CMake Server" ==]
Type signal
The server can send signals when it detects changes in the system
state. Signals are of type signal, have an empty cookie and inReplyTo
field and always have a name set to show which signal was sent.
Specific Signals
The cmake server may sent signals with the following names:
dirty Signal
The dirty signal is sent whenever the server determines that the con-
figuration of the project is no longer up-to-date. This happens when
any of the files that have an influence on the build system is changed.
The dirty signal may look like this:
[== "CMake Server" ==[
{
"cookie":"",
"inReplyTo":"",
"name":"dirty",
"type":"signal"}
]== "CMake Server" ==]
fileChange Signal
The fileChange signal is sent whenever a watched file is changed. It
contains the path that has changed a.
CMAKE-SERVER(7) CMake CMAKE-SERVER(7)
NAME
cmake-server - CMake Server
3.18.4 September 13, 2021 CMAKE-SERVER(7)
Czas wygenerowania: 0.00037 sek.
Created with the man page lookup class by Andrew Collington.
Based on a C man page viewer by Vadim Pavlov
Unicode soft-hyphen fix (as used by RedHat) by Dan Edwards
Some optimisations by Eli Argon
Caching idea and code contribution by James Richardson
Copyright © 2003-2025 Linux.pl
Hosted by Hosting Linux.pl