suggestion for the autoconf configuration

[Xiouhua Fu]

c-------------------------------------------------c
Dr. Xiouhua (Joshua) Fu
International Pacific Research Center (IPRC)
SOEST, University of Hawaii at Manoa
1680 East West Rd., POST Bldg., 4th Floor
Honolulu, HI 96822
Tel: (808) 956-2629, Fax: (808) 956-9425
Web: <http://www.soest.hawaii.edu/~xfu>
=============================================

----- Original Message -----
From: "Richard A. Ryan" <Richard.A.Ryan at noaa.gov>
Date: Thursday, September 15, 2005 6:27 am
Subject: Re: suggestion for the autoconf configuration

> Hi,
>
> I know this isn't directly related to what you wrote here,
> but your mention of macros did remind of this recommendation
> from the automake manual.  It's in the ``Local Macros'' node
> of automake.info.  It recommends against using acinclude.m4
> for storing macros.  This is only a small excerpt, what
> follows in the manual is recommended reading.
>
> ### BEGIN EXCERPT{(automake.info)Local Macros}
>
>   There are two ways to organize custom macros in a package.
>
>   The first possibility (the historical practice) is to list all your
> macros in `acinclude.m4'.  This file will be included in `aclocal.m4'
> when you run `aclocal', and its macro(s) will henceforth be
> visible to
> `autoconf'.  However if it contains numerous macros, it will rapidly
> become difficult to maintain, and it will be almost impossible to
> sharemacros between packages.
>
>   The second possibility, which we do recommend, is to write each
> macroin its own file and gather all these files in a directory.  This
> directory is usually called `m4/'.  To build `aclocal.m4', one should
> therefore instruct `aclocal' to scan `m4/'.  From the command line,
> this is done with `aclocal -I m4'.  The top-level `Makefile.am'
should
> also be updated to define
>
>      ACLOCAL_AMFLAGS = -I m4
>
> ### END EXCERPT{(automake.info)Local Macros}
>
> If you're planning on maintaining a large number of macros,
> this approach makes sense.  It's easy to write new macros.
> Maintaining them is not so easy.  When understanding or
> debugging the existing software becomes difficult, the
> common practice is to ignore the old and just write
> something new to add to what's already there.  A good
> maintenance strategy should make it easier to reuse and
> repair existing code and reduce redundancy.
>
> Richard Ryan
>
>
> Patrice Dumas wrote:
> > On Wed, Sep 14, 2005 at 02:58:06PM -0600, Richard A. Ryan wrote:
> >
> >>Hello,
> >>
> >>   libwww-config --libs
> >>
> >>instead.  Similarly, you're going to want to get the
> >>include files for libwww from
> >>
> >>   libwww-config --cflags
> >
> >
> > This is only needed if you want to build with opendap support?
> Regarding> opendap support and detection in configure.in, I send
> patches and .m4
> > files to the list you should want to have a look at. I would be
> pleased> if somebody could enhance those files to cope with older
> releases of
> > opendap/DODS, especially the pre opendap-3.4 releases that
> required libwww
> > and librx. I canot do that myself as I only have new versions
> and therefore
> > cannot test.
> >
> >
> >>I am thinking of trying to simplify the grads build
> >>configuration myself.  If I can set up another configure for
> >>the grads client, is anyone out there interested in getting
> >>the new configuration files, and in particular, maintaining
> >>it?  To be honest, I'm not sure I'm going to be able to do
> >>this.
> >
> >
> > I made an autoconf macro for the detection of netcdf. I attach
> it to
> > that mail. At the beginning there is an example of use in
> comments. It
> > could be enhanced with use of ac_cache...
> >
> > Overall I agree that the configure.in of grads could be improved
> a lot,
> > by doing more elaborate macros for the detection of features
> with the
> > ability to detect more than one configuration, instead of
> rewriting the
> > tests in each GA_ macros. This is especially true for udunits,
> libz and
> > netcdf. For example I posted a patch for libsx detection but it is
> > a bit convoluted due to this lack of separation.
> >
> > I could also contribute to that, but I can't really understand
> how the
> > development of grads proceeds. I don't see where development is
> discussed,> where the development sources are, how to submit
> changes nor who approve
> > them and how and I couldn't find such information on the web
> (maybe I
> > didn't searched at the right place?). So far all my mails regarding
> > development seem to have been ignored (at least on the mailing
> list).>
> > --
> > Pat
> >
> >
> > -----------------------------------------------------------------
> -------
> >
> > dnl example of use
> > dnl AC_CHECK_NETCDF(
> > dnl   [
> > dnl       LIBS="$LIBS $NC_LIBS"
> > dnl       LDFLAGS="$LDFLAGS $NC_LDFLAGS"
> > dnl       CPPFLAGS="$CPPFLAGS $NC_CPPFLAGS"
> > dnl   ],
> > dnl   [
> > dnl       echo "*** Use --with-netcdf for the root netcdf
> directory."> dnl       echo "*** Otherwise use --with-netcdf-
> include switch for includes directory"
> > dnl       echo "*** and --with-netcdf-libdir switch for
> libraries directory."
> > dnl       AC_MSG_ERROR([netcdf library and netcdf headers are
> required.])> dnl   ]
> > dnl )
> >
> > dnl Check for the netcdf library.
> > AC_DEFUN([AC_CHECK_NETCDF],
> > [
> > AC_ARG_WITH([netcdf],
> >             [AS_HELP_STRING([--with-netcdf=ARG],[netcdf
> directory])],>             [NC_PATH=${withval}],
> >             [NC_PATH="/usr/local/netcdf"])
> >
> > AC_ARG_WITH([netcdf_inc],
> >             [AS_HELP_STRING([--with-netcdf-include=ARG],[netcdf
> include directory])],
> >             [NC_PATH_INC=${withval}],
> >             [NC_PATH_INC=""])
> >
> > AC_ARG_WITH([netcdf_libdir],
> >             [AS_HELP_STRING([--with-netcdf-libdir=ARG],[netcdf
> library directory])],
> >             [NC_PATH_LIBDIR=${withval}],
> >             [NC_PATH_LIBDIR=""])
> >
> >
> >
> > AS_IF([test "z$NC_PATH_LIBDIR" =
> "z"],[NC_PATH_LIBDIR="$NC_PATH/lib"])>
> > AS_IF([test "z$NC_PATH_INC" = "z"],
[NC_PATH_INC="$NC_PATH/include"])
> >
> > ac_netcdf_ok='no'
> >
> > NC_LIBS=
> > NC_LDFLAGS=
> > ac_nc_save_LDFLAGS="$LDFLAGS"
> > ac_nc_save_LIBS="$LIBS"
> > LIBS="$LIBS -lnetcdf"
> > LDFLAGS="$LDFLAGS -L${NC_PATH_LIBDIR}"
> > AC_CHECK_LIB([netcdf],[nc_open],
> >    [
> >      ac_netcdf_ok='yes'
> >      NC_LIBS="-lnetcdf"
> >      NC_LDFLAGS="-L${NC_PATH_LIBDIR}"
> >    ],
> >    [ac_netcdf_ok='no']
> > )
> > LIBS="$ac_nc_save_LIBS"
> > LDFLAGS="$ac_nc_save_LDFLAGS"
> >
> > AC_SUBST([NC_LDFLAGS])
> > AC_SUBST([NC_LIBS])
> >
> > NC_CPPFLAGS=
> > ac_netcdf_h='no'
> > ac_nc_save_CPPFLAGS="$CPPFLAGS"
> > CPPFLAGS="$CPPFLAGS -I$NC_PATH_INC"
> > AC_CHECK_HEADERS([netcdf.h],
> >   [ac_netcdf_h='yes'],
> >   [ac_netcdf_h='no']
> > )
> > CPPFLAGS=$ac_nc_save_CPPFLAGS
> >
> > AS_IF([test "$ac_netcdf_h" = 'yes' ],
> >   [NC_CPPFLAGS="-I$NC_PATH_INC"]
> > )
> > AC_SUBST([NC_CPPFLAGS])
> >
> > AS_IF([test "$ac_netcdf_ok" = 'no' -o "$ac_netcdf_h" = 'no'],
> >   [m4_if([$2], [], [:], [$2])],
> >   [m4_if([$1], [], [:], [$1])]
> > )
> >
> > ])
> >
>