[Opengrads-devel] the build environment

[Jennifer A. <jm...@co...>]

On May 12, 2008, at 4:03 PM, Arlindo da Silva wrote:

> On Mon, May 12, 2008 at 2:24 PM, Jennifer Adams <jm...@co...>  
> wrote:
> Mods to the build system are on my list of important things to work  
> on, but they have been trumped by my list of urgent things to do  
> right away. I will rework the build scripts when we add geotiff and  
> shapefile output.
>
> I am sure you realize that both Pat and myself have spent a lot of  
> time reworking the GrADS build scripts
Yes, of course I have no intention of starting from scratch.

> for v1.9 and more recently adapted it for v2. We don't claim that  
> what is on the OpenGrADS repo is perfect but it is a pretty good  
> start.  Some of the small changes we made to the v2 codebase were  
> made to support the new build, and to fix some potentially hard to  
> find bugs (for example, "grads.h" no longer includes "netcdf.h").
Why is that a bug?

I know it still needs work, but it's still in alpha, after all. There  
were a lot of nits to pick when merging gradsc, gradsnc, and  
gradshdf, and all of the flags set in config.h and the #IFDEF  
statements in the code do not work perfectly. For example, I just  
discovered that if you have DAP libs but not netcdf, it doesn't set  
the USESDF flag.

> So, keep in touch we will be glad to help out with whatever we can.

My impression is that that working on mods to the current configure  
system is a bit like building up a house of cards -- the foundation  
is a bit shaky and not perfectly designed. Maybe GrADS should  
configure more like other packages do... something like this:
     ./configure --with-hdf=/the/path/where/hdf/is/installed --with- 
grib2=/the/path/where/grib2/libs/are

The problem with the "--with-feature" option is that features like  
grib2 needs more than one library, and some of the features have  
overlapping library needs (png, jpeg, zlib, et al). And it just  
doesn't seem practical to put --with-<libname> for each and every  
library you need. Users can't be bothered with that level of detail,  
and even I get a little annoyed if I have to use a lot of options on  
configure. On the Mac, there are packages like fink and MacPorts that  
install libraries effortlessly in places like /opt/local/ (linux has  
yum and other similar easy ways to install stuff), and I'd like to  
take advantage of that with the -enable-dynamic-supplibs. But many of  
the library packages don't install the include files with a named  
subdirectory under include  (such as $SUPPLIBS/include/hdf/ ) so then  
I have to consider differences in configuring HDF if I'm using a non- 
GrADS customized installation or a user-configured one. Then I end up  
in the usual place -- putting the whole messy business on the back  
burner while I work on something more urgent.

Incidentally, I found the opengrads supplibs tarball hard to use -- I  
tried it with an ubuntu build environment and it was a BIG file to  
download, and it took hours to configure/make everything, and then it  
didn't build everything flawlessly "out of the box." After that, it  
was hard to figure out how to just use some of the libs, and then  
they didn't work when trying to link with GrADS. I had to rerun  
configure with manual options on a few occasions. Will have to get  
back to that problem because it will be easier to put out a ubuntu  
binary distro than walk users through building from source on that OS.

As Hoop would say, %}
--Jennifer