godot-rust / project-utils Goto Github PK

with the release of 0.1.3 (although its working with the template) I found small issues when the gdnlib file was created

• it created another gdnlib file alongside the template's gdnlib file (I suggest not to create another one if one already exist)
• the path to the library is pointing to debug (users will keep changing this if we want a debug or release)
• absolute paths (I suggest using relative paths instead)
• its pointing to the wrong target folder (this is a bug for users not using the template)

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

@karroffel

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())).

Description

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.

Reproduce

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://

Initial investigation

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...