Conversation
|
You could try https://github.com/AzureMarker/n3ds-remote-play |
There was a problem hiding this comment.
I think this looks reasonable at first glance and probably won't cause any issues although it might be useful to warn if any of these flags are detected in the environment.
As for testing it out, did you try the project the issue was originally filed about? https://github.com/adryzz/imgui-ctru-rs (edit: or any random sys crate maybe, e.g. https://lib.rs/crates/libz-sys)
| ); | ||
|
|
||
| command.env("CFLAGS_armv6k-nintendo-3ds", &cflags); | ||
| command.env("CXXFLAGS_armv6k-nintendo-3ds", &cflags); |
There was a problem hiding this comment.
For most of these, I would probably suggest not overriding them (or at least emitting a warning of some sort) if they are already set in cargo-3ds's environment, to allow users to override this default behavior with more specific flags if they want.
For CFLAGS/CXXFLAGS we could do something like we have for RUSTFLAGS and just append all of these builtin flags, so the user could do something like CFLAGS_armv6k_nintendo_3ds=-Wall cargo 3ds build easily enough if they wanted to.
The downside is that to be "truly correct" you'd need to parse all the different ones that cc does.
Edit: one other thing, you could set these as e.g. TARGET_CFLAGS or TARGET_CC since we know the target here should always be armv6k-nintendo-3ds, and this would allow users to override with the more specific CC_armv6k_nintendo_3ds if they want to.
There is a function try_flags_from_environment but I'm not sure it works the way this is intended to... perhaps users would just need to override flags in their own build.rs if they really wanted
Closes #41
CC: @adryzz @ian-h-chamberlain
Bad first implementation i cooked up 2 months ago. Is there any project i could try this on? Extremely simple and portable C code doesn't have much problems regardless, and I can't find a reasonably sized test to use this on.