CMAKE_HOME_DIRECTORY error/warning message?

[René J.V. Bertin]

Hi,

What does this new message mean?

error!! QJsonObject({"cookie":"","errorMessage":"Failed to activate protocol version: \"CMAKE_HOME_DIRECTORY\" is set but incompatible with configured source directory value.","inReplyTo":"handshake","type":"error"})

R.

[René J. V. Bertin]

Post by René J.V. Bertin
What does this new message mean?
error!! QJsonObject({"cookie":"","errorMessage":"Failed to activate protocol
version: \"CMAKE_HOME_DIRECTORY\" is set but incompatible with configured
source directory value.","inReplyTo":"handshake","type":"error"})

And above all, is it related to the fact that I'm seeing parsing errors in many
of my configured projects due to header files no longer being found?

NB: many of my projects are set up according to a probably unusual method: the
build directory lives on a special partition, in parallel to the source
directory:

/path/to/source
/path/to/build

(cd /path/to/build ; cmake /path/to/source)

with the unusual bit that /path/to/source is often a symlink to the actual
source tree on a different partition.

If and how I do this kind of thing shouldn't be any of KDevelop's concern; as
long as files can be accessed via the expected path they could be stored on the
moon with anyone have to worry about that.

R.

[René J. V. Bertin]

Post by René J.V. Bertin
error!! QJsonObject({"cookie":"","errorMessage":"Failed to activate protocol
version: \"CMAKE_HOME_DIRECTORY\" is set but incompatible with configured
source directory value.","inReplyTo":"handshake","type":"error"})

It seems the message comes from CMake's cmServer.cxx, which I guess must provide
a new CMake server feature that is also responsible for messages like

unhandled message QJsonObject({"supportedProtocolVersions":
[{"isExperimental":true,"major":1,"minor":0}],"type":"hello"})
unhandled message
QJsonObject({"cookie":"","inReplyTo":"configure","message":"Could not set up the
appstream test. appstreamcli is missing.","type":"message"})
unhandled message
QJsonObject({"cookie":"","inReplyTo":"configure","progressCurrent":138,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"})
unhandled message
QJsonObject({"cookie":"","inReplyTo":"configure","message":"Found KF5: success
(found version \"5.32.0\") found components: CoreAddons GuiAddons ConfigWidgets
WindowSystem I18n ","type":"message"})
unhandled message
QJsonObject({"cookie":"","inReplyTo":"configure","progressCurrent":207,"progressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type":"progress"})


(those come from a normal project where source and build trees are real
directories with the same parent)

R.

[Milian Wolff]

Post by René J. V. Bertin

Post by René J.V. Bertin
error!! QJsonObject({"cookie":"","errorMessage":"Failed to activate
protocol version: \"CMAKE_HOME_DIRECTORY\" is set but incompatible with
configured source directory
value.","inReplyTo":"handshake","type":"error"})

It seems the message comes from CMake's cmServer.cxx, which I guess must
provide a new CMake server feature that is also responsible for messages
like
[{"isExperimental":true,"major":1,"minor":0}],"type":"hello"})
unhandled message
QJsonObject({"cookie":"","inReplyTo":"configure","message":"Could not set up
the appstream test. appstreamcli is missing.","type":"message"})
unhandled message
QJsonObject({"cookie":"","inReplyTo":"configure","progressCurrent":138,"prog
ressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type"
:"progress"}) unhandled message
success (found version \"5.32.0\") found components: CoreAddons GuiAddons
ConfigWidgets WindowSystem I18n ","type":"message"})
unhandled message
QJsonObject({"cookie":"","inReplyTo":"configure","progressCurrent":207,"prog
ressMaximum":1000,"progressMessage":"Configuring","progressMinimum":0,"type"
:"progress"})
(those come from a normal project where source and build trees are real
directories with the same parent)

Just fixed that.

[René J. V. Bertin]

Post by Milian Wolff

Post by René J. V. Bertin
(those come from a normal project where source and build trees are real
directories with the same parent)

Just fixed that.

Hmmm, should that also fix the case where the source directory is in fact a
symlink?

Either way I have the impression that support for the CMake server is still not
very stable or feature complete so I think I'll be using the 5.1 branch for a
while.

I did have a look around the code to see if using a cmake server is optional.
The CMakeServer class suggests it might be but there clearly is no fallback for
when no server is available.

I also noticed that this is another case where Q_ASSERTS are being used in a way
that isn't ideal IMHO. Not only does the approach mean that production code runs
without any protection at all against cmake server disconnects. It is also very
user unfriendly (not to say unprofessional) to provoke an abort if this happens,
instead of trying to relaunch the cmake server or at least exit gracefully with
an explanation/apology.

Q_ASSERTs should be reserved for situations that are clearly bugs that lead to
situations that cannot be handled except by a more or less ungraceful exit
because of unknow and possibly hopeless internal instability. A server
disconnect is not a bug and not an indication of such instability.

R.

[Aleix Pol]

Post by René J. V. Bertin

Post by Milian Wolff

Post by René J. V. Bertin
(those come from a normal project where source and build trees are real
directories with the same parent)

Just fixed that.

Hmmm, should that also fix the case where the source directory is in fact a
symlink?
Either way I have the impression that support for the CMake server is still not
very stable or feature complete so I think I'll be using the 5.1 branch for a
while.
I did have a look around the code to see if using a cmake server is optional.
The CMakeServer class suggests it might be but there clearly is no fallback for
when no server is available.
I also noticed that this is another case where Q_ASSERTS are being used in a way
that isn't ideal IMHO. Not only does the approach mean that production code runs
without any protection at all against cmake server disconnects. It is also very
user unfriendly (not to say unprofessional) to provoke an abort if this happens,
instead of trying to relaunch the cmake server or at least exit gracefully with
an explanation/apology.
Q_ASSERTs should be reserved for situations that are clearly bugs that lead to
situations that cannot be handled except by a more or less ungraceful exit
because of unknow and possibly hopeless internal instability. A server
disconnect is not a bug and not an indication of such instability.

We all have a lot to learn from you, René.

Meanwhile, if you can offer a way to reproduce, I can look into fixing it.

Aleix

[René J.V. Bertin]

Post by Aleix Pol
We all have a lot to learn from you, René.

I guess we could all have a lot to learn from each other if we cared to listen. Without any form of boasting I can say I have a long history of working with and on software in a variety of often atypical contexts. What you know of me in the context of MacPorts is just the tip of the iceberg. I'd indeed hope there must be some value in that.

One thing I've learned is that if you use a helper process in something that can be (very) long running, you better design from the onset with the idea in mind that the helper process should be allowed to exit, and be launched on-demand. Esp. if you're communicating with it via its stdin/stdout. If I understood the code correctly you're interacting with cmake in a similar fashion as you could be communicating with say an imapd process.
But maybe I missed the code path where you initiate a cmake exit yourself (and not when the KDevelop project is being closed)?

Post by Aleix Pol
Meanwhile, if you can offer a way to reproduce, I can look into fixing it.

Reproduce what exactly? If you mean the side-effects of Q_ASSERT'ing that the cmake server started and is still running, I haven't seen them. Yet.
As to the CMAKE_HOME_DIRECTORY and other messages I can be a little bit more exhaustive:

1) create a directory structure of the form /path1/to1/work/build and unpack or clone a project into /path1/to1/work (e.g. /path1/to1/work/kdevelop)
2a) move /path1/to1/work/$source to /path2/to2/$source, replacing it with a symlink to the new location
2b) invoke `cmake /path1/to1/work/$source` in /path1/to1/work/build

I have never seen any difference between doing 2a,2b and 2b,2a and "2b,2a" set-ups will all end up becoming "2a,2b" projects anyway when you discard /path1/to1/work/CMake* and re-cmake from scratch (which is certain I did at more than 1 occasion since I created the projects that gave me issues with the new KDevelop git/master version).

3a) Import the project into a KDevelop 5.0.3 or 5.1.x session, any recent version not using a CMake server. FWIW I always configure my KDevelop sessions NOT to parse the whole project when opening it.
3b) Open a number of files then exit the KDevelop without closing them.
4) Open this session in KDevelop git/master.

FWIW I'm currently using cmake 3.7.1, haven't had the time to update to 3.7.2 yet.

I didn't need to do anything else to trigger the CMAKE_HOME_DIRECTORY messages. From what I understood the message may have to do with the fact that CMAKE_HOME_DIRECTORY points to /path1/to1/work/$source instead of the the normalised version /path2/to2/$source . I also understand that the message comes from CMake itself, and I have no idea why it would complain about this in "server" (interactive, right?) mode and not when just doing its job in regular mode.

I didn't keep the git/master builds so cannot easily test again on my end. If really necessary I may end up creating an extra set of build & packaging scripts (and patch sets...) in addition to the ones I have for the release version and what's now the 5.1 branch "devel" build.

Maybe there are things I can try "manually"? IIUC the "cmake server" is just cmake in interactive mode to which you send commands over its stdin, right? If so I should be able to provide its output without even using KDevelop.

R.

[Aleix Pol]

Post by René J.V. Bertin
Maybe there are things I can try "manually"? IIUC the "cmake server" is just cmake in interactive mode to which you send commands over its stdin, right? If so I should be able to provide its output without even using KDevelop

Yes, if you could do that, that would be even better.

[René J.V. Bertin]

Post by Aleix Pol

Post by René J.V. Bertin
Maybe there are things I can try "manually"? IIUC the "cmake server" is just cmake in interactive mode to which you send commands over its stdin, right? If so I should be able to provide its output without even using KDevelop

Yes, if you could do that, that would be even better.

No problem, but it would help if you could give me a typical invocation and list of commands to test.

R.

[Milian Wolff]

Post by René J.V. Bertin

Post by Aleix Pol

Post by René J.V. Bertin
Maybe there are things I can try "manually"? IIUC the "cmake server" is
just cmake in interactive mode to which you send commands over its
stdin, right? If so I should be able to provide its output without even
using KDevelop>

Yes, if you could do that, that would be even better.

No problem, but it would help if you could give me a typical invocation and
list of commands to test.

Look into the sources, or here:

https://gitlab.kitware.com/cmake/cmake/issues/16736

[Aleix Pol]

Post by René J.V. Bertin

Post by Aleix Pol

Post by René J.V. Bertin
Maybe there are things I can try "manually"? IIUC the "cmake server" is just cmake in interactive mode to which you send commands over its stdin, right? If so I should be able to provide its output without even using KDevelop

Yes, if you could do that, that would be even better.

No problem, but it would help if you could give me a typical invocation and list of commands to test.
R.

Don't bother testing with cmake 3.7.1. It's broken.

Aleix

[Aleix Pol]

Post by Aleix Pol

Post by René J.V. Bertin

Post by Aleix Pol

Post by René J.V. Bertin
Maybe there are things I can try "manually"? IIUC the "cmake server" is just cmake in interactive mode to which you send commands over its stdin, right? If so I should be able to provide its output without even using KDevelop

Yes, if you could do that, that would be even better.

No problem, but it would help if you could give me a typical invocation and list of commands to test.
R.

Don't bother testing with cmake 3.7.1. It's broken.
Aleix

For completion, here you can see how I debugged this issue:
https://gitlab.kitware.com/cmake/cmake/issues/16531

Aleix

[René J.V. Bertin]

On Thursday March 23 2017 17:38:37 Aleix Pol wrote:

Hi,

Remembered this tidbit after rediscovering cmake's "server" mode in Qt Creator. I now have 3.8.2 installed, is that version really unbroken?

R.

Post by Aleix Pol

Post by Aleix Pol
Don't bother testing with cmake 3.7.1. It's broken.
Aleix

https://gitlab.kitware.com/cmake/cmake/issues/16531
Aleix

[Aleix Pol]

Post by René J.V. Bertin
Hi,
Remembered this tidbit after rediscovering cmake's "server" mode in Qt Creator. I now have 3.8.2 installed, is that version really unbroken?
R.

Post by Aleix Pol

Post by Aleix Pol
Don't bother testing with cmake 3.7.1. It's broken.
Aleix

https://gitlab.kitware.com/cmake/cmake/issues/16531
Aleix

Yes