-
-
Notifications
You must be signed in to change notification settings - Fork 15k
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
futhark: init at 0.6.2 #43865
futhark: init at 0.6.2 #43865
Conversation
mkDerivation { | ||
pname = "futhark"; | ||
version = "0.6.2"; | ||
src = /nix/store/5n2kpq21b3hm0yfr7wsinh5v24y81s98-source; |
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.
While a bit ugly, this is always overridden by the default.nix
. This file is autogenerated by the update script via cabal2nix.
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.
Why not take the src
as an argument? This is too ugly.
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.
This is autogenerated by cabal2nix, I can't just change what it generates. I also don't want to have to manually edit the file every time an update comes out. It would be possible to use cabal2nix
's git fetching. But that has the problem that it doesn't use the github tarballs, it fetches all submodules, and futhark has a super big submodule that takes forever to fetch. This may get better with NixOS/cabal2nix#260. I don't know of a cleaner solution than this.
|
||
path = stdenv.lib.makeBinPath [ gcc ]; | ||
|
||
wrapped = symlinkJoin { |
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.
Why do you use symlinkJoin
with one one thing in paths
?
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.
Makes it easy to patch a single file, since everything gets symlinked and I can just replace a symlink. Idris also uses this in its wrapper.
Alternative would be to do ln -s ${package}/* $out; rm $out/bin; mkdir $out/bin; ln -s ${package}/bin/* $out/bin; rm $out/bin/futhark-c; rm $out/bin/futhark-opencl
and then the makeWrappers. I can do that if you prefer.
exit 1 | ||
fi | ||
|
||
echo Updated package.nix file successfully |
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 feel like if you have to use this script then it should be packaged properly and automatically run on whatever src
you choose rather than just living in the directory.
@mpickering I removed the update script and replaced it with a short manual description of how to update in the file, is this alright? |
Where is the description? |
@@ -0,0 +1,55 @@ | |||
# Generated using `cabal2nix --hpack .`, then replace src |
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.
@mpickering Here
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 guess it's a bit on the short side, but I think anybody knowing how to use cabal2nix will know what it means
OK, I think this is fine. It seems annoying that there isn't one invocation of For example:
|
Yeah currently there isn't, as previously mentioned, there is an issue for it: NixOS/cabal2nix#260 |
@peti @basvandijk Is it okay to add a haskell package like this? It's not in hackage |
Was able to compile some examples with it, so futhark should be fine. Unfortunately couldn't execute them, as I couldn't get OpenCL to work on my hardware (yet).
Thinkpad T460p with i7-6820HQ, currently not using the nvidia card |
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.
@infinisil cool compiler!
The fact that futhark is a Haskell package is an implementation detail. To install it users should just have to specify futhark
instead of haskellPackages.futhark
.
Note that we also do this for most other Haskell executables. Like those other Haskell executables we should also override futhark with haskell.lib.justStaticExecutables
to
reduce closure size.
I made these changes in: LumiGuide@5ba57d5. You may want to merge that into your branch or I can also do it if you like.
Offtopic: note that in #45406 I'm disabling library profiling for justStaticExecutables
meaning that once that is merged futhark
will build much quicker.
wrapProgram $out/bin/futhark-c \ | ||
--prefix PATH : "${path}" | ||
|
||
wrapProgram $out/bin/futhark-opencl \ |
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.
@basvandijk These wrappers don't seem to be applied like this, building either pkgs.futhark
or pkgs.haskellPackages.futhark
results in raw ELF binaries
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.
Strange, I did test if it created the correct wrappers but I can confirm it now results in ELF binaries. I'll look into it.
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.
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: futhark Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: futhark Partial log (click to expand)
|
Success on x86_64-darwin (full log) Attempted: futhark Partial log (click to expand)
|
@GrahamcOfBorg build futhark |
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: futhark Partial log (click to expand)
|
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: futhark Partial log (click to expand)
|
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: futhark Partial log (click to expand)
|
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: futhark Partial log (click to expand)
|
2575d70
to
fb01115
Compare
Success on x86_64-linux (full log) Attempted: futhark Partial log (click to expand)
|
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: futhark Partial log (click to expand)
|
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: futhark Partial log (click to expand)
|
Can confirm it works now |
Success on x86_64-linux (full log) Attempted: futhark Partial log (click to expand)
|
Timed out, unknown build status on x86_64-linux (full log) Attempted: futhark Partial log (click to expand)
|
@GrahamcOfBorg build haskell-ci @infinisil I'll let you do the honours of merging this in if you think it's OK now. |
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: haskell-ci Partial log (click to expand)
|
Success on x86_64-darwin (full log) Attempted: haskell-ci Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: haskell-ci Partial log (click to expand)
|
@@ -8423,7 +8425,7 @@ with pkgs; | |||
|
|||
msitools = callPackage ../development/tools/misc/msitools { }; | |||
|
|||
multi-ghc-travis = haskell.lib.justStaticExecutables haskellPackages.multi-ghc-travis; | |||
haskell-ci = haskell.lib.justStaticExecutables haskellPackages.haskell-ci; |
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.
@basvandijk Why this 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.
While moving the non-hackage packages to a dedicated file I discovered that multi-ghc-travis
has been renamed to haskell-ci
and that haskell-ci
is now on Hackage. This is explained in: 6106664
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.
Mmm maybe an alias might be in order here...
The fact that futhark is a Haskell package is an implementation detail. To install it users should just have to specify `futhark` instead of `haskellPackages.futhark`. Additionally futhark is overridden with `haskell.lib.justStaticExecutables` to reduce closure size.
We had a few "overrides" in configuration-common.nix that were really extensions. They introduced packages that weren't in hackage-packages.nix. The advantage of having a dedicated file for these packages is that we can still place Nix-specific overrides to these packages in configuration-nix.nix. We weren't able do this before because configuration-nix.nix extended only the packages from hackage-packages.nix.
multi-ghc-travis has been renamed to haskell-ci which is now also on Hackage.
fb01115
to
5ea9d9d
Compare
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: futhark Partial log (click to expand)
|
Rebased to fix conflicts, tested the binary again (still works) and added a |
Success on x86_64-linux (full log) Attempted: futhark Partial log (click to expand)
|
Timed out, unknown build status on aarch64-linux (full log) Attempted: futhark Partial log (click to expand)
|
Motivation for this change
Predicate to be able to demonstrate how well Nix can work as Futhark's package manager for https://www.reddit.com/r/ProgrammingLanguages/comments/90fnop/the_future_futhark_package_manager/
Edit: It's live :) https://github.com/infinisil/futharknixdemo
Tested with a simple compilation and run. It needed some fancy gcc
NIX_
stuff to work, @cleverca22 helped a lot with that on IRC :).It's a Haskell package not present in hackage. I used cabal2nix to generate a file with the dependencies and made the updating process automated via a small script.
Ping @peti @domenkozar for Haskell
Things done
sandbox
innix.conf
on non-NixOS)./result/bin/
)