| 9 Feb 2025 |
 Niklas Korz | https://github.com/rust-lang/rust/pull/135107#discussion_r1948052377 | 10:05:24 |
 Sandro 🐧 | Someone wrote earlier that we could compile the mitmproxy-linux-ebpf crate separately. I could do that probably by copying things from rust-hypervisor-firmware but I am a bit lost how to integrate that back into mitmproxy-linux | 17:08:06 |
| Niklas Korz | yup tried with --disable-docs and that builds fine... | 10:25:18 |
| Sandro 🐧 | probably we would need to hock into https://github.com/mitmproxy/mitmproxy_rs/blob/79dbbf7e080574b7bb8b92766232f7e1b6e1d0a3/mitmproxy-linux/build.rs#L141 ? | 17:09:36 |
| Niklas Korz | so good news, unlike a few years ago it appears the set of crates to generate docs for is not hardcoded anymore | 10:36:49 |
| Niklas Korz | now to find out how to configure this per target, and if that's not possible, how to patch it not to produce std docs for no_std targets | 10:37:10 |
| Niklas Korz | the source of the crate set appears to be in https://github.com/rust-lang/rust/blob/43ca9d18e333797f0aa3b525501a7cec8d61a96b/src/bootstrap/src/core/build_steps/compile.rs#L399-L418 | 10:38:28 |
| Niklas Korz | which appears to have no_std handling already, odd | 10:39:00 |
| Niklas Korz | added in https://github.com/rust-lang/rust/pull/128182 which was shipped with Rust 1.82 | 10:39:48 |
 Alyssa Ross | In reply to @sandro:supersandro.de
Someone wrote earlier that we could compile the mitmproxy-linux-ebpf crate separately. I could do that probably by copying things from rust-hypervisor-firmware but I am a bit lost how to integrate that back into mitmproxy-linux please no more of that pattern | 17:17:55 |
| Alyssa Ross | re-importing nixpkgs is a huge antipattern | 17:18:07 |
| Alyssa Ross | should absolutely not be doing that | 17:18:15 |
|  dgb joined the room. | 21:40:20 |
|  @tired:fairydust.space left the room. | 22:52:42 |
| 10 Feb 2025 |
| Sandro 🐧 | I am fine with whatever but I just lack the knowledge to help with anything inside rustc 😕 | 17:08:07 |
| 11 Feb 2025 |
 Andy Hamon | Is there any way to specify a custom --target in buildRustCrate without using crossSystem? | 02:59:07 |
| Andy Hamon | (using crate2nix fwiw) | 02:59:18 |
| Andy Hamon | trying to compile a rust lib for iOS and android. its easy enough to add the extra targets I need using rust-overlay and then use them on the command line | 03:16:05 |
| Andy Hamon | but the advice in the manual says use crossSystem. I tried doing roughly this:
rustTargetOverride = {rust.rustcTarget = "aarch64-apple-ios";};
crossSystem = (lib.systems.elaborate "aarch64-darwin") // rustTargetOverride;
My rationale being "I just want to change the target for rustc"
| 03:22:36 |
| Andy Hamon | but that results in an infinite loop. and i've realized by rationale was flawed, since i don't want to change rustc everywhere, only for my one target | 03:23:06 |
| Andy Hamon | * but that results in an infinite loop. and i've realized by rationale was flawed, since i don't want to change rustc everywhere, only for my one target (and perhaps its dependencies) | 03:23:17 |
| Andy Hamon | on the verge of giving up and doing a fixed-output runCommand that just invokes cargo in the way I want | 04:04:23 |
| Andy Hamon | actually I have something working!!! | 04:40:29 |
| Andy Hamon | with crate2nix | 04:40:43 |
| Andy Hamon | very jank though | 04:40:46 |
| Andy Hamon | crate2nix lets you override the impl of buildRustCrate. So I made an impl with transforms arguments on the way in and tacks on extraRustcOpts = ["--target aarch64-apple-ios"]; | 04:42:27 |
| Andy Hamon | (and I already have a custom rustPlatform from rust-overlay which has additional targets added) | 04:44:47 |
| Andy Hamon | not toooo worried about a lack of correctness here from a cross compiling point of view since I only want to build a staticlib | 04:47:56 |
| Andy Hamon | not sure yet if it works with dependencies or not, crate has 0 deps. But I don't see why it wouldn't | 04:48:48 |
| Andy Hamon | also no idea if my .a file even works | 04:48:57 |
