@skosukhin @WardF do y'all have any problem with this?

I don't really like that we have mpi variant for netcdf-fortran because the configure script of the package does not actually control this. The support for parallel features comes from netcdf-c and instead of running spack install netcdf-fortran~mpi we should have spack install netcdf-fortran ^netcdf-c~mpi. I agree that it's convenient to run netcdf-fortran~mpi but why can't I run netcdf-fortran+dap then? Should we copy the rest of the options from netcdf-c and introduce multiple depends_on statements in netcdf-fortran?

Regarding this PR. If we say that netcdf-c~mpi+parallel-netcdf is a valid spec then it should be possible to build netcdf-fortran with it. As far as I understand, this PR forbids that. I think that it would be better to keep the depends_on statements of netcdf-fortran as it is now and do one of the following:

1. Add conflicts('+parallel-netcdf', when='~mpi') to netcdf-c. I think that the combination netcdf-c~mpi+parallel-netcdf is rather strange and it should be OK to forbid it.
2. Replace the string if '+mpi' in self.spec: in netcdf-fortran with

   if '+mpi' in self.spec['netcdf-c'] or '+parallel-netcdf' in self.spec['netcdf-c']:

   Note that replacing it with if '^mpi' in self.spec: might bring problems because in priciple it is possible to build netcd-c~mpi ^hdf5+mpi.

@skosukhin are you sure it's possible to build netcdf-fortran with a serial compiler against netcdf-c+parallel-netcdf? I think that's the issue. My guess is that netcdf-c+parallel-netcdf has a build/link dependency on MPI, and that it exposes MPI symbols to netcdf-fortran that force the fortran interface to depend on MPI as well.

@becker33 I am not saying that it's possible to build netcdf-fortran with a serial compiler against netcdf-c+parallel-netcdf. What I am saying is that as long as we allow for netcdf-c~mpi+parallel-netcdf, it should be possible to build netcdf-fortran against it.

So a conflict statement needs to exist in netcdf-c for having +parallel-netcdf and ~mpi. I guess my question would be, is it actually possible to build netcdf-c~mpi^hdf5+mpi? Not in terms of Spack allowing it, but in terms of the build actually working. If not, another conflict statement should be added for that as well.

A member of my team that builds these products for our deployments pre-Spack has expressed interest in having all of the netcdf packages merged into a single package with each instance being a variant. I believe he's working on an example package.py file right now.

Hi, I support the netcdf package at LANL. I build all the languages in the same prefix one after the other, and we've been doing it like this since before I took over the package. That is, there is no netcdf-fortran path or modulefile, there is only netcdf and I build netcdf-fortran and netcdf-cxx into it.

It's more convenient to consider netcdf a single package so the user only has to load a single module even if they need c, cxx, and fortran libraries to compile an application. It's also more in line with the way similar software is built, in spack hdf5 has options for fortran and cxx. So in my opinion, if possible within the spack api, netcdf should be provided as a package with fortran and cxx options. It would have to run configure, make, make install 3 times during the installation if both options are set.

@nicholas-sly it is possible (not in Spack but in principle) to build netcdf-c~mpi^hdf5+mpi starting version 4.4.0:

However, it is possible that we allow for netcdf-c~mpi^hdf5+mpi in the future again, therefore, switching to MPI wrappers in netcdf-fortran should happen depending on whether netcdf-c is built using them and not on the fact that ^mpi is somewhere in the spec.

Also, as I have already mentioned, netcdf-c~mpi+parallel-netcdf is a strange but valid combination.

Personally, I don't like that we started putting conflicts and introduce redundant variants just to improve the usability. I like Spack for its flexibility. I have created #16719 that demonstrates how netcdf-c and netcdf-fortran should look like in my opinion.

@dmageeLANL I agree that most likely the end-users will be more comfortable with having one module in one installation directory. However, I guess this should be possible with Spack environments and/or Spack views (I am not really familiar with those features yet). If that is not the case, it should become a feature request.

One way of merging netcdf-c, netcdf-fortran, and netcdf-cxx4 packages into one could be done with the resource directive. I see at least two problems here:

1. We might lose flexibility. If I am not mistaken, we will be in a situation when a particular version of netcdf-c can be installed with only one particular version of netcdf-fortran. Additionally, we will have to track which versions of the packages are compatible with each other. Currently, the users have at least a room for workarounds using the command line.
2. We will need to run make install for netcdf-c before we run ./configure for netcdf-fortran. This means that we will start putting files into the installation directories before we know that we can configure everything at all. This is not such a big problem, of course, but might become annoying.

@skosukhin I think you're right that we should re-work the integration between netcdf-c and netcdf-fortran. But that's a bigger project, and I don't think we should hold up this bugfix over it, as this will allow people to avoid broken builds right now and the PR you outlined will take more time.