rnhmjoj 61b7cab481 treewide: use perl.withPackages when possible ... Since 03eaa48 added perl.withPackages, there is a canonical way to create a perl interpreter from a list of libraries, for use in script shebangs or generic build inputs. This method is declarative (what we are doing is clear), produces short shebangs[1] and needs not to wrap existing scripts. Unfortunately there are a few exceptions that I've found: 1. Scripts that are calling perl with the -T switch. This makes perl ignore PERL5LIB, which is what perl.withPackages is using to inform the interpreter of the library paths. 2. Perl packages that depends on libraries in their own path. This is not possible because perl.withPackages works at build time. The workaround is to add `-I $out/${perl.libPrefix}` to the shebang. In all other cases I propose to switch to perl.withPackages. [1]: https://lwn.net/Articles/779997/		2021-03-31 21:35:37 +02:00
..
applications	treewide: use perl.withPackages when possible	2021-03-31 21:35:37 +02:00
build-support	treewide: use perl.withPackages when possible	2021-03-31 21:35:37 +02:00
common-updater
data	Merge staging-next into staging	2021-03-29 00:15:53 +00:00
desktops	Merge master into staging-next	2021-03-30 00:14:33 +00:00
development	treewide: use perl.withPackages when possible	2021-03-31 21:35:37 +02:00
games	Merge pull request #118156 from jonringer/fix-paradox-launcher-steam	2021-03-31 19:00:58 +02:00
misc	treewide: use perl.withPackages when possible	2021-03-31 21:35:37 +02:00
os-specific	treewide: use perl.withPackages when possible	2021-03-31 21:35:37 +02:00
pkgs-lib
servers	Merge staging-next into staging	2021-03-31 18:15:02 +00:00
shells	Merge staging-next into staging	2021-03-31 18:15:02 +00:00
stdenv
test
tools	treewide: use perl.withPackages when possible	2021-03-31 21:35:37 +02:00
top-level	Merge staging-next into staging	2021-03-31 18:15:02 +00:00