The builder does not technically need the modSha256 of the vendor dir, and even
though we pass it the entire vendor dir it makes sense not to risk having an
accidental dependency on that variable.
However, tools like [nixpkgs-update](https://github.com/ryantm/nixpkgs-update)
need to inspect the `modSha256` of a package in order to be able to update them,
and since this is a real part of the package (describes info about its
dependencies) let's add it to `passthru`.
Specifically, this allows us to run a cmd like `nix eval -f . tflint.modSha256`
to get the current value, which is how the bot finds it to replace with the new
version in the Rust ecosystem.
Previously, systemd.network.links was only respected with networkd
enabled, but it's really udev taking care of links, no matter if
networkd is enabled or not.
With our module fixed, there's no need to manually manage the text file
anymore.
The builder does not technically need the modSha256 of the vendor dir, and even
though we pass it the entire vendor dir it makes sense not to risk having an
accidental dependency on that variable.
However, tools like [nixpkgs-update](https://github.com/ryantm/nixpkgs-update)
need to inspect the `modSha256` of a package in order to be able to update them,
and since this is a real part of the package (describes info about its
dependencies) let's add it to `passthru`.
Specifically, this allows us to run a cmd like `nix eval -f . tflint.modSha256`
to get the current value, which is how the bot finds it to replace with the new
version in the Rust ecosystem.
* 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: https://github.com/NixOS/nixpkgs/commit/e36b3ec0a56c3b06152a205a46804733b88695d6 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).
Mario Rodas