ropp_io configure checks for ncdf90

[Dave Offiler]

1) configure (io) checks for ncdf90 Fortran mod file and for a routine in the ncdf90 object library (see bleow). Since ncdf90 is part of ropp_io and is built by this module, so it shouldn't expect it to be present.

2) the check (which shouldn't be done) for the mod file finds it, because it's not being removed by a make clean (or make distclean, we think)

I suspect this is legacy from when ncdf90 was built separatly.

The checks for ncdf90 should be removed from the configure.am (see below)? Nothing bad seems to happen when the is_netscf check fails; does configure skip building ncdf90 if it had been found? If it would attempt build it anyway (except for 'make' testing for it being up-to-date), then the checks are completely redundant.)

Suggestion action: 1) remove the ncdf90 checks from configure.am 2) ensure ncdf mod file is removed by make clean (any other mod files not being deleted?) Chris to action or advise/confirm Dave to do the biz.

Output from configure: checking for Fortran module ncdf90... yes ... checking for is_netcdf of the ncdf90 library... no

Lines to be removed in configure.am (??):

configure.ac:CM_CHECK_MODULE(ncdf90)
configure.ac:if test x$HAVE_MODULE_ncdf90 = xyes ; then
configure.ac:   CM_CHECK_LIB(ncdf90, is_netcdf, -lncdf90)
configure.ac:AM_CONDITIONAL(USE_NCDF90, test x$HAVE_LIBRARY_ncdf90 = xyes)

[marq]

Interesting point, this. Originally, this piece was in there intentionally, and the idea was that users of ncdf90 do not have recompile the routines they already have. With the same argument, I was actually going to add similar constructs to the tools library in order to catch those parts which are taken from my tools90 library (one of the preexisting software packages) - well, at least until a while ago.

However, I do understand that this introduces an additional point of failure and will only make a difference for very few people (like me). For simplicity, one might simply compile everything. So I guess it's reasonable to remove the said portion from the configure.ac. I have just done that (but it raises another issue we should discuss; please see #42 on this).

I believe your point 2) comes from a wrong understanding of what the test actually does - or I haven't understood what your problem is. The code first tries to compile a sample fortran code which uses the ncdf90.mod (CM_CHECK_MOD(ncdf90)); if it finds one (i.e., if the sample file can be compiled with the current compiler options), it is further checked that the ncdf90 library does exist and can be used for linking. If yes, the existing ncdf90 lib is used. If no, it is assumed that the ncdf90 module stems from an earlier installation of the io library, and therefore the the entire ncdf90 is compiled.

If the compiler finds the ncdf90 module, it does so because it is somewhere in the search path of the compiler. A make clean or make distclean does not remove those files; it only removes stuff which is build, and that would be in the build subdirectory. I have looked at the configure.ac and build/Makefile.am and believe that the code is correct; if you build the ncdf90.mod locally, it should be removed. In the past, we had a problem if the library was build for one compiler (say with upper case modnames), build, reconfigured for another compiler (say with lower case modnames), and only then the make distclean was run. Now that would, of course, not remove the previously build uppercase modules. But this also is an unintended use of the build system; always do a make distclean before you run a new configure.

Anyway, removing the optional compilation of the udunits90 and ncdf90 routines (changeset [731])should have solved this as well.