Open lopsided98 opened 1 year ago
I just realized that this will cause the top-level defaultCrateOverrides
argument to be ignored. I need to think about this some more, since I don't understand the exact conditions that trigger the bug.
@lopsided98 yes this has bugged me too --- and I am glad you trying out cross stuff again!
So the thing that has been bugging me is that buildRustCrate
really should not take an attribute set of all the overrides, it should accept just the override for just the crate that is being built --- or better yet just accept the arguments to build and have something like overrideAttrs
for overriding them.
I think we do that, and the knot will start to untangle and it will become clear what crate2nix
ought to do.
But fixing that is easier said that done, sadly.
When cross-compiling, there are different versions of
defaultCrateOverrides
for each platform. This causesbuildRustCrateWithFeatures
to think the user has passed a custom value ofcrateOverrides
, which prevents the normaldefaultCrateOverrides
from being applied. To fix this, use a null default forcrateOverrides
to detect whether the user has actually specified a value.This issue can be reproduced by applying a crate override as described here: https://github.com/kolloch/crate2nix#patching-crate-derivations-with-crateoverrides, and then attempting to cross-compile the package. The overrides will not be applied.