Conversation
Jarkko Sakkinen
jarkko
Any known examples in open source products doing the following pattern with Rust:
1. You have a Rust crate that you compile to you compile as usual host-to-host.
2. You have a build.rs that spawns cargo to a directory with rust-toolchain.xml defining nightly target.
3. You pass options (e.g. --target) for cargo to compile for a different target than the host.
Obviously Command is used to create the process together with current_directory() to change the directory to the one with Cargo.toml and rust-toolchain.xml. It is not a sub-crate per se topologically but a disjoint crate.
In Linux and macOS this can be made to work. With Windows cargo is acting like --target etc. options did not exist at all and ignores rust-toolchain.xml.
Any ideas how to make this type of pattern work?
#rust #rustlang #cargo #windows #riscv
1. You have a Rust crate that you compile to you compile as usual host-to-host.
2. You have a build.rs that spawns cargo to a directory with rust-toolchain.xml defining nightly target.
3. You pass options (e.g. --target) for cargo to compile for a different target than the host.
Obviously Command is used to create the process together with current_directory() to change the directory to the one with Cargo.toml and rust-toolchain.xml. It is not a sub-crate per se topologically but a disjoint crate.
In Linux and macOS this can be made to work. With Windows cargo is acting like --target etc. options did not exist at all and ignores rust-toolchain.xml.
Any ideas how to make this type of pattern work?
#rust #rustlang #cargo #windows #riscv
2
0
0
Related:
1.The PR in trouble: https://github.com/paritytech/polkavm/pull/240
2. NINE years old Rust bug: https://github.com/rust-lang/rust/issues/37868
I even went on sending email to Jack who reported the Rust bug, and also is author of this crate: https://docs.rs/duct/latest/duct/.
Well, he did not have off-the-shelf answer but he did say that I should probably remove env_clear(). In Linux actually removing it breaks the build and makes it behave like the Windows build.
I'm a bit pessimistic ATM ;-)
1.The PR in trouble: https://github.com/paritytech/polkavm/pull/240
2. NINE years old Rust bug: https://github.com/rust-lang/rust/issues/37868
I even went on sending email to Jack who reported the Rust bug, and also is author of this crate: https://docs.rs/duct/latest/duct/.
Well, he did not have off-the-shelf answer but he did say that I should probably remove env_clear(). In Linux actually removing it breaks the build and makes it behave like the Windows build.
I'm a bit pessimistic ATM ;-)
0
0
0
Peter Hartley
TalesFromTheArmchair@hachyderm.io
@jarkko I confess I haven't tried it on Windows, but even on Linux to make it work sensibly I had to remove CARGO_* environment variables, but leave all others intact, might be worth a try: https://github.com/pdh11/cotton/blob/main/systemtests/build.rs
1
0
1
Jarkko Sakkinen
jarkko
@TalesFromTheArmchair Thanks I honestly do appreciate your comment! Anything is really worth of a shot by now ;-)
As per Windows I learned the basics of how to debug NT kernel and now I should be able to start capture the environment of every cargo process launched:
https://social.kernel.org/notice/AqZds7vXTuTxSm2gds
I.e. build from command-line within the directory where rust-toolchain.toml and Cargo.toml reside but otherwise with same arguments as in build.rs and then do the build.rs build. Finally "subtract the sets".
What you're doing is an interesting idea, I will definitely give it a shot. Also wonder does the position of current_dir() call matter (I had it before arg() calls)....
As per Windows I learned the basics of how to debug NT kernel and now I should be able to start capture the environment of every cargo process launched:
https://social.kernel.org/notice/AqZds7vXTuTxSm2gds
I.e. build from command-line within the directory where rust-toolchain.toml and Cargo.toml reside but otherwise with same arguments as in build.rs and then do the build.rs build. Finally "subtract the sets".
What you're doing is an interesting idea, I will definitely give it a shot. Also wonder does the position of current_dir() call matter (I had it before arg() calls)....
1
0
0
@TalesFromTheArmchair Not critique for cargo per se because in order to criticize one show the better way (or actually "show the code") but somehow in the "non-generic case" cargo can be a bitch.
One example is custom targets: there should be really within a project directory a directory where they could be deployed and all the tools would automatically discover them. Then one could just use them by name.
I was so sure that I just don't know how to make that happen but I'd presume that it is not possible reflecting e.g. this tutorial:
https://security.googleblog.com/2024/09/deploying-rust-in-existing-firmware.html
I trust that Google would know the way if that would exist.
One example is custom targets: there should be really within a project directory a directory where they could be deployed and all the tools would automatically discover them. Then one could just use them by name.
I was so sure that I just don't know how to make that happen but I'd presume that it is not possible reflecting e.g. this tutorial:
https://security.googleblog.com/2024/09/deploying-rust-in-existing-firmware.html
I trust that Google would know the way if that would exist.
1
0
0
@TalesFromTheArmchair Dude! I fixed the Windows build thanks to your suggestion!
Do you have email so that I could put suggested-by tag to the commit?
Do you have email so that I could put suggested-by tag to the commit?
1
0
0
@TalesFromTheArmchair Off-topic: I noticed from your blog BTW that you're using RTIC. I know the author (Per Lindgren) and meeting him on Saturday :-)
https://www.meetup.com/finland-rust-meetup/events/305666104/
https://www.meetup.com/finland-rust-meetup/events/305666104/
1
0
0
1
0
0
Peter Hartley
TalesFromTheArmchair@hachyderm.io@jarkko Ah, that's great, thanks for the mention!
1
0
1
Jarkko Sakkinen
jarkko
@TalesFromTheArmchair You're welcome! It is painful for me to push commits if I don't take this type of stuff in detail. It's not even like first and foremost even politeness: I've been kernel maintainer long enough that I feel that I compromise myself or something like that if I don't always be super explicit on these :-)
0
0
0