the current build seems broken

[SeleDreams]

I've been trying cargo-3ds after building it and no matter the arguments I give to it it simply will act as if i didn't provide arguments whether I type build or run etc

[Meziu]

Did you put it in the .cargo/bin directory and invoked it with cargo 3ds run? I guess your behaviour may be cause by not being invoked by cargo itself, but just by running it as a normal binary.

[Meziu]

This “manual” installation wouldn’t be needed if we released it via crates.io, but we don’t do that yet. Also, it has been rewritten so we’ll have to wait a bit before making any changes.

[ian-h-chamberlain]

After #21 is ready / merged, it might be nice to support running the tool either as cargo-3ds or cargo 3ds, which would probably involve a bit of inspection of argv[0] and argv[1]... Not sure how Clap might handle that though...

[SeleDreams]

ah it's not su[[psed to be invoked on its own ? the page about 3ds wasn't very clear about it https://doc.rust-lang.org/nightly/rustc/platform-support/armv6k-nintendo-3ds.html and the readme didn't specify it

[Meziu]

I know, and you are right about that. It’s just standard for tools with the cargo- prefix to be cargo subcommands.

[Meziu]

After #21 is ready / merged, it might be nice to support running the tool either as cargo-3ds or cargo 3ds, which would probably involve a bit of inspection of argv[0] and argv[1]... Not sure how Clap might handle that though...

I honestly see no point in doing that 😅. It’s a cargo subcommand meant to extend cargo’s functionality, not a replacement.

[SeleDreams]

I placed it in .cargo/bin and used "cargo 3ds build" but it says that it doesn't find the 3ds command

[ian-h-chamberlain]

Is .cargo/bin in your $PATH? According to Cargo docs that's where it will look when invoking subcommands.

It’s a cargo subcommand meant to extend cargo’s functionality, not a replacement.

That's true, but if it's easy enough to say something like if arg == "3ds" { continue } then why not support both? There's no reason it shouldn't be able to work, right?

In either case, we should probably double check the README and/or platform support docs to make sure it's clear to users so issues like this don't pop up again.

[Meziu]

Is .cargo/bin in your $PATH? According to Cargo docs that's where it will look when invoking subcommands.

Doesn't the rustup installation take care of that? How could they run all other commands otherwise?

[SeleDreams]

seems like from the docs cargo install --git https://github.com/rust3ds/cargo-3ds.git was the way to go about it

[SeleDreams]

unrelated but btw when I set things in the toml to define the path of the linker and co i keep getting this kind of annoying error error: expected a table, but found a string for target.armv6k-nintendo-3ds.ranlib in /home/seledreams/rust3ds-template/.cargo/config.toml

[Meziu]

unrelated but btw when I set things in the toml to define the path of the linker and co i keep getting this kind of annoying error error: expected a table, but found a string for target.armv6k-nintendo-3ds.ranlib in /home/seledreams/rust3ds-template/.cargo/config.toml

Define the path of the linker? That is all specified in the target-specification (unless you have a custom build, but at that point you could just change the DEVKITARM env var).

Still, I have no idea what ranlib does in the Cargo.toml, but just know that for specific target configurations it should be: [target.'cfg(target_os = "horizon")'.ranlib]

[Meziu]

Wait @SeleDreams, are you trying to run https://github.com/rust3ds/rust3ds-template ?? If so, please stop immediately.

To test the toolchain you can just clone my https://github.com/Meziu/ctru-rs repository and run the examples with cargo 3ds run --example _example-name_

Edit: Sadly we haven't been able to archive the old repositories because of our lack of admin permissions in this github organization. This also goes for my fork of ctru-rs as I can't pass ownership when a repo with the same name exists. I'm sorry for the misguidance, but we are still sorting things out on this regard.

[SeleDreams]

Wait @SeleDreams, are you trying to run https://github.com/rust3ds/rust3ds-template ?? If so, please stop immediately.

To test the toolchain you can just clone my https://github.com/Meziu/ctru-rs repository and run the examples with cargo 3ds run --example _example-name_

Edit: Sadly we haven't been able to archive the old repositories because of our lack of admin permissions in this github organization. This also goes for my fork of ctru-rs as I can't pass ownership when a repo with the same name exists. I'm sorry for the misguidance, but we are still sorting things out on this regard.

I see, it seems like i was actually going at things the wrong way though i still end up when creating a new project and trying to build it with this issue

