Comments on building GrADS from source

[Jennifer Adams]

Dear All --
Building GrADS from source has always been a bit of a headache. The
core of GrADS is in ANSI C, which means you ought to be able to compile
gradsc without any features using only the code in the src tarball and
gcc. The complications come when you start adding features, such as
readline and printim, and data formats such netCDF and HDF. The icing
on the cake is OPeNDAP, and the cherry on top is getting station data
via OPeNDAP. Adding each of these features means compiling some 3rd
party libraries, and linking them with GrADS code in various
combinations. Thus was born the term "supplibs" which refers to the
supplemental libraries that are required to build fully-featured GrADS
executables. There is a set of src tarballs for the supplibs on the
COLA FTP server:
     ftp://grads.iges.org/grads/Supplibs/1.8/src/
     ftp://grads.iges.org/grads/Supplibs/1.9/src/
Some of these are old versions that are known to work with GrADS. In
some cases (libgd comes to mind) there were some modifications to the
library source code, and (I think) only the version posted at the above
location will work. To try to organize the supplibs, a secondary
directory tree was set up alongside the src tree that contains only the
the ./lib/*.a  and ./include/*.h files from the libraries. With the
supplibs tree, it was only necessary to look in one place for all the
extra stuff when setting up the Makefile.

Next came the autoconf era, when the subblib tree was reorganized and
the business of building a Makefile was "simplified" (at least for the
user). Since that time, the programmer who wrote all the autoconf code
has left COLA, and the management of the GrADS source code (autoconf
and everything else) is handled on an extreme part-time basis by me. I
welcome patches from the user community; those relating to the build
system are particularly welcome since I don't know much about autoconf.
I do what I can to explore and implement these patches as time allows,
but progress is slow. We have no Development of GrADS is discussed
primarily in this forum, but we also maintain a GForge site for posting
patches and bug reports (gforge.iges.org); unfortunately, its IP
address (192.239.84.22) resolves to an incorrect domain and so it is
necessary to edit your local /etc/hosts file in order to reach the
website.

As for the future, changes to the supplibs are becoming impossible to
avoid and these will affect the build system significantly. I am
planning to start testing OPeNDAP 3.5, which means libcurl and libxml2
have to be added to the supplib fold and libwww (which was included in
the DODS 3.2 release, but may have originally come from www.w3.org)
will be given the pink slip. I also want to use the latest version of
the NetCDF library which has large (>2GB) file support. The newer
version of libgd that supports anti-aliasing is also on our shopping
list. And there's a grib2 library that we will probably have to include
as well.

On some linux flavors, many of the supplibs already exist as part of
the standard operating system -- my current inclination is to copy
these to the supplibs location (or use soft links), rather than rewrite
autoconf macros to hunt them down all over the local system disk
partitions, but maybe software like libtool is really the answer ... at
this point I don't have time to weigh all the options; I am overcome by
the inertia associated with sticking with the current method.

I know many of you have been wondering about a windows build.... Here
at COLA we are gradually phasing out MS Windows desktop systems and
moving to Mac OSX and linux. Since our primary responsibility is to
support COLA's operations, it is unlikely that we will find the time to
work on a Windows build any time soon.

Jennifer

--
Jennifer Miletta Adams
Center for Ocean-Land-Atmosphere Studies (COLA)
4041 Powder Mill Road, Suite 302
Calverton, MD 20705 USA
jma at cola.iges.org