Comments on building GrADS from source

[Don Hooper]

Jennifer,

GrADS always has used a custom version of udunits for the static builds.
This small mod caused it to look in $GADDIR for udunits.dat by default,
rather than some fixed path.  This made the static builds work on sites
that had no udunits, let alone udunits.dat in the "expected" place.  Hence,
udunits.dat is in the data tarball distributed with GrADS, just like the
fonts.  So, it wouldn't be terribly precedent-setting to include a
further-customized version of udunits with GrADS.  Granted, I don't envy
you the programming task, but....  %}  I, for one, would raise no objections
to your "easiest" solution.

-Hoop
> From owner-gradsusr at LIST.CINECA.IT  Thu Oct 27 09:15:52 2005
> From: Jennifer Adams <jma at COLA.IGES.ORG>
>
> 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