seledreams@seledreams-Predator-PH315-51:~/ctrtest$ cargo 3ds build Running Cargo No pre-built std found, using build-std Compiling ctrtest v0.1.0 (/home/seledreams/ctrtest) error: linker arm-none-eabi-gcc not found | = note: No such file or directory (os error 2)

error: could not compile ctrtest due to previous error

which means cargo 3ds is ignoring my env paths for devkitpro which are set

[SeleDreams]

I tested with examples, same error

all my env variables are set

seledreams@seledreams-Predator-PH315-51:~/ctru-rs$ echo $DEVKITPRO
/opt/devkitpro
seledreams@seledreams-Predator-PH315-51:~/ctru-rs$ echo $DEVKITARM
/opt/devkitpro/devkitARM
seledreams@seledreams-Predator-PH315-51:~/ctru-rs$ echo $CTRULIB
/opt/devkitpro/libctru

[Meziu]

Do you have the DEVKITPRO binaries (including arm-none-eabi-gcc) in your PATH? Try running the linker by itself and see if the command exists.

[SeleDreams]

Do you have the DEVKITPRO binaries (including arm-none-eabi-gcc) in your PATH? Try running the linker by itself and see if the command exists.

they aren't in my path but i don't think they even should be in my path, if devkitpro installs its own it's to avoid conflicting with the system wide ones, i feel like cargo-3ds should automatically figure out its location using the DEVKITPRO env variable in order to find where it is automatically

[Meziu]

It isn’t cargo-3ds at fault. This process is handled by rustc. I don’t remember how my installation went back then, but I don’t think having a different arm-none-eabi-gcc linker would be a problem, since it’s llvm doing the compiling.

[SteveCookTU]

After #21 is ready / merged, it might be nice to support running the tool either as cargo-3ds or cargo 3ds, which would probably involve a bit of inspection of argv[0] and argv[1]... Not sure how Clap might handle that though...

Wanted to confirm this. Running it standalone will be a little awkward still as it will need to be ran as cargo-3ds 3ds as if you are running cargo 3ds. This is because of how cargo works with subcommand extensions. Cargo looks for an executable with the name of cargo-{subcommand} but still passes the argument (which I'm not sure the case for since that would mean another executable would be needed for other subcommands?)

[ian-h-chamberlain]

It isn’t cargo-3ds at fault. This process is handled by rustc. I don’t remember how my installation went back then, but I don’t think having a different arm-none-eabi-gcc linker would be a problem, since it’s llvm doing the compiling.

I suppose in the invocations of cargo we could extend PATH to include $DEVKITARM/bin, just as a failsafe for this case. I have set up my PATH to include those binaries by default but it might be less friction to make the user only have to set DEVKITPRO and DEVKITARM in their environment, since we expect those binaries to be under $DEVKITARM/bin anyway.

Actually, in a similar vein we might want to look for 3dslink, 3dsxtool etc. in there as well instead of relying on $PATH.

[Meziu]

I suppose in the invocations of cargo we could extend PATH to include $DEVKITARM/bin, just as a failsafe for this case. I have set up my PATH to include those binaries by default but it might be less friction to make the user only have to set DEVKITPRO and DEVKITARM in their environment, since we expect those binaries to be under $DEVKITARM/bin anyway.

Actually, in a similar vein we might want to look for 3dslink, 3dsxtool etc. in there as well instead of relying on $PATH.

All good ideas, but now a thought crosses my mind: is it possible to not use arm-none-eabi-gcc and just use lld? Back when I wrote the target-spec I ignored the possibility because of the need for the link script and the other flags I didn’t know how to set in lld. If we were able to port all of that over (like the people behind psp-rust did), we would greatly improve the toolchain.

[ian-h-chamberlain]

All good ideas, but now a thought crosses my mind: is it possible to not use arm-none-eabi-gcc and just use lld? Back when I wrote the target-spec I ignored the possibility because of the need for the link script and the other flags I didn’t know how to set in lld. If we were able to port all of that over (like the people behind psp-rust did), we would greatly improve the toolchain.

It might be possible, but there's definitely custom stuff they do with the linker scripts (see e.g. $DEVKITARM/arm-none-eabi/lib/3dsx.ld). It might be worth looking into, but from what I understand the devkitPro maintainers have little interest in helping people trying to use other toolchains or languages, so it would probably be a lot of trial and error.