Re: [Opengrads-devel] the build environment

[Patrice D. <per...@fr...>]

On Mon, May 12, 2008 at 06:26:45PM -0400, Jennifer Adams wrote:
>
> 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

It is already done that way with --enable-dyn-supplibs for some selected
packages (for example, in m4/hdf4.m4 you can see --with-hdf4, 
--with-hdf4-include, --with-hdf4-libdir). These could certainly be
consolidated with the --with-* options that select features (by doing
something specific when --with-hdf4=no or --without-hdf4 has been
specified).

But this is not the hard part, the hard part is automatic system library 
detection.

But what is the precise issue with the current configure system (in
opengrads, be it 1.9 or 2.0)? The 2 issues I see is that it is somewhat 
double, since there is the part that corresponds with supplibs (without
--enable-dyn-supplibs) and the part allowing for system library detection
(with --enable-dyn-supplibs), and also, as you said above, that --with-* 
should be used consistently. However, I think that the fact that it is
double is not an issue in my opinion, the supplibs part is quite simple,
I rewrote from scratch most of the part with --enable-dyn-supplibs in a 
more traditional autoconf macro style.

The consolidation of --with-* options could involve a bit of work, but
nothing problematic (read, I could do it ;-). The complex part, which is 
system library detection is already done.

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

It should not be useful in the default case, but allow to override what
is autodetected. And this should not be needed for all the library, only
those that are often in non system places, since it is always possible
to override LDFLAGS and CPPFLAGS (or the corresponding pkgconfig
variables).

In the current m4 macros, there is --with-hdf4, --with-hdf4-include,
--with-hdf4-libdir, --with-dods-root, --with-netcdf,
--with-netcdf-include, --with-netcdf-libdir. For most libs, LDFLAGS and
CPPFLAGS should be set. But the other libs are more traditional system
libs, and libdap which has it own config system and use pkgconfig.

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

That are 2 different subjects. One is packaging (fink and yum). The
other is library detection (with -enable-dynamic-supplibs). The
packaging part is not really a relevant target, you should just make sure
that packaging is easy. But the library detection is clearly in the
scope of 'upstream' grads.

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

Normally I have already done all that (when --enable-dyn-supplibs is
set), that is, autoconf m4 files for library detection, that can be 
overriden with --with-* options, for some of these, and setting LDFLAGS 
and CPPFLAGS for the others. Maybe you could try this system for the most 
standard setting you use and report if it has limitations?

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

It is not surprising to me. Portability on a given platform requires trying, 
testing and adapting for that platform. Even the most general autoconf
macros need to be adapted when a software is ported to a new platform,
and it is true with static supplibs and with --enable-dyn-supplibs.

--
Pat