The `GDCLASS` macro should not assume to be called inside the `godot`
namespace and should thus prefix function calls for that namespace with
`::godot::` to ensure proper namespace referencing.
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.
Rémi Verschelde
Aaron Franke
Fabio Alessandrelli
clayjohn
Zhehang Ding
bruvzg
Yuri Sizov
Hugo Locurcio
Alexander Rieder
Kevin Smith
DNKpp
Joshua Cooper