detecting and using hdf compiled with -DHAVE_NETCDF

[Don Hooper]

Patrice Dumas,

I don't believe you understand the true reason why there are seperate
gradshdf and gradsnc executables.  When I originally added the sdfopen
command to GrADS, I wanted to link against the HDF libraries only, as
that would give the ability to *read* both NetCDF (Unidata-style) and
HDF-SDS (NCSA-style) files.  However, early on in this process, the
PCMDI folks were contributing the LATS interface to GrADS.  LATS, for
those who don't know, allows *writing* out of GrADS data into any of
its input formats.  Well, not quite any; because none of us *then*
knew of any of these techniques to avoid name conflicts (they may not
have been invented yet), the LATS stuff used nc* calls.  Thus, if one
linked with the Unidata library, one got Unidata NetCDF output, which either
library set could read.  If one linked with NCSA's HDF libraries, one
got HDF-SDS output, which only NCSA's HDF libraries could read.  This
is the distinction that justified gradsnc and gradshdf as separate
executables.  What would I "prefer"?  I'd prefer you stop overreaching
yourself.  I'd prefer you to stop stomping all over code you don't truly
understand.  That's what I'd prefer.  Believe it or not, the future of
GrADS is in good hands at COLA.  Adding modular improvements, contributing
bug fixes, etc., is great.  Messing about with the structural design,
however, is not good at all.

-Hoop

> From owner-gradsusr at LIST.CINECA.IT  Fri Feb 17 04:08:44 2006
> From: Patrice Dumas <pertusus at FREE.FR>
>
> Hello,
>
> To avoid clashes with the netcdf symbols, hdf may be compiled with
> -DHAVE_NETCDF. In that case instead of defining the symbols like
> ncopen, it defines sd_ncopen. This allows to link a program with netcdf and
> hdf at the same time. grads don't requires this as gradshdf and gradsnc
> are different executables. However gdl requires that, and now in fedora
> the interface with sd_ is used.
>
> I think that grads should be able to use both interfaces. With configure,
> it shouldn't be hard to detect that sd_ncopen is defined and not ncopen
> when linking against hdf. The code should also be changed to call sd_
> variants. I see 2 possibilities for that:
>
> 1) add a wrapper file that wraps the call to sd_ functions, like
>
> int ncopen (....)
> {
>   sd_ncopen(...)
> }
>
> And include the file if sd_ variants have been detected.
>
> It is not intrusive, but adds a function call.
>
> 2) define a macro (for example HDFNAME) that translates a name to the
> sd_ variant name.
> If the sd_ variants are detected, the following macro is defined:
>
> #define HDFNAME(name) sd_ # name
>
> otherwise HDFNAME does nothing:
>
> #define HDFNAME(name) name
>
> And the code must be modified to call HDFNAME for each nc symbols, so
> ncopen should be changed to HDFNAME(ncopen).
>
> It requires to modify the code, but there is no additional function call.
>
>
>
> Does it look right? What would you prefer?
>
> --
> Pat