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
criterion: init at 2.3.3 #70403
criterion: init at 2.3.3 #70403
Conversation
I guess you forgot to add your package to |
@wucke13 Thanks for your review! I've pushed updated commits with your comments taken into account. |
Hello, I am the author of #70609 which also adds |
Hi ! I guess its a matter of who gets to maintain it. You seem to have two extra commits in your pull-request and, purely subjectively, I find my derivation to be cleaner, so I'd say my PR is currently more ready for merge. |
I think I actually agree with you on this, I was just working on rebasing these two (accidental) commits away, but your derivation file is more complete and cleaner. (though I can't help but wonder if running unit tests in a package build is really necessary) I will be closing my PR shortly. |
Noo! If you want to, add both of you to the maintainer list. It is never wrong to have more people to fix things once they go bad! |
I couldn't agree more! @Thesola10 do you want me to add you to the maintainer list ? |
@Yumasi please do it then (my maintainer entry already exists and is |
Signed-off-by: Guillaume Pagnoux <gpagnoux@gmail.com>
Signed-off-by: Guillaume Pagnoux <gpagnoux@gmail.com>
Signed-off-by: Guillaume Pagnoux <gpagnoux@gmail.com>
that's cool, but why exactly did ofborg request me for review? |
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.
Looks good to me.
Probably because I added you to the package maintainer list. Thanks for your reviews! Anyway, this look good to me as well, so I think we can get this merged at this point, if everyone is ok with it. @wucke13 is there anything else you think I should change ? |
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.
Looks good to me.
Not necessary but something about the cosmetics again:
I prefer to have my deps sorted by nativeBuildInputs (stdenv
, cmake
, ...), then buildInputs (libxyz
, ...) and then check and postBuild deps. All of these groups sorted by alphanumerical order (but stripping away very generic prefixes like lib
. That is just a personal preference, but I think it looks nice plus deps are named in the same order in the arguments and the vars, so that checking for deps which are mentioned in the arguments but not mentioned anywhere in the build are easier to spot by eye.
@GrahamcOfBorg build boxfort criterion |
can't wait for it to reach |
Motivation for this change
Criterion
was not packaged for NixOS, so here is a derivation for it. Alongside it is a derivation forBoxFort
, which is a library specifically created to implementCriterion
. SinceBoxFort
is a very nice project, it does not have any release and is built by Criterion's build system againstBoxFort
's master branch. Since this behavior is not Nix-friendly, I packaged it using the commit hash as a version number. This also guarantees me to have a working Criterion derivation. This PR also adds me in the maintainer list for those packages.Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nix-review --run "nix-review wip"
./result/bin/
)nix path-info -S
before and after)