rust3ds / cargo-3ds

Cargo command to work with Nintendo 3DS project binaries.
Apache License 2.0
59 stars 10 forks source link

Allow using a prebuilt std if one is found #18

Closed ian-h-chamberlain closed 2 years ago

ian-h-chamberlain commented 2 years ago

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.

Meziu commented 2 years ago

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

ian-h-chamberlain commented 2 years ago

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

AzureMarker commented 2 years ago

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.