-
-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
libtensorflow: 1.9 -> 1.14.0 #63208
libtensorflow: 1.9 -> 1.14.0 #63208
Conversation
@GrahamcOfBorg build libtensorflow |
Should close #47025 when this is merged. |
I'm working on upgrading the haskell package: tensorflow/haskell#244 |
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’m not extremely excited about having to maintain multiple versions of bazel.
Can you please put the renaming file action into a separate commit, so that I can see the differences in generic.nix
?
I've updated to 1.14.0-rc1, which does compile with bazel 0.26.1. Not ideal but probably better than including another bazel version. |
I'm working on cuda support now. |
Cuda support compiles now. Feel free to merge. |
cc @basvandijk |
I wish I had seen this before starting to work on #63616! Lots of good work here. We should merge the libtensorflow derivation with the tensorflow wheel build. Probably best to build both at the same time and then split it, to save build time. |
This also changes it to a from-source build.
I updated this to 1.14.0 final. @timokau that seems to have some good changes. Using system libraries might help a lot with our dynamic linking problems! Any ideas about how to do the multiple build outputs if this is built for multiple python versions? |
Its probably not easy, maybe not even desirable to do this with multiple outputs. It would be possible to build multiple different bazel targets and put them in different outputs. That would add some complexity however and would always force everyone who wants to build one to build all of them. |
Superseded by #64716 |
This merges work done by yorickvP and timokau in NixOS#63208 and NixOS#63616 respectively. Now the derivation builds both libtensorflow and the Python package and puts them into different outputs. Quite a bit of improvements were done on the top, including: * Use official tag revision as source, not a branch; * Use all system libraries possible (before only one was actually used); * Move various environment variables to the derivation itself from hooks; * Use source Python build instead of wheel build to ensure fixup hooks do their important jobs on libraries; * And more that I forgot!
This merges work done by yorickvP and timokau in NixOS#63208 and NixOS#63616 respectively. Now the derivation builds both libtensorflow and the Python package and puts them into different outputs. Quite a bit of improvements were done on the top, including: * Use official tag revision as source, not a branch; * Use all system libraries possible (before only one was actually used); * Move various environment variables to the derivation itself from hooks; * Use source Python build instead of wheel build to ensure fixup hooks do their important jobs on libraries; * And more that I forgot!
This also changes it to a from-source build.
Motivation for this change
Update, also convert to built-from-source package.
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)This still needs testing everywhere. The linux build without cuda compiled one time. I can't test on darwin.
cc: @basvandijk