godot-next icon indicating copy to clipboard operation
godot-next copied to clipboard

Framework and script(s) needed for C++ NativeScript integrations.

Open willnationsdev opened this issue 4 years ago • 2 comments

For this project and godot-journey, there are C++ scripts that need to exist. I would prefer to make compiling these scripts follow the same workflow that Godot Engine uses, with several sub-libraries compiled in a single execution, and built on the same infrastructure as it and the C++ GDNative bindings use for consistencies' sake: scons. This means writing an SConstruct file that can accommodate all of the projects' needs.

What I think would really be useful here is a script that will meet the requirements of any arbitrary combination of NativeScript C++ projects. I believe such a script would have the following requirements:

  • Allow multiple GDNative bindings versions to be supported so that users can store multiple bindings in a single directory and then select which bindings they want to use on command.
    • Perhaps also enable the script to download and store the GDNative bindings files in a centralized location, and manage the files for the user? That way the user just has to install git, but doesn't necessarily need to know how to use it. They can just install scons, run it, and it will do a git clone of the depended-on GDNative bindings for each project automatically.
  • Allow multiple GDNative projects to exist within the compilation framework such that a single scons command can build several dynamic libraries all at once.
    • Users should be able to configure which version of NativeScript each project will compile with.
  • Allow the compilation of these projects to automatically generate updated GDNativeLibrary and NativeScript resources (.gdnlib, .gdns) in configurable directories.
  • Allow the GDNative projects to specify other projects to include as dependencies within the compilation framework's script.
    • Dependencies would be compiled first as libraries and then the library would be included in the dependent library.
    • Dependencies would need to keep header files in a dedicated directory so that other projects can more easily access and include those header files in their compilation workflows.

Based on my limited knowledge of scons and Godot's module system, I think the per-project-customization features would involve each project having an SCSub file which could then be used by the top-level SConstruct script to plug into the compilation framework. Bonus points if we can program the scons script to generate a template SCSub file for an arbitrary project. Bonus-Bonus points if we work out a way to integrate all of this with a custom Godot resource that can replace the ongoing/unfinished work in the godot-builder repository.

willnationsdev avatar Aug 29 '19 18:08 willnationsdev

I would love to join this... Also in my case as an example, just providing the .cpp and .h** files would be perfect, I agree with you in case of Godot-Next turn into a godot module w/ a custom build.

nonunknown avatar Aug 03 '20 22:08 nonunknown

Most of the requirements for this are now bundled into godotengine/godot-proposals#119 which I have a bit of a WIP going on. Unfortunately, due to a monumentally large work thing that has come up, I'm likely going to have less and less time to devote to Godot stuff for a while. But, @nonunknown, if you are interested in spearheading some of that proposal's work, I'd be happy to give you guidance on it, etc. To be honest, for that proposal, the vast majority of the "work" is something that script code can do. You'd just need to write it all as a plugin to get it into a testable state and then port that script code to an editor-only module.

willnationsdev avatar Aug 07 '20 21:08 willnationsdev