godot-rust / project-utils Goto Github PK
View Code? Open in Web Editor NEWUtilies for working with GDNative projects
License: MIT License
Utilies for working with GDNative projects
License: MIT License
with the release of 0.1.3 (although its working with the template) I found small issues when the gdnlib
file was created
gdnlib
file alongside the template's gdnlib
file (I suggest not to create another one if one already exist)debug
(users will keep changing this if we want a debug or release)for your reference this is the gdnlib
file created by project-utils
[entry]
Android.armeabi-v7a="/home/macalimlim/workspace/godot-rust-template/my-awesome-game/target/x86_64-unknown-linux-gnu/armv7-linux-androideabi/debug/libmy_awesome_game.so"
Android.arm64-v8a="/home/macalimlim/workspace/godot-rust-template/my-awesome-game/target/x86_64-unknown-linux-gnu/aarch64-linux-android/debug/libmy_awesome_game.so"
Android.x86="/home/macalimlim/workspace/godot-rust-template/my-awesome-game/target/x86_64-unknown-linux-gnu/i686-linux-android/debug/libmy_awesome_game.so"
Android.x86_64="/home/macalimlim/workspace/godot-rust-template/my-awesome-game/target/x86_64-unknown-linux-gnu/x86_64-linux-android/debug/libmy_awesome_game.so"
X11.64="/home/macalimlim/workspace/godot-rust-template/my-awesome-game/target/x86_64-unknown-linux-gnu/debug/libmy_awesome_game.so"
OSX.64="/home/macalimlim/workspace/godot-rust-template/my-awesome-game/target/x86_64-unknown-linux-gnu/debug/libmy_awesome_game.dylib"
Windows.64="/home/macalimlim/workspace/godot-rust-template/my-awesome-game/target/x86_64-unknown-linux-gnu/debug/my_awesome_game.dll"
[dependencies]
Android.armeabi-v7a=[ ]
Android.arm64-v8a=[ ]
Android.x86=[ ]
Android.x86_64=[ ]
X11.64=[ ]
OSX.64=[ ]
[general]
singleton=false
load_once=true
symbol_prefix="godot_"
reloadable=true
I'm not entirely sure if there is a universally sane way to handle this, but I'm seeing a lot of spurious gdns
files being made during development when I try various type names, since I've configured rust-analyzer to check the project on save. The easiest way, I believe, would be adding an option to automatically delete orphaned gdns
files in the output directory. This would of course destroy any custom changes made on the files, so it's not ideal, but it should suffice for simple use cases.
Another approach might be somehow detecting whether the crate is actually being built with a cargo build
command, if possible, and skip generation if not. An option might also be added for this, although I doubt it'll be very useful to opt out of this.
Hi!
Really great idea with this cargo :) Only have a small problem.
Have only tested on Windows 10 and it seams that the path generation is wrong.
Probably has to do with the code trying to adapt to the platform by using \
for directories when it should be using /
.
For example the *.gdnlib looks like this:
X11.64="res://libs\game\target\debug\libGame.so"
OSX.64="res://libs\game\target\debug\libGame.dylib"
Windows.64="res://libs\game\target\debug\Game.dll"
And the *.gdns looks like this:
[ext_resource path="\\?\C:\Users\user\Documents\Projects\Game\native\Game.gdnlib" type="GDNativeLibrary" id=1]
Since there isn't a way to register static methods yet, having gdns
files and global names for types with #[no_constructor]
isn't exactly useful. This is only relevant to the master
branch of gdnative
for now.
Use case:
I use cargo build
during development and then cargo build --release
to prepare for release. If I forget to delete the scripts before switching to release mode, they still refer to the debug build outputs. I'd be less likely to make that mistake if the tool always regenerated the output files. Essentially, I'd like the build script to be the authoritative source of the gdnlib and gdns files, overwriting anything that's already there.
This would overwrite handwritten changes to the files. I'm okay with this (especially as an opt-in option), but if we want to avoid that an alternative approach would be to make the gdnlib refer to outputs in a third directory that doesn't include "debug" or "release" in the path, then modify build scripts to output to that directory. That way, we only need to generate the gdnlib once, and simply swap out the libraries in the third directory as needed.
Looking at the docs, I don't see a way to set the target dir without a build mode, so if the latter route is chosen that's the option that would be needed.
Neither String
or &String
actually implement AsRef<String>
. To work around that using standard types I had to wrap the string with a smart pointer: .lib_name(Box::new("mylibrary".to_string()))
.
When generating the .gdnlib file on Windows this causes the paths to be generated using UNC paths see https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN
So e.g. .gdnlib file will look something like:
[entry]
X11.64="\\?\C:/myproject/target/debug/mylib.so"
OSX.64="\\?\C:/myproject/target/debug/mylib.dylib"
Windows.64="\\?\C:/myproject/target/debug/mylib.dll"
The effect this has is godot will fail to load the library.
Any simple build script will work and just generate on Windows where it's not seperate target dir to the godot directory i.e. not needing res://
I did some initial investigation and it's related to how the code is using fs::canonicalize which has different behaviour on Windows
See rust-lang/rust#42869
and https://doc.rust-lang.org/std/fs/fn.canonicalize.html
Exporting the error would be helpful when ignoring parse errors in build.rs, otherwise the cargo check
result will not show what the parse errors are.
let classes_res = scan_crate(&crate_src);
if let Err(ScanError::Parse(_)) = classes_res {
// ignore parse errors
return Ok(());
}
rerun_if_changed()
is emitting for the generated code and not the source code.
https://github.com/godot-rust/project-utils/blob/master/src/generate.rs#L190
I believe it should only be emitting for the source files.
While trying out the template, I noticed that the project-utils is overwriting the existing .gdns
file and creating another .gdnlib
file. It should not overwrite an existing .gdns
file and create another .gdnlib
file if another one is already existing.
Essentially if one or both files already exist, don't do anything on that particular file...
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.