GDNative Rust unable to compile just cause the folder was moved

https://github.com/GodotNativeTools/godot-rust

I am using GDNative Rust to do Godot game development.

I was able to compile the code when I cloned the repository.

But after moving the folder that contains the code, how come I cannot compile anymore and I get an error message.

E:\Godot example\godot-rust1\examples\spinning_cube\Assets\Code\spinning_cube>cargo build
←[0m←[0m←[1m←[31merror:←[0m failed to read `E:\Godot example\godot-rust1\examples\spinning_cube\Cargo.toml`

Caused by:
  The system cannot find the file specified. (os error 2)

Have you checked the folders content if Cargo.toml has been copied properly or is in fact missing as the error suggests?

I can only think of 2 reasons for this error, either you made a mistake when copying and the file is missing or you made a mistake when copying and permissions are forbidding the file to be visible at all for cargo.

It has been copied properly.

No I actually copied and it copied fine, do you want a copy of the project mate?

I'm not able to check on windows, and how cargo behaves there… But when it worked before, did your Path contain spaces as well? If not, can you try again at another place that does not contain spaces?

I already tried same problem.

Then I'm sorry, I can not help you any further.

I do not think I understand. Is E:\Godot example\godot-rust1\examples\spinning_cube\ a project and E:\Godot example\godot-rust1\examples\spinning_cube\Assets\Code\spinning_cube a subproject?

Also, do you have some absolute path in some Cargo.toml?

Not a sub project, I moved the contents to a new location.

What do you mean by that mate?

You are not very clear. Is E:\Godot example\godot-rust1\examples\spinning_cube\ the current path of the prject? Can you invoke cargo from there?

I as wondering if you have something in you Cargo.toml as

[dependencies]
thing = { path="/absolute/path/to/thing" }

Yes it was as well as it is the Godot project's folder as well, the cargo.toml file was there as well as the src folder. I moved both the cargo.toml file and the src folder to E:\Godot example\godot-rust1\examples\spinning_cube\Assets\Code\spinning_cube

[dependencies]
gdnative = { path = "../_Other stuff/gdnative", features = ["graphics"] }

I have this.

Could there be some auxiliar file remembering the old path? Perhaps running cargo clean?

I honestly never heard of this one before.

Do I run this inside E:\Godot example\godot-rust1\examples\spinning_cube\Assets\Code\spinning_cube or in this directory E:\Godot example\godot-rust1\examples\spinning_cube?

E:\Godot example\godot-rust1\examples\spinning_cube\Assets\Code>cargo clean
←[0m←[0m←[1m←[31merror:←[0m failed to read `E:\Godot example\godot-rust1\examples\spinning_cube\Cargo.toml`

Caused by:
  The system cannot find the file specified. (os error 2)

I ran the command same problem :confused:

The only way I have seen to recreate this error is to give Cargo.toml incorrect permissions. If the file is missing it says to me

error: could not find `Cargo.toml` in `/tmp/cargo-test/movetest/assets` or any parent directory

With bad permissions it says

error: failed to read `/tmp/cargo-test/movetest/assets/code/movetest/Cargo.toml`

So it seems the file is in place, but it cannot be read for whatever reason. I can think of some actions:

  • To check again the permissions.
  • Check that it is indeed a file and not some link or something strange. (Although it should work being a software link).
  • If still failing then move the Cargo.toml outside and make a new file with the same content. Remember the 'C' in Cargo.toml is uppercase. Windows usually ignores case, but it could be relevant.

You need to consider that you are using linux or macos, which communicates a missing file differently than a windows does.

Or do you see the extra line saying "caused by: … (os error 2)"?

In linux I see without permissions

Caused by:
  Permission denied (os error 13)

Certainly I expect many differences with windows. I have not any windows machine available, so I do my best. However, the fact that cargo considers the two situations (missing file or unreadable) to be different, should be true regardless of the platform.