Closed ian-h-chamberlain closed 1 year ago
This is a very welcome addition, especially since cargo-3ds
presents a film of obscurity between the user and the commands actually run (maybe we should do something about documenting how cargo-3ds
interacts with the environment).
Just a thing: even though I think that it'd be almost impossible to move away from 3dslink
(especially for how it interacts with the Homebrew Menu), I would still like to work on #2. What do you think about moving away from console commands and actually re-implement some features?
Just a thing: even though I think that it'd be almost impossible to move away from
3dslink
(especially for how it interacts with the Homebrew Menu), I would still like to work on #2. What do you think about moving away from console commands and actually re-implement some features?
Sure, I don't think it's a bad idea, if you want to. I personally wouldn't consider it a priority, since users will always have to have the toolchain installed anyway, so we should always be able to rely on the existence of those tools. Having more stuff in Rust (and library-usable) is always nice though!
One thing we could do is find the tools' full path using $DEVKITARM/tools/bin/$tool
, instead of just relying on $PATH
to be set correctly. That would be a much easier change and probably more reliable, in case people don't add that directory to their PATH
.
Going to go ahead and merge this, it fixes some issues with building doctests and doesn't seem too controversial.
I often find myself wanting to reproduce the same command that
cargo-3ds
was running, so I thought it would be handy to print these commands out when a flag is passed in.The output looks like this, with the intention that it can be copy-pasted back into the shell easily to run the same command:
Also fix minor issue with building
test
crate for doctests.