[DISCUSSION] Plugin Functions (what will do)

[nonunknown]

While we discuss UX at #1 I think its important to decide the plugin functions, I mean what it will be able to do.
Also a lot of objectives was mentioned in godot-proposals 119, but here we need to specify more things, and more specific things too. Here's my list:

• Copy source files to project folder e.g library/HelloWorld.cpp to godotproject/cpp/HelloWorld.cpp
• Support Cross-compiling for all platforms
• Support Rust Language (Done yet!)
• Support Nim Language (to study)

[willnationsdev]

Support Rust Language (Done yet!)
Support Nim Language (to study)

I would try and make language-specific operations an async/one-way dependency. After all, the end-goal is to have whatever plugin design we make be something that could conceivably be integrated into the official engine in a future release (once the design is finalized). So, the code should try to work off a generic interface to perform all of its operations, and then each language binding should provide its own implementation of that interface to plug its own operations into the required methods that the plugin depends on. This is referring to the various operations that 119 mentions.

So, rather than the quoted stuff above, it would just be something that bindings include in their own repos that implements a class that we have defined (and they could maintain that in a separate branch, or their master, or however they want to do that).

[SIsilicon]

How about the ability to support custom language, as long as you have the templates and build script for them.
That way, supporting languages like Rust and Nim can be done more efficiently, and can be maintained apart from the main plugin.

Edit: Basically what @willnationsdev said.

[SIsilicon]

While we are taking about Plugin functions, where we should place all the data for the following?

• source code per Library
• binaries per Library
• the languages' data (templates and build scripts)
• bindings (per language?)

For reference, I have the following setup in my plugin now.

• source code under addons/gdnative_data/<Library>/src
• binaries under addons/gdnative_data/<Library>/bin
• language data under <Godot Data Folder>/native_languages
• godot cpp bindings under <Godot Data Folder>/native_languages

[willnationsdev]

Cross-compilation, also, should be something that is mostly handled by the target language since they are the ones defining what compilation tools should be used.

All our code should do is ascertain what the current platform is and provide an interface for

1. What platforms are available for target_language?
2. Which platform out of those options does the user currently want to target?

These would both be questions that are answered by methods on a GDNativeBuild object since the object defines the entirety of the build configuration (or something to that effect - we might wanna distinguish between a Library and its source code files vs. the configuration of parameters to pass to a given compiler tool.

[nonunknown]

The problem is , @SIsilicon, that CPP and Rust, and probably Nim, workflow are totally different, there's no way to create a pattern between them, I recommend you to check godot-rust bindings, there you will see how it works.

[willnationsdev]

@SIsilicon My proposal handles all that stuff in a GDNativeBuild resource (generic interface) with language-specific implementations of those scripts. Then, the user should be the one to decide where they want to store their source code/build files (res://, user://, 3rd-party location). It should all be something the user decides.

[willnationsdev]

@nonunknown Isn't the basic pattern of how builds work all the same under-the-hood? Even if the exact files are different and the exact compilers, etc. you still have some collection of source files, an optional set of header/definition files (C/C++/F# all have things like that), and a list of dependent library files. Then you need the compiler tool, the target platform, the target build type (release/debug), and whatever other arbitrary list of compiler options are needed (which the language should be able to specify). Do C/C++, Rust, and Nim behave in different ways in these regards?

[SIsilicon]

The problem is , @SIsilicon, that CPP and Rust, and probably Nim, workflow are totally different, there's no way to create a pattern between them, I recommend you to check godot-rust bindings, there you will see how it works.

Just checked out the rust bindings. I think that as long as the process of building the code can be automated from a python script (assuming we're using Python here), then any language can be implemented as a "custom language". After all, they all still build the same thing: a binary that Godot can use.

[willnationsdev]

@SIsilicon Idk if we want to assume a dependency on python though. I suppose we could, but I do know that there are people who want to compile Godot with their own custom compiler options (not scons) so they don't necessarily have to be tied to Python. But if it is necessary to use python in order to have git-less fetching/unpacking of git repos for source code, then demanding that dependency might be worth it.

[SIsilicon]

Yeah, after all, you don't need Scons for every language. the language can simply request that Scons should be installed.
Plus, using python instead of a batch file or shell script makes it easier to cross compile, plus you get more built-in features such as tkinter, which I use to prompt the user to locate the android ndk for compiling to Android.

[nonunknown]

@willnationsdev as you mentioned under the hood is the same, but the workflow changes, rust need to recompile the bindings everytime (when I tested, maybe I can be wrong) but it already generate everything the workflow is way easier than cpp

@SIsilicon There's no need to automate with python, when can do everything executing shell commands this way we avoid more dependencies as will mentioned.

Rust workflow:

cargo --lib lib_name_here
modify your code
cargo build
done

CPP workflow:
Generate Bindings
Create your code
Create Gdlib.cpp (register classes)
Compile Code
Done

[SIsilicon]

Yes, but when you use shell commands, you then require to make a version for the three different desktop platforms, which means more code to maintain (batch for Windows, shell for Linux and Mac).

[willnationsdev]

@SIsilicon Ah, true. Yeah, python would definitely make that easier. And make just writing the code a lot easier (geez, I really dislike bash/batch scripting - Python's a lot better).

[willnationsdev]

Wait, does Rust not have any sort of bindings generation process? How are you supposed to use Rust in master versions of the engine? Do they not generate their API automatically?

[willnationsdev]

Here we go. They do still have the ability to generate bindings for custom builds: https://godot-rust.github.io/book/advanced-guides/custom-bindings.html