!FBuJyWXTGcGtHTPphC:nixos.org

Nix Rust

693 Members
Rust157 Servers

Load older messages


SenderMessageTime
13 Jul 2022
@pennae:matrix.eno.spacepennae joined the room.08:17:44
@pennae:matrix.eno.spacepennaeif we want to package a rust thing with tests that have to run the compiled binary multiple times with different sets of flags, what's the best way to do that?08:18:18
@pennae:matrix.eno.spacepennae running target/${rust.toRustTargetSpec stdenv.hostPlatform}/release/$thing doesn't seem like it's the intended solution 08:20:01
@qyliss:fairydust.spaceAlyssa RossWhat does upstream do?08:32:40
@pennae:matrix.eno.spacepennaeit's a webservice that has a test suite for its rest api, can run in two different modes of lockdown with two different sets of tests08:34:36
@pennae:matrix.eno.spacepennaewe are upstream, so all changes to make this easy are on the table08:34:50
@qyliss:fairydust.spaceAlyssa RossIs it possible a library interface that you could pass the options to, so you don't have to run the compiled binary?08:36:19
@qyliss:fairydust.spaceAlyssa RossAlternatively, I think cargo integration tests give you the binary path?08:36:39
@pennae:matrix.eno.spacepennaepretty much have to run the binary, part of what we're testing is how the client reacts to the responses08:36:42
@qyliss:fairydust.spaceAlyssa Ross > Binary targets are automatically built if there is an integration test. This allows an integration test to execute the binary to exercise and test its behavior. The CARGO_BIN_EXE_<name> environment variable is set when the integration test is built so that it can use the env macro to locate the executable. 08:37:38
@qyliss:fairydust.spaceAlyssa Rosshttps://doc.rust-lang.org/cargo/reference/cargo-targets.html#integration-tests08:37:44
@pennae:matrix.eno.spacepennaeah, that sounds like it's just the thing :)08:38:03
@pennae:matrix.eno.spacepennaewill give that a shot, tyvm08:38:28
@pennae:matrix.eno.spacepennaeyeah, this is much better than what we had before :)09:32:26
@qyliss:fairydust.spaceAlyssa Rossyay :)09:32:46
@pennae:matrix.eno.spacepennae(even if it's still mostly doing some setup and calling python 😅)09:32:56
14 Jul 2022
@grahamc:nixos.org@grahamc:nixos.org

I have a shell that comes from this use of Naersk. When I open a shell, it pre-builds all my dependencies. The naersk docs show just throwing rustc and cargo into a mkShell but that isn't sufficient for the case I show below. Is there a way to ask naersk to stop prebuilding and just use buildPackage for my shell?

naersk-lib.buildPackage {
          src = ./.;

          nativeBuildInputs = with pkgs; [
            clang
            cpiotools.defaultPackage.${system}
            grub2_efi
            jq
            nix
            pkgsStatic.pkg-config
            pkgsStatic.stdenv.cc
            qemu
            rustfmt
            which
            vim # xxd
          ];
          buildInputs = with pkgs; [ pkgsStatic.zstd cryptsetupStatic rustPlatform.bindgenHook ];

          OVMF_PATH = pkgs.OVMF.fd;

          # Configures the target which will be built.
          # ref: https://doc.rust-lang.org/cargo/reference/config.html#buildtarget
          CARGO_BUILD_TARGET = "x86_64-unknown-linux-musl";

          # Enables static compilation.
          #
          # If the resulting executable is still considered dynamically
          # linked by ldd but doesn't have anything actually linked to it,
          # don't worry. It's still statically linked. It just has static
          # position independent execution enabled.
          # ref: https://github.com/rust-lang/rust/issues/79624#issuecomment-737415388
          CARGO_BUILD_RUSTFLAGS = "-C target-feature=+crt-static";

          # Configures the linker which will be used. cc.targetPrefix is
          # sometimes different than the targets used by rust. i.e.: the
          # mingw-w64 linker is "x86_64-w64-mingw32-gcc" whereas the rust
          # target is "x86_64-pc-windows-gnu".
          #
          # This is only necessary if rustc doesn't already know the correct linker to use.
          #
          # ref: https://doc.rust-lang.org/cargo/reference/config.html#targettriplelinker
          CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER = with pkgs.pkgsStatic.stdenv;
            "${cc}/bin/${cc.targetPrefix}gcc";
          # link against libc.a
          CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_RUSTFLAGS = "-lc";

          doCheck = true;
        };
14:40:02
@jonringer:matrix.orgjonringer Not naersk, but I just rustPlatform.buildRustPackage + cargoLock.lockFile example 21:25:39
@jonringer:matrix.orgjonringer * Not naersk, but I just use rustPlatform.buildRustPackage + cargoLock.lockFile example 21:26:26
15 Jul 2022
@dpc:matrix.orgdpc
In reply to @grahamc:nixos.org

I have a shell that comes from this use of Naersk. When I open a shell, it pre-builds all my dependencies. The naersk docs show just throwing rustc and cargo into a mkShell but that isn't sufficient for the case I show below. Is there a way to ask naersk to stop prebuilding and just use buildPackage for my shell?

naersk-lib.buildPackage {
          src = ./.;

          nativeBuildInputs = with pkgs; [
            clang
            cpiotools.defaultPackage.${system}
            grub2_efi
            jq
            nix
            pkgsStatic.pkg-config
            pkgsStatic.stdenv.cc
            qemu
            rustfmt
            which
            vim # xxd
          ];
          buildInputs = with pkgs; [ pkgsStatic.zstd cryptsetupStatic rustPlatform.bindgenHook ];

          OVMF_PATH = pkgs.OVMF.fd;

          # Configures the target which will be built.
          # ref: https://doc.rust-lang.org/cargo/reference/config.html#buildtarget
          CARGO_BUILD_TARGET = "x86_64-unknown-linux-musl";

          # Enables static compilation.
          #
          # If the resulting executable is still considered dynamically
          # linked by ldd but doesn't have anything actually linked to it,
          # don't worry. It's still statically linked. It just has static
          # position independent execution enabled.
          # ref: https://github.com/rust-lang/rust/issues/79624#issuecomment-737415388
          CARGO_BUILD_RUSTFLAGS = "-C target-feature=+crt-static";

          # Configures the linker which will be used. cc.targetPrefix is
          # sometimes different than the targets used by rust. i.e.: the
          # mingw-w64 linker is "x86_64-w64-mingw32-gcc" whereas the rust
          # target is "x86_64-pc-windows-gnu".
          #
          # This is only necessary if rustc doesn't already know the correct linker to use.
          #
          # ref: https://doc.rust-lang.org/cargo/reference/config.html#targettriplelinker
          CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER = with pkgs.pkgsStatic.stdenv;
            "${cc}/bin/${cc.targetPrefix}gcc";
          # link against libc.a
          CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_RUSTFLAGS = "-lc";

          doCheck = true;
        };
I don't understand what's 'isn't sufficient for the case I show below'
18:56:27
@grahamc:nixos.org@grahamc:nixos.orgI wanted to do this, but had trouble making it cross-compile to musl18:57:00
@dpc:matrix.orgdpcDo you want the binary that you're building with naersk in your shell ... ?18:59:16
@dpc:matrix.orgdpc I should finally try musl target with crane. I couldn't get it working with naersk as well, though I did not try really hard. 19:01:36
16 Jul 2022
@denommus:matrix.orgdenommusHow to have a checkPhase in cargo2nix?17:45:01
19 Jul 2022
@robin:icewind.nlIcewind joined the room.12:44:51
20 Jul 2022
@benfrank:matrix.orgBen Frank joined the room.20:58:51
23 Jul 2022
@didiercrunch:matrix.orgdidiercrunch joined the room.22:14:32
26 Jul 2022
@ctem:matrix.orgctem joined the room.11:32:40
@tinybronca:sibnsk.nettinybronca changed their display name from tinybronca to tailrec.14:48:56
@tinybronca:sibnsk.nettinybronca changed their display name from tailrec to tinybronca.15:38:18

There are no newer messages yet.


Back to Room ListRoom Version: 6