Tags: mcpplibs/godot-cpp-m

feat: godot-cpp 10.0.0-rc1 (Godot 4.6), unblocked by a hashfuncs shim

Upstream godot-cpp moved onto its own version line, and 10.0.0-rc1 binds
Godot 4.6. Wrapping it hit a wall that no amount of exporting-less could get
around:

  error: 'uint32_t godot::hash_murmur3_one_float(float, uint32_t)' exposes
         TU-local entity 'union ...::<unnamed>'
  note: ... is also TU-local but has been exposed elsewhere

hash_murmur3_one_float/_double are `static` -- internal linkage, hence
TU-local -- and each declares an unnamed union in its body, which is a class
with no linkage. Exposing a TU-local TYPE from a module interface is a hard
error, and -Wno-expose-global-module-tu-local, -fpermissive and -Wno-error=
all leave it standing (all three verified). Nor is it attributable to any one
export: minimising the export set converges on a single engine class being
enough, and dropping that one still leaves the error, because with 10.x many
of them reach those functions independently. Scoping out the whole templates/
layer did not help either.

The fix is a shim header, generated next to the module unit: upstream's
hashfuncs.hpp with `static` dropped from exactly those two functions and
nothing else changed. This package's include/ precedes the dependency's on the
command line, so only this package's TUs see it -- compat.godot-cpp keeps
compiling upstream's copy untouched -- and the bodies are identical, so the
sole difference is linkage: internal (a copy per TU, invisible) becomes inline
(one weak symbol). The generator refuses to run if either declaration stops
matching exactly once, so an upstream rename cannot silently disable it.

With the shim, nothing has to be held back any more. The skip lists are gone
and the export surface grows on both versions -- 4.5: 1754 -> 1765, 10.x:
1818 -- picking up HashMap, HashSet, AHashMap, PairHash and the rest of
templates/.

Verified with the CI-pinned mcpp 2026.8.3.3:
  mcpp test        -> 2 passed; 0 failed (module surface + GDCLASS/macros)
  examples/summator -> libsummator.so exporting summator_library_init

release: short name is godot-cpp-m, not godot-cpp

This package and its own compat.godot-cpp dependency are always resolved
together, and mcpp's installed-package lookup matches on (name, version)
WITHOUT the namespace. With both named `godot-cpp` at the same version --
which "the version tracks upstream" guarantees -- resolving this one lands on
compat's unpacked directory and dies with

  index entry has no `mcpp = ...` field, and no mcpp.toml was found at
  <verdir>/mcpp.toml or <verdir>/*/mcpp.toml

Reproducible with a namespace unrelated to either package: leave a single
<anything>-x-godot-cpp/4.5.0 in the store and the resolution goes to it;
remove it and the same descriptor installs and builds fine. The store
DIRECTORIES are namespaced (ns-x-name) -- it is the lookup that is not.

Distinct short names sidestep it entirely, keep the version tracking upstream,
and `-m` matches the repository name. `import godot_cpp;` is unchanged.