Closed starry-abyss closed 6 years ago
No, the external generation is fine as it is. I agree that the godotbinpath is confusing, I should change it to point to the actual executable itself, so the naming problems should go away.
To expand a little bit more on that:
GDNative is a simple API that's very thin and tries to leave as much work for the bindings - as such it doesn't make any assumptions about how bindings should be made. This is a strength because C++ is no less favored than Nim, D, Rust or even Brainfuck.
The SConstruct
file needs a path to the Godot executable because that executable generates a JSON file that can be used to create class bindings for Godot classes. So this is kind of like a pre-binding-generation, the binding_generator.py then just does the rest to actually make that into C++.
I know this looks a bit over-the-top when you only consider C++ bindings, but this has great flexibility and as such there won't be any build-in-support from Godot for any language bindings.
That said, the mentioned godotbinpath fix was added a while ago :)
Instead of messing with specifying in
SConstruct
where Godot executable resides not forgetting about trailing slash and also replacingtools.64
withtools.32
, it might be more convenient to run binding generation from Godot executable (command line and/or from menu)