cmake server (was: CMAKE_HOME_DIRECTORY error/warning message?)

[René J.V. Bertin]

On Thursday March 23 2017 00:32:11 Aleix Pol wrote:

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

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