Allow using a prebuilt std if one is found
ian-h-chamberlain opened this issue · comments
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.
@ian-h-chamberlain how did you go about building it? Trying a standard: ./x.py build -i --stage 2 library/std --target armv6k-nintendo-3ds
fails abruptly for me.
The relevant parts of my config.toml
look like this, I think this should mostly cover it:
# Includes one of the default files in src/bootstrap/defaults
profile = "library"
changelog-seen = 2
[build]
docs = false
locked-deps = true
# adjust for your host target
target = ["x86_64-apple-darwin", "armv6k-nintendo-3ds"]
# really, I think we want install-stage = 1 for "src/librustc", "library/std"
# and 0 for everything else
install-stage = 0
extended = true
tools = [
"src",
# "cargo",
# "clippy",
# "rustfmt",
# "llvm-tools",
]
[rust]
deny-warnings = false
[target.armv6k-nintendo-3ds]
# TODO: we need some way to pass CFLAGS here?
# CFLAGS_armv6k_nintendo_3ds = "-mfloat-abi=hard -mtune=mpcore -mtp=soft -march=armv6k"
cc = "/opt/devkitpro/devkitARM/bin/arm-none-eabi-gcc"
cxx = "/opt/devkitpro/devkitARM/bin/arm-none-eabi-g++"
ar = "/opt/devkitpro/devkitARM/bin/arm-none-eabi-ar"
ranlib = "/opt/devkitpro/devkitARM/bin/arm-none-eabi-ranlib"
linker = "/opt/devkitpro/devkitARM/bin/arm-none-eabi-gcc"
The only other important thing is that you'd need to export CFLAGS_armv6k_nintendo_3ds
as listed in the comment there. I think we called that out in the platform support doc being upstreamed.
With those options, I think you should just be able to ./x.py build
and use the resulting std? I have mostly been using stage 1 instead of 2 but I think it should work roughly the same way...
For comparison, this is my config.toml
:
# Includes one of the default files in src/bootstrap/defaults
profile = "compiler"
changelog-seen = 2
[build]
extended = true
tools = ["clippy", "rustfmt"]
target = ["x86_64-unknown-linux-gnu", "armv6k-nintendo-3ds"]
[rust]
debuginfo-level-std = 2
[target.armv6k-nintendo-3ds]
cc = "/opt/devkitpro/devkitARM/bin/arm-none-eabi-gcc"
cxx = "/opt/devkitpro/devkitARM/bin/arm-none-eabi-g++"
ar = "/opt/devkitpro/devkitARM/bin/arm-none-eabi-ar"
ranlib = "/opt/devkitpro/devkitARM/bin/arm-none-eabi-ranlib"
linker = "/opt/devkitpro/devkitARM/bin/arm-none-eabi-gcc"
And I build with ./x.py build library/std --stage 1
most of the time.