Comments on building GrADS from source

[Jennifer Adams]

I never thought an email thread about auto-configure systems would make
me feel warm and fuzzy inside, but it has been a cruel and lonely
business trying to compile and link GrADS and its required libraries on
all the unix flavors and it comforts me to find out there are others
out there fighting the same battles.

Re: gd
(just a warning -- not fatal) I don't know exactly what it is (will
have to consult with Brian), but there is a mod in that old version of
the gd library that GrADS needed for some reason. So, although
commenting out some chunk of code made the SuSe build work with gd 2,
there may be a problem down the line when actually using the GrADS
executable. I will try to track down that old mod in the library and
see if we can modernize. It may have been related to the gif
compression patent.

Re: udunits
I believe there are some specific tests in the configure system for
udunits -- when checking which of the executables can be built. One of
the things I have been working on lately is a remedy to the gregorian
vs. 365-day calendar problem when using udunits to determine the
initial time for self-describing files. Time metadata is so painful to
manage, I want to leverage off of what's already been coded in the
library, but I also need to modify a few of those routines so I can do
some conversions assuming no leap years. That means I'm headed down the
same path that we took with gd, which is likely to cause a serious snag
in the auto-configure business when udunits may be already installed
but the GrADS-specific udunits is what's needed. What is the best
solution? The easy option (for me) is to have sdfopen refuse to open a
file that has a time:calendar attribute of "noleap" or
"365_day_calendar" and force the user to provide the correct TDEF
information in a descriptor file (xdf or dtype netcdf).

Re: GrADS configure system vs. "other" packages
GrADS's dependence on supplibs cannot be avoided, unless you're willing
to work in a fairly limited way with binary or grib data. The current
build system is a first stab, and almost certainly was influenced by
the setup we were using before the autoconf system came along. I think
a discussion like this one is incredibly valuable, as are the proposed
changes submitted by the members of the community who know more about
this than anyone at COLA. I am perfectly willing to adopt what you guys
agree is a better system, as long as it works for the unix operating
systems that we need to build on. All I really want is to be able to
untar, configure, make, install, and execute.  I think the autoconf
stuff has to work smoothly so more users can easily build from source
-- we simply can't provide enough pre-compiled binaries that will work
universally anymore, especially for linux.

Re:  Building on a MacOSX 10.4 system, using gcc 4.0 and g95
I struggled with this for a long time; it made me sorely regret
upgrading to Tiger on my laptop. Had a breakthrough not too long ago.
It should not be necessary for you to build everything from scratch.
You should be able to build/link with the compiled supplibs that we
distribute that were built in the pre-panther days (can't even remember
what name that was...) Grab this tarfile:

ftp://grads.iges.org/grads/Supplibs/1.9/grads-1.9b3-supplibs-
darwin6.8.tar.gz
With these supplibs, the only thing I needed to do was add:
   # include <fcntl.h>
to grads.h -- this somehow allowed the compiler to know what to do with
the off_t declarations. I have no idea why -- just a little bit of
magic that google provided. See if that helps.

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