mirror of
https://github.com/Unidata/netcdf-c.git
synced 2024-12-03 08:01:25 +08:00
100 lines
3.0 KiB
Plaintext
100 lines
3.0 KiB
Plaintext
Resolved:
|
|
|
|
The netCDF-3 package will only support *.F FORTRAN files.
|
|
|
|
Ramification:
|
|
|
|
The netCDF FORTRAN include-file will contain C preprocessor
|
|
directives.
|
|
|
|
Arguments For:
|
|
|
|
1. We can rely on a C preprocessor being available.
|
|
|
|
2. Most FORTRAN compilers automatically run *.F files through the
|
|
C preprocessor.
|
|
|
|
3. Without C preprocessor macros, it will be extremely difficult
|
|
and cumbersome to write portable FORTRAN code (e.g. ftest.F):
|
|
the macros are necessary to customize the code to the data types
|
|
that the system supports (e.g. byte, integer*2).
|
|
|
|
4. The problem of writing portable FORTRAN code will have to be
|
|
solved in order to write the FORTRAN API test utility (ftest).
|
|
It is wrong for us to solve this problem yet tell our clients
|
|
that they're on their own.
|
|
|
|
5. Supporting portability is why the netCDF package exists.
|
|
|
|
Arguments Against:
|
|
|
|
1. It is wrong to unnecessarily require a programmer to use the C
|
|
preprocessor.
|
|
|
|
2. It is possible that a person could distribute a netCDF-using
|
|
FORTRAN library to a system that doesn't have a C compiler.
|
|
|
|
(It would seem to me that the onus would be on the distributor
|
|
of the library to support portability --Steve)
|
|
|
|
3. Most FORTRAN programmers work on Crays, which don't
|
|
automatically preprocess *.F files. It is wrong to require them
|
|
to do something that they didn't have to do before.
|
|
|
|
(I don't know that most FORTRAN programmers work on Crays.
|
|
With netCDF 2.4, if a Cray FORTRAN programmer wanted to write
|
|
portable code, then they had to use our m4(1)-based fortc(1)
|
|
utility to do it. Using the C preprocessor is better in many
|
|
ways).
|
|
|
|
Possible Compromise:
|
|
|
|
Have 2 netCDF FORTRAN include-files: one that contains C
|
|
preprocessor directives and one that doesn't. The one that doesn't
|
|
would not be able to support the writing of portable FORTRAN code.
|
|
|
|
For example:
|
|
|
|
File `netcdf.inc':
|
|
|
|
C Contains (possibly system-specific) PARAMETER, EXTERNAL,
|
|
C and data-type statements only, e.g.
|
|
|
|
INTEGER NF_BYTE
|
|
...
|
|
PARAMETER (NF_BYTE = 1)
|
|
...
|
|
PARAMETER (NF_FILL_BYTE = -127)
|
|
...
|
|
EXTERNAL NF_CREATE
|
|
INTEGER NF_CREATE
|
|
...
|
|
|
|
C Since this file only contains the above types of
|
|
C statements, conditional compilation is unnecessary. As a
|
|
C consequence, however, this file cannot be used to write
|
|
C portable code.
|
|
|
|
File `netcdf.F' (can anyone think of a better extension?):
|
|
|
|
#define NF_BYTE_T BYTE /* type of `data' argument in
|
|
* nf_{put,get}_var*_int1()
|
|
* routines */
|
|
#undef NF_SHORT_T /* i.e. FORTRAN doesn't support the
|
|
* INTEGER*2 data type */
|
|
...
|
|
#include "netcdf.inc" /* so portable FORTRAN code would
|
|
* only need to `#include
|
|
* "netcdf.F"' */
|
|
|
|
Arguments For:
|
|
|
|
Seems to satisfy both camps.
|
|
|
|
Arguments Against:
|
|
|
|
More complex.
|
|
|
|
Comments?
|
|
This is a test.
|