Some R packages require access to a home directory to pass install tests. Extend
r-modules to allow creating a temporary home directory for packages with
such requirements.
The restriction of hydraPlatforms was added in [1: ef05fad51a], but
doesn't seem to be a real reason behind it. R is Free Software and it
take takes a few minutes to build so I believe it can be distributed by
Hydra.
1: 2014-05-04 ef05fad51a
R: don't restrict meta.platforms to Linux; other architectures should build fine
The current behaviour for generate-r-packages.R is to delete
packages that have been remove upstream. This patch changes the
behaviour to mark packages as broken rather than removing them.
This has the advantage of never breaking expressions, which
previously occured when a package with overrides in default.nix
was deleted. As a result, the update procedure is simplified,
allowing automated updates to the package tree to run, and
additionally if a package is re-established upstream the previous
overrides still exist.
generate-R-packages.R fails without these changes.
Without `cacert`, all wget/curl calls will fail
with an error about no valid certificates.
Without `nix`, calling `nix-hash` fails.
An impure nix-shell can get away with not adding
these if the system NIXPKGS version is the same
as the version of NIXPKGS used
with `nix-shell generate-shell.nix`
BioConductor releases are tied to specific R releases.
Updating the package set now automatically selects the
correct version of bioconductor to match the current version of
R.
r-modules: fix r package system dependencies
r-modules: fix terra package dependencies
r-modules: fix edge case for R package import
The R package "import" has a name that clashes
with the nix function "import". The package
name in nixpkgs is correctly modified to
avoid the clash, but the name of the
R package was also being changed in
cran-packages.nix, which broke downloading
of the package.
cran-packages.nix has been manually patched,
and genreate-r-packages.R has been fixed so
future automatic updates will succeed.
r-modules: fix repeated `pkgs.` and svglite
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb3, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
Use the attribute mpi to provide a system wide default MPI
implementation. The default is openmpi (as before).
This now allows for overriding the MPI implentation by using
the overlay mechanism. Build all packages with mpich instead
of the default openmpi can now be achived like this:
self: super:
{
mpi = super.mpich;
}
All derivations that have been using "mpi ? null" to provide optional
building with MPI have been change in the following way to allow for
optional builds with MPI:
{ ...
, mpi
, useMpi ? false
}
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).
