Add missing GODOTCPP_API_VERSION to CMakeLists.txt

[jacobcoughenour]

Cloning the template right now then trying to build it with CMake instead of SCons gives you this error about the GODOTCPP_API_VERSION being unset:

-- Found Python3: /usr/bin/python3.14 (found suitable version "3.14.7", minimum required is "3.4") found components: Interpreter
-- Auto-detected 24 CPU cores available for build parallelism.
-- If not already cached, setting CMAKE_MSVC_RUNTIME_LIBRARY.
        For more information please read godot-cpp/cmake/windows.cmake
-- The CXX compiler identification is GNU 16.2.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using all cores. You can override this at configure time by using -j <n> or --parallel <n> in the build command.
--   eg. cmake --build . -j 7  ...
CMake Error at godot-cpp/cmake/godotcpp.cmake:280 (message):
  'GODOTCPP_API_VERSION' must be provided
Call Stack (most recent call first):
  godot-cpp/CMakeLists.txt:72 (godotcpp_generate)

I just set it to 4.3 in the CMakeLists.txt now to match how it's being set in SConstruct as of #130

[Ivorforce]

cc @enetheru

[enetheru]

i haven't checked, but wasn't the godot-cpp decision to leave the variable unset to ensure people know they have to set it?
I think this was the discussion i was recollecting: godotengine/godot-cpp#2034

[dsnopek]

Yeah, on the godot-cpp side, we want developers to set it, but in the godot-cpp-template I think it makes sense to set it to show developers how

[enetheru]

Yeah, on the godot-cpp side, we want developers to set it, but in the godot-cpp-template I think it makes sense to set it to show developers how

Then I think a cached variable would suit as a means of setting a default, and exposing it from the command line as something settable. This is off the top of my head but should be about right:

# This sets the default for the value to 4.3, and will expose the setting when calling the `cmake -L <source path>` on the command line 
set( GODOTCPP_API_VERSION "4.3" CACHE STRING "Some form of description of what the version does, and what the plugin developer supports")
# Setting this property will expose the list of comma separated values in the cmake gui in a dropdown(i think), and any tool that supports such things.
set_property(CACHE GODOTCPP_API_VERSION PROPERTY STRINGS "4.3;<semicolon separated API versions the plugin supports>")

but if the plugin developer simply wants to set the variable then what @jacobcoughenour has done is perfectly valid.

[dsnopek]

I'd expect any setting to be on the godot-cpp side, or does that need to be in the extension itself with CMake?

With SCons we define the setting in godot-cpp, and then in the extension (or the template in this case) the developer can set their own default

[enetheru]

I'd expect any setting to be on the godot-cpp side, or does that need to be in the extension itself with CMake?

With SCons we define the setting in godot-cpp, and then in the extension (or the template in this case) the developer can set their own default

Well setting the variable would create a default, something you wanted to avoid in godot-cpp.
There's nothing special that needs to happen in godot-cpp to define it.
CMake vars once set exist for all child scopes, so setting it in the plugin makes that value available to godot-cpp as godot-cpp is a child scope of the parent plugin project.