Comments on building GrADS from source

[Matthias Munnich]

Jennifer Adams wrote:

>
> 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.

I think it's fine.  AFAIK, there are no mods in the library. What
Brian did is re-implement 2 of the gd routines in gxhpng.c.  He
modified there names so everything should work as long as the API of GD
hasn't changed.

>
> 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).

The simple solution sounds fine with me, at least until someone has
more time to put into this.
Have GrADS spit out  good info in the error message letting  people
know they can still may be able to work with these files if they write
a  descriptor file and everybody should be reasonably happy.

>
> 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.

One problem is that at the time the autoconfigure scripts were
written, the goal was to simplify the building of  the GrADS binaries
that COLA was distributing. Using autoconf to ease the built of local
dynamic version  wasn't the focus. This was before the GrADS was GPLed.

This is why static builds are the default and why we have the supplibs
and not a list of dynamic libraries that need to be installed prior to
building GrADS.  As you may remember I was suggesting to use dynamic
builds and a wrapper script to set the library search path.  Most
developers didn't like the idea and I never  proceeded in this
direction.

With the shift towards source distribution and local builds the
configure script seems to need an overhaul. Luckily we now have Pat
and others on board who  know more about the auto-tools that we did.
Most likely, Pat will  even supply us with and rpm setup!

Matt