The unqualified ClassDB friending was causing (at least for me on
VS2022) an implicit forward declaration of ClassDB in the namespace
of my class, instead of using the godot namespaced one. By qualifying
the namespace, this compiles for me.
Test-Information:
My project builds now.
This is an attempt to make the lifecycle of wrapped objects clearer.
Godot keeps track of bindings' userdata for each object it creates.
This allows allocating the memory of the wrapper only once per object
even if that object is passed multiple times between binding code and
godot code.
The binding information is composed of multiple functions, this includes
a callback for when the userdata is to be allocated (called once) and
for when the userdata is to be deallocated (again, called once).
When allocating data with "memnew" we set the object bindings during the
postinitialize phase, but surely we shouldn't do that when allocating
the userdata as a result of bindings callback themselves.
Additionally, since we let Godot handle (and track) raw memory
allocation and de-allocation, we need to manually call the deconstructor
of the wrapper class during the free callback, to ensure that its
non-trivial members are correctly de-initialized.
Previously, Windows builds were being produced without debug
information, leading to somewhat unhelpful backtraces etc.
without symbols.
This builds the symbols in (only for debug builds - I've
deliberately not touched release builds here) so gdextension
bugs are a little more tractable.
Test-Information:
Have been running this patch for weeks, and getting useful
traces out on the commandline, and useful debugging from
debuggers.
This doesn't change the behavior when `--jobs`/`-j` is specified as a
command-line argument or in `SCONSFLAGS`.
The SCons hack used to know if `num_jobs` was set by the user is derived
from the MongoDB setup.
We use `os.cpu_count()` for portability (available since Python 3.4).
With 4 CPUs or less, we use the max. With more than 4 we use max - 1 to
preserve some bandwidth for the user's other programs.
Visual C++ has a clang-based driver, available through the
clang-cl wrapper (which provides the same interface as
cl) - this generates objects binary-compatible with the
default (traditional) driver, and can then be linked in
the normal way. As such, this patch simply configures for
MSVCC and then overwrites the cl compiler with clang-cl
in the environment.
Clang gives (subjectively) much more understandable compiler warnings
and errors than MSVCC, which was my motivation for switching.
Test-Information:
Builds for me with VS2022, and my gdextension library
builds and links.
Rémi Verschelde
Hugo Locurcio
Alexander Rieder
Kevin Smith
Fabio Alessandrelli
DNKpp
bruvzg
Joshua Cooper
Alessandro Famà