the current build seems broken about cargo-3ds HOT 22 CLOSED

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

from cargo-3ds.

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.

from cargo-3ds.

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.

from cargo-3ds.

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

from cargo-3ds.

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

from cargo-3ds.

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

from cargo-3ds.

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.

from cargo-3ds.

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

from cargo-3ds.

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.

from cargo-3ds.

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?

from cargo-3ds.

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

from cargo-3ds.

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]

from cargo-3ds.

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.

from cargo-3ds.

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

from cargo-3ds.

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

from cargo-3ds.

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.

from cargo-3ds.

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

from cargo-3ds.

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.

from cargo-3ds.

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?)

from cargo-3ds.

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.

from cargo-3ds.

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.

from cargo-3ds.

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.

from cargo-3ds.