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
meson: Clean up build and infra #86080
Conversation
I've since convinced upstream to not use such vars for the build platform during cross. Finally!
That seems like it's unrelated |
Oops sorry! meant mesonbuild/meson#6363 |
armv7l = "arm"; | ||
i686 = "x86"; | ||
x86_64 = "x86_64"; | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should default to the cpu.name when none match.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair, but let's do that in a follow-up? I just moved it as-is for now.
}; | ||
crossFile = builtins.toFile "cross-file.conf" ('' | ||
[properties] | ||
needs_exe_wrapper = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t think we should set this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it was what was there so I rather change separately, but I do agree. Didn't you make a thing just for this sort of thing?
See comment in code and the PR it references, mesonbuild/meson#6827, for details. We can remove entries from the cross file because they will be gotten from env vars now.
d49e2c1
to
6c7bd57
Compare
@matthewbauer so what i ended up doing is removing most of the items from |
The cross file is added in the `mkDerivation`. It isn't nice putting build tool-specific stuff here, but our current architecture gives us little alternative.
6c7bd57
to
8245230
Compare
Ugh I missed ofborg telling me I broke eval on staging. Fixing in a moment. |
Actually, we shouldn't really need this. We are building `native: false` binaries so when we look up a `native: true` binary the override should not apply. I've fixed this upstream in meson in NixOS/nixpkgs#86080, though some backwards compatibility migration might be in order. In the meantime, we can make `gi_cross_use_host_gi` prevent the overrides from happening, which will achieve the desired behavior. Finally, this allows us to use `find_program` in `scanner_command`, unconditionally, letting the presence of the override dictate whether a freshly-built or pre-built `g-ir-scanner` is used.
Motivation for this change
The big thing that happened is that mesonbuild/meson#6363 was finally merged!
Fixes #58831
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)CC @matthewbauer @jtojnar