Comments on building GrADS from source

[Tom Pollard]

Hi,

On Oct 26, 2005, at 8:53 PM, Len Makin wrote:
> Thanks, but prefer not to have to keep old versions of libraries
> about.
> As I indicated, with the one simple change, all compiled and linked
> OK,
> and our users are happily using the installed GrADS, so I'm happy with
> gd 2.... (and grads).
>
>> I don't know what SuSe and Fedora have in common, but you might
>> want to
>> try Pat Dumas's version of the auto-configure system (recently posted
>> to gradsusr) and see how it works with version 1.7.3 of the gd
>> library.
>>
> I have tried the version recently announced from
> http://www.environnement.ens.fr/docs/fc-srpms/grads-1.9b4.tar.gz
> but the new configure tests are now too strict. configure no longer
> finds my version of udunits, even though the CPPFLAGS and LDFLAGS had
> the appropriate  -I/tools/udunits -L/tools/udunits settings. Your
> original configure worked fine, detecting the non-standard
> locations via
> these FLAGS.
>
> My comment for Patrice would be to let the FLAGS be part of the
> environment for the testing rather than enforce fixed ideas on where
> things should be. Maybe that's what he intends anyway? He has
> implemented configure options allowing the specification of non-
> standard
> locations for hdf4 and netcdf (Applause!), but not for udunits. If the
> FLAGS were checked, perhaps none of these would be necessary in my
> case.
> In the general case, we probably need another option to specify
> configure  --with-udunits=<location>
> YMMV.

I have to agree.  I've never seen a project that used 'configure' in
this strange way.  The whole point of configure is to define the
requirements for a job in a flexible way, so that it works naturally
for new platforms and system configurations.  If a library is
required, it should only matter that it's there at link time (and
that its headers are there at compile time); it should not matter
what directory it's in.


> The supplibs thing seems to be unusual among the packages I have
> built/installed. Usually there is just some sort of list of pre-
> requisites, saying something like:
> Needs libxxx version 99 or greater
>       libyyy version 555 or greater
> It seems to be rare to find a pre-requisite for an older (obsolete?)
> version of something, and even rarer (but very thoughtful) if such
> older
> versions are supplied with the package. I guess HDF did similar things
> for netcdf.

That's not so rare, really.  That's why Linux distributions ship with
compatibility packages for older versions of glibc, for instance.
What's unusual is that the dependent libraries are handled in such a
rigid way.


I'm still trying to complete a source build of grads 1.9b4 from
scratch on a MacOSX 10.4 system, using gcc 4.0 and g95.  I think I've
finally collected all of the sources for the dependent libraries
(except for the one that provides freq.h) , but I'm currently stuck
on a problem in the build of HDF4...  If I ever get this to succeed,
I wanted to take a shot at redoing the configure system so that it
would accommodate from-scratch builds like this, and register the
various libraries with DarwinPorts.  But, it's a spare-time project
and progress has been slow (if steady).



Tom