Required extracting default generator evaluation
to explicit function, as Visual Studio generators
get validated during their construction.
Fixes: #18544
The last KDevelop3 release was many years ago, in 2008 I think.
I haven't seen or read about anybody using KDevelop 3 since a
long time, so I think it can safely be removed from CMake.
KDevelop 4 (first released in 2010) has its own proper CMake
support now, independent from this generator.
Alex
Catch more problematic input during handshake and report failure.
These were caught before when trying to configure, but it is way better
to get these reports early.
Change our message wrapper from
[== CMake Server ==[ ... ]== CMake Server ==]
to
[== "CMake Server" ==[ ... ]== "CMake Server" ==]
to guarantee that no JSON content can ever contain the ending string
(because it would be encoded as `]== \"CMake Server\" ==]`).
We expect the server to exit when its communication pipes are closed.
Close them and wait for the server to exit. If supported by the current
version of python, kill the server if it does not exit after a few
seconds.
Do some basic unit tests for "codemodel", "cmakeInputs" and "cache"
commands of the cmake server.
This just calls the commands right now and makes sure the server
thinks it can reply to the request. The data itself is currently not
validated.
Add "globalSettings" command that returns:
* Return capability information
* Return currently used generator/extra generator
* Return a range of flags for debug/trace/etc.
Use it to split pipe and stdin/out handling out of cmServer itself.
The server will shut down when it looses its connection to the client.
This has the nice property that a crashing client will cause the server
to terminate as the OS will close the connection on behave of the client.
Allow for experimental cmProtocolVersions, which will only ever get
listed if the server was started with the (undocumented)
"--experimental" flag.
Mark current protocol version 1.0 as experimental.