Re: GDL ITP

[Igor Khavkine <igor.kh@gmail.com>]

On 15 Jan 2006 23:09:46 +0100, Thomas Walter <t.walter@nefkom.net> wrote:
> Hello,
>
> On Sun, 2006-01-15 at 22:36, Igor Khavkine wrote:
> > On 1/4/06, Juan Antonio Añel Cabanelas <aetherlux@gulo.org> wrote:
> > > I opened an ITP for Gnudatalaguage (GDL could be confusing in Debian
> > > because it is similar to "Gnome Development Library") 9 months ago.
> > >
> > > It exist some problems with libraries, GDL is a complex package, but a
> > > friend of mine and my sponsor, DD, has packaged a GDL version with
> > > without support for HDF files and it is not tested.
> >
> > Let me take a guess at why HDF support was turned off. I just tried
> > compiling the latest release of GDL (0.8.11) and ran into a problem.
> > The problem has to do with the netcdf.h header file. In Debian, it can
> > be found in two packages:
> >
> > libhdf4g-dev: usr/include/hdf/netcdf.h
> > netcdfg-dev: usr/include/netcdf.h
> >

> > When all the features are turned on, GDL wants both the HDF4 and
> > NetCDF libraries to be available. The header file it really wants is
> > from the netcdfg-dev package. However, if HDF4 support is turned on,
> > the -I/usr/include/hdf gets passed to gcc. Hence, the header file from
> > libhdf4g-dev will always take priority over the other one, since
> > netcdfg-dev puts it into the standard include path.
>
> I think there should be found a solution which allows both.
> As far as I know, the best would be to use HDF5 and perhaps combined
> with netCDF-4 project to get he benefit of both.  Campatibility and
> simplicity from CDF and the rich data model from HDF5.

I should mention that, when all compile time features are enabled, GDL
wants both the HDF4 and HDF5 libraries.

> > The two easiest solutions to this problem is to either replace every
> > instance of <netcdf.h> in GDL by "/usr/include/netcdf.h" (after which
> > everything compiles fine) or to hack the Makefiles to remove the HDF
> > directory from the include path for the few source files that cause
> > problems. However, given that there is at least one application that
> > encounters this problem, does it make sense to try to fix this at the
> > level of the packaging of netcdfg-dev? For instance, GDL itself tries
> > to look for NetCDF headers in /usr/include/netcdf-3.
>
> That would result in a loss to use the improved data functionality of
> HDF5.

I'm not sure what you mean here. Under optimal circumstances, GDL
wants to use all of NetCDF-3, HDF4, and HDF5. My question was whether
the it is best to fix the above problem by patching the GDL source or
changing the location of header files in netcdfg-dev.

Igor