use gdnative-project-utils for creation of Godot resources

[karroffel]

The project utils crate has an API usable in build scripts and automatically creates any .gdns and .gdnlib files required. Maybe it makes sense for new projects to use that instead of manually creating those resources?

Ideally any issues that come up with the crate should be fixed, I do think it makes the workflow a lot better, so it might make sense to use it in new projects by default?

Let me know what you think!

[macalimlim]

The .gdnlib file is only created once, and most of the time you don't have to touch it again unless you have to add more targets (which I plan to do in the future). The template already does the creation of game.gdnlib file for you. As for the .gdns files, these files are created ad hoc which the project utils crate would make sense. The generated .gdns file should point to the game.gdnlib which was created by the template. This would be a good feature if we could run it on the $EDITOR like whenever a user creates a *.rs file that derives from NativeClass, a corresponding .gdns file is created within the scenes directory. If not from the $EDITOR, we can run it from make.

[karroffel]

The template already does the creation of game.gdnlib file for you.

That's fair, probably the gdnative_project_utils API should have a way to specify a pre-made gdnlib file.

This would be a good feature if we could run it on the $EDITOR like whenever a user creates a *.rs file that derives from NativeClass, a corresponding .gdns file is created within the scenes directory. If not from the $EDITOR, we can run it from make.

The behaviour with using the project utils is the same actually. If you use it in a build script then the .gdns files will be automatically created (if they don't already exist) in a directory that can be specified. There is no need to run make or a custom tool, just invoking cargo will deal with all that.

If you feel like that approach is not well suited then I'd love to hear how to make the project-utils accomodate what you imagine it should do!

[macalimlim]

That's fair, probably the gdnative_project_utils API should have a way to specify a pre-made gdnlib file.

Yeah, If a .gdnlib file exist, skip creating a .gdnlib file then create the .gdns files referencing the already existing .gdnlib file, if the .gdnlib file does not exist, create a game.gdnlib then proceed to creating the .gdns files referencing game.gdnlib.

We can go further with .tscn files :smile: And even further with lib.rs :wink:

Which brings me to, what if we build something like what Ruby on Rails does?

For example:

In Ruby on Rails they have

$ rails new my-awesome-game

it does similar to our template

In our theoretical app (lets call it godot-rust)

$ godot-rust new my-awesome-game <template-type>

<template-type> can be optional :wink:

In Ruby on Rails they have

$ rails server

it runs the web app and view it on the browser, similar to our make run

We can have

$ godot-rust run

In Ruby on Rails they have

$ rails generate controller Player

this creates PlayerController class plus a bunch of other files used by the controller

In our app, we can have

$ godot-rust create-class Player <node-type>

which creates the files we discussed above

This might be a stretch, wdyt?

[karroffel]

Yeah, If a .gdnlib file exist, skip creating a .gdnlib file then create the .gdns files referencing the already existing .gdnlib file, if the .gdnlib file does not exist, create a game.gdnlib then proceed to creating the .gdns files referencing game.gdnlib.

It actually basically does all that already, it tries to create a new .gdnlib if none exists already. The only "issue" is that that .gdnlib file is called {{crate}}.gdnlib and is in the same folder as generated .gdns files. That's why I suggested to maybe make it so that a custom name/path can be supplied.

We can go further with .tscn files smile And even further with lib.rs wink

I thought about that, but I feel like that is a bit too much of an "invasion" into the code for a tool like that. I intended the project-utils crate to be a nice helper that does work for you in the background. Having to include!(concat!(env!("OUT_DIR"), "/init_function.rs")) feels a bit too much like an implementation detail to me.

That's not the best explanation I can give, but I personally as a person that works on code like clarity more than that added developer convenience.

Which brings me to, what if we build something like what Ruby on Rails does?

That might be a useful tool, but I personally think there's a lot of value in adding as much convenience into tools that everybody already uses. Which is why I think (ab-)using build scripts for these tasks is a nice hack :)

[macalimlim]

That might be a useful tool...

I will spike it out first, If I have working prototype, I will share it to you guys :wink:

It actually basically does all that already, it tries to create a new .gdnlib if none exists already. The only "issue" is that that .gdnlib file is called {{crate}}.gdnlib and is in the same folder as generated .gdns files. That's why I suggested to maybe make it so that a custom name/path can be supplied.

For the .gdnlib file, can we just name it to game.gdnlib? It's for simplistic reasons (and one less thing to think about).

When I started the template I'm not really sure where to put the .gdnlib and .gdns files. I put them where I think where they logically should be. Is there a convention, standard or best practice on where to put these files? What do the others think about this? Maybe lets discuss it more with one more guy (or everyone) here and also maybe put it in a vote on where to put those, Once decided, the template and/or project util will adjust accordingly.

wdyt?

[ghost]

I don't think there is a "standard best practice" yet. Personally I put .gdnlib and all .gdns files under a native directory under the project root when using GDNative, and binaries under native/bin/{platform}, but I only have one GDNative binary for everything in my project. If I had multiple ones I might have used a lib{crate} directory for each one of them, instead of native.

[macalimlim]

Ok, I will adjust the template to put the .gdnlib and .gdns files under native directory. How about for the name of the .gdnlib file itself? I would prefer it to be game.gdnlib...

[ghost]

I do use the crate name, or precisely lib{crate} for the .gdnlib file as well, but if it's hard to make it change with the crate name, then game.gdnlib should also be fine. I don't know enough about cargo-generate to know which way it is.

[karroffel]

If it would be {{crate}}.gdnlib under a native/ folder then that's exactly the behaviour that gdnative_project_utils already has