Some extensions depend on other extensions. Previously, these had to
be added manually to the list of included extensions, or we got a
cryptic error message pointing to strings-with-deps.nix, which wasn't
very helpful. This makes sure all required extensions are included in
the set from which textClosureList chooses its snippets.
Rework withExtensions / buildEnv to handle currently enabled
extensions better and make them compatible with override. They now
accept a function with the named arguments enabled and all, where
enabled is a list of currently enabled extensions and all is the set
of all extensions. This gives us several nice properties:
- You always get the right version of the list of currently enabled
extensions
- Invocations chain
- It works well with overridden PHP packages - you always get the
correct versions of extensions
As a contrived example of what's possible, you can add ImageMagick,
then override the version and disable fpm, then disable cgi, and
lastly remove the zip extension like this:
{ pkgs ? (import <nixpkgs>) {} }:
with pkgs;
let
phpWithImagick = php74.withExtensions ({ all, enabled }: enabled ++ [ all.imagick ]);
phpWithImagickWithoutFpm743 = phpWithImagick.override {
version = "7.4.3";
sha256 = "wVF7pJV4+y3MZMc6Ptx21PxQfEp6xjmYFYTMfTtMbRQ=";
fpmSupport = false;
};
phpWithImagickWithoutFpmZip743 = phpWithImagickWithoutFpm743.withExtensions (
{ enabled, all }:
lib.filter (e: e != all.zip) enabled);
phpWithImagickWithoutFpmZipCgi743 = phpWithImagickWithoutFpmZip743.override {
cgiSupport = false;
};
in
phpWithImagickWithoutFpmZipCgi743
Make buildEnv take earlier overridden values into account by
forwarding all arguments (a merge of generic's arguments, all previous
arguments and the current arguments) to the next invocation of
buildEnv.
Make all arguments to a PHP build overridable; i.e, both configuration
flags, such as valgrindSupport, and packages, such as valgrind:
php.override { valgrindSupport = false; valgrind = valgrind-light; }
This applies to packages built by generic and buildEnv/withExtensions;
i.e, it works with both phpXX and phpXXBase packages.
The following changes were also made to facilitate this:
- generic and generic' are merged into one function
- generic now takes all required arguments for a complete build and
is meant to be called by callPackage
- The main function called from all-packages.nix no longer takes all
required arguments for a complete build - all arguments passed to it
are however forwarded to the individual builds, thus default
arguments can still be overridden from all-packages.nix
This implements the override pattern for builds done with buildEnv, so
that we can, for example, write
php.override { fpmSupport = false; }
and get a PHP package with the default extensions enabled, but PHP
compiled without fpm support.
mkDerivation uses the dev output in buildInputs if it exits, hence the
php-with-extensions package was never built or put into the path of
packages dependent on it during build. With this fix, the php packages
built with buildEnv or withExtensions don't have any dev outputs;
packages which need the dev output can refer to the phpXXbase packages
instead.
This provides a means to build a PHP package based on a list of
extensions from another.
For example, to generate a package with all default extensions
enabled, except opcache, but with ImageMagick:
php.withExtensions (e:
(lib.filter (e: e != php.extensions.opcache) php.enabledExtensions)
++ [ e.imagick ])
So now we have only packages for human interaction in php.packages and
only extensions in php.extensions. With this php.packages.exts have
been merged into the same attribute set as all the other extensions to
make it flat and nice.
The nextcloud module have been updated to reflect this change as well
as the documentation.
Make mkExtension put headers in the dev output and use them, instead of
a different part of the current source tree, when referring to another
extension by using internalDeps.
This means external extensions can be built against the internal ones.
This means php packages can now refer to other php packages by looking
them up in the php.packages attribute and gets rid of the internal
recursive set previously defined in php-packages.nix. This also means
that in applications where previously both the php package and the
corresponding version of the phpPackages package set had to be
specified, the php package will now suffice.
This also adds the phpWithExtensions parameter to the
php-packages.nix, which can be used by extensions that need a fully
featured PHP executable.
A slight rewrite of buildEnv which:
1. Makes buildEnv recursively add itself to its output, so that it can
be accessed from any php derivation.
2. Orders the extension text strings according to their internalDeps
attribute - dependencies have to be put before dependants in the
php.ini or they will fail to load due to missing symbols.
This moves yet more extensions from the base build to
phpPackages.ext. Some of the extensions are a bit quirky and need
patching for this to work, most notably mysqlnd and opcache.
Two new parameters are introduced for mkExtension - internalDeps and
postPhpize. internalDeps is used to specify which other internal
extensions the current extension depends on, in order to provide them
at build time. postPhpize is for when patches and quirks need to be
applied after running phpize.
Patch notes:
- For opcache, older versions of PHP have a bug where header files are
included in the wrong order.
- For mysqlnd, the config.h is never included, so we include it in the
main header file, mysqlnd.h. Also, the configure script doesn't add
the necessary library link flags, so we add them to the variable
configure should have added them to.
Also, add opcache to default extensions since it significantly
increases PHP's performance and is by default enabled on Debian based
distributions. Not having it enabled by default results in a puzzling
performance loss for anyone attempting to migrate from Debian/Ubuntu
to NixOS who is unaware of this. Therefore, enable it by default. /talyz
Initially discussed in #55460.
This patch adds a `buildEnv` function to `php` that has the
following features:
* `php.buildEnv { extraConfig = /* ... */; }` to specify custom
`php.ini` args for the CLI.
* `php.buildEnv { exts = phpPackages: [phpPackages.apcu] }` to
create a PHP interpreter for the CLI with the `apcu` extension.
Per https://www.php.net/manual/en/intro.mhash.php, mhash extension
is obsolete, so disabling it here. (Also it doesn't cross-compile)
**Warning**: This could be a breaking change for some packages that
are very old and rely on this extension, maintainer discretion is
advised.
PHP 7.1 is currently on life support, as in only recieving security related patches.
This will only continue until: 2019-12-01
This date are in the middle of the 19.09 lifecycle. So it would be
nice to not have it in the 19.09 stable release. Dropping it now would
also result in less maintanance in updating them.
The death dates can be seen on following links:
- https://endoflife.date/php
- https://php.net/supported-versions.php
- https://en.wikipedia.org/wiki/PHP#Release_history
