Suggest of reimplementing the CMake support with cmake-server #379

Activity

1. DWVoid commented on May 18, 2018

   

   DWVoid

   on May 18, 2018

   Last edited by DWVoid

   Author

   More actions

   PS: A detailed documentation can be found here on the official website
2. eidheim commented on May 19, 2018

   

   eidheim

   on May 19, 2018

   Member

   More actions

   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.
3. eidheim commented on May 19, 2018

   

   eidheim

   on May 19, 2018

   Member

   More actions

   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).
4. DWVoid commented on May 19, 2018

   

   DWVoid

   on May 19, 2018

   Author

   More actions

   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.
5. DWVoid commented on May 19, 2018

   

   DWVoid

   on May 19, 2018

   Author

   More actions

   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.
6. DWVoid commented on May 20, 2018

   

   DWVoid

   on May 20, 2018

   Last edited by DWVoid

   Author

   More actions

   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.
7. DWVoid commented on May 20, 2018

   

   DWVoid

   on May 20, 2018

   Author

   More actions

   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.