Re: [Opengrads-devel] the build environment

[Arlindo da S. <da...@al...>]

On Mon, May 12, 2008 at 6:26 PM, Jennifer Adams <jm...@co...> wrote:

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

The problem is that both "grads" and "gradsdap" link against the same
"grads.o". So, you end up linking "gradsdap" with something that was
compiled with the wrong "netcdf.h" (the one from the NetCDF library, rather
than the one from nc-dap). Since both versions of "netcdf.h" currently in
use are very similar, I have no evidence that your v2 build has a problem.
However, we've been bitten by this netcdf.h mismatch issue several times in
the past that it pays to play it save.



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

I see Pat already answered this one.


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

Although I set out to do just that, I never that the supplibs build "out of
the box" on all platforms. However, once properly built, grads itself builds
"out of the box" with the pre-compiled supplibs.


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

You should have asked for help. We keep a section on the wiki for "Platform
Specific Notes". Which configure did you have to manually rerun, ours or
yours?


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

I am surprised by your experience, I build on Ubuntu all the time with the
pre-compiled supplibs, for both i686 and x86_64.  Even when the generic
GrADS binaries for these platforms do not work, building against the static
supplibs usually does the trick.  Just yesterday, I built v2.0.a2.oga.1 on
the latest Ubuntu 8.04 "out of the box" using the stock supplibs-2.0.1 for
x86_64 (which were built on Mandriva), and the binaries passed 100% of the
tests.

I have had a very good experience with the binaries for v1.9.0-rc1 (even for
Windows if you discount the initial configuration glitches). The i686
binaries seem very robust, running fine on x86_64, and even IA64. The x86_64
binaries are a bit less portable, but as I said before, building against the
pre-compiled supplibs is all that it takes. My experience building v2 with
our build scripts seems to indicate that these binaries behave similarly,
although I have not distributed my v2 binaries to a wider audience (you are
welcome to distribute these binaries if you wish.)

BTW, about half of our 1.9.0-rc1 downloads are for Windows. I suspect that a
v2 build for Win 32 would be well received. I'll be glad to contribute a
build but it would make my life a lot simpler if we could reconcile the
build scripts, and have the windows specific code maintained along with
COLA's codebase, as we used to do in the past.

    Arlindo


-- 
Arlindo da Silva
da...@al...