-
-
Notifications
You must be signed in to change notification settings - Fork 14k
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
graphene-hardened-malloc: migrate to by-name, build light variant #266540
Conversation
5369939
to
a54172f
Compare
Got to say I'm very much not a fan of the "by-name" layout. |
Well there was an RFC for it for a reason.. |
@risicle what do you want done then? The end goal is apparently having as many packages as possible in by-name... |
a54172f
to
d08cf30
Compare
d08cf30
to
8cd63eb
Compare
An RFC doesn't (and cannot) produce unanimity. But I can't stand in the way of the great scattering myself, so do as you like. |
My point is that at the moment we don't have a policy in-place so it is up to yo,u but it seems like in the near future everything will be moved to by-name so your decision won't be that relevant longer term. |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/prs-already-reviewed/2617/1245 |
buildPhase = '' | ||
runHook preBuild | ||
|
||
for VARIANT in default light; do make $makeFlags ''${enableParallelBuilding:+-j$NIX_BUILD_CORES} VARIANT=$VARIANT; done | ||
|
||
runHook postBuild | ||
''; |
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.
Please use makeTargets instead
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.
From my tinkering, looks like both makeTargets
and makeFlags
won't work with how hardened_malloc's Makefile handles VARIANT.
From what I experimented with, we have 2 variants left:
let mkMalloc = variant: stdenv.mkDerivation {}; in { graphene-hardened-malloc = mkMalloc "default"; graphene-hardened-malloc-light = mkMalloc "light"; }
but this will creategraphene-hardened-malloc.default
andgraphene-hardened-malloc.light
+ I don't like how theselet blabla = stdenv.mkDerivation in
look 🙄- we can introduce an overridable variant attribute like mimalloc package and then override it in the module.
8cd63eb
to
af65b87
Compare
Rebased, rewrote descriptions. (more like pasted them from readme) Also bumped the package from branch Regarding overriding buildPhase - I can't really think of anything better when it comes to how the upstream Makefile works, personally I would prefer to leave it as it is here unless someone has a better idea. |
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.
Result of nixpkgs-review pr 266540
run on x86_64-linux 1
2 packages blacklisted:
- nixos-install-tools
- tests.nixos-functions.nixos-test
2 packages built:
- graphene-hardened-malloc
- graphene-hardened-malloc.debug
Description of changes
Also added it to the malloc module :p
Things done
nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)