Building `openjfx11` or `openjfx12` on a machine with many cores can consume huge amounts of RAM. With 24 cores, the memory usage exceeded `25GB` per build for me.
Using `NIX_BUILD_CORES` to reduce the number of parallel tasks doesn't help, because a script invoking `cmake` does not respect `NIX_BUILD_CORES` and passes `-j <number of cores>`.
Setting `NUMBER_OF_PROCESSORS` overrides the automatic core count detection in the script.
https://github.com/search?q=repo%3Aopenjdk%2Fjfx%20NUMBER_OF_PROCESSORS&type=code
Co-authored-by: Fabian Möller <fabianm88@gmail.com>
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
as usual this is mostly copy-pasted from 18, so this commit is best
reviewed with '--find-copies-harder'
stop exposing openjdk 18 since it was not a long-term support release
change the default openjdk from 17 to 19 since nixpkgs is a
rolling-release repository
drop the ceremony around bootstrapping via adoptopenjdk for 64-bit
builds vs. via earlier openjdk builds for 32-bit, because, to be
frank, since we're using temurin now, it's not a simple copy-paste
job. :-/ if someone needs a 32-bit openjdk, that work can be done
separately.
JavaFX revs from 17 to 19; it looks like 18 was never packaged along
with JDK 18.
* the gradle invocation used to build JavaFX must still be done with
Java 18, as gradle does not yet support running itself on Java 19.
* a couple of patches need to be applied, since a new State enum was
introduced in the JDK that collides with one in JavaFX.
* the hash of the gradle dependencies has not changed, which is
surprising, but as far as I can tell correct.
One application (libreoffice) doesn't work with 19 yet, so pin it to
jdk 17 for now.
Co-authored-by: Mario Rodas <marsam@users.noreply.github.com>
openjfx17's plugins/av/mpegtsdemuxer.c expects ffmpeg 4 and does not build
with ffmpeg 5.1.1.
This change does not result in any rebuilds because nixpkgs `ffmpeg` still
points to `ffmpeg_4`.
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: gsttypefindelement.o:(.bss._gst_disable_registry_cache+0x0): multiple definition of
`_gst_disable_registry_cache'; gst.o:(.bss._gst_disable_registry_cache+0x0): first defined here
openjfx17 is not affected.
Remove -Werror=implicit-function-declaration, which when passed to cmake
for webkit build breaks C++ compiler configuration due to spurious warnings:
`cc1plus: warning: '-Werror=' argument '-Werror=implicit-function-declaration' is not valid for C++`
Manipulating the store paths on the Nix side doesn’t work with CA
derivations (because these paths are just placeholders of the form
`/{hash}` at eval-time)
