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.
