Closed edwardhartnett closed 2 months ago
I think we need to figure out a way to do a broader community survey and determine just what this would break, for who, and where. I think about packages like WRF
that use legacy install scripts to bundle netCDF and dependencies; while I can easily imagine saying 'that's their problem, they'll have to update their tools', in the short term, at least, it would become a community problem.
That said, if there were a way we could dump autotools tomorrow, I would; cmake is pretty great, and @K20shores is doing great work pitching in and helping us modernize the cmake we have. Once we get new releases for libnetcdf & interface libraries, I'll try to figure out how we can have this conversation. Maybe something at AGU next year to take the temperature of the community; it's a shame we don't have a broader sample show up for the regional RMACC HPC conference.
I will close this issue. I recommend that the autotools be deprecated after the 4.9.3 release.
These days, the vast majority of users either gets netCDF installed by sysadmins (on HPC systems), or else they get it from a package management system like apt-get.
So having two independent build systems is probably a luxury that netCDF cannot afford, given reduced staffing at Unidata.
I think in light of Dennis' upcoming departure, it's worth examining this issue. I think having one build system instead of two would lighten the load.
Here at NOAA we rely entirely on CMake and that seems to work everywhere. CMake is available on more platforms than autotools in fact.
So perhaps its time to retire the netcdf-c and netcdf-fortran autotools builds, and rely on cmake only.