Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some sort of support for .cargo/config.toml ? #338

Open
Fuuzetsu opened this issue Mar 20, 2024 · 4 comments
Open

Some sort of support for .cargo/config.toml ? #338

Fuuzetsu opened this issue Mar 20, 2024 · 4 comments

Comments

@Fuuzetsu
Copy link
Contributor

We have something like this in our .cargo/config.toml

[target.'cfg(target_arch="x86_64")']
rustflags = "-Ctarget-feature=+fma,+avx2"

[target.'cfg(target_arch="aarch64")']
rustflags = "-Ctarget-cpu=native"

After crate2nix, on x86_64 there's no mention of those explicit target features. We're currently doing a hack where we manually override all of the crates out of Cargo.nix to re-add these but that's quite manual and generally annoying. It'd be very nice if some basic features were supported. Or at least we should have a closed ticket that's explicit about not supporting this or something.

@Ten0
Copy link

Ten0 commented May 1, 2024

#345 (comment) may be a generic workaround that avoids having to manually operate on each crate, however it is a bit hacky in that it uses cargoNix.internal to identify the list of crates, then specify the flags for each of them individually.

@ncrocker-anduril
Copy link

Definitely need this too, or at least a way to specify arbitrary additional rustc args.

In my case, we're building dylib crates, and these must be built with -C prefer-dynamic to properly link the std library. Normally you specify this in your workspace .cargo/config.toml:

[build]
rustflags = ["-C", "prefer-dynamic"]

@Ten0
Copy link

Ten0 commented Feb 9, 2025

Maybe the hacky workaround above works for your case as well?

@Fuuzetsu
Copy link
Contributor Author

Fuuzetsu commented Feb 10, 2025

FWIW what we ended up doing is to add a comment to config.toml:

# crate2nix doesn't read anything out of this file , if you change it, you may
# need to update nix/rust_build_overrides.nix
[target.'cfg(target_arch="x86_64")']
rustflags = "-Ctarget-feature=+fma,+avx2"

and in some nix code later we override everything in the Cargo.nix like this:

pkgs.lib.foldlAttrs
      (acc: name: value:
        acc // {
          ${name} = attrs:
            let
              existing = (acc.${name} or (_: { })) attrs;

              # Manually applied overrides from .cargo/config.toml. If that file
              # changes, you should always update the content below. Technically
              # there's a nix builtin to read TOML files but parsing out seems
              # more effort than needed. Instead we just assert that the config
              # hash hasn't changed and assume the manual parsing result below
              # is correct.
              cargo_toml_file_hash = builtins.hashFile "sha256" ../.cargo/config.toml;
              cargo_toml_expected_hash = "ef839e0fdd5fae2434de17675518dd469a0a1488950d2044246d353787729ba2";
              config_toml =
                assert pkgs.lib.asserts.assertMsg (cargo_toml_file_hash == cargo_toml_expected_hash)
                  ".cargo/cargo.toml sha256 should be ${cargo_toml_expected_hash} but found ${cargo_toml_file_hash}";
                {
                  extraRustcOpts = existing.extraRustcOpts or [ ] ++
                  pkgs.lib.optionals pkgs.stdenv.hostPlatform.isx86_64 [ "-Ctarget-feature=+fma,+avx2" ];
                };
              # Put anything that should apply to the crates in the brackets here. For example:
              # { extraRustcOpts = existing.extraRustcOpts or [ ] ++ [ "-Clto=thin" ]; }
            in
            existing // config_toml // { };
        }
      )
      manual
      cargoNixNoOverrides.internal.crates;

I guess we could parse the config.toml here and try and do something smarter but we very rarely change config.toml so this has done fine. It at least lets us know when the two go out of date. Ignore some of the irrelevant code in here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants