Investigate using nc-config / nf-config to discover NetCDF libraries

[letmaik]

#24 (comment)

In some situations, typically HPC environments, this would avoid having to set -DNETCDF_DIR=.. / -DNETCDF_FORTRAN_DIR=...

Note that if netcdf-fortran is built with CMake, then nf-config --prefix just prints "not supported in CMake builds" or something similar.

[zbeekman]

Note that if netcdf-fortran is built with CMake, then nf-config --prefix just prints "not supported in CMake builds" or something similar.

oh. sigh.

It's relatively easy to get CMake to generate pkg-config files. I wish NetCDF would install good/thorough CMake package config files and generate pkg-config files, then just abandon auto-tools. It would save everyone the hassle of having to write yet another FindNetCDF.cmake module. I've seen at least 4 popular versions floating around, each with its strengths and deficiencies. If NetCDF always used CMake, installed decent CMake pacakge config files and pkg-config files, and was smart enough to set nf-config --prefix in CMake based builds, then the world would be a beautiful place.

(i.e., you could adjust CMAKE_PREFIX_PATH if needed and find_package(NetCDF) would just work without having to roll your own find module.)

[dmey]

Could we not simply rely on nc-config instead of nf-config and use it to infer the path to netcdf with the --fflags and --flibs? But then again I think this would end up not being configured if users build NetCDF Fortran with CMake... . The question is whether all this is actually worth doing all this...

If not I would probably just the hints to something like:

PATH_SUFFIXES ["x86_64-linux-gnu", ""]

and then the user can simply pass NETCDF_DIR and NETCDF_FORTRAN_DIR at configure time...

[letmaik]

@dmey Do you have a concrete situation where you're unable to use NETCDF_DIR/NETCDF_FORTRAN_DIR on some system? Not sure why you mention x86_64-linux-gnu.

[dmey]

Well this is why I suggested adding to PATH_SUFFIXES ["x86_64-linux-gnu", ""]-- at the moment it would only work with "x86_64-linux-gnu", I think -- I am pretty sure I had this issue some time ago...