Extensive modifications to NetCDF package#400
Conversation
|
Does NetCDF have two build systems? Looks like the old version used cmake and the new one uses autotools. Any reason to prefer one or the other? |
|
Merging for now. We can revive the cmake build if needed. |
Extensive modifications to NetCDF package
|
You've always been able to build NetCDF with autotools. However, as of version 4.3.0, they've added support so that you can build it with CMake. Honestly, I've never used CMake before. I just chose autotools because that's how we had been building it at Argonne and because it matched most of the other packages in Spack. One advantage of CMake is that you can build on Windows (don't think this is important for us). One advantage of autotools is that you can build NetCDF prior to version 4.3.0. If you want I can switch it back to CMake. I have no allegiances :) |
|
The switch to CMake was done in #128 where netcdf needed to link to MPI, but I couldn't decipher the autotools to see how to get it done. Really, as long as that MPI linking works fine, it doesn't matter to me which build system is used. |
|
I'm currently having some issues getting NetCDF to link to the hdf4 df library, so it's not perfect yet. But if I can't get everything working with autotools I'll switch it back to CMake and work from there. |
|
Ok sounds good. If there's a future dependent package that wants cmake configs we could consider switching too, but looks good to me. |
There was a problem hiding this comment.
@tgamblin : I was wondering what is our position regarding options that trigger the download of additional material. In the past we avoided them (e.g. gcc script to download dependencies), but sometimes they simplify your life a lot...
There was a problem hiding this comment.
I think this type of download is very similar to a resource, so it doesn't bother me so much. Of course, I didn't check if they sync the versions properly in here, so that would be a problem.
Basically I'm ok with downloading extra resources as long as the versions are locked (like LLVM). It would be nice if Spack did the download, but in this case it seems way simpler to allow the Fortran bootstrap to happen in a single netcdf package, although we may need two packages eventually...
What I mainly want to avoid is missing provenance. If a package is downloading an arbitrary version of something, and if that thing is not tracked, then it probably needs to be made into a properly versioned package to let Spack deal with the combinatorial part, and not the packager/user.
* Added version printing in neurodamus * Changed preferred version of neurodamus-core to 2.3.4
…s_mods revert jcsda modifications to lib/.../modules/*
4 participants
This pull request is currently blocked by #339. Until the new HDF package is added, I won't be able to test my changes. Please let me know if there is anything preventing #339 from being merged and I will fix it.
I'm not sure how well the new experimental feature for building NetCDF-Fortran works. If it doesn't work, I'll just have to add a separate NetCDF-Fortran package.