Suggest of reimplementing the CMake support with cmake-server

[DWVoid]

I was studying the code of jucipp in resent days and noticed that you are implementing cmake support in a hard way. Since cmake3.7 a official server mode was added to cmake to provide semantic information about CMake code it executes to generate. I consider it a much better way of implementing cmake support.

[DWVoid]

PS: A detailed documentation can be found here on the official website

[eidheim]

Thank you, I found the information we need by running cmake -E server --debug --experimental and sending the following commands:

[== "CMake Server" ==[
{"type":"handshake","protocolVersion":{"major":1},
 "sourceDirectory":"/Users/eidheim/test/examples", "buildDirectory":"/Users/eidheim/test/examples/build"}
]== "CMake Server" ==]

[== "CMake Server" ==[
{"type":"configure"}
]== "CMake Server" ==]

[== "CMake Server" ==[
{"type":"compute"}
]== "CMake Server" ==]

[== "CMake Server" ==[
{"type":"codemodel"}
]== "CMake Server" ==]

I did not find an exit command though.

Meson, on the other hand, let us know which executables exist in the project in its generated compile_commands.json file. I would like to see this done by CMake as well, but I guess in the meanwhile one would have to use the cmake-server to get accurate result in all cases. The main issue with this approach though, compared to the current, is higher resource use. Also, not all commonly used Linux distributions have cmake version >=3.7 installed.

[eidheim]

After some additional tests, I find the cmake-server quite slow, even though the build directory has been prepared (both compile_commands.json and executables present).

[DWVoid]

Well, cmake does not consider compile_commands.json as part of the build system info, but just a generated file, so normally fetching such data will take a couple of seconds since it have to iterate through the trees to get these data needed. But I consider this cost of time acceptable since users will not be bothered with inaccurate data, which cost them much more than a couple of seconds. Currently I am trying to refactor the build system and make configurations run as background tasks on my local branch. I'll put that to test if I have time.

[DWVoid]

For older versions, if you want to get accurate information, there are two choices. One is to iterate through the trees by yourself and extract information form *.cmake files. A second choice is to read from the generated makefile or project. Either way is hard.

[DWVoid]

PS: I've just checked out the cmake support for qtcreator and discovered that it implemented both support for legacy versions with codeblock projects and newer versions with cmake server. But the information extracted from generated files seems rather inaccurate and I could see a lot of hacks was applyed in the code. As a conclusion, I personally suggests that maybe bundling a desired cmake version in the IDE might be g good idea.

[DWVoid]

PPS: another possible implementation is by using CMAKE_TOOLCHIAN_FILES Write a toolchain file like this:

# Mark variables as used so cmake doesn't complain about them
mark_as_advanced(CMAKE_TOOLCHAIN_FILE)

function(juci_dump_target_info name)
    get_target_property(TGT_SRC ${name} SOURCES)
    get_target_property(TGT_TYPE ${name} TYPE)
    file(WRITE ${CMAKE_BINARY_DIR}/targets/${name}.txt 
        "TYPE:${TGT_TYPE}\n"
        "NAME:${name}\n"
        "SOURCES:${TGT_SRC}\n"
        )
endfunction()

function(add_executable name)
    _add_executable(${ARGV})
    if(NOT _CMAKE_IN_TRY_COMPILE)
        juci_dump_target_info(${name})
    endif()
endfunction()

function(add_library name type)
    _add_library(${ARGV})
    if(NOT _CMAKE_IN_TRY_COMPILE)
        juci_dump_target_info(${name})
    endif()
endfunction()

Supply it during configuration via -DCMAKE_TOOLCHAIN_FILE and it will dump target info under the binary directory automatically, generating something like

TYPE:EXECUTABLE
NAME:TestConfiguration
SOURCES:main.cpp

The information is accurate, but the downside is that users will be troubled if their project need to supply their toolchain file. I am still working on a solution right now.