rust3ds / cargo-3ds Goto Github PK

View Code? Open in Web Editor NEW

54.0 7.0 9.0 198 KB

Cargo command to work with Nintendo 3DS project binaries.

License: Apache License 2.0

Rust 100.00%

rust homebrew nintendo-3ds cargo-subcommand

cargo-3ds's People

Contributors

Stargazers

Watchers

Forkers

ian-h-chamberlain mateocabanal stevecooktu seledreams pmarkive spazzylemons maccraft123 fekie iamcco

cargo-3ds's Issues

Add `test --doc` support

Doc tests are... well, kind of an unfinished feature it seems like. A few gaps we will most likely run into:
- We need an unstable flag to even compile doctests: rust-lang/cargo#7040
- --no-run is not supported by rustdoc / cargo:
```
 $ cargo 3ds test --doc -Zdoctest-xcompile
 No pre-build std found, using build-std
 error: Can't skip running doc tests with --no-run
```
  We can probably work around this in cargo-3ds somehow since this still seems to work: cargo test -vvv -Zdoctest-xcompile -Zbuild-std --target armv6k-nintendo-3ds --doc.
  See also rust-lang/rust#87022

Originally posted by @ian-h-chamberlain in rust3ds/ctru-rs#106 (comment)

Allow using a prebuilt std if one is found

In the course of development, I have ended up building a toolchain (roughly following the directions laid out in the armv6k-nintendo-3ds platform doc) and have a working std in my sysroot. It would be nice if cargo-3ds could detect this, and avoid passing -Zbuild-std to rebuild the standard library every time, for faster iteration when changing compile flags etc. It's still useful to use cargo-3ds in this case, to build the .3dsx and work nicely with cargo 3ds run, etc.

I think we should just be able to run rustc --print sysroot and look for the existence of a lib/rustlib/armv6k-nintendo-3ds directory under the sysroot, but perhaps there is even a better way we could auto-detect this as well.

Code mess

The code is a mess, between reading the arguments and weird panics (especially without having an -help option), it is a mess to use for anybody but me. It should be rewritten with the use of some fancy crate for CLI applications, but for now i just need it to work.

[Help/Feature Request]: Support for winit and rustix

I'm trying to build my game engine to work on a 3DS and noticed that it fails to compile because of an indirect dependency on rustix. I sent a report to both rust-windowing/winit#3522 and bytecodealliance/rustix#1023

I've already successfully tested against a project that uses ctru, so the environment itself is setup correctly. It just doesn't work for winit right now

compile-log.txt

Make tool parameters accessible

It has been a month or so that 3dslink hasn't been able to find my 3DS on the network. I've ignored the issue for a while, but now that tests are in too, it's really annoying (I have to run 3dslink separately with the address parameter). I can't understand if it's an OS problem, since it started when I switched to OpenSUSE, or a problem with my network, but I believe we should make those arguments available one way or another, especially server, which seems useful.

Edit: I didn’t mention something important. I actually believe these parameters are outside cargo-3ds‘ CLI scope. Maybe we should implement these integrations through .cargo/config.toml or other external sources.

Missing values in `libc` in latest nightly

Whenever I try to compile rust3ds-template project using cargo 3ds build, I get the following error:

error[E0425]: cannot find value `UTIME_OMIT` in crate `libc`
   --> /home/spencer/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/unix/fs.rs:552:63
    |
552 |         let omit = libc::timespec { tv_sec: 0, tv_nsec: libc::UTIME_OMIT as _ };
    |                                                               ^^^^^^^^^^ not found in `libc`

error[E0425]: cannot find function `futimens` in crate `libc`
    --> /home/spencer/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/unix/fs.rs:1118:36
     |
1118 |                 cvt(unsafe { libc::futimens(self.as_raw_fd(), times.0.as_ptr()) })?;
     |                                    ^^^^^^^^ help: a function with a similar name exists: `utimes`
     |
    ::: /home/spencer/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.126/src/unix/mod.rs:1159:5
     |
1159 |     pub fn utimes(filename: *const ::c_char, times: *const ::timeval) -> ::c_int;
     |     ---------------------------------------------------------------------------- similarly named function `utimes` defined here

For more information about this error, try `rustc --explain E0425`.
error: could not compile `std` due to 2 previous errors

I have tried running cargo clean, cargo update, and I have even deleted the entire folder and started over.

My version of nightly is:

nightly-x86_64-unknown-linux-gnu (default)
rustc 1.64.0-nightly (affe0d3a0 2022-08-05)

Not building when in release mode on Windows

I just set everything up and it builds normally with cargo 3ds build. I am using all the devkitPro stuff and LLVM on Windows. However, running cargo 3ds build --release gives this error. Not sure if this is a rustflags thing and an issue with cargo-3ds.

Compiling ctru-sys v22.2.0+2.2.2-1 (https://github.com/rust3ds/ctru-rs#4d718c41) The following warnings were emitted during compilation:

warning: [email protected]+2.2.2-1: failed to check libctru version: cannot find binary path
warning: [email protected]+2.2.2-1: arm-none-eabi-gcc: error: unrecognized command-line option '-m64'

error: failed to run custom build command for ctru-sys v22.2.0+2.2.2-1 (https://github.com/rust3ds/ctru-rs#4d718c41)

Caused by:
process didn't exit successfully: C:\Users\fek\k-git\first-3ds-rust-project\target\release\build\ctru-sys-d91d501a2927c647\build-script-build (exit code: 1)
--- stdout
cargo:rerun-if-changed=build.rs
cargo:rerun-if-env-changed=DEVKITPRO
cargo:rustc-link-search=native=C:\devkitPro/libctru/lib
cargo:rustc-link-lib=static=ctru
cargo:warning=failed to check libctru version: cannot find binary path
TARGET = Some("x86_64-pc-windows-msvc")
OPT_LEVEL = Some("3")
cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("false")
CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
HOST = Some("x86_64-pc-windows-msvc")
cargo:rerun-if-env-changed=CFLAGS_x86_64-pc-windows-msvc
CFLAGS_x86_64-pc-windows-msvc = None
cargo:rerun-if-env-changed=CFLAGS_x86_64_pc_windows_msvc
CFLAGS_x86_64_pc_windows_msvc = None
cargo:rerun-if-env-changed=HOST_CFLAGS
HOST_CFLAGS = None
cargo:rerun-if-env-changed=CFLAGS
CFLAGS = None
running: "C:\devkitPro\devkitARM\bin/arm-none-eabi-gcc" "-O3" "-ffunction-sections" "-fdata-sections" "-m64" "-I" "C:\devkitPro\libctru\include" "-Wall" "-Wextra" "-march=armv6k" "-mtune=mpcore" "-mfloat-abi=hard" "-mfpu=vfp" "-mtp=soft" "-Wno-deprecated-declarations" "-o" "C:\Users\fek\k-git\first-3ds-rust-project\target\release\build\ctru-sys-d4aabc400d3d9b70\out\884983ec69cfa99d-libctru_statics_wrapper.o" "-c" "C:\Users\fek\k-git\first-3ds-rust-project\target\release\build\ctru-sys-d4aabc400d3d9b70\out\libctru_statics_wrapper.c"
cargo:warning=arm-none-eabi-gcc: error: unrecognized command-line option '-m64'

exit code: 1

--- stderr

error occurred: Command "C:\devkitPro\devkitARM\bin/arm-none-eabi-gcc" "-O3" "-ffunction-sections" "-fdata-sections" "-m64" "-I" "C:\devkitPro\libctru\include" "-Wall" "-Wextra" "-march=armv6k" "-mtune=mpcore" "-mfloat-abi=hard" "-mfpu=vfp" "-mtp=soft" "-Wno-deprecated-declarations" "-o" "C:\Users\fek\k-git\first-3ds-rust-project\target\release\build\ctru-sys-d4aabc400d3d9b70\out\884983ec69cfa99d-libctru_statics_wrapper.o" "-c" "C:\Users\fek\k-git\first-3ds-rust-project\target\release\build\ctru-sys-d4aabc400d3d9b70\out\libctru_statics_wrapper.c" with args "arm-none-eabi-gcc" did not execute successfully (status code exit code: 1).

Panic during cargo build (build-std) when using nightly (non-dev) Rust

I'm having some trouble using this in combination with the rust-horizon repo.

I have the rustc fork at /home/mark/media/CLionProjects/rust-horizon, with branch horizon-std. It's only modified in library/std/Cargo.toml to use your forked libc copy via git dependency (instead of path dependency):

libc = { git = "https://github.com/Meziu/libc", rev = "8409849a11381bd4861faede6b7943da30d4b30c", default-features = false, features = ['rustc-dep-of-std'] }

I created a new project in /home/mark/media/CLionProjects/rust-3ds-hello-world with the default binary project template.

Based on the latest commit in the rustc fork, I am using nightly-2021-12-16 via rust-toolchain file override (rustup) in the hello world project.

Running cargo 3ds build gives lots of errors because it uses the nightly std shipped via rustup, which doesn't have the 3ds changes. I added an env variable override for __CARGO_TESTS_ONLY_SRC_ROOT to tell build-std to use the forked std. However now this results in a panic:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/tools/cargo/src/cargo/core/workspace.rs:1519:39
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I tried debugging this in cargo's codebase, but I'm not able to find a plausible spot in the code that matches up with the panic location (workspace.rs:1519:39) and the backtrace. Maybe this error has been seen before?

Full log with debug printing and backtrace

$ __CARGO_TESTS_ONLY_SRC_ROOT="$(pwd)/../rust-horizon" RUST_BACKTRACE=full CARGO_LOG=debug cargo 3ds build
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_members - only me as a member
[2021-12-22T22:01:47Z DEBUG cargo::util::rustc] adding rustup info to rustc fingerprint
[2021-12-22T22:01:47Z DEBUG cargo::util::rustc] reusing existing rustc info cache
[2021-12-22T22:01:47Z DEBUG cargo::util::rustc] rustc info cache hit
[2021-12-22T22:01:47Z DEBUG cargo::util::rustc] rustc info cache hit
[2021-12-22T22:01:47Z DEBUG cargo::util::rustc] rustc info cache hit
[2021-12-22T22:01:47Z DEBUG cargo::util::rustc] rustc info cache hit
[2021-12-22T22:01:47Z DEBUG cargo::util::rustc] rustc info cache hit
[2021-12-22T22:01:47Z DEBUG cargo::util::rustc] rustc info cache hit
[2021-12-22T22:01:47Z DEBUG cargo::util::rustc] rustc info cache hit
[2021-12-22T22:01:47Z DEBUG cargo::util::config::target] Got all targets {}
[2021-12-22T22:01:47Z DEBUG cargo::ops::resolve] avoid_patch_ids={}
[2021-12-22T22:01:47Z DEBUG cargo::ops::resolve] attempting to prefer rust-3ds-hello-world v0.1.0 (/home/mark/media/CLionProjects/rust-3ds-hello-world)
[2021-12-22T22:01:47Z DEBUG cargo::core::registry] load/missing  /home/mark/media/CLionProjects/rust-3ds-hello-world
[2021-12-22T22:01:47Z DEBUG cargo::core::registry] loading source /home/mark/media/CLionProjects/rust-3ds-hello-world
[2021-12-22T22:01:47Z DEBUG cargo::sources::config] loading: /home/mark/media/CLionProjects/rust-3ds-hello-world
[2021-12-22T22:01:47Z DEBUG cargo::core::resolver] initial activation: rust-3ds-hello-world v0.1.0 (/home/mark/media/CLionProjects/rust-3ds-hello-world)
[2021-12-22T22:01:47Z DEBUG cargo::ops::resolve] avoid_patch_ids={}
[2021-12-22T22:01:47Z DEBUG cargo::ops::resolve] attempting to prefer rust-3ds-hello-world v0.1.0 (/home/mark/media/CLionProjects/rust-3ds-hello-world)
[2021-12-22T22:01:47Z DEBUG cargo::core::registry] load/locked   /home/mark/media/CLionProjects/rust-3ds-hello-world
[2021-12-22T22:01:47Z DEBUG cargo::core::resolver] initial activation: rust-3ds-hello-world v0.1.0 (/home/mark/media/CLionProjects/rust-3ds-hello-world)
[2021-12-22T22:01:47Z DEBUG cargo::core::package] rust-3ds-hello-world v0.1.0 (/home/mark/media/CLionProjects/rust-3ds-hello-world) doesn't need a download
[2021-12-22T22:01:47Z DEBUG cargo::core::resolver::features] features={
        (
            PackageId {
                name: "rust-3ds-hello-world",
                version: "0.1.0",
                source: "/home/mark/media/CLionProjects/rust-3ds-hello-world",
            },
            false,
        ): {},
    }
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_members - /home/mark/media/CLionProjects/rust-horizon/library/std/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/library/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found a root checking exclusion
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found!
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/library/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found a root checking exclusion
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found!
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/library/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found a root checking exclusion
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found!
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/library/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found a root checking exclusion
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found!
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/library/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found a root checking exclusion
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found!
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/library/stdarch/crates/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/library/stdarch/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found a root checking exclusion
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found!
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/library/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found a root checking exclusion
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found!
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_members - /home/mark/media/CLionProjects/rust-horizon/library/core/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_members - /home/mark/media/CLionProjects/rust-horizon/library/alloc/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_members - /home/mark/media/CLionProjects/rust-horizon/library/test/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/library/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found a root checking exclusion
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found!
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/library/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found a root checking exclusion
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found!
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/library/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - trying /home/mark/media/CLionProjects/rust-horizon/Cargo.toml
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found a root checking exclusion
[2021-12-22T22:01:47Z DEBUG cargo::core::workspace] find_root - found!
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/tools/cargo/src/cargo/core/workspace.rs:1519:39
stack backtrace:
   0:     0x55c7e54e94dc - std::backtrace_rs::backtrace::libunwind::trace::he79a6b2087577c89
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x55c7e54e94dc - std::backtrace_rs::backtrace::trace_unsynchronized::h9277c4233029dddb
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x55c7e54e94dc - std::sys_common::backtrace::_print_fmt::hbb2b612ef9b02ca8
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x55c7e54e94dc - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hc8c6e5fc9f07659b
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x55c7e5512acc - core::fmt::write::h72801a82c94e6ff1
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/core/src/fmt/mod.rs:1149:17
   5:     0x55c7e54e0a45 - std::io::Write::write_fmt::h49956859070326a8
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/io/mod.rs:1660:15
   6:     0x55c7e54eb9a0 - std::sys_common::backtrace::_print::h7c949d00e447ca1b
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x55c7e54eb9a0 - std::sys_common::backtrace::print::hac5d7b208ff86b2e
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x55c7e54eb9a0 - std::panicking::default_hook::{{closure}}::h2d5b8c951b73433e
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:211:50
   9:     0x55c7e54eb54b - std::panicking::default_hook::hc1d5a882e94ba293
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:228:9
  10:     0x55c7e54ec054 - std::panicking::rust_panic_with_hook::hc9dd570d8cf7aba9
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:606:17
  11:     0x55c7e54ebb02 - std::panicking::begin_panic_handler::{{closure}}::hf5dee398c82a5cad
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:500:13
  12:     0x55c7e54e9984 - std::sys_common::backtrace::__rust_end_short_backtrace::hc6e01318a754dc4c
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/sys_common/backtrace.rs:139:18
  13:     0x55c7e54eba99 - rust_begin_unwind
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:498:5
  14:     0x55c7e4b74aa1 - core::panicking::panic_fmt::h7b8580d81fcbbacd
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/core/src/panicking.rs:107:14
  15:     0x55c7e4b749ed - core::panicking::panic::h50b51d19800453c0
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/core/src/panicking.rs:48:5
  16:     0x55c7e4f7ead4 - <cargo[bfd075933838aeed]::core::workspace::Workspace>::find_members
  17:     0x55c7e4f79ca3 - <cargo[bfd075933838aeed]::core::workspace::Workspace>::new_virtual
  18:     0x55c7e4f1e297 - cargo[bfd075933838aeed]::core::compiler::standard_lib::resolve_std
  19:     0x55c7e4f34520 - cargo[bfd075933838aeed]::ops::cargo_compile::create_bcx
  20:     0x55c7e4f334ae - cargo[bfd075933838aeed]::ops::cargo_compile::compile_ws
  21:     0x55c7e4f33396 - cargo[bfd075933838aeed]::ops::cargo_compile::compile
  22:     0x55c7e4be2f51 - cargo[54d369ee1b2b1644]::commands::build::exec
  23:     0x55c7e4bac78b - cargo[54d369ee1b2b1644]::cli::execute_subcommand
  24:     0x55c7e4ba9ca1 - cargo[54d369ee1b2b1644]::cli::main
  25:     0x55c7e4b8b225 - cargo[54d369ee1b2b1644]::main
  26:     0x55c7e4bbf053 - std[21670a705af8c7c3]::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>
  27:     0x55c7e4be0789 - std[21670a705af8c7c3]::rt::lang_start::<()>::{closure#0}
  28:     0x55c7e54e8d21 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h6c750193e4920652
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/core/src/ops/function.rs:259:13
  29:     0x55c7e54e8d21 - std::panicking::try::do_call::h02274dfcd9faf3ac
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:406:40
  30:     0x55c7e54e8d21 - std::panicking::try::h6804f9d41b571054
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:370:19
  31:     0x55c7e54e8d21 - std::panic::catch_unwind::hd51f6164bf3938ec
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panic.rs:133:14
  32:     0x55c7e54e8d21 - std::rt::lang_start_internal::{{closure}}::h9b7eb891d44cd5c3
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/rt.rs:128:48
  33:     0x55c7e54e8d21 - std::panicking::try::do_call::haf8d551523bae443
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:406:40
  34:     0x55c7e54e8d21 - std::panicking::try::h7a438e992ba8b1cc
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:370:19
  35:     0x55c7e54e8d21 - std::panic::catch_unwind::h759691315e97e81b
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panic.rs:133:14
  36:     0x55c7e54e8d21 - std::rt::lang_start_internal::hff5980633344c2a1
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/rt.rs:128:20
  37:     0x55c7e4b8d482 - main
  38:     0x7f2260124560 - __libc_start_call_main
  39:     0x7f226012460c - __libc_start_main@@GLIBC_2.34
  40:     0x55c7e4b75281 - <unknown>

Add basic CI / testing

The CI for this repo should in theory be simpler compared to ctru-rs, since it's more of a "normal" Rust project. Some basic stuff we could add:

formatting / linting, should be pretty easy
more "unit" tests? Maybe just for the stuff like get_romfs_path, make_cargo_build_command, etc.
smoke test that builds a super simple ctru hello-world ?

Respect `--no-run` when custom runner is set

in #43 I introduced a little bug which breaks --no-run if you specify a runner. It should be an easy fix, just creating the issue to remind myself of it

Is it necessary to modify `RUSTFLAGS` in `cargo-3ds`?

libctru is included twice

I think there's something to this stemming from the fact that cargo-3ds adds RUSTFLAGS for linking libctru, and ctru-rs also does in its build script. I'll open an issue to investigate on cargo-3ds

Originally posted by @ian-h-chamberlain in rust3ds/ctru-rs#46 (comment)

More context: RUSTFLAGS get updated here in cargo-3ds, but there is already a build script for ctru-sys which specifies that it links against libctru (as well as the links field in Cargo.toml, although that seems to be more about convention and less functional).

If rustc will automatically link to the right libraries via the build script, is it necessary to provide via RUSTFLAGS the same linker args? I have noticed when linking fails there seem to be several duplicated references to ctru, e.g. (edited for clarity):

error: linking with `arm-none-eabi-gcc` failed: exit status: 1
  |
  = note: "arm-none-eabi-gcc"
"-specs=3dsx.specs"
"-mtune=mpcore"
"-mfloat-abi=hard"
"-mtp=soft"
... lots of object files ...
"-Wl,--as-needed"
"-L"
"/Users/ianchamberlain/Documents/Development/3ds/ctru-rs/target/armv6k-nintendo-3ds/debug/deps"
"-L"
"/Users/ianchamberlain/Documents/Development/3ds/ctru-rs/target/debug/deps"
"-L"
"/opt/devkitpro/libctru/lib"
"-L"
"/opt/devkitpro/libctru/lib"
"-L"
"/Users/ianchamberlain/.rustup/toolchains/horizon/lib/rustlib/armv6k-nintendo-3ds/lib"
"-lctru"
"-Wl,-Bstatic"
... rlib files ...  
"-Wl,-Bdynamic"
"-lctru"
"-lctru"
"-lc"
"-lm"
"-lctru"
"-lc"
"-lm"
"-lctru"
"-Wl,--eh-frame-hdr"
"-Wl,-znoexecstack"
"-L"
"/Users/ianchamberlain/.rustup/toolchains/horizon/lib/rustlib/armv6k-nintendo-3ds/lib"
"-o"
"/Users/ianchamberlain/Documents/Development/3ds/ctru-rs/target/armv6k-nintendo-3ds/debug/deps/common-238f93ba962b2c97.elf"
"-Wl,--gc-sections"
"-no-pie"

I think it's probably harmless to have -lctru multiple times like that, but I wonder if we are doing extra work unnecessarily for the linker invocation. If so, the fix would probably be to simply remove the RUSTFLAGS modification from cargo-3ds.

the current build seems broken

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

More comprehensive CI coverage

Right now, the CI only does two basic functionality checks of the tool:

      - name: Create new project
        run: cargo 3ds new app --bin

      - name: Build project
        working-directory: ./app
        run: cargo 3ds build --release

We could add more unit tests, integration tests, etc., but it would probably be a good idea to just run through some of the different uses cases that are supported. Offhand these are the ones that I can think of:

cargo 3ds build maybe with a couple of other argument combinations
cargo 3ds test (with and without --no-run)
- --lib
- --doc
- --test ?
- --example? is that supported?
cargo 3ds run
- --bin
- --example
cargo 3ds doc, I guess? Maybe also other passthrough commands like check, clippy, etc.

We'd probably need to use custom runners or a custom 3dslink wrapper script to really test everything properly.

Also would be nice to test on different platforms, but the lack of devkitPro toolchain images will probably make it hard to test the whole process. We should bbe able to at least test cargo 3ds new and maybe cargo 3ds check?

devkitPRO depedencing isn't great

Having dependencies on third party tools that must be in range of the environment commands isn't a good idea. Also, smdhtool isn't designed very well, and misses some features. Rewriting the tools in Rust, in the form of libraries for the main binary, would be the best approach, but it will take quite some time.

Issue Building Project using cargo-3ds

I've started building a hello world project which uses this tool and ctru-rs to run. When running cargo 3ds build I'm getting error: could not find native static library ctrud, perhaps an -L flag is missing?. Full Log Below:

C:/Users/hydos/.cargo/bin/cargo.exe 3ds build
No pre-build std found, using build-std
   Compiling ctru-sys v0.4.1 (https://github.com/rust3ds/ctru-rs.git#4e221667)
   Compiling linker-fix-3ds v0.1.0 (https://github.com/rust3ds/rust-linker-fix-3ds.git#ed1ec9c7)
   Compiling pthread-3ds v0.1.0 (https://github.com/rust3ds/pthread-3ds.git#c132988a)
   Compiling ctru-rs v0.7.1 (https://github.com/rust3ds/ctru-rs.git#4e221667)
error: could not find native static library `ctrud`, perhaps an -L flag is missing?

error: could not compile `ctru-sys` due to previous error
warning: build failed, waiting for other jobs to finish...

Set environment variables for CC and CXX to allow building C/C++ wrapper crates

I was trying to build imgui-rs, to make a library that provides an interface between imgui and the 3DS system, to allow for easy creation of GUI applications, and i ran into a problem. (what little code i wrote is here)

imgui-rs, like many crates that wrap a C or C++ library, uses the cc crate to build the C dependency. The problem is that when the C dependency is being built, it targets the host system's architecture, because the CC, CXX and other standard environment variables aren't being overridden by cargo-3ds.

By manually setting the following environment variables, i was able to build the imgui-rs crate, the zstd crate and other C wrappers without any issues, linking or otherwise.

CRATE_CC_NO_DEFAULTS=1 as documented here, to override the default build configuration (that would build for the host target).
CXX=/opt/devkitpro/devkitARM/bin/arm-none-eabi-g++ (the path has to not be hardcoded, of course)
CC=/opt/devkitpro/devkitARM/bin/arm-none-eabi-gcc (same thing here as before)
All the variables in /opt/devkitpro/3dsvars.sh (same thing here with the path), as documented here

With all of these set, the crates build fine with no extra warnings or anything.

Build 3dsx for all executables built by a given command

This might be tricky to solve, but it would be nice if we could generate a .3dsx for every binary artifact generated by a given command. Otherwise, it's kinda weird that you might get a different .3dsx depending on which one built first, since we just take the last one currently (which I think is non-deterministic order as binaries can be built in parallel).

Potential use cases:

cargo 3ds test (can build lib tests and possibly multiple integration tests. Doc tests are separate due to needing doctest-xcompile currently)
Any cargo 3ds build command with multiple binaries explicitly requested, e.g. --examples, --bin foo --bin bar, etc.

Part of what will make this hard to implement is figuring out how to specify the metadata for each binary. Most of the fields can probably still be pulled from cargo_metadata like author, name etc., but some things might be useful to specify per-executable, especially icon and RomFS.

Side note: should we call it romfs-dir instead? Most other Cargo.toml keys seem to be kebab-case rather than snake_case

In the case of lib tests, we can probably just use what we already have, but for bins, integration tests and examples I think we might need a new scheme. Initially I'd propose something like this:

[[example]]
name = "ex1"
# I think "description" is non-standard here as it's not documented in
# https://doc.rust-lang.org/cargo/reference/cargo-targets.html#configuring-a-target 
# We could still look for it, but we'd have to manually read in from Cargo.toml 

# examples/ex2.rs may exist but not be defined explicitly in Cargo.toml

[[bin]]
name = "mybin"

# etc. for tests, benches if need be

[package.metadata.cargo-3ds]
romfs_dir = "examples/romfs" # still optional

# should we call these "example", "bin" etc. to match the top-level key?
examples.ex1.romfs_dir = "examples/ex1_romfs"
examples.ex2.romfs_dir = "examples/ex2_romfs"

tests.integration.romfs_dir = "tests/romfs"

# mybin falls back to using "examples/romfs"

# if we needed something else for lib tests we could also do something like this
# but probably it should just use the top level one if we can manage that
lib.romfs_dir = "..."

As a further enhancement, we could allow setting .icon to specify a custom path to an icon, instead of always looking for ./icon.png, or really any of the CTRConfig fields could be overridden on a per-target basis if we want. I think the important ones would probably just be

romfs dir
icon
description

Overall, I think the flow would look something like this:

Collect package metadata with cargo_metadata::MetadataCommand. This gives us a list of all possible targets (bin, example, etc. including auto-discovered ones), as well as the contents of package.metadata.cargo-3ds.
Construct a CTRConfig for each target (either now or on the fly later, if we store the metadata, doesn't matter too much)
Run the underlying cargo build for whatever command, collecting the output with cargo_metadata::Message
For each artifact found in the build output:
1. lookup/construct its CTRConfig from earlier by kind and name (e.g. (Example, "foobar"))
2. generate SMDH
3. Generate 3dsx

Obviously, this is a pretty big change so I thought I'd start by proposing it and see if there's any discussion to be had before an implementation. This isn't really a super important thing to have since it can always be worked around by building one thing at a time, but it would be nice if it basically Just Worked the way cargo does.

Curious to hear other people's thoughts on this!

Rustdoc no longer working

I've recently updated Cargo 3DS, and cargo 3ds rustdoc no longer works. Looks like #21 is the culprit.
(Also, looks like #26 would fix this)

cc @SteveCookTU

[Question]: Is the family supposed to say unix?

I was looking into the environment variables for 3DS building and it looks like the only identifying feature that marks it is the target variable that says armv6k-nintendo-3ds. The family and arch say it's unix and arm respectively. I was looking into modifying my Cargo.toml and build.rs to handle 3DS for potential future implementation and to remove things like ctrlc support if it's not in the unix and windows families. Right now the only other option I see is wasm. I was thinking the family would be something different for something that's unique like maybe setting it to horizon or nintendo. So, I'm just wanting to know if setting to unix is intentional

Error trying to compile on MacOS

I have created a new project using cargo 3ds new command and I am trying to build using cargo 3ds build but I am getting the following error:

error: linker arm-none-eabi-gcc not found | = note: No such file or directory (os error 2)

I have reviewed all my routes and have configured the ones indicated in the devkitpro installation in this way:

.bash_profile:

export DEVKITPRO=/opt/devkitpro
export DEVKITARM="${DEVKITPRO}/devkitARM"
export DEVKITPPC="${DEVKITPRO}/devkitPPC"
export PATH=/opt/devkitpro/devkitARM/bin:/opt/devkitpro/tools/bin:$PATH

Another thing I have tried to do is copy one of the devkitpro 3ds examples to my desktop and compile it using make and it generated the .3dsx correctly without the linker error.

If I run the command: $DEVKITARM/bin/arm-none-eabi-gcc --version I get this output:

arm-none-eabi-gcc (devkitARM release 63) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'm not sure what else to try and although I still have the doubt that it is a problem with the environment variables, I am not sure which of them is the problem, on the other hand I wanted to mention that my version of macos is 12.6.6 with a chip: apple m1.

`cargo 3ds new` and `init` commands

Since cargo new is a convenient way to start a new project, I thought it might be useful to have a cargo 3ds new as well, to try and make it even easier to get started. This definitely isn't a necessary feature, but it might be nice to have to simplify the setup.

We could probably piggyback off plain cargo new --bin (forwarding arguments), then just modifying main.rs and Cargo.toml to add the dependencies on ctru and do some basic setup of Gfx and a Console to get a hello-world going.

Same all applies for cargo init, I think. Finding the directory would be slightly trickier but probably not too bad.

no license

(i am not a lawyer)

as far as i can tell, this project has no license. i don't think i or other people can legally use or contribute to it without a license.

also, the readme says it's based on cargo-psp, which is quite vague. if it uses its code, i'm pretty sure it needs the mit license of cargo-psp somewhere in this repo, and the PSPSDK license (since cargo-psp uses it)

Consider renaming `link` to `run` for more typical Cargo experience

Another thought I had – should we consider renaming link to run instead, to make a more typical kind of Cargo experience? In other words, cargo run, cargo test, Just Work™️ ?

This is a good idea

Originally posted by @AzureMarker in #11 (comment)

Handle empty "authors" in Cargo.toml

As of this RFC, the authors field is no longer required in Cargo.toml and is not populated by default via cargo new.

When running cargo 3ds build, the tool attempts to find the author to create the smdh file and panics:

$ RUST_BACKTRACE=1 cargo 3ds build
Running Cargo
    Finished dev [unoptimized + debuginfo] target(s) in 0.32s
Getting metadata
thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', src/main.rs:323:17
stack backtrace:
   0: rust_begin_unwind
             at /rustc/7abab1efb21617ba6845fa86328dffa16cfcf1dc/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/7abab1efb21617ba6845fa86328dffa16cfcf1dc/library/core/src/panicking.rs:107:14
   2: core::panicking::panic_bounds_check
             at /rustc/7abab1efb21617ba6845fa86328dffa16cfcf1dc/library/core/src/panicking.rs:75:5
   3: cargo_3ds::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

We should be able to gracefully handle this case especially as it's the default for new projects.