Menu
▾
▴
opengrads-devel
|
From: Arlindo da S. <da...@al...> - 2008-05-11 22:41:54
|
All,
I have just merged and checked in COLA's latest release. As before, none
of our patches have made to the COLA release, it is does not build
transparently with the supplibs-2.0.1. In addition to the merge, I have
implemented a couple of small enhancements to "fwrite" to allow me to better
interface GrADS v2 to python/perl, although the patch to enable fwrite to
work with named pipes (FIFOs) may be of general interest. I also added a set
of Grib-2 specific tests to pytests. See ChangeLog below for details.
To check out this version:
% gacvs co -P -r grads-2_0_a2-oga-1
It builds out of the box with the supplibs-2.0.1.
Jennifer, as always, you are more than welcome to incorporate these patches
to your codebase if you are interested.
Cheers!
Arlindo
>From the ChangeLog:
2008-05-10 <da...@op...>, Version GrADS 2.0.a2.oga.1
* merged GRADS2_DEV_BRANCH with COLA's v2.0.a2.
* From COLAS e-mail annoucing v2.0.a2:
Features:
* ready for use with GDS-2.0 to access 5-dimensional data
sets via OPeNDAP
* support for thinned grib2 grids
* gribmap has -0 option for grib2
* allows non-float data types for hdf coordinate axes
Bug Fixes:
* memory leak when replacing an existing defined variable
* multiple fixes for netcdf/hdf handling (templating,
zrev, %nodim%, et al.)
* contour interval and label handling for double precision
numbers
* changed 'query dims' output for ensembles
* fixed gribmap's handling of data sets templated over T but not
E
* fixed 'set annot' command and other minor bugs
* Added Grib-2 specific tests to pytests/
* src/gagx.c: Enhancements to fwrite in function gafwrt():
* When fwrite output file name is "-" output is sent to STDOUT
* Now uses stat() rather fopen(...,"r") to check is the file
already
exists. This is important for using fwrite on FIFOs - a
deadlock
occurs if a FIFO is opened for both read/write by a process.
---------- Forwarded message ----------
From: Jennifer Adams <jm...@co...>
Date: Fri, May 2, 2008 at 12:40 PM
Subject: NEW RELEASE of GrADS 2.0.a2
To: GRA...@li...
Dear All,I have posted a new version of GrADS: 2.0.a2. This version has
several new features and important bug fixes. The GrADS downloads web page (
http://iges.org/grads/downloads.html) has also been updated with links to
the source code and two binary releases (more binaries to follow as soon as
possible).
Features:
* ready for use with GDS-2.0 to access 5-dimensional data sets via
OPeNDAP
* support for thinned grib2 grids
* gribmap has -0 option for grib2
* allows non-float data types for hdf coordinate axes
Bug Fixes:
* memory leak when replacing an existing defined variable
* multiple fixes for netcdf/hdf handling (templating, zrev, %nodim%, et
al.)
* contour interval and label handling for double precision numbers
* changed 'query dims' output for ensembles
* fixed gribmap's handling of data sets templated over T but not E
* fixed 'set annot' command and other minor bugs
This release is a companion for GDS 2.0, which can now serve 5-D data sets.
COLA is running a 2nd GDS for testing on port 9191 that is serving
everything on the 9090 server plus GFS ensemble forecasts. Check 'em out at
http://monsoondata.org:9191/dods/gfsens/
A public release of GDS 2.0 is forthcoming -- we are still testing. If you'd
like to help, please try using the 9191 server.
Please post comments and questions and bug reports here (low-tech bug
tracking is still in use at COLA). As always, I must be able to reproduce a
problem on my own systems in order to fix it, so keep that in mind when
reporting bugs.
Jennifer
--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...
--
Arlindo da Silva
da...@al...
|
|
From: Jennifer A. <jm...@co...> - 2008-05-12 18:24:39
|
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. Jennifer On May 11, 2008, at 6:42 PM, Arlindo da Silva wrote: > All, > > I have just merged and checked in COLA's latest release. As > before, none of our patches have made to the COLA release, it is > does not build transparently with the supplibs-2.0.1. In addition > to the merge, I have implemented a couple of small enhancements to > "fwrite" to allow me to better interface GrADS v2 to python/perl, > although the patch to enable fwrite to work with named pipes > (FIFOs) may be of general interest. I also added a set of Grib-2 > specific tests to pytests. See ChangeLog below for details. > > To check out this version: > > % gacvs co -P -r grads-2_0_a2-oga-1 > > It builds out of the box with the supplibs-2.0.1. > > Jennifer, as always, you are more than welcome to incorporate > these patches to your codebase if you are interested. > > Cheers! > > Arlindo > > From the ChangeLog: > > 2008-05-10 <da...@op...>, Version GrADS 2.0.a2.oga.1 > * merged GRADS2_DEV_BRANCH with COLA's v2.0.a2. > * From COLAS e-mail annoucing v2.0.a2: > Features: > * ready for use with GDS-2.0 to access 5-dimensional data > sets via OPeNDAP > * support for thinned grib2 grids > * gribmap has -0 option for grib2 > * allows non-float data types for hdf coordinate axes > Bug Fixes: > * memory leak when replacing an existing defined variable > * multiple fixes for netcdf/hdf handling (templating, > zrev, %nodim%, et al.) > * contour interval and label handling for double > precision numbers > * changed 'query dims' output for ensembles > * fixed gribmap's handling of data sets templated over > T but not E > * fixed 'set annot' command and other minor bugs > * Added Grib-2 specific tests to pytests/ > * src/gagx.c: Enhancements to fwrite in function gafwrt(): > * When fwrite output file name is "-" output is sent to > STDOUT > * Now uses stat() rather fopen(...,"r") to check is the > file already > exists. This is important for using fwrite on FIFOs > - a deadlock > occurs if a FIFO is opened for both read/write by a > process. > > ---------- Forwarded message ---------- > From: Jennifer Adams <jm...@co...> > Date: Fri, May 2, 2008 at 12:40 PM > Subject: NEW RELEASE of GrADS 2.0.a2 > To: GRA...@li... > > > Dear All, > I have posted a new version of GrADS: 2.0.a2. This version has > several new features and important bug fixes. The GrADS downloads > web page (http://iges.org/grads/downloads.html) has also been > updated with links to the source code and two binary releases (more > binaries to follow as soon as possible). > > Features: > * ready for use with GDS-2.0 to access 5-dimensional data sets > via OPeNDAP > * support for thinned grib2 grids > * gribmap has -0 option for grib2 > * allows non-float data types for hdf coordinate axes > > Bug Fixes: > * memory leak when replacing an existing defined variable > * multiple fixes for netcdf/hdf handling (templating, zrev, % > nodim%, et al.) > * contour interval and label handling for double precision numbers > * changed 'query dims' output for ensembles > * fixed gribmap's handling of data sets templated over T but not E > * fixed 'set annot' command and other minor bugs > > This release is a companion for GDS 2.0, which can now serve 5-D > data sets. COLA is running a 2nd GDS for testing on port 9191 that > is serving everything on the 9090 server plus GFS ensemble > forecasts. Check 'em out at > http://monsoondata.org:9191/dods/gfsens/ > A public release of GDS 2.0 is forthcoming -- we are still testing. > If you'd like to help, please try using the 9191 server. > > Please post comments and questions and bug reports here (low-tech > bug tracking is still in use at COLA). As always, I must be able to > reproduce a problem on my own systems in order to fix it, so keep > that in mind when reporting bugs. > > Jennifer > > -- > Jennifer M. Adams > IGES/COLA > 4041 Powder Mill Road, Suite 302 > Calverton, MD 20705 > jm...@co... > > > > > > > -- > Arlindo da Silva > da...@al... > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save > $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http:// > java.sun.com/javaone_______________________________________________ > Opengrads-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengrads-devel -- Jennifer M. Adams IGES/COLA 4041 Powder Mill Road, Suite 302 Calverton, MD 20705 jm...@co... |
|
From: Arlindo da S. <da...@al...> - 2008-05-12 20:03:01
|
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 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").
So, keep in touch we will be glad to help out with whatever we can.
Best Regards,
Arlindo
--
Arlindo da Silva
da...@al...
|
|
From: Jennifer A. <jm...@co...> - 2008-05-12 22:26:46
|
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
|
|
From: Patrice D. <per...@fr...> - 2008-05-12 23:59:47
|
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 |
|
From: Arlindo da S. <da...@al...> - 2008-05-13 03:29:37
|
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...
|
|
From: Jennifer A. <jm...@co...> - 2008-05-14 16:09:47
|
I think the opengrads-devel list needs a "Reply-To:" header when it sends out messages. I sent the following as a 'reply' but it only went to Arlindo... --Jennifer Begin forwarded message: From: Jennifer Adams <jm...@co...> Date: May 14, 2008 11:47:36 AM EDT To: Arlindo da Silva <da...@al...> Subject: Re: [Opengrads-devel] the build environment On May 12, 2008, at 11:29 PM, Arlindo da Silva wrote: > 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. Why should grads.o be different for grads and gradsdap? There are no netcdf dependent calls in there. All the netcdf library calls are in gasdf.c, gaio.c and gauser.c -- these three files have: #include netcdf.h and have separate .o files when linking grads and gradsdap. The other .o files that are separated for the two executables are gaddes and gacfg because there are some netcdf dependencies there but no calls to the library. Jennifer |
|
From: Arlindo da S. <da...@al...> - 2008-05-14 18:50:06
|
On Wed, May 14, 2008 at 12:09 PM, Jennifer Adams <jm...@co...> wrote: > I think the opengrads-devel list needs a "Reply-To:" header when it sends > out messages. I sent the following as a 'reply' but it only went to > Arlindo... > This is a good idea. I need to learn how to configure mailman at sf.net. Does anybody know? -- Arlindo da Silva da...@al... |
|
From: Arlindo da S. <da...@al...> - 2008-05-15 00:25:36
|
On Wed, May 14, 2008 at 12:09 PM, Jennifer Adams <jm...@co...> wrote: > I think the opengrads-devel list needs a "Reply-To:" header when it sends > out messages. I sent the following as a 'reply' but it only went to > Arlindo... > For consistency with gradsusr, I just updated the opengrads-devel list so that the "reply to" defaults to the list. For some reason, sf.netdiscourages people from setting up the lists this way. Arlindo -- Arlindo da Silva da...@al... |
|
From: Arlindo da S. <da...@al...> - 2008-05-14 18:47:38
|
On Wed, May 14, 2008 at 11:47 AM, Jennifer Adams <jm...@co...> wrote:
>
> On May 12, 2008, at 11:29 PM, Arlindo da Silva wrote:
>
> 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.
>
>
> Why should grads.o be different for grads and gradsdap? There are no netcdf
> dependent calls in there. All the netcdf library calls are in gasdf.c,
> gaio.c and gauser.c -- these three files have:
> #include netcdf.h
> and have separate .o files when linking grads and gradsdap. The other .o
> files that are separated for the two executables are gaddes and gacfg
> because there are some netcdf dependencies there but no calls to the
> library.
>
>
Having a separate grads.o would solve this problem, but if we don't watch
soon enough we would having 2 versions of a lot of files (since grads.h is a
very popular header file). My solution was to move all the sdf prototypes
from grads.h to sdf.h, and not include sdf.h at all in grads.h (it is not
needed).
>From an architectural point of view the current approach of adding all
possible prototypes flat in grads.h is somewhat problematic as it violates
"information hiding" and get's in the way of encapsulation. (It would also
creates a configuration management nightmare in an environment with multiple
developers all making changes to grads.h). In principle, only the "public"
functions of a given subpackage (e.g., gasdf) would need its prototype
broadcast through "grads.h". Internal (read: private) functions and
datatypes should be kept in a separate header file and only included by the
subpackage itself (or at the top of the file as it is done in many places
throughout grads). Even in this case, "grads.h" should *include* the
"public" header files rather than have them all flat in the same file.
Another suggestion. Right now every time a given feature is not compiled in
you get an error message trying to use it:
ga-> printim
Unknown command: printim
something which can be very confusing for a new user. A message like:
This version of GrADS has not been built with "printim" support.
would be more user friendly. One way to achieve this, which is also more
modular and would eliminate all those USE??? scattered through the code,
would be to have each subpackage compiling in a stub when it is not being
USEd. Of course the package API would be unchanged: if the subpackage is not
being used only the subpackage needs to know about it.
The same goes for gasdf.c. If the NetCDF and nc-dap versions have the exact
same API and public header, you only need 2 versions of gasdf.o, all the
rest of the GrADS code (except for gacfg.c) would stay exactly the same.
This kind of encapsulation would simplify the build tremendously, and
ultimately is much easier to maintain.
I hope you don't mind my unsolicited suggestions...
Regards,
Arlindo
--
Arlindo da Silva
da...@al...
|
|
From: Arlindo da S. <da...@al...> - 2008-05-15 01:32:49
|
On Wed, May 14, 2008 at 11:47 AM, Jennifer Adams <jm...@co...> wrote: > > > Why should grads.o be different for grads and gradsdap? There are no netcdf > dependent calls in there. All the netcdf library calls are in gasdf.c, > gaio.c and gauser.c -- these three files have: > #include netcdf.h > and have separate .o files when linking grads and gradsdap. The other .o > files that are separated for the two executables are gaddes and gacfg > because there are some netcdf dependencies there but no calls to the > library. > > Sorry, I didn't quite answer your question last time. As you stated, one only needs a single grads.o as there is no netcdf or sdf calls in there. What makes it confusing is that by including gasdf.h (and indirectly) netcdf.h in grads.c you create a misleading dependency between these 2 files (as far as the build system is concerned there is a dependency: you can't compile grads.c without supplying a netcdf.h). Unless someone examines every line of grads.c it appears that grads.c does depend on netcdf.h. So, technically it is not a "bug" as it has no side effects in today's codebase, but it would be much safer to eliminate the inclusion of netcdf.h in grads.c altogether. My overall point is that by slowly adopting encapsulation and other OO constructs (as it can be done in the constraints of good old C) one could make the grads codebase easier to extend and maintain. At this early stage of development, GrADS v2 still shares the same monolithic architecture o v1. Do you you see it this way? Arlindo -- Arlindo da Silva da...@al... |
|
From: Jennifer A. <jm...@co...> - 2008-07-24 19:11:37
|
Dear All,
I am finally getting around to working on the build environment. I
need help!!!
I have changed the expected directory structure of $supplibs/include/
so now GrADS will look for subdirectories for each library. This led
to me editing configure.in, acinclude.m4, and src/Makefile.am. I am
using the latest opengrads src (2.0.a2.oga.1) as a guide. My approach
is to update things slowly, making sure they work before updating the
next. So, the dynamic-supplib-detection is not in yet. One thing that
is not working is adding the proper include directory for netcdf.h
when compiling grads and gradsdap. This is done with a variable
called nc_include, which is set in configure.in:
use_nc=no
if test "$with_nc" != "no" ; then
echo "Checking netcdf support..."
GA_CHECK_NC([use_nc=yes], {})
fi
if test $use_nc = "yes" ; then
nc_include = "-I\$(supp_include_dir)/netcdf"
AC_SUBST(nc_include)
GA_SET_LIB_VAR(nc_libs, [netcdf udunits])
AC_SUBST(nc_libs)
AC_DEFINE(USESDF, 1, [Enable netcdf])
echo "+ netcdf enabled"
else
AC_DEFINE(USESDF, 0, [Enable netcdf])
echo "- netcdf disabled"
fi
I put the nc_include variable in src/Makefile.am like this:
COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -DUSEGADODS=0
But after running ./bootstrap and ./configure, nc_include is empty in
the Makefile.
Here I grep for it in the top level, and the directories below:
> grep nc_include *
Makefile:nc_include =
Makefile.in:nc_include = @nc_include@
config.log:nc_include=''
config.status:s,@nc_include@,,;t t
configure:ac_subst_vars='SHELL <....snipped...> nc_include
<...snipped...>
configure: nc_include = "-I\$(supp_include_dir)/netcdf"
configure:s,@nc_include@,$nc_include,;t t
configure.in: nc_include = "-I\$(supp_include_dir)/netcdf"
configure.in: AC_SUBST(nc_include)
> grep nc_include */*
autom4te.cache/output.0:ac_subst_vars='SHELL <....snipped...>
nc_include <...snipped...>
autom4te.cache/output.0: nc_include = "-I\$(supp_include_dir)/netcdf"
autom4te.cache/output.0:s,@nc_include@,$nc_include,;t t
autom4te.cache/traces.0:m4trace:configure.in:358: -1- AC_SUBST
([nc_include])
src/Makefile:nc_include =
src/Makefile:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -
DUSEGADODS=0
src/Makefile.am:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -
DUSEGADODS=0
src/Makefile.in:nc_include = @nc_include@
src/Makefile.in:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -
DUSEGADODS=0
What am I doing wrong?
Jennifer
--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...
|
|
From: Jennifer A. <jm...@co...> - 2008-07-24 20:42:39
|
The $nc_include variable is almost exactly like $NC_CFLAGS in the
opengrads build. I renamed it to distinguish it because I added one
more step (the AC_SUBST(nc_include) call). I was trying to reproduce
the behavior of $dap_libs, which is working in my build. Am I
forgetting to add something somewhere?
--Jennifer
On Jul 24, 2008, at 3:11 PM, Jennifer Adams wrote:
> Dear All,
> I am finally getting around to working on the build environment. I
> need help!!!
>
> I have changed the expected directory structure of $supplibs/
> include/ so now GrADS will look for subdirectories for each
> library. This led to me editing configure.in, acinclude.m4, and src/
> Makefile.am. I am using the latest opengrads src (2.0.a2.oga.1) as
> a guide. My approach is to update things slowly, making sure they
> work before updating the next. So, the dynamic-supplib-detection is
> not in yet. One thing that is not working is adding the proper
> include directory for netcdf.h when compiling grads and gradsdap.
> This is done with a variable called nc_include, which is set in
> configure.in:
>
> use_nc=no
> if test "$with_nc" != "no" ; then
> echo "Checking netcdf support..."
> GA_CHECK_NC([use_nc=yes], {})
> fi
> if test $use_nc = "yes" ; then
> nc_include = "-I\$(supp_include_dir)/netcdf"
> AC_SUBST(nc_include)
> GA_SET_LIB_VAR(nc_libs, [netcdf udunits])
> AC_SUBST(nc_libs)
> AC_DEFINE(USESDF, 1, [Enable netcdf])
> echo "+ netcdf enabled"
> else
> AC_DEFINE(USESDF, 0, [Enable netcdf])
> echo "- netcdf disabled"
> fi
>
> I put the nc_include variable in src/Makefile.am like this:
> COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -DUSEGADODS=0
>
> But after running ./bootstrap and ./configure, nc_include is empty
> in the Makefile.
> Here I grep for it in the top level, and the directories below:
>
> > grep nc_include *
> Makefile:nc_include =
> Makefile.in:nc_include = @nc_include@
> config.log:nc_include=''
> config.status:s,@nc_include@,,;t t
> configure:ac_subst_vars='SHELL <....snipped...> nc_include
> <...snipped...>
> configure: nc_include = "-I\$(supp_include_dir)/netcdf"
> configure:s,@nc_include@,$nc_include,;t t
> configure.in: nc_include = "-I\$(supp_include_dir)/netcdf"
> configure.in: AC_SUBST(nc_include)
>
> > grep nc_include */*
> autom4te.cache/output.0:ac_subst_vars='SHELL <....snipped...>
> nc_include <...snipped...>
> autom4te.cache/output.0: nc_include = "-I\$(supp_include_dir)/netcdf"
> autom4te.cache/output.0:s,@nc_include@,$nc_include,;t t
> autom4te.cache/traces.0:m4trace:configure.in:358: -1- AC_SUBST
> ([nc_include])
> src/Makefile:nc_include =
> src/Makefile:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -
> DUSEGADODS=0
> src/Makefile.am:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -
> DUSEGADODS=0
> src/Makefile.in:nc_include = @nc_include@
> src/Makefile.in:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -
> DUSEGADODS=0
>
>
> What am I doing wrong?
>
> Jennifer
>
> --
> Jennifer M. Adams
> IGES/COLA
> 4041 Powder Mill Road, Suite 302
> Calverton, MD 20705
> jm...@co...
>
>
>
> ----------------------------------------------------------------------
> ---
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...
|
|
From: Patrice D. <per...@fr...> - 2008-07-25 10:36:08
|
On Thu, Jul 24, 2008 at 03:11:38PM -0400, Jennifer Adams wrote: > Dear All, > I am finally getting around to working on the build environment. I need > help!!! > > > But after running ./bootstrap and ./configure, nc_include is empty in > the Makefile. it looks right. You should adapt to autoreconf before doing the remaining, though. I think I can't help further without access to the actual code. -- Pat |
|
From: Arlindo da S. <da...@al...> - 2008-07-25 04:25:32
|
On Thu, Jul 24, 2008 at 3:11 PM, Jennifer Adams <jm...@co...> wrote:
> Dear All,
> I am finally getting around to working on the build environment. I need
> help!!!
> I have changed the expected directory structure of $supplibs/include/ so now
> GrADS will look for subdirectories for each library. This led to me editing
> configure.in, acinclude.m4, and src/Makefile.am. I am using the latest
> opengrads src (2.0.a2.oga.1) as a guide. My approach is to update things
> slowly, making sure they work before updating the next.
This may work, but it could be very painful. We also evolved slowly
before we reached the current configuration, with a lot of fine tuning
along the way. Trying to retrace the same steps may be very time
consuming. Another approach is for you to start with the autoconf
structure from opengrads, and replace the *.c, *.h under src with your
current sources and give it a go (If you give me your current sources
I can make sure it builds with the opengrads autoconf structure
without touching your sources).
> So, the
> dynamic-supplib-detection is not in yet. One thing that is not working is
> adding the proper include directory for netcdf.h when compiling grads and
> gradsdap. This is done with a variable called nc_include, which is set in
> configure.in:
> use_nc=no
> if test "$with_nc" != "no" ; then
> echo "Checking netcdf support..."
> GA_CHECK_NC([use_nc=yes], {})
> fi
> if test $use_nc = "yes" ; then
> nc_include = "-I\$(supp_include_dir)/netcdf"
> AC_SUBST(nc_include)
> GA_SET_LIB_VAR(nc_libs, [netcdf udunits])
> AC_SUBST(nc_libs)
> AC_DEFINE(USESDF, 1, [Enable netcdf])
> echo "+ netcdf enabled"
> else
> AC_DEFINE(USESDF, 0, [Enable netcdf])
> echo "- netcdf disabled"
> fi
> I put the nc_include variable in src/Makefile.am like this:
> COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -DUSEGADODS=0
> But after running ./bootstrap and ./configure, nc_include is empty in the
> Makefile.
The bootstrap script is deprecated; I usually use "autoreconf". Also,
keeping up with current practice, configure.in has been renamed
configure.ac ("in" kind of files is usually produced after running
autoconf, like Makefile.in). Which version of autoconf are you using?
> Here I grep for it in the top level, and the directories below:
>> grep nc_include *
> Makefile:nc_include =
> Makefile.in:nc_include = @nc_include@
> config.log:nc_include=''
> config.status:s,@nc_include@,,;t t
> configure:ac_subst_vars='SHELL <....snipped...> nc_include <...snipped...>
> configure: nc_include = "-I\$(supp_include_dir)/netcdf"
> configure:s,@nc_include@,$nc_include,;t t
> configure.in: nc_include = "-I\$(supp_include_dir)/netcdf"
> configure.in: AC_SUBST(nc_include)
>> grep nc_include */*
> autom4te.cache/output.0:ac_subst_vars='SHELL <....snipped...> nc_include
> <...snipped...>
> autom4te.cache/output.0: nc_include = "-I\$(supp_include_dir)/netcdf"
> autom4te.cache/output.0:s,@nc_include@,$nc_include,;t t
> autom4te.cache/traces.0:m4trace:configure.in:358: -1- AC_SUBST([nc_include])
> src/Makefile:nc_include =
> src/Makefile:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -DUSEGADODS=0
> src/Makefile.am:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0
> -DUSEGADODS=0
> src/Makefile.in:nc_include = @nc_include@
> src/Makefile.in:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0
> -DUSEGADODS=0
>
> What am I doing wrong?
I remember having similar issues, but frankly I cannot remember
exactly what I did. I'd have to get your tarball and poke around. In
the new structure we now define NC_CFLAGS which among other things,
define the include dirs; parts of NC_CFLAGS is defined inside the
netcdf/hdf specific m4 macros. Pat has a good eye for these things,
perhaps he can spot something from your output.
Can you make sense of our configure.ac/Makefile.am? I could give you a
walk thru if you would like. There is no rocket science in this ---
simply little gotchas here and there that after lots of
experimentation and testing one gets it working. Are you sure you want
to go thru the same teething pain? Either way, I'd be glad to help,
but I'd need to have your sandbox to see what is going on.
Arlindo
--
Arlindo da Silva
da...@al...
|
|
From: Jennifer A. <jm...@co...> - 2008-07-25 11:33:19
|
On Jul 25, 2008, at 12:25 AM, Arlindo da Silva wrote:
> On Thu, Jul 24, 2008 at 3:11 PM, Jennifer Adams <jm...@co...>
> wrote:
>> Dear All,
>> I am finally getting around to working on the build environment. I
>> need
>> help!!!
>> I have changed the expected directory structure of $supplibs/
>> include/ so now
>> GrADS will look for subdirectories for each library. This led to
>> me editing
>> configure.in, acinclude.m4, and src/Makefile.am. I am using the
>> latest
>> opengrads src (2.0.a2.oga.1) as a guide. My approach is to update
>> things
>> slowly, making sure they work before updating the next.
>
> This may work, but it could be very painful.
Painstaking, but not painful. I'm glad to learn how to control the
configure process, and it's much easier for me to support code I have
thoroughly picked over. I am working on an intel mac running 10.4.11.
autoconf version 2.59. I will try using autoreconf instead of the
bootstrap script and see if that helps.
--Jennifer
> We also evolved slowly
> before we reached the current configuration, with a lot of fine tuning
> along the way. Trying to retrace the same steps may be very time
> consuming. Another approach is for you to start with the autoconf
> structure from opengrads, and replace the *.c, *.h under src with your
> current sources and give it a go (If you give me your current sources
> I can make sure it builds with the opengrads autoconf structure
> without touching your sources).
>
>> So, the
>> dynamic-supplib-detection is not in yet. One thing that is not
>> working is
>> adding the proper include directory for netcdf.h when compiling
>> grads and
>> gradsdap. This is done with a variable called nc_include, which is
>> set in
>> configure.in:
>> use_nc=no
>> if test "$with_nc" != "no" ; then
>> echo "Checking netcdf support..."
>> GA_CHECK_NC([use_nc=yes], {})
>> fi
>> if test $use_nc = "yes" ; then
>> nc_include = "-I\$(supp_include_dir)/netcdf"
>> AC_SUBST(nc_include)
>> GA_SET_LIB_VAR(nc_libs, [netcdf udunits])
>> AC_SUBST(nc_libs)
>> AC_DEFINE(USESDF, 1, [Enable netcdf])
>> echo "+ netcdf enabled"
>> else
>> AC_DEFINE(USESDF, 0, [Enable netcdf])
>> echo "- netcdf disabled"
>> fi
>> I put the nc_include variable in src/Makefile.am like this:
>> COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -DUSEGADODS=0
>> But after running ./bootstrap and ./configure, nc_include is empty
>> in the
>> Makefile.
>
> The bootstrap script is deprecated; I usually use "autoreconf". Also,
> keeping up with current practice, configure.in has been renamed
> configure.ac ("in" kind of files is usually produced after running
> autoconf, like Makefile.in). Which version of autoconf are you using?
>
>> Here I grep for it in the top level, and the directories below:
>>> grep nc_include *
>> Makefile:nc_include =
>> Makefile.in:nc_include = @nc_include@
>> config.log:nc_include=''
>> config.status:s,@nc_include@,,;t t
>> configure:ac_subst_vars='SHELL <....snipped...> nc_include
>> <...snipped...>
>> configure: nc_include = "-I\$(supp_include_dir)/netcdf"
>> configure:s,@nc_include@,$nc_include,;t t
>> configure.in: nc_include = "-I\$(supp_include_dir)/netcdf"
>> configure.in: AC_SUBST(nc_include)
>>> grep nc_include */*
>> autom4te.cache/output.0:ac_subst_vars='SHELL <....snipped...>
>> nc_include
>> <...snipped...>
>> autom4te.cache/output.0: nc_include = "-I\$(supp_include_dir)/
>> netcdf"
>> autom4te.cache/output.0:s,@nc_include@,$nc_include,;t t
>> autom4te.cache/traces.0:m4trace:configure.in:358: -1- AC_SUBST
>> ([nc_include])
>> src/Makefile:nc_include =
>> src/Makefile:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0 -
>> DUSEGADODS=0
>> src/Makefile.am:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0
>> -DUSEGADODS=0
>> src/Makefile.in:nc_include = @nc_include@
>> src/Makefile.in:COMPILE_C = $(COMPILE) $(nc_include) -DUSEDAP=0
>> -DUSEGADODS=0
>>
>> What am I doing wrong?
>
> I remember having similar issues, but frankly I cannot remember
> exactly what I did. I'd have to get your tarball and poke around. In
> the new structure we now define NC_CFLAGS which among other things,
> define the include dirs; parts of NC_CFLAGS is defined inside the
> netcdf/hdf specific m4 macros. Pat has a good eye for these things,
> perhaps he can spot something from your output.
>
> Can you make sense of our configure.ac/Makefile.am? I could give you a
> walk thru if you would like. There is no rocket science in this ---
> simply little gotchas here and there that after lots of
> experimentation and testing one gets it working. Are you sure you want
> to go thru the same teething pain? Either way, I'd be glad to help,
> but I'd need to have your sandbox to see what is going on.
>
> Arlindo
>
> --
> Arlindo da Silva
> da...@al...
>
> ----------------------------------------------------------------------
> ---
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...
|
|
From: Arlindo da S. <da...@al...> - 2008-07-25 14:23:39
|
On Fri, Jul 25, 2008 at 7:33 AM, Jennifer Adams <jm...@co...> wrote: > > On Jul 25, 2008, at 12:25 AM, Arlindo da Silva wrote: > > On Thu, Jul 24, 2008 at 3:11 PM, Jennifer Adams <jm...@co...> wrote: > > Dear All, > I am finally getting around to working on the build environment. I need > help!!! > I have changed the expected directory structure of $supplibs/include/ so now > GrADS will look for subdirectories for each library. This led to me editing > configure.in, acinclude.m4, and src/Makefile.am. I am using the latest > opengrads src (2.0.a2.oga.1) as a guide. My approach is to update things > slowly, making sure they work before updating the next. > > This may work, but it could be very painful. > > Painstaking, but not painful. I'm glad to learn how to control the configure > process, and it's much easier for me to support code I have thoroughly > picked over. I hear you; sometimes I do reverse picking over. I start with something that works and then examine it line by line revising/adapting it as I go long. Absolutely, if you are going to support it you need to be comfortable with it. > I am working on an intel mac running 10.4.11. autoconf version > 2.59. I will try using autoreconf instead of the bootstrap script and see if > that helps. I am currently running Mac OS X 10.5.4 and autoconf 2.62 I installed from mac ports, but until very recently I was running on tiger 10.4.something; autoconf 2.59 shoul be recent enough. Arlindo -- Arlindo da Silva da...@al... |
|
From: Jennifer A. <jm...@co...> - 2008-07-25 13:16:54
|
I have got it to work by creating a new macro in acinclude.m4:
dnl GA_SET_INCLUDE_VAR : Puts necessary options to compile with
include directories given
dnl into a shell variable.
dnl args: : shell-variable-name, list-of-directories
AC_DEFUN([GA_SET_INCLUDE_VAR],
[
ga_include_prefix='-I$(supp_include_dir)/'
for ga_include_name in $2 ; do
$1="$$1 ${ga_include_prefix}${ga_include_name}"
done
])
Now configure.ac has this:
use_nc=no
if test "$with_nc" != "no" ; then
echo "Checking netcdf support..."
GA_CHECK_NC([use_nc=yes], {})
fi
if test $use_nc = "yes" ; then
GA_SET_INCLUDE_VAR(nc_include, [netcdf])
AC_SUBST(nc_include)
if test $use_hdf = "yes" ; then
GA_SET_LIB_VAR(nc_libs, [netcdf])
else
GA_SET_LIB_VAR(nc_libs, [netcdf udunits])
fi
AC_SUBST(nc_libs)
AC_DEFINE(USESDF, 1, [Enable netcdf])
echo "+ netcdf enabled"
else
AC_DEFINE(USESDF, 0, [Enable netcdf])
echo "- netcdf disabled"
fi
echo
And my Makefile has this:
nc_include = -I$(supp_include_dir)/netcdf
--Jennifer
--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...
|
|
From: Arlindo da S. <da...@al...> - 2008-07-25 15:01:22
|
On Fri, Jul 25, 2008 at 9:16 AM, Jennifer Adams <jm...@co...> wrote:
> I have got it to work by creating a new macro in acinclude.m4:
> dnl GA_SET_INCLUDE_VAR : Puts necessary options to compile with include
> directories given
> dnl into a shell variable.
> dnl args: : shell-variable-name, list-of-directories
> AC_DEFUN([GA_SET_INCLUDE_VAR],
> [
> ga_include_prefix='-I$(supp_include_dir)/'
> for ga_include_name in $2 ; do
> $1="$$1 ${ga_include_prefix}${ga_include_name}"
> done
> ])
>
This works and is more flexible than what I had done which was to have
this macro in Makefile.am that assumed a prescribed supplib structure:
INCLUDES = -I$(supp_include_dir) \
-I$(supp_include_dir)/curl \
-I$(supp_include_dir)/xml2 \
-I$(supp_include_dir)/gd \
-I$(supp_include_dir)/gadap \
-I$(supp_include_dir)/udunits \
-I$(supp_include_dir)/hdf \
-I$(supp_include_dir)/jpeg \
-I$(supp_include_dir)/libpng \
-I$(supp_include_dir)/zlib \
-I$(supp_include_dir)/X11/neXtaw \
-I$(supp_include_dir)/libsx \
-I$(supp_include_dir)/grib2c \
-I$(supp_include_dir)/jasper \
$(X_CFLAGS) $(XAW_CFLAGS) $(GD_CFLAGS) \
$(HDF4_CFLAGS)
Where are you defining the list of subdirectories to be searched?
> Now configure.ac has this:
> use_nc=no
> if test "$with_nc" != "no" ; then
> echo "Checking netcdf support..."
> GA_CHECK_NC([use_nc=yes], {})
> fi
> if test $use_nc = "yes" ; then
> GA_SET_INCLUDE_VAR(nc_include, [netcdf])
> AC_SUBST(nc_include)
> if test $use_hdf = "yes" ; then
> GA_SET_LIB_VAR(nc_libs, [netcdf])
> else
> GA_SET_LIB_VAR(nc_libs, [netcdf udunits])
> fi
> AC_SUBST(nc_libs)
> AC_DEFINE(USESDF, 1, [Enable netcdf])
> echo "+ netcdf enabled"
> else
> AC_DEFINE(USESDF, 0, [Enable netcdf])
> echo "- netcdf disabled"
> fi
> echo
> And my Makefile has this:
> nc_include = -I$(supp_include_dir)/netcdf
How would you handle the cases when netcdf is not coming from the
supplibs? In our case, NC_CFLAGS/NCDAP_CFLAGS are defined outside the
Makefile. Pat has macros to either use the supplibs or else discover
netcdf in the system and set NC_CFLAGS accordingly; so this logic is
outside the Makefile.
Note: "Why then the INCLUDES macro above with the list of directories
under the supplibs?", you ask. In this case the suplibs would not be
found (could set SUPPLIBS to /dev/null). Having INCLUDES in
configure.ac, or even in the m4 macro GA_DEF_SUPPLIBS would be a
better solution.
Arlindo.
--
Arlindo da Silva
da...@al...
|
|
From: Jennifer A. <jm...@co...> - 2008-07-25 15:52:42
|
On Jul 25, 2008, at 11:01 AM, Arlindo da Silva wrote:
> On Fri, Jul 25, 2008 at 9:16 AM, Jennifer Adams <jm...@co...>
> wrote:
>> I have got it to work by creating a new macro in acinclude.m4:
>>
>
> This works and is more flexible than what I had done which was to have
> this macro in Makefile.am that assumed a prescribed supplib structure:
>
> INCLUDES = -I$(supp_include_dir) \
> -I$(supp_include_dir)/curl \
> -I$(supp_include_dir)/xml2 \
> -I$(supp_include_dir)/gd \
> -I$(supp_include_dir)/gadap \
> -I$(supp_include_dir)/udunits \
> -I$(supp_include_dir)/hdf \
> -I$(supp_include_dir)/jpeg \
> -I$(supp_include_dir)/libpng \
> -I$(supp_include_dir)/zlib \
> -I$(supp_include_dir)/X11/neXtaw \
> -I$(supp_include_dir)/libsx \
> -I$(supp_include_dir)/grib2c \
> -I$(supp_include_dir)/jasper \
> $(X_CFLAGS) $(XAW_CFLAGS) $(GD_CFLAGS) \
> $(HDF4_CFLAGS)
>
> Where are you defining the list of subdirectories to be searched?
At the moment, this list of include subdirectories is still in
Makefile.am, and is fixed for compiling everything regardless if
there's anything relevant in those subdirectories. (As I mentioned
earlier, I change things slowly, so I can track the problems more
readily.) For now, I'm using the GA_SET_INCLUDE_VAR macro just for
isolating ./dap/netcdf.h and ./netcdf/netcdf.h.
By the way, I don't think the subdirs /curl and /xml2 are needed to
build anything for GrADS, and I use /dap which contains the netcdf.h
from libnc-dap and the *.h files from the gadap library.
> How would you handle the cases when netcdf is not coming from the
> supplibs?
For the moment, I am trying to get everything working to my
understanding and satisfaction assuming everything is coming from the
supplibs. I will add the dynamic library detection on top of that
when I am ready.
> In our case, NC_CFLAGS/NCDAP_CFLAGS are defined outside the
> Makefile. Pat has macros to either use the supplibs or else discover
> netcdf in the system and set NC_CFLAGS accordingly; so this logic is
> outside the Makefile.
I noticed that Pat's code adds a supplibs/bin directory that contains
programs like dap-config and ncdap-config. That's a clever way to get
around the problem of different dap_libs for different operating
systems.
>
> Note: "Why then the INCLUDES macro above with the list of directories
> under the supplibs?", you ask. In this case the suplibs would not be
> found (could set SUPPLIBS to /dev/null). Having INCLUDES in
> configure.ac, or even in the m4 macro GA_DEF_SUPPLIBS would be a
> better solution.
Yes, the more you can avoid hard-coded solutions, the better.
By the way, I have added library versions and URLs to the 'q config'
output. Like this:
This version of GrADS has been configured with the following options:
o Built on a LITTLE ENDIAN machine
o Command line editing ENABLED
readline-5.0 http://tiswww.case.edu/php/chet/readline/rltop.html
o printim command for image output ENABLED
zlib-1.2.3 http://www.zlib.net/
libpng-1.2.18 http://www.libpng.org/pub/png/libpng.html
gd-2.0.34 http://www.libgd.org/Main_Page
o GRIB2 interface ENABLED
g2clib-1.0.5 http://www.nco.ncep.noaa.gov/pmb/codes/GRIB2
jasper-1.701.0 http://www.ece.uvic.ca/~mdadams/jasper
jpeg-6b 27-Mar-1998 http://www.ijg.org
o NetCDF interface ENABLED
libnc-dap "3.7.0" of Feb 15 2007 09:14:25 $ http://
www.opendap.org
o NCSA HDF interface ENABLED
HDF4.2r3 http://hdf.ncsa.uiuc.edu
o Athena Widget GUI DISABLED
o OPeNDAP gridded data interface ENABLED
libdap 3.7.8 http://www.opendap.org
o OPeNDAP station data interface ENABLED
libgadap 2.0 http://iges.org/grads/gadoc/supplibs.html
I am also getting ready to release libgadap-2.0, which will go with
GrADS 2.0 and GDS 2.0 and will have the new copyright.
--Jennifer
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X