godot_singleton_init and godot_gdnative_singleton are missing

[thorlucas]

Great library! Will come in handy for a game I'm working on, where I'd like to write some of the data manipulation in Rust. However:

Provisions for GDNative singletons are missing entirely from the library. Exporting a function called godot_singleton_init seems to work to solve one of the problems, however I am unsure on how to register the godot_gdnative_singleton types. Macros need to be created to handle this.

I'm sorry, but I don't think I understood what you are trying to accomplish. What is godot_singleton_init and godot_gdnative_singleton? They don't seem to be present in the GDNative C API at all. Searches for these symbols in the Godot repository yielded no results. May I ask what version of Godot are you using?

If by "GDNative singletons" you mean auto-load scripts, I'm able to register them in Project Settings -> AutoLoad. Just point Path to your .gdns file.

I see that godot_singleton_init is an entry point that can be exposed to Godot. This is a feature that hasn't been required by me and other users so far, so if you could explain how you plan to use it, it could help us greatly in understanding its importance!

[LikeLakers2]

Hi! I don't have too much of a use case, but I thought I'd throw my thoughts out there for you to hear.

I'm wanting to write my own bindings to SQLite (specifically, the rusqlite crate). While most of the bindings can be written with Godot-rust as-is, I feel like some parts of it (primarily the global functions like sqlite3_version() or sqlite3_config()) may be better exposed under a singleton.

I hope that helps you understand why singleton capabilities may be useful to me.

@LikeLakers2 AFAIK that is possible to do with an auto-load "singleton", and doesn't require godot_singleton_init:

#[derive(NativeClass, Copy, Default)]
#[inherit(Node)]
#[user_data(Aether<Self>)] // This is a light-weight user-data wrapper for this exact purpose. It doesn't perform any allocation.
struct SQLite;

#[methods]
impl SQLite {
    #[export]
    fn version() -> Version {
        call_sqlite3_version()
    }
}

You can then register the gdns for this type as an auto-load script in project settings, as if it was a GDScript singleton. You'll then be able to access its methods from GDScript or other languages, as if it was a GDScript singleton.

Is there anything you need from godot_singleton_init that isn't covered by this? I can't find any examples of godot_singleton_init on the internet, so some explanation would certainly help.

[LikeLakers2]

Is there anything you need from godot_singleton_init that isn't covered by this?

Not really. Thank you for the suggestion, by the way!

However, thinking about it, it feels like an AutoLoad would have the same effect as setting a GDNativeLibrary as a singleton in almost any situation. And if that's the case, I wonder why they even offer setting a library as a singleton at all. The documentation does state that singleton libraries are loaded at startup rather than the first time they're called, and it does state that singleton libraries can't be reloadable, but those two don't really seem like practical advantages over just using an AutoLoad.

It just seems odd to me. Maybe it's worth some level of investigation? Perhaps singleton libraries have other differences that would make them beneficial over using an AutoLoad-ed NativeScript. If it turns out they do, then we have a reason to support godot_singleton_init and godot_gdnative_singleton -- and if they don't, then we can document that and document your workaround.

Did some blaming and it appears that "singleton libraries" are added by karroffel in godotengine/godot#10921. The commit message reads:

A GDNativeLibrary now has a field "gdnative_singleton" which can be
used to let the godot_gdnative_singleton procedure be executed on
Godot's startup. In future this can be used to register new
scripting languages or resource importer types.

So judging from the stated purpose here, I'd suppose that the "singleton" name is really a misnomer. Should have been "early loaded" or something. This should be worth supporting (even though there isn't much to do -- the entry point is just a nullary function) and documenting!