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)
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
