Improve checks on existence etc of $BUFR_TABLES and $BUFR_LIBRARY

[Ian Culverwell]

ROPP8.0 beta reviewer Axel von Engeln (EUM) says:

I just came across another possible problem. I wanted to re-install 
ROPP7 into a local directory, using the already installed libs of 
netCDF, bufr, etc, and it fails since it cannot remove the 
roppbufrcodes.nl file (which we have centrally installed). Not sure 
why this is required. Might be sufficient to just cross check if the 
latest version is there.

A (tested) partial solution was committed at r4403. But the following logic might be better still:

1) If $BUFR_TABLES or $BUFR_LIBRARY is writable, overwrite roppbufrcodes.nl with the latest one in the ROPP distribution.

2) If not, but it is readable and contains a roppbufrcode.nl file, then compare the existing and new (ROPP distro) versions of it and

a) if they're the same, issue an INFO message to that effect;

b) if they're different, issue a WARNING message saying that the existing one may not be compatible with the latest value of ROPP.

3) If not, but it is readable and does not contains a roppbufrcode.nl file, then issue an ERROR saying that ROPP BUFR tools will not work, but continue building the rest of the module.

This has Axel's approval.

Note the overlap with #390.

[Ian Culverwell]

Dave Offiler adds:

.nl file should be independent of ROPP version. Just leave! (Not installed to <prefix>.)

[Dave Offiler]

roppbufrcodes.nl can and should be updated with the next version of ROPP so as to support new missions, so case (1) would be the normal situation.

Note 1: according to #386, if BUFR_LIBRARY (MetDB) or BUFR_TABLES (ECMWF) are not writeable, then the buildbufr installation of those packages will (from now on) abort. For reasons given in #386, it would require enemy action to explicitly make the target BUFR directory unwritable if the parent installation <prefix> directory is (the BUFR files must reside in the same installation tree when using buildbufr which doesn't support installing elsewhere, even if the environment variable is set outside the script - should it?).

Note 2: if roppbufrcodes.nl cannot be found at run-time then an equivalent set of hard-coded internal tables will be used instead. Normally, the namelist and internal tables will be the same, but the namelist - if different - takes precedence.

Note 3: I don't see how (or why) a file in a central, unwritable, directory - and presumably not in <prefix> should (or could) be replaced.

It seems Axel is installing files in a manner not supported by ROPP; I suggest that this is a rare corner case and not worth putting a lot (if any) effort into - it would be messy to implement the suggested logic within the makefile templates. I recommend a "won't fix" unless I've completely misunderstood Axel's 'use-case'.

[Ian Culverwell]

So in case 93) we should issue a WARNING that the internal table will (anomalously) be used, because roppbufrcodes.nl is absent.

Discuss with Axel. Defer ticket to ROPP10.0.

[Ian Culverwell]

Some overlap with #685. Bear in mind Dave's comment. Defer to ROPP-11.0.

[Ian Culverwell]

Try to absorb in ROPP-11.1 I/O devts, so change milestone accordingly.