-
-
Notifications
You must be signed in to change notification settings - Fork 15.3k
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
treewide: standardize JDKs on darwin #375212
Conversation
formatting: my mortal enemy |
faac810
to
a2dc519
Compare
|
|
forgot to install rosetta 2, no wonder the x86_64-darwin builds all failed |
As best I can tell, all the packages broken on The |
|
Out of those 151 reported failing packages on x86_64-darwin, hydra-check only reports the following as successful:
|
I suspect that they may be Rosetta 2 errors |
I'm able to build |
|
a2dc519
to
e87ff4c
Compare
All four of these build (off the pre-rebase commit) on a native x86_64-darwin machine |
|
Ran
|
I still don't think these failures are caused by this PR. For example, I started investigating |
Could it be related to the vendor of JDK? Certificate ripper for example needs to be built with GraalVM JDK. The script in the NixOS pkgs has also the instruction to built a native executable instead of a fat jar being bundled with a JRE. See here for the script nixpkgs/pkgs/by-name/ce/certificate-ripper/package.nix Lines 50 to 71 in f21847f
|
@Hakky54 I don't think that's an issue here. I didn't touch GraalVM and the changes that I did make were just moving output files around to standardize locations |
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.
Code looks good to me. I'm not a darwin user, nor do I have a setup to test darwin (and admittedly, nor do I really want to set one up), so I leave in-practice testing to others.
Minor concern about the scoping of rec
and a complaint about darwin, that's all.
Thank you for the standardization, definitely necessary.
mv $sourceRoot $out | ||
mkdir -p $out/Library/Java/JavaVirtualMachines | ||
|
||
bundle=$out/Library/Java/JavaVirtualMachines/${name-prefix}-${lib.versions.major version}.jdk | ||
mv $sourceRoot $bundle | ||
|
||
# jni.h expects jni_md.h to be in the header search path. | ||
ln -s $out/Contents/Home/include/darwin/*_md.h $out/Contents/Home/include/ | ||
ln -s $bundle/Contents/Home/include/darwin/*_md.h $bundle/Contents/Home/include/ | ||
|
||
# Remove some broken manpages. | ||
# Only for 11 and earlier. | ||
[ -e "$out/Contents/Home/man/ja" ] && rm -r $out/Contents/Home/man/ja | ||
[ -e "$bundle/Contents/Home/man/ja" ] && rm -r $bundle/Contents/Home/man/ja | ||
|
||
ln -s $out/Contents/Home/* $out/ | ||
ln -s $bundle/Contents/Home/* $out/ |
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 can't see anything wrong with any of this. I just don't like it for "I don't like Darwin" reasons. Wacky paths.
e87ff4c
to
46628f9
Compare
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 PR rebuilds a lot of packages which means we must target staging. Please follow the contributing guide to not potentially ping a lot of people.
@@ -67,6 +70,7 @@ let | |||
passthru = { | |||
jre = result; | |||
home = result; | |||
bundle = "${result}/Library/Java/JavaVirtualMachines/${name-prefix}-${lib.versions.major finalAttrs.version}.jdk"; |
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.
For correctness:
result
should be swapped out for finalAttrs.finalPackage
.
(Also, the old instances of result
should probably get replaced as well.)
If you don't want to do this right now, it's fine. (It won't cause a rebuild if we do it in another PR) (Also, this change would be unrelated to the actual PR, so more reason not to do it now).
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 included it in this PR because I was also the one to introduce the usage of finalAttrs
in the first place, but I did separate it out into its own commit. I'm happy to squash it into the previous commit or discard it entirely if you'd prefer
46628f9
to
fa90dc0
Compare
fa90dc0
to
be08110
Compare
be08110
to
fb14d78
Compare
Thanks! |
lets hope for the best 🤞🏼 as we obviously cannot test everything |
The proper way to install a JDK on macOS is to copy or link a "JDK bundle" into
/Library/Java/JavaVirtualMachines
(or~/Library/Java/JavaVirtualMachines
). Most of the JDKs in nixpkgs already produce these JDKs, but they are not produced at a consistent path relative to the root of the derivation, so it's hard to install them. For example:$out/zulu-$MAJOR_VERSION.jdk
$out
This PR standardizes the bundle path at
$out/Library/Java/JavaVirtualMachines/$NAME-$MAJOR_VERSION.jdk
(chosen because it feels like adding the JDK toenvironment.systemPackages
with the appropriatepathsToLink
). It also sets apassthru.bundle
attribute that is the path to this produced bundle.This PR should have no effect on non-Darwin platforms. It is technically a breaking change for anything that expects to find JDK bundles at the previous locations, but I couldn't find any use of this in-tree and this PR should make it easier to find JDK bundles in any case.
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/
)Add a 👍 reaction to pull requests you find important.