remove build.rs

[macalimlim]

remove build.rs as its not needed anymore

[ghost]

Is the intention to stop using project-utils here? Why is that decision made?

[macalimlim]

yes until the new version of project-utils is released. If you notice I commented the code block on build.rs. It does nothing and doesn't make sense to include it. I can include it again once a new version of project-utils is released.

[ghost]

I don't see any relevant issues or PRs in the project-utils repo. Is the 0.1.2 release on crates.io simply not recent enough, or are there other problems that are not tracked as issues?

[macalimlim]

The current version of project-utils is overwriting the gdns file (which messes up the path to the original gdnlib file) and also adding another gdnlib file (which has different paths to the libraries (so, dll, dylib)). I can file this issue in project-utils. I guess we need more discussion on how can project-utils be compatible with the template since it is opinionated on what and where things should be. And honestly going forward, I don't see the purpose of project-utils in the template anymore, since ftw can automate stuff that is similar to project-utils plus more... Thoughts? @toasteater @karroffel

[ghost]

It does not make sense imo to push a separate CLI for what can totally be done without it. If project-utils will be dropped one day, it will be thanks to automatic registration via https://github.com/godot-rust/godot-rust/issues/350, not yet another separate thing to maintain.

As a personal anecdote, I have started using project-utils and find its defaults fairly sane, with *.gdnlib files excluded from version control. I'm using a .env file to point to the godot project, which is then read in the build script, and the whole setup works pretty well.

[macalimlim]

Oooh, that auto registration thing is very nice :+1: but even if the auto register thing is available today, it just helps in one part of the workflow. For example, ftw not only creates a class (*.rs file) but also wires up the gdns and tscn files for you (assuming auto register is working now). In comparison to project-utils, ftw provides a (which I strongly believe) much more seamless workflow from a dev's POV. Since everything in the template is already pre-configured for you, a developer don't have to think about configuring where certain paths are. Another advantage of ftw is comparing make run and ftw run. make run only works in one platform, you have to change it if you are on a different platform. ftw run works on the platform you are currently on without changing anything.

[ghost]

ftw not only creates a class (*.rs file) but also wires up the gdns and tscn files for you (assuming auto register is working now). In comparison to project-utils, ftw provides a (which I strongly believe) much more seamless workflow from a dev's POV.

godot-rust is not a framework. We don't want to bless any specific workflow by our tools. What described here strongly favors a certain workflow where each script is a Node and corresponds to a scene, one that is not even efficient in most cases:

• Frequent API access over FFI doesn't offer a lot of performance advantage over built-in scripting
• Low-level access to the scene tree is a lot more painful in Rust compared to GDScript
• Encourages the premature optimization use pattern

Indeed, most devs I have communicated with that are using the bindings for actual projects don't tend to pick such an architecture, including myself. Such a setup would be of little use outside quick experiments and GDScript porting (that is more than likely ill-adviced if not done for learning).

Another advantage of ftw is comparing make run and ftw run. make run only works in one platform, you have to change it if you are on a different platform. ftw run works on the platform you are currently on without changing anything.

You're leaving out the third option here: cargo build and F5, with an open editor. This also works on the platform you are currently on without changing anything, costing one extra keystroke for the extra benefit of remote debugging in the editor. How is this inferior to either of the commands you suggested?

[macalimlim]

Sure godot-rust is not a framework, but I think creating tools around the library is a great way of introducing it to the wider public. Beginners can quickly pick it up and create games. I don't have a good answer with the technical bits you stated but what I can say is with ftw class you can specify what type of the class is. The library has potential to be used more than just experiments. With cargo build and F5 you still have to modify the paths from gdnlib for it to be able to work. I haven't used the godot editor for debugging, mostly I used my own text editor's interface for rust-gdb...

[karroffel]

I published 0.1.3 of gdnative-project-utils on crates.io now!

[ghost]

The library has potential to be used more than just experiments.

Yes, of course, and by blessing a suboptimal pattern we risk limiting its potential to just that.

With cargo build and F5 you still have to modify the paths from gdnlib for it to be able to work.

So project-utils? It's a build script, so it'll be triggered by cargo build if necessary.

I haven't used the godot editor for debugging, mostly I used my own text editor's interface for rust-gdb...

This betrays that you have either never actually tried making a game with Godot, or are just terribly clueless and missing out on a huge part of Godot's value proposition. Even if you don't need to ever look at the remote node tree, there are many reasons why you would want an editor open at your disposal. Making a game is not just about eliminating crashes, but also iterating on game design, tweaking parameters, creating content, polishing the user interface, and on and on -- all tasks that benefit from a good editor, and that's what makes Godot so good!

Please, make something, however small, even if it's just on the level of a weekend game jam. Finish it, reflect on it, and then come back talking about improving workflows and such. How can you improve something that you don't even know about?

[macalimlim]

With cargo build and F5 you still have to modify the paths from gdnlib for it to be able to work.

What I meant by that is you have to change the path to the library from the gdnlib file if its either a debug or release.

This betrays that you have either never actually tried making a game with Godot, or are just terribly clueless and missing out on a huge part of Godot's value proposition. Even if you don't need to ever look at the remote node tree, there are many reasons why you would want an editor open at your disposal. Making a game is not just about eliminating crashes, but also iterating on game design, tweaking parameters, creating content, polishing the user interface, and on and on -- all tasks that benefit from a good editor, and that's what makes Godot so good! Please, make something, however small, even if it's just on the level of a weekend game jam. Finish it, reflect on it, and then come back talking about improving workflows and such. How can you improve something that you don't even know about?

Even I'm missing out on what the editor could do, please don't accuse me of not creating any game or not knowing anything about it. I'm just using a different approach to debugging. I do make small games, its either for personal enjoyment or for my daughter's enjoyment. Its also a way that I could get her interested in programming. All the work that I made was to improve workflow based on a little more than a year of playing around with godot and the library.

[ghost]

What I meant by that is you have to change the path to the library from the gdnlib file if its either a debug or release.

It appears that the latest project-utils already detects the profile and writes the path accordingly: https://github.com/godot-rust/project-utils/blob/603bada40c0b271bf8816e36cac1dcd376259b97/src/generate.rs#L132

Even I'm missing out on what the editor could do, please don't accuse me of not creating any game or not knowing anything about it.

Fine, but I'm not convinced that we should drop project-utils for another tool. Now that a new version is released and the grounds for removing it is no more, I'm hoping that it could be put back into place.