* Switch to default buildPhase & installPhase
* In preConfigure
* Do not add -DNPARTITION to CHOLMOD_CONFIG. That would disable the use of Metis but we already have that.
* Do not remove -lrt on Darwin, Darwin compiler can handle that and the code no longer exists anyway.
* With CUDA enabled
* Do not replace CUDA_ROOT. It does not exist any more. Instead we are setting CUDA_PATH in makeFlags.
* Do not replace GPU_BLAS_PATH, it defaults to CUDA_PATH so it will end up with the same value.
* Do not add -DCHOLMOD_OMP_NUM_THREADS to GPU_CONFIG. Why would be having the library use the same number of threads as the builder a good idea?
* Do not replace CUDA_PATH, we are setting it in makeFlags now.
* Do not replace CUDART_LIB and CUBLAS_LIB. They were being replaced incorrectly (cuda libs are located in lib directory, not lib64). Instead set the correct paths in makeFlags.
* Do not replace CUDA_INC_PATH. Its default looks like it will end up with the same value.
* Do not replace NV20, NV30, NV35 – not used any more.
* Do not replace NVCC, defaults to the same.
* Do not replace NVCCFLAGS, we just used the default from SourceSparse 4.4.7 with -gencode=arch=compute_60,code=compute_60 tacked on top. Current upstream default looks much better.
* Stop adding -DNTIMER to CFLAGS on Darwin – clock_gettime is supported by macOS 10.12 SDK.
* In buildPhase
* Move the make arguments to makeFlags and library to buildFlags, allowing us to drop the manual make call. I did not verify all of these are still needed.
* Remove the creation of libsuitesparse.so. As far as I could tell it is some kind of remnant of our old expression – perhaps due to past deficiencies of the build scripts, we created the individual libraries as symlinks to libsuitesparse.so: e36b3ec0a5 But since the build script can now build individual .so libraries, there should be no need for this abomination. No other distros do this either.
* In installPhase
* No need to copy things manually, there is an install target. We just need to pass INSTALL=$out flag to make to let it know where to install the files.
* I do not have means of verifying the darwin dylib name fix but it looks like it might be fixed in an upcoming release.
* I dropped the rpath fixup as it does not seem to be needed any more (ldd does not report any unresolved libraries).
* Split to multiple outputs
* Fetch source from GitLab (the only source for future releases)
* Re-order attrset to be more idiomatic
* Format with nixpkgs-fmt
Naive concatenation of $LD_LIBRARY_PATH can result in an empty
colon-delimited segment; this tells glibc to load libraries from the
current directory, which is definitely wrong, and may be a security
vulnerability if the current directory is untrusted. (See #67234, for
example.) Fix this throughout the tree.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
I haven't been doing any maintenance for a long time now and not only
do I get notified, it also creates a fake impression that all these
packages had at least one maintainer when in practice they had none.
