Initial buildZigPackage #241741
Initial buildZigPackage #241741
Conversation
Janik-Haag
added
the
12. first-time contribution
|
Working on fixing the workflow problems rn. :p |
|
Is it fine that the maintainers file got reformatted? |
No, please revert it. |
|
Ill do some work before finalizing |
ofborg
bot
added
10.rebuild-darwin: 0
|
I dont know how to make the changes @figsoda said about |
I changed this now |
|
@figsoda How do i deal with the attribute merge? So I don't mention phases? |
pkgs/top-level/zig-packages.nix
Outdated
| @@ -0,0 +1,10 @@ | |||
| { lib, pkgs, stdenv, newScope, zig, fetchFromGitHub, buildPackages }: | |||
|
|
|||
| lib.makeScope newScope (self: | |||
There was a problem hiding this comment.
not sure if this is the best approach, are we planning to package zig libraries? how would that work exactly?
There was a problem hiding this comment.
I was planning on packing them as Zig doesn't have a package manager right now.
There was a problem hiding this comment.
How would packaging zig libraries work, would you be able incrementally compile them?
Also, IIRC zig will have a package manager in 0.11
There was a problem hiding this comment.
If zig will have a package manger then I don't see the point in adding packages to nixpkgs, so I will remove zigpackages
|
cc maintainers of the zig compiler @aiotter @andrewrk @AndersonTorres cc people that might be interested @adamcstephens @strager @winterqt |
|
@figsoda I think this is it. What do you think? |
|
Building |
|
So the finalAttrs approach is failing. |
|
You should finish your pr and I will rebase on top of master, then I add EDIT: Change for clarity |
| wrapDerivation = f: | ||
| stdenv.mkDerivation (finalAttrs: | ||
| f (lib.toFunction argsFun finalAttrs) | ||
| ); | ||
| in | ||
| wrapDerivation ( |
There was a problem hiding this comment.
| wrapDerivation = f: | |
| stdenv.mkDerivation (finalAttrs: | |
| f (lib.toFunction argsFun finalAttrs) | |
| ); | |
| in | |
| wrapDerivation ( | |
| changeDerivationArgs = f: | |
| stdenv.mkDerivation (finalAttrs: | |
| f (lib.toFunction argsFun finalAttrs) | |
| ); | |
| in | |
| changeDerivationArgs ( |
The derivation itself isn't wrapped (which is good).
| { strictDeps ? true | ||
| , nativeBuildInputs ? [ ] | ||
| , meta ? { } | ||
| , ... | ||
| }@attrs: | ||
|
|
||
| attrs // { | ||
| inherit strictDeps; | ||
| nativeBuildInputs = [ zig ] ++ nativeBuildInputs; | ||
|
|
||
| buildPhase = attrs.buildPhase or '' | ||
| runHook preBuild | ||
| export ZIG_GLOBAL_CACHE_DIR=$(mktemp -d) | ||
| zig build -Drelease-safe -Dcpu=baseline $zigBuildFlags | ||
| runHook postBuild | ||
| ''; | ||
|
|
||
| checkPhase = attrs.checkPhase or '' | ||
| runHook preCheck | ||
| zig build test | ||
| runHook postCheck | ||
| ''; | ||
|
|
||
| installPhase = attrs.installPhase or '' | ||
| runHook preInstall | ||
| zig build -Drelease-safe -Dcpu=baseline $zigBuildFlags --prefix $out install | ||
| runHook postInstall | ||
| ''; | ||
|
|
||
| meta = { | ||
| inherit (zig.meta) platforms; | ||
| } // meta; | ||
| } |
There was a problem hiding this comment.
This function has the shape of an overlay, if you bring finalAttrs into scope.
- this will be helpful if you have to need the overlay to be aware of the final attrs (at some point)
- you can document it as such
Specifically you can then say:
buildZigPackage invokes mkDerivation with your package definition and then overlays it, to add its defaults.
Hence the layers are applied in the following order:
- your argument to
buildZigPackage - zig defaults
- anything changed afterwards with
overrideAttrs mkDerivationlogic, such as the addition offinalAttrs.finalPackage
| let | ||
| wrapDerivation = f: | ||
| stdenv.mkDerivation (finalAttrs: | ||
| f (lib.toFunction argsFun finalAttrs) |
There was a problem hiding this comment.
When you change f to be an overlay, the composition here becomes a lot like lib.extends, except the first layer doesn't take a prev argument.
I think we could use a helper for this.
There was a problem hiding this comment.
I think we could use a helper for this.
Actually just lib.extends.
Change f to take finalAttrs: prevAttrs: and then:
- stdenv.mkDerivation (finalAttrs:
- f (lib.toFunction argsFun finalAttrs)
+ stdenv.mkDerivation (lib.extends f (lib.toFunction argsFun))
I think I've read most of the conversation, but and found no reason why. What happened? |
|
I think we should wait for work on refactoring the zig compiler is done before I do any more work on the builder function. |
|
@roberth torres wants me to remove finalattrs support because if this pr is merged it would conflict with his own. So I will wait and refactor my pr after his is merged. |
|
Not too happy about another |
Basically he tried to implement the finalAttrs support, however it is not working. So I am suggesting to implement this later. |
+1 for this! |
An easy (as in easy to design) way to do this would be to have one hook for each phase, like the ones for |
|
@RaitoBezarius @figsoda so you are saying rather than having custom phases I just add hooks to each phase that do the build process It's already preforming? I will go ahead and look at the meson and cmake code to get a better idea of how things are done. |
Co-authored-by: figsoda <figsoda@pm.me> Co-authored-by: Anderson Torres <torres.anderson.85@protonmail.com> Co-authored-by: roberth <robert@roberthensing.nl> Co-authored-by: fortuneteller2k <lythe1107@gmail.com>
Co-authored-by: Anderson Torres <torres.anderson.85@protonmail.com> Co-authored-by: figsoda <figsoda@pm.me>
Co-authored-by: figsoda <figsoda@pm.me>
Co-authored-by: Anderson Torres <torres.anderson.85@protonmail.com>
Description of changes
Creating a top level for zig packages as well as a simple way to build a zig package based off of
nimPackages.I tested building a Zig binary using buildZigPackage on
x86_64-linuxand it works.Example of usage in a flake.
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)