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.
While trying to build a haskell-project I got:
Configuring library for inline-r-0.10.4..
cabal: The pkg-config package 'libR' version ==3.0 || >3.0 is required but it
could not be found.
the rWrapper was only bringing the R binary without its companion
library: this fixes it.
rzmq uses pkgconfig.
clustermq now incorporates ZMQ libs directly, rather than using
the rzmq package. clustermq now uses zeromq and pkgconfig.
Both packages needed patchShebangs, due to pkgconfig.
this takes care of the following folders in pkgs/development:
* arduino
* chez-modules
* go-packages
* guile-modules
* idris-modules
* perl-modules
* r-modules
* ruby-modules
`data.table` had a `postInstall` step to rename `data.table.so` to `datatable.so`, but after the package bump the file was already called `datatable.so` and `mv` command would fail.
The last snapshot was 4 months ago (2020-08-19). I also found that I needed newer definitions when I was trying to fix the R arrow package.
This update required a couple of manual changes:
1. Removing a few deleted packages from default.nix
2. Renaming the "assert" package to "r_assert" in generate-r-packages.R because "assert" is a keyword in Nix
This makes packages use lapack and blas, which can wrap different
BLAS/LAPACK implementations.
treewide: cleanup from blas/lapack changes
A few issues in the original treewide:
- can’t assume blas64 is a bool
- unused commented code
This update was primarily done to update rPackages.V8 to 3.0 which
doesn't depend on an ancient version of v8 anymore.
Also dropped the `-lv8_libplatform` linker flag. It seems as this now
part of `v8.so` as `v8_libplatform.so` doesn't exist anymore on recent
v8 versions in nixpkgs, but the headers are still there and there aren't
any "undefined reference to" errors while linking.
It seems that the dev output of libGLU needs to be included explicitly
for this to work. I've also moved the libraries from nativeBuildInputs
to buildInputs to be more semantically correct (and maybe support
cross compilation, not tested though).
