Previously, only if `withHelp` was `false`, we added the `./configure`
flag `--without-help`, but apparently `--without-help` does nothing, as
not building help is the default behavior. Using `lib.withFeature` gives
the most expected behavior no matter what are the defaults. Quoting from
`./configure --help` for reference:
> --with-help Enable the build of help. There is a special
> parameter "common" that can be used to bundle only
> the common part, .e.g help-specific icons. This is
> useful when you build the helpcontent separately.
>
> Usage: --with-help build the old local help
> --without-help no local help (default)
> --with-help=html build the new HTML local help
> --with-help=online build the new HTML online help
This commit fixes#276400.
Broke in 408ece7d3d because the
`disallowedRequisites` fails here since the QT variant apparently needs
to reference a few dev outputs[1].
I won't look into the details of that now, so the easiest way to unbreak
is to skip the check for the QT variant. It should be kept for non-QT
though to make sure that a change similar to the BUILDCONFIG thing isn't
missed again by us.
[1] https://github.com/NixOS/nixpkgs/pull/245361#issuecomment-1651389735
error: output '/nix/store/2y0czyy26gcsqhmcvd2mlqa35f0gcl4l-libreoffice-7.5.4.1' is not allowed to refer to the following paths:
/nix/store/0hmvklj0mbhrn8flwbcwivvkv45limhg-freetype-2.13.0-dev
/nix/store/0rnx7rc87hwkbrhsys7mgwq4jw6pz7ma-zlib-1.2.13-dev
[...]
In v7.5.x a change was introduced that writes the BUILDCONFIG into
`$out/lib/libreoffice/program/libsofficeapp.so` including the
`PKG_CONFIG_PATH` containing references to all `dev` outputs of library
dependencies:
$ strings $(nix-build -A libreoffice-fresh)/lib/libreoffice/program/libsofficeapp.so|grep PKG_CONFIG_PATH
[...], "BuildConfig": "[...] 'PKG_CONFIG_PATH=[...]'"
This isn't really needed because this information can also be obtained
by `nix derivation show`. Also, this causes a 20% larger runtime-closure
because of all the dev dependencies being referenced by the output and
thus downloaded whenever libreoffice is substituted somewhere. The
actual numbers look like this:
$ nix path-info -Sh ./result-old
/nix/store/3mzrqh4gg7v27vdrrap9dj3x8myysmyf-libreoffice-7.5.4.1-wrapped 2.0G
$ nix path-info -Sh ./result
/nix/store/g5y60s0a2q2v6r58xcayv62z7fjfi816-libreoffice-7.5.4.1-wrapped 1.6G
Only `libreoffice-fresh` is affected, `pkgs.libreoffice` isn't because
it still points to 7.4 whereas the problematic change was introduced in
7.5.
To make sure this doesn't get reintroduced by accident, the derivation
also prohibits now to reference any dev output from a build input.
[1] https://gerrit.libreoffice.org/c/core/+/141197
Cleanup the unwrapped derivation's postInstall. Delete wrapper.sh, and
put it's contents in the wrapped derivation via configurable
`makeWrapper`. Also, always install dolphin templates in the unwrapped
derivation.
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>
