Allow godot-cpp to be installable

[ytnuf]

Describe the project you are working on

Currently making a gdextension library for dammaku.

Describe the problem or limitation you are having in your project

Currently the way to use godot-cpp is to use as a subproject of your project.

A package manager such as vcpkg would be preferable as one doesn't need to rebuild godot-cpp whenever they build a gdextension project.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I have made a PR that would make godot-cpp installable.

godotengine/godot-cpp#1418

There are other PRs that also try to address this:

godotengine/godot-cpp#1309
godotengine/godot-cpp#1041

One of the authors would like to be able to build & install this in a docker image to save time. So this would have that benefit too.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

find_package("godot-cpp" 4.2.0 CONFIG REQUIRED)
target_link_library("my-gdextension-project" PRIVATE "godot::cpp")

If this enhancement will not be used often, can it be worked around with a few lines of script?

The work around is using godot-cpp as a subproject, but that can undesirable (unnecessary rebuilds).

Making the library installable, would mean it's a lot easier to port this to package managers.

Is there a reason why this should be core and not an add-on in the asset library?

This feature is for godot-cpp.

[sanderfoobar]

This would be great, as it allows package maintainers of, for example, various Linux distributions to include godot-cpp as a package more easily. It's also nice when us developers are able to keep godot-cpp out of our project and have it just sit somewhere in /usr/local/, and locate it via find_package() and enforce a version.

Working with submodules is annoying, and imo is a relic of earlier times: "just vendor everything in your build tree as-is"

[dsnopek]

Installing godot-cpp system-wide and dynamically linking it will create some issues with the binary compatibility model of godot-cpp.

Currently, you build your extension to statically include the version of godot-cpp and extension_api.json of the Godot version you are targeting, which will allow it to work with that version of Godot or later. Other extensions you use may be compiled against a different godot-cpp/extension_api.json, and you can use those together in the same project without problems.

If your extension were dynamically linked to a system-wide godot-cpp, and you updated the system-wide godot-cpp for a newer version of Godot, it could break existing extensions that were compiled against the older godot-cpp. So, you end up in a situation where you need to update and re-compile all your GDExtensions to work with the one godot-cpp.

[sanderfoobar]

@dsnopek CMake should generate library filenames that take into account the version, and a consumer only has to enforce the version requirement through find_package().

Not everything in e.g /usr/local/ is dynamically linked, and godot-cpp should be statically linked. By using CMake's project(godot-cpp VERSION x.x.x) and then install'ing it, CMake can write these files to the libdir in a manner that does not clash with others, as well as generate the necessary CMake config files to differentiate between the various installed versions.

In short, you'll be able to install multiple godot-cpp's to a libdir/includedir. There is nothing that says everything in /usr should be dynamically linked. See also find /usr/lib/x86_64-linux-gnu/ | grep 'a$'

[dsnopek]

Ah, ok, thanks! If developers are still statically linking with godot-cpp, then there is no effect on binary compatibility.