[GDExtension/CMake] Add shared Godot/Godot-cpp CMakeFile for use via FetchContent

[LouChiSoft]

I know CMake support is new and isn't as mature as SCons, but as it get better I think more people are going to prefer it over SCons. Right now from my experience if I want to make a GDExtension with CMake I need to manually get, build and run a matching version of Godot to dump the extension_api.json to then pass it into the godot-cpp CMakeLists for making the GDExtension.

My proposal is a sort of CMake based "glue file". The idea would be that you can use via methods like FetchContent and gets and builds both the Godot engine and the godo-cpp library. It would sync the settings between the projects, precision, engine version, etc. and provide a target for the godot engine being built for a convenient way to test the GDExtension being developed.

In theory if done well, the user could include the CMakeLists.txt then using a custom command add targets for each combination of engine settings. e.g. one target for single precision and one target for double precision, as well as generating a gdextension file based on the outputs of the project. Also a user updating a GDExtension would be as simple as updating the branch that is used to build Godot and godot-cpp.

Pseudo-code example usage:

# Standard project setup
project(my-gdextension LANGUAGES CXX)
    set(CMAKE_CXX_STANDARD 17)
    set(CMAKE_CXX_STANDARD_REQUIRED ON)

    # Include new CMake project files
    include(FetchContent)
    FetchContent_Declare(
        godot-cmake
        GIT_REPOSITORY https://github.com/godotengine/godot-cmake.git
    )
    FetchContent_MakeAvailable(godot-cmake)

    # Define GDExtension target
    file(GLOB SRC "src/*.cpp")
    add_library(${PROJECT_NAME} SHARED ${SRC})
    target_include_directories(${PROJECT_NAME} PRIVATE "${CMAKE_SOURCE_DIR}/src")

    # Link to Godot and Godot-CPP
    link_to_godot(
        TARGET ${PROJECT_NAME} 
        PRECISION "single"
        # other features
    )
    
    # Same again, but this time for double precision
    link_to_godot(
        TARGET ${PROJECT_NAME} 
        PRECISION "double"
        # other features
    )

    # Generate a GDExtension file
    generate_gdextension_file(
        TARGET ${PROJECT_NAME}
    )

[dsnopek]

cc @enetheru

[enetheru]

I know CMake support is new and isn't as mature as SCons, but as it get better I think more people are going to prefer it over SCons.

The install base of CMake is larger, so even if it isnt a chosen preference, I can also see it being widely used for third party library integration.

Right now from my experience if I want to make a GDExtension with CMake I need to manually get, build and run a matching version of Godot to dump the extension_api.json to then pass it into the godot-cpp CMakeLists for making the GDExtension.

AFAIK This is only the case if you are using the master branch, or if you are using a custom godot. The godot-cpp releases are made to match the godot releases such that you should be able to use one of the release branches, use the api.json provided, and have it work. Also the api.json doesnt depend on precision. To test the extension you need godot regardless of configuration.

I can see a point to using a chosen godot executable as a means to configure matching build arguments for godot-cpp, and I've looked into this myself a while ago, but at the time didnt find a way to fetch a list of feature flags.

My proposal is a sort of CMake based "glue file". The idea would be that you can use via methods like FetchContent and gets and builds both the Godot engine and the godo-cpp library. It would sync the settings between the projects, precision, engine version, etc. and provide a target for the godot engine being built for a convenient way to test the GDExtension being developed.

This has been done before in vorlac's rogue-lite project. And IMHO does indeed fit best as a separate project. There was discussion somewhere about a demo or example git repo to put projects that can be used as starting points for different concepts, and this would suit that agenda.

There is one more thing I want to make sure is understood; There is a requirement of feature parity between SCons and CMake in the godot-cpp project, so anything that is built for one needs to be built for the other and maintained, so please keep that in mind.

Cheers,
Enetheru.

[LouChiSoft]

AFAIK This is only the case if you are using the master branch, or if you are using a custom godot.

True, but if you're developing a plugin intended for wider use you might also be more inclined to use pre-releases/non-release versions while you develop new versions to test upcoming features and bug fixes. There is value in being able to sync everything quickly and easily.

Also the api.json doesnt depend on precision.

It doesn't? This is explicity something I was told would affect the extension_api.json here . In either case, being able to have a separate target for each precision type would still be beneficial for people like myself who uses CLion for development where running single and double precision would be as simple as changing targets.

To test the extension you need godot regardless of configuration.

Again, true. But to test a double precision build you would still need a double precision Godot which IIRC isn't available as a release build on the Godot website where most people get the engine from. So you're going to have to build it anyway.

I can see a point to using a chosen godot executable as a means to configure matching build arguments for godot-cpp, and I've looked into this myself a while ago, but at the time didnt find a way to fetch a list of feature flags.

If I understand this correctly, you are suggesting that the Godot engine executable itself stores the build features and you would be able to pass those build features to godot-cpp to make a matching build? That wasn't a direction I had considered. And to be honest thinking about it more, if there was a convenient way to query the build features then to me it would make more sense to add a godot-executable flag to the godot-cpp CMake file that takes a path to a godot executable and internally would query the build features and match them in godot-cpp. Doing it that way would remove the need for a glue file, at least for the official releases where you just need to download the file.

There is one more thing I want to make sure is understood; There is a requirement of feature parity between SCons and CMake in the godot-cpp project, so anything that is built for one needs to be built for the other and maintained, so please keep that in mind.

I have little to no experience with SCons. Before using Godot I hadn't even heard of it. I understand that there is a feature parity requirement, but what happens when the tools themselves don't have feature parity? CMake has FetchContent which if used properly is a very convenient way to get and include other CMake projects in your project. To my knowledge, but feel free to correct me if I am wrong, SCons doesn't have such an equivalent feature. You admitted yourself that given CMake's wider user base that it could be widely used for third party integrations. To me at least it makes sense to make that process as simple as possible in some manner. Not necessarily my suggestion.

Cheers,
LouChiSoft