Menu
▾
▴
opengrads-devel — OpenGrADS development issues, with focus on interfaces and extensions
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(16) |
Dec
(24) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(19) |
Feb
(50) |
Mar
(10) |
Apr
(1) |
May
(12) |
Jun
(4) |
Jul
(17) |
Aug
(39) |
Sep
(9) |
Oct
|
Nov
|
Dec
(12) |
| 2009 |
Jan
(8) |
Feb
(11) |
Mar
(4) |
Apr
(3) |
May
(2) |
Jun
(2) |
Jul
(1) |
Aug
(2) |
Sep
(3) |
Oct
(17) |
Nov
(8) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
(12) |
Aug
|
Sep
|
Oct
(12) |
Nov
|
Dec
|
| 2011 |
Jan
(10) |
Feb
|
Mar
|
Apr
(2) |
May
(6) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(25) |
Nov
(4) |
Dec
(2) |
| 2012 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(5) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Arlindo da S. <da...@al...> - 2008-08-21 11:51:34
|
On Thu, Aug 21, 2008 at 1:22 AM, Mark Sponsler <msp...@co...> wrote:
> Hi Arlindo,
> Couldn't help myself and started digging a little deeper. Stumbled on a
> couple of what are likely minor issues:
>
> First issue is the same one we had earlier with the software unable to read
> DOS formatted text files. Once I converted them to unix format, it ran
> fine.
>
This is very helpful. I passed some of these patches to Jennifer but I
may have missed something. Will investigate.
> Second it doesn't appear to be able to handle your new function reading
> shp_line files. This worked fine under 1.9. The commnad in the script was:
>
> 'set line 34 1 6'
> 'shp_lines gshhs_land'
>
The shp_line command is an OpenGrADS extension, and extensions are not
yet supported in GrAS v2. There is no technical reason why they could
not be ported to grads v2. However, we need to coordinate with COLA so
that we have an uniform way to introduce these extensions. I'll keep
you posted.
Arlindo
--
Arlindo da Silva
da...@al...
|
|
From: <msp...@co...> - 2008-08-21 05:04:59
|
Hi Arlindo, I just ran a few of my scripts using the new 2.0 verion from the zip file. All worked great! Awesome work. I'll dig in deeper as time permits. Thanks for the great product! -- Mark -------------- Original message -------------- From: "Arlindo da Silva" <da...@al...> > Guys, > > I just refreshed the binaries to include the most recent front end I > have been using for v1.9.0-rc1. The [Start] menu also includes GrADS > GUI with starts with an Athena GUI. > > Arlindo > > On Tue, Aug 19, 2008 at 1:35 AM, Arlindo da Silva wrote: > > All, > > I have my first win32 build of GrADS v2. The packaging is similar to what > > I had done for v1.9.0-rc1, with both a self installing .exe and a .zip file. > > These can be found here: > > http://opengrads.org/devel/grads2/grads-2.0.a3.oga.1.win32_superpack.exe > > http://opengrads.org/devel/grads2/grads-2.0.a3.oga.1.win32_superpack.zip > > > > If you have a chance to try it out, please let me know if it works. These > > are supposed to be relocatable. Because v2 does not support it yet, there > > are no extensions included. > > Thank you, > > Arlindo > > -- > > Arlindo da Silva > > da...@al... > > > > > > -- > Arlindo da Silva > da...@al... |
|
From: Arlindo da S. <da...@al...> - 2008-08-21 00:19:07
|
Jennifer,
I just made my first Mac universal build:
http://opengrads.org/devel/grads2/grads-2.0.a3.oga.1-bin-universal-apple-darwin9.4.0.tar.gz
This was made on Mac OS X 10.5.4 (Leopard) on an intel Mac using
cross-compilation; see the attached script, it might work with your
build. No changes were made to the build scripts. I tried these on an
old PPC Mac running Tigger but it could not find some of the X
libraries, more likely a Leopard/Tigger issue than related to the
universal binaries.
BTW, which version of Mac OS X do you use for your builds?
Arlindo
--
Arlindo da Silva
da...@al...
|
|
From: Arlindo da S. <da...@al...> - 2008-08-20 11:24:22
|
On Wed, Aug 20, 2008 at 6:45 AM, John Huddleston <jhu...@hu...> wrote: > Good morning Arlindo > > Thank you for suggesting that extra test. There was one additional DLL > cygxml2-2.dll that was missing. I added the additional DLL file to the > grads-cygwin-dap-dlls.zip ZIP container and uploaded the new file this > morning. The utility "cygcheck" is equivalient to "ldd" on Linux/Unix and lists all the DLLs used by an executable. cygcheck grads.exe It has been tested successfully with the standard datasets. Would > you please send me a control file or set of commands to test the DAP portion > of the GrADS application? Fire up gradsdap and open a sample dataset, e.g., gradsdap ... ga-> sdfopen http://opendap.nccs.nasa.gov:9090/dods/GEOS-5/ARCTAS/0.5_deg/assim/inst2d_hwl_x ga-> d o3du I need to place the standard test datasets on a GDS so that the pytests/ do this automatically. Arlindo -- Arlindo da Silva da...@al... |
|
From: Arlindo da S. <da...@al...> - 2008-08-20 11:14:59
|
On Wed, Aug 20, 2008 at 4:53 AM, See Hai Ooi <ax...@ya...> wrote:
> Dear Mr Arlindo da Silva,
>
> Thank you.
>
> I notice that the X-server window is larger than the 1.9 rc1 version [I prefer the old one so that I can have my command and GrADS windows placing nicely in one screen].
This is a question for Jennifer; I believe the default size of the
initial window has changed in GrADS v2. I did not do anything special
for the Win32 build.
> So far, I did not encounter any problems in running some of my scripts. However, can you let Xming exit automatically after quiting GrADS ?
Hmm.... This is not as simple to implement as you might think. By
default, if you have several instances of GrADS running simultaneously
they all share the same X server. So, if you kill Xming on exit, you
have to make sure there is no other process using it. I'll think about
it.
> Will keep you informed if I do come across some problems later on.
As always, thank you very much for your feedback.
Arlindo
--
Arlindo da Silva
da...@al...
|
|
From: John H. <jhu...@hu...> - 2008-08-20 10:45:41
|
Good morning Arlindo
Thank you for suggesting that extra test. There was one additional DLL
cygxml2-2.dll that was missing. I added the additional DLL file to the
grads-cygwin-dap-dlls.zip ZIP container and uploaded the new file this
morning. It has been tested successfully with the standard datasets. Would
you please send me a control file or set of commands to test the DAP portion
of the GrADS application?
Thanks for all you notes and links. I'll look at these and get back to you
on the builds.
John Huddleston, PhD, PE
jhu...@hu...
-----Original Message-----
From: arl...@gm... [mailto:arl...@gm...] On Behalf
Of Arlindo da Silva
Sent: Tuesday, August 19, 2008 12:02 PM
To: jhu...@hu...
Cc: ope...@li...
Subject: Re: Cygwin DLLs for the DAP version of GrADS2.0a3
On Tue, Aug 19, 2008 at 8:58 AM, John Huddleston <jhu...@hu...>
wrote:
>
> Jennifer,
>
>
>
> I hope you are having a nice vacation!
>
>
>
> I've uploaded the Cygwin DLLs required to run the DAP version of
GrADS2.0a3.
>
>
>
> Would you please move grads-cygwin-dap-dlls.zip to the ftp site for the
GrADS users?
>
>
Did you have a chance to test this on a machine where cygwin is not
installed? In particular, there are issues with the cygwin file system
(for example, is /tmp mounted somewhere?) that can lead to bizarre
behavior.
BTW, I finally got around to make a "Win32 Superpack" build for GrADS
2.0.a3, which follows the same approach I had for the latest
v1.0.0-rc1, with a .exe, .zip and a light weight tarball for people
with cygwin already installed. You can find the files here:
http://opengrads.org/devel/grads2/
>From the sf.net download stats for v1.9.0-rc1 on sf.net, the
superpack.exe has 561 downloads, the superpack.zip 208 downloads, and
the plain tarball only 69 downloads. Linux i686 got 278 downloads,
Linux x86_64 got 118 downloads. By far, the win32 builds are the most
widely used, something that was a bit of a surprise to me. It could be
that the Linux version is installed on servers with muiltiple users,
while win32 is more of a personal thing.
I also uploaded the latest supplibs-2.0.1 for cygwin to sf.net:
http://sourceforge.net/project/showfiles.php?group_id=161773&package_id=2416
81
At this time the best way to get the sources I used for the superpack,
including the Ino Setup scripts that I used for the setup.exe kind of
packaging, is to checkout code from the opengrads repository:
cvs -d:pserver:ano...@op...:/cvsroot/opengrads
login
cvs -z3
-d:pserver:ano...@op...:/cvsroot/opengrads
co -r GRADS2_DEV_BRANCH grads
cvs -z3
-d:pserver:ano...@op...:/cvsroot/opengrads
co -r GRADS2_DEV_BRANCH PCGrADS_base
I'll wait until we finish merging our build scripts with COLA's to
write a wiki page about preparing the Win32 Superpack. If you checkout
the sources above, take a look at main_win32.c to see some of tricks I
had to do for getting it to work stably on a machine without cygwin
installed. Or else, you can browse this file here:
http://opengrads.cvs.sourceforge.net/opengrads/grads/src/main_win32.c?view=m
arkup&pathrev=GRADS2_DEV_BRANCH
If you would like to join us and take over the maintenance of the
win32 superpack and subsequent builds just drop me a note.
Cheers!
Arlindo
--
Arlindo da Silva
da...@al...
|
|
From: See H. O. <ax...@ya...> - 2008-08-20 08:53:45
|
Dear Mr Arlindo da Silva,
Thank you.
I notice that the X-server window is larger than the 1.9 rc1 version [I prefer the old one so that I can have my command and GrADS windows placing nicely in one screen]. So far, I did not encounter any problems in running some of my scripts. However, can you let Xming exit automatically after quiting GrADS ? Will keep you informed if I do come across some problems later on.
Regards.
Ooi See Hai
--- On Wed, 20/8/08, Arlindo da Silva <da...@al...> wrote:
> From: Arlindo da Silva <da...@al...>
> Subject: Re: New Win32 GrADS build
> To: smc...@pl...
> Cc: "See Hai Ooi" <ax...@ya...>, "Bill Reilly" <Bil...@co...>, "Eric Altshuler" <el...@co...>, "Maat, Herbert ter" <Her...@wu...>, "Michael G Bosilovich" <Mic...@na...>, ope...@li..., "Mark Sponsler" <msp...@co...>
> Date: Wednesday, 20 August, 2008, 2:06 AM
> Guys,
>
> I just refreshed the binaries to include the most recent front end I have been using for v1.9.0-rc1. The [Start] menu also includes GrADS GUI with starts with an Athena GUI.
>
> Arlindo
>
> On Tue, Aug 19, 2008 at 1:35 AM, Arlindo da Silva
> <da...@al...> wrote:
> > All,
> > I have my first win32 build of GrADS v2. The packaging is similar to what I had done for v1.9.0-rc1, with both a self installing .exe and a .zip file. These can be found here:
> >
> http://opengrads.org/devel/grads2/grads-2.0.a3.oga.1.win32_superpack.exe
> >
> http://opengrads.org/devel/grads2/grads-2.0.a3.oga.1.win32_superpack.zip
> >
> > If you have a chance to try it out, please let me know if it works. These are supposed to be relocatable. Because v2 does not support it yet, there are no extensions included.
> > Thank you,
> > Arlindo
> > --
> > Arlindo da Silva
> > da...@al...
New Email names for you!
Get the Email name you've always wanted on the new @ymail and @rocketmail.
Hurry before someone else does!
http://mail.promotions.yahoo.com/newdomains/aa/
|
|
From: Arlindo da S. <da...@al...> - 2008-08-19 18:06:06
|
Guys,
I just refreshed the binaries to include the most recent front end I
have been using for v1.9.0-rc1. The [Start] menu also includes GrADS
GUI with starts with an Athena GUI.
Arlindo
On Tue, Aug 19, 2008 at 1:35 AM, Arlindo da Silva <da...@al...> wrote:
> All,
> I have my first win32 build of GrADS v2. The packaging is similar to what
> I had done for v1.9.0-rc1, with both a self installing .exe and a .zip file.
> These can be found here:
> http://opengrads.org/devel/grads2/grads-2.0.a3.oga.1.win32_superpack.exe
> http://opengrads.org/devel/grads2/grads-2.0.a3.oga.1.win32_superpack.zip
>
> If you have a chance to try it out, please let me know if it works. These
> are supposed to be relocatable. Because v2 does not support it yet, there
> are no extensions included.
> Thank you,
> Arlindo
> --
> Arlindo da Silva
> da...@al...
>
--
Arlindo da Silva
da...@al...
|
|
From: Arlindo da S. <da...@al...> - 2008-08-19 18:01:59
|
On Tue, Aug 19, 2008 at 8:58 AM, John Huddleston <jhu...@hu...> wrote:
>
> Jennifer,
>
>
>
> I hope you are having a nice vacation!
>
>
>
> I've uploaded the Cygwin DLLs required to run the DAP version of GrADS2.0a3.
>
>
>
> Would you please move grads-cygwin-dap-dlls.zip to the ftp site for the GrADS users?
>
>
Did you have a chance to test this on a machine where cygwin is not
installed? In particular, there are issues with the cygwin file system
(for example, is /tmp mounted somewhere?) that can lead to bizarre
behavior.
BTW, I finally got around to make a "Win32 Superpack" build for GrADS
2.0.a3, which follows the same approach I had for the latest
v1.0.0-rc1, with a .exe, .zip and a light weight tarball for people
with cygwin already installed. You can find the files here:
http://opengrads.org/devel/grads2/
>From the sf.net download stats for v1.9.0-rc1 on sf.net, the
superpack.exe has 561 downloads, the superpack.zip 208 downloads, and
the plain tarball only 69 downloads. Linux i686 got 278 downloads,
Linux x86_64 got 118 downloads. By far, the win32 builds are the most
widely used, something that was a bit of a surprise to me. It could be
that the Linux version is installed on servers with muiltiple users,
while win32 is more of a personal thing.
I also uploaded the latest supplibs-2.0.1 for cygwin to sf.net:
http://sourceforge.net/project/showfiles.php?group_id=161773&package_id=241681
At this time the best way to get the sources I used for the superpack,
including the Ino Setup scripts that I used for the setup.exe kind of
packaging, is to checkout code from the opengrads repository:
cvs -d:pserver:ano...@op...:/cvsroot/opengrads login
cvs -z3 -d:pserver:ano...@op...:/cvsroot/opengrads
co -r GRADS2_DEV_BRANCH grads
cvs -z3 -d:pserver:ano...@op...:/cvsroot/opengrads
co -r GRADS2_DEV_BRANCH PCGrADS_base
I'll wait until we finish merging our build scripts with COLA's to
write a wiki page about preparing the Win32 Superpack. If you checkout
the sources above, take a look at main_win32.c to see some of tricks I
had to do for getting it to work stably on a machine without cygwin
installed. Or else, you can browse this file here:
http://opengrads.cvs.sourceforge.net/opengrads/grads/src/main_win32.c?view=markup&pathrev=GRADS2_DEV_BRANCH
If you would like to join us and take over the maintenance of the
win32 superpack and subsequent builds just drop me a note.
Cheers!
Arlindo
--
Arlindo da Silva
da...@al...
|
|
From: Arlindo da S. <da...@al...> - 2008-08-19 05:34:56
|
All, I have my first win32 build of GrADS v2. The packaging is similar to what I had done for v1.9.0-rc1, with both a self installing .exe and a .zip file. These can be found here: http://opengrads.org/devel/grads2/grads-2.0.a3.oga.1.win32_superpack.exe http://opengrads.org/devel/grads2/grads-2.0.a3.oga.1.win32_superpack.zip If you have a chance to try it out, please let me know if it works. These are supposed to be relocatable. Because v2 does not support it yet, there are no extensions included. Thank you, Arlindo -- Arlindo da Silva da...@al... |
|
From: Jennifer A. <jm...@co...> - 2008-08-15 13:55:26
|
On Aug 15, 2008, at 9:40 AM, Arlindo da Silva wrote: > On Fri, Aug 15, 2008 at 8:58 AM, Jennifer Adams <jm...@co...> > wrote: > Arlindo -- > I am happy to hear 2.0.a3 built (almost) perfectly with your > supplibs and passed your tests. Was the change from Pixel to > gaPixel the only change needed to get the GUI to build? > > Yep, besides the build being able to detect libsx, etc. Good. That's easy. > > Did you try out the sdfwrite command? > > Not yet. My plan is to write a test for it adapting what I had for > lats in v1.9. (Data is written out using sdfwrite, read back and > compared to what we started with.) The netcdf files created by sdfwrite are type NC_DOUBLE (since that's how the variable is defined in memory). Next round will include netcdf4, so we can enable compression to make the output file smaller. > > > The mods you outline below seem fine with me, but I will check with > Brian about the main() changes. > > In a way, this is mainly organizational, as I already had Win32 > ifdef's around main in there. This way I do not have to pollute > grads.c with Win32 specific stuff. You do not have to do anything > with main_win32.c right now; I am waiting for the build to settle > for me to wire that in. > > I asked him about /pytests and he would prefer that there is no > dependence on python at all, even just for testing. > > It is not a dependence like the others: if python with the vanilla > standard libraries is not present then "make check" will not work. > Except for a very old sun, I am yet to find a platform where python > does not come standard. It is almost like depending on sh(1) these > days. But OK, it is not a big deal. > > Seems like an easy enough thing to package separately, if people > who are building from source want to use to check on their work. > > Consider using it yourself, you do not need to know python to read > the "OK's" :-). yuk yuk yuk I can understand "OK", but can my computer??? # OK tcsh: OK: Command not found. > Seriously, you can also add tests by providing a gs script with > your tests. I will likely just adapt the python stuff to use GrADS scripts. I think a test suite is a good idea. > > Have a nice vacation! Thanks! I will be checking email sporadically. --Jennifer |
|
From: Arlindo da S. <da...@al...> - 2008-08-15 13:40:29
|
On Fri, Aug 15, 2008 at 8:58 AM, Jennifer Adams <jm...@co...> wrote: > Arlindo -- I am happy to hear 2.0.a3 built (almost) perfectly with your > supplibs and passed your tests. Was the change from Pixel to gaPixel the > only change needed to get the GUI to build? > Yep, besides the build being able to detect libsx, etc. > Did you try out the sdfwrite command? > Not yet. My plan is to write a test for it adapting what I had for lats in v1.9. (Data is written out using sdfwrite, read back and compared to what we started with.) > > The mods you outline below seem fine with me, but I will check with Brian > about the main() changes. > In a way, this is mainly organizational, as I already had Win32 ifdef's around main in there. This way I do not have to pollute grads.c with Win32 specific stuff. You do not have to do anything with main_win32.c right now; I am waiting for the build to settle for me to wire that in. > I asked him about /pytests and he would prefer that there is no dependence > on python at all, even just for testing. > It is not a dependence like the others: if python with the vanilla standard libraries is not present then "make check" will not work. Except for a very old sun, I am yet to find a platform where python does not come standard. It is almost like depending on sh(1) these days. But OK, it is not a big deal. > Seems like an easy enough thing to package separately, if people who are > building from source want to use to check on their work. > Consider using it yourself, you do not need to know python to read the "OK's" :-). Seriously, you can also add tests by providing a gs script with your tests. Have a nice vacation! Arlindo -- Arlindo da Silva da...@al... |
|
From: Jennifer A. <jm...@co...> - 2008-08-15 12:59:19
|
Arlindo -- I am happy to hear 2.0.a3 built (almost) perfectly with your supplibs and passed your tests. Was the change from Pixel to gaPixel the only change needed to get the GUI to build? Did you try out the sdfwrite command? The mods you outline below seem fine with me, but I will check with Brian about the main() changes. I asked him about /pytests and he would prefer that there is no dependence on python at all, even just for testing. Seems like an easy enough thing to package separately, if people who are building from source want to use to check on their work. --Jennifer p.s. I will be on vacation next week, so all this will idle for a little while until I get back. On Aug 15, 2008, at 1:13 AM, Arlindo da Silva wrote: > Jennifer et al, > > In the previous message I reported that v2.0.a3 (almost) builds > out of the tarball with the supplibs-2.0.1. Here I report the > first steps towards having the build mechanism reconciled/merged. > > 1) The first step is to bring your sources into the OpenGrADS > codebase so that we can approach this from 2 directions. This time > I took your sources pretty much AS IS except for: > > - Changed #include <config.h> to #include "config.h"; this can > be accomplished with > sed -i -e 's/\(# *include \+\)<config.h>/ > \1"config.h"/' src/*.c src/*.h > This is more than a stylistic patch; <> is usually > reserved for system includes. > - Removed Arlindo's copyright notice in gacfg.c, kept COLA's > - Changed Pixel to gaPixel in gatypes.h because of conflicts > with libsx.h > - Updated copyright notice in pcx11e.[ch]; I'd suggest removing > these 2 files altogether. > - Changed main() to grads_main() in grads.c > - Introduced main.c and main_win32.c; this will be very > important for a user friendly Win32 > build and is essential for working with DLL extensions > later on. > - Commented out libdap_version() and libgadap_version() in > gacfg.c (for now, so that we can > use the existing supplibs-2.0.1 "as is"). > > I am attaching the diffs as well as the full sources (I did not > change your build to use main.c). Do you think you could > incorporate these mods in your code base so that we can start from > a common source code base when working on the build? Some of the > licensing patches are important for Pat and his Fedora package > (Pat: did I miss anything?) The main.c mod anticipates what I will > need for the Win32 build. > > 2) With the above source patches I was able to make a full build > with the supplibs-2.0.1, including the GUI, using the current > opengrads build. > Like with COLA's build, it passed all tests. For reference I issued > the tag grads-2_0_a3-a1; you can check it out with > > % gacvs co -r grads-2_0_a3-oga-1 grads > > 3) The next step is for Pat to go over the autoconf scripts and > reconcile/merge what we have with COLA's. As I said, it would be > good if we start with the same sources. > > 4) As for the pytests/, it works pretty much as an add-on and we > will continue to maintain it at OpenGrADS. I find it extremely > useful to check the builds on different platforms and I'ff continue > to add to it. This is very separate from PyGrADS, although it > include a very small part of it needed to drive the tests. > > Let me know if this is an acceptable plan to you. > > Cheers! > > Arlindo > > > > > > -- > Arlindo da Silva > da...@al... > <grads_src.diffs><grads_src.tgz>-------------------------------------- > ----------------------------------- > 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-08-15 04:25:03
|
Jennifer,
I just downloaded the v2.0.a3 and gave it a try. First impressions:
1) I made a symlink of the supplibs-2.0.1 to ../supplibs and did a
configure which resulted in:
+=========================================================================+
GrADS 2.0.a3 : Built Fri Aug 15 00:08:23 EDT 2008 for
i386-apple-darwin9.4.0
+=========================================================================+
+----------------------------------+
| |
| Configuration Summary |
| |
| + readline enabled |
| + printim enabled |
| + netcdf enabled |
| + hdf4 enabled |
| + grib2 enabled |
| - GUI disabled |
| |
| Build Summary |
| |
| + grads enabled |
| + gradsdap enabled |
| (both grid & stn interfaces) |
| |
| + Dynamic linking enabled |
| |
+----------------------------------+
Except for the GUI, everything else was detected.
2) Then, attempted a build
% make
which resulted in
"_libgadap_version", referenced from:
_gacfg in gacfg-dap.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [gradsdap] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
because libgagap_version() is not available in the current version of
libgadap in the supplibs-2.0.1; a similar problem happens with
libdap_version(). So I commented these out and the build completed.
3) Then I put a copy of pytests parallel to src, ran the tests, and the
binaries passed all the 74 the tests. Very good.
I'll report in a separate e-mail steps towards getting the GUI to build
and reconciling the COLA/OpenGrADS build scripts.
Arlindo
---------- Forwarded message ----------
From: Jennifer Adams <jm...@co...>
Date: Tue, Aug 12, 2008 at 9:41 AM
Subject: New Release GrADS 2.0.a3
To: GRA...@li...
I have posted a new version of GrADS: 2.0.a3. The GrADS downloads web page (
*http://iges.org/grads/downloads.html*<http://iges.org/grads/downloads.html>)
has been updated with links to the source code and pre-compiled binaries for
Macs and a few 64-bit linux flavors. Here's what new in this release:
Features:
* New set of commands for writing out netcdf files.
'sdfwrite' (creates the file, takes a defined variable name as
an argument)
'set sdfwrite' (sets the output filename, default is
grads.sdfwrite.nc)
'query sdfwrite' (shows the output filename, format, and
user-specified attributes)
'set sdfattr' (sets attribute metadata for the output file)
'clear sdfwrite' (resets the sdf output filename and releases
any attributes)
* Added "PDEF GENERAL" as an data-format independent alternative to
"PDEF FILE".
Fixes:
* Station data handling via OPeNDAP (enabled with libgadap) works with
GDS 2.0.
* The stnmap utility does not seg fault when some templated data files
are missing.
* Added PDEF handling for 2-D native HDF and NetCDF files
* Data format dependence in PDEF FILE better documented;
warning issued when data set that uses PDEF FILE is opened.
* Memory leak in scorr().
* The index files created by gribmap are portable
* parsing of VECTORPAIRS entry in descriptor file does not seq fault
Misc:
* Graphical display window is sized according to the height of the
display;
portait is 90% of display height, landscape is 60%.
* Changes to the configure tools to facilitate building from source
* The sdfopen command handles files with "axis" attribute
* Output from 'query config' more complete, contains some supplib
versions
* Support for NetCDF and HDF files with spaces in the variable names;
substitute ~ for <space> in varname=>alias syntax.
This build has the initial implementation of the capability to write out
netCDF files. The interface is to set the desired dimension environment,
then define a variable, then 'sdfwrite' it: ga-> set lon ... lat ... lev
... time ... ens
ga-> define newvar = var
ga-> sdfwrite newvar
In this release, you can only write out one variable per file, and you
cannot append to an existing file. Later releases will have more flexibility
built in, but I wanted to get this initial implementation out there for
testing first. In the meanwhile, the workaround is to write two files, then
use the netcdf operators to merge them.
Documentation pages for the new commands are here:
*http://iges.org/grads/gadoc/gradcomdsdfwrite.html***<http://iges.org/grads/gadoc/gradcomdsdfwrite.html>
*http://iges.org/grads/gadoc/gradcomdsetsdfwrite.html*<http://iges.org/grads/gadoc/gradcomdsetsdfwrite.html>
*http://iges.org/grads/gadoc/gradcomdsetsdfattr.html***<http://iges.org/grads/gadoc/gradcomdsetsdfattr.html>
*http://iges.org/grads/gadoc/gradcomdqsdfwrite.html*
I will be adding additional documentation to the Users Guide on how to work
with ensembles, how to write out data in various formats, how to build from
source, and other interesting topics.
Jennifer
--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
*jm...@co...*** <jm...@co...>
--
Arlindo da Silva
da...@al...
|
|
From: Arlindo da S. <da...@al...> - 2008-08-12 14:53:51
|
On Tue, Aug 12, 2008 at 10:00 AM, Jennifer Adams <jm...@co...> wrote: > The src and some binaries are out now. ftp://grads.iges.org/grads/2.0/ > > The supplibs/include directory names I used are like this: > gadap/ gd/ grib2c/ hdf/ libnc-dap/ libpng12/ netcdf/ readline/ > udunits/ zlib/ > > I have not used your pre-compiled supplibs. I believe the new code should > work with them, but I'm sure some changes to configure.ac and Makefile.am > will be required. > If you give me a sneak preview of a3 I can make sure it builds with supplibs-2.0.1. It would be much less work than patch and rebuild the supplibs on all the different platforms. I rather spend the time providing builds and supplibs for new platforms. > For my pre-compiled builds, I rebuilt the curl library --without-libidn and > --without-ssl and then rebuilt all the *dap*.a libraries around that. > Hopefully they will be more portable. The python interface is not included; > without any knowledge of python, I can't realistically support it. > The pytests/ are not the python interface. I just have a small part of it (1 file) built in to support the tests. I consider it part of the build as it allows you a straightforward way to test what you have built. Nothing python gets installed or distributed, it is just an aid for the builder. It is just a drop in and uses standard python libraries, no extra install required (you need python 2.3 or later, pretty common these days). BTW, grads v2 is getting nice and stable stable. Isn't about time for a "b3"? Some people simply would not touch alpha code. Alpha usually means code that is unstable and with known bugs; you are passed this point. Arlindo -- Arlindo da Silva da...@al... |
|
From: Jennifer A. <jm...@co...> - 2008-08-12 14:00:50
|
The src and some binaries are out now. ftp://grads.iges.org/grads/2.0/ The supplibs/include directory names I used are like this: gadap/ gd/ grib2c/ hdf/ libnc-dap/ libpng12/ netcdf/ readline/ udunits/ zlib/ I have not used your pre-compiled supplibs. I believe the new code should work with them, but I'm sure some changes to configure.ac and Makefile.am will be required. For my pre-compiled builds, I rebuilt the curl library --without-libidn and --without-ssl and then rebuilt all the *dap*.a libraries around that. Hopefully they will be more portable. The python interface is not included; without any knowledge of python, I can't realistically support it. > --Jennifer On Aug 12, 2008, at 1:16 AM, Arlindo da Silva wrote: > On Mon, Aug 11, 2008 at 9:36 AM, Jennifer Adams <jm...@co...> > wrote: > > It will be easier to discuss when 2.0.a3 is out, but ... here are > examples of the kind of stuff I changed in configure.ac: > > OK, I'll wait until a3 is out and then try to reconcile. > > As for the supplibs/include subdirectories, I renamed grib2->grib2c, > > You mean, grib2c->grib2? This kind of renaming end up causing me a > lot of extra work for the supplibs-2.0.x, things like having to > make changes to the repository, build mechanism, etc. > > BTW, are you using grib2c from the supplibs-2.0.x? I've added > autoconf to it and contributed to NCEP, but I am not sure if they > have adopted it. > > and split dap into gadap and libnc-dap. > > In the supplibs 2.0.x we already had 3 libraries: > > gadap > libdap > libnc-dap > > Have you actually tried a build using the pre-compiled supplibs-2.0.1? > > http://sourceforge.net/project/showfiles.php? > group_id=161773&package_id=241681 > > In v1.9.0-rc1, with pre-compiled supplibs, GrADS builds very simply > out of the tarball: > > http://opengrads.org/wiki/index.php? > title=Building_GrADS_v1.9_from_Sources > > The idea is for people not to have to do any renaming, rearranging > of the the supplibs. I actually started working on a perl script > that detects people's hardware, then retrieves pre-compiled > supplibs + grads sources automatically, does the build and cleans > up the mess. Very easy. > > But the libpng12 name comes from their source code, to distinguish > from earlier versions, so I think we should leave that as is (they > renamed the library too, libpng12.a). > > In the supplibs-2.0.x libpng12 is symlinked to libpng. In any case, > pkg-config takes care of it, better not to hardwire the name of the > library, include directory. > > The remainder of the include directories that weren't in my list > may be essential for building all the supplibs in a coherent way, > but they are not necessary for compiling GrADS -- I generally > extract only what GrADS needs from a complete library installation > and put that into my supplibs location. > > I'd say that these are necessary not only for building the supplibs > consistently but more importantly for getting *portable* GrADS > binaries. For example, using a system provided libcurl that depends > on openssl does not lead to portable binaries, I learned it the > hard way (I believe your binaries have this problem). The > advantage of having portable binaries is that you can have a > generic Linux i686 binary, rather than binaries for specific distros. > > I should mention that I never build with GUI, so I don't know > what's required there. > > The supplibs-2.0.x should have all you need. > > BTW, are you planing to include the pytests/ in a3? > > I look forward to seeing 2.0.a3. > > Thanks, > > 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-08-12 05:16:05
|
On Mon, Aug 11, 2008 at 9:36 AM, Jennifer Adams <jm...@co...> wrote: > > It will be easier to discuss when 2.0.a3 is out, but ... here are examples > of the kind of stuff I changed in configure.ac: > OK, I'll wait until a3 is out and then try to reconcile. > As for the supplibs/include subdirectories, I renamed grib2->grib2c, > You mean, grib2c->grib2? This kind of renaming end up causing me a lot of extra work for the supplibs-2.0.x, things like having to make changes to the repository, build mechanism, etc. BTW, are you using grib2c from the supplibs-2.0.x? I've added autoconf to it and contributed to NCEP, but I am not sure if they have adopted it. > and split dap into gadap and libnc-dap. > In the supplibs 2.0.x we already had 3 libraries: gadap libdap libnc-dap Have you actually tried a build using the pre-compiled supplibs-2.0.1? http://sourceforge.net/project/showfiles.php?group_id=161773&package_id=241681 In v1.9.0-rc1, with pre-compiled supplibs, GrADS builds very simply out of the tarball: http://opengrads.org/wiki/index.php?title=Building_GrADS_v1.9_from_Sources The idea is for people not to have to do any renaming, rearranging of the the supplibs. I actually started working on a perl script that detects people's hardware, then retrieves pre-compiled supplibs + grads sources automatically, does the build and cleans up the mess. Very easy. But the libpng12 name comes from their source code, to distinguish from > earlier versions, so I think we should leave that as is (they renamed the > library too, libpng12.a). > In the supplibs-2.0.x libpng12 is symlinked to libpng. In any case, pkg-config takes care of it, better not to hardwire the name of the library, include directory. > The remainder of the include directories that weren't in my list may be > essential for building all the supplibs in a coherent way, but they are not > necessary for compiling GrADS -- I generally extract only what GrADS needs > from a complete library installation and put that into my supplibs location. > > I'd say that these are necessary not only for building the supplibs consistently but more importantly for getting *portable* GrADS binaries. For example, using a system provided libcurl that depends on openssl does not lead to portable binaries, I learned it the hard way (I believe your binaries have this problem). The advantage of having portable binaries is that you can have a generic Linux i686 binary, rather than binaries for specific distros. > I should mention that I never build with GUI, so I don't know what's > required there. > The supplibs-2.0.x should have all you need. BTW, are you planing to include the pytests/ in a3? I look forward to seeing 2.0.a3. Thanks, Arlindo -- Arlindo da Silva da...@al... |
|
From: Jennifer A. <jm...@co...> - 2008-08-11 13:37:44
|
It will be easier to discuss when 2.0.a3 is out, but ... here are examples of the kind of stuff I changed in configure.ac: 1) I noticed that the GA_CHECK_LIB routine only checked for the presence of a required library, but did not check whether it could actually be used in a program. So I changed all those to AC_CHECK_LIB, first making sure that the -I and -L flags were limited to the supplibs dir. 2) I avoid double checking for libraries that are required by more than one feature within the context of the with/without flags. The logic had been mostly in line with setting up the different 1.9 exectuables, whereas now it's focused on enabling features in a single build. (Remember gradsdap will be phased out as soon as unidata netcdf 4 is opendap-ready.). 3) I added login to skip to dynamic macros if supplibs doesn't exist. I am not trying to tear apart what you've already done, only trying to improve it. As for the supplibs/include subdirectories, I renamed grib2->grib2c, and split dap into gadap and libnc-dap. But the libpng12 name comes from their source code, to distinguish from earlier versions, so I think we should leave that as is (they renamed the library too, libpng12.a). The remainder of the include directories that weren't in my list may be essential for building all the supplibs in a coherent way, but they are not necessary for compiling GrADS -- I generally extract only what GrADS needs from a complete library installation and put that into my supplibs location. I should mention that I never build with GUI, so I don't know what's required there. The pkgconfig files are a very user-friendly; I hadn't looked at them before. I was using executables like "ncdap-config --libs" which were giving me inconsistent results. --Jennifer On Aug 8, 2008, at 9:45 PM, Arlindo da Silva wrote: > On Fri, Aug 8, 2008 at 11:25 AM, Jennifer Adams <jm...@co...> > wrote: >> Dear All, >> I have been poring over the configure scripts. The whole thing got >> complicated quickly trying to prioritize supplibs v. system >> libraries and >> factor in the --with and --enable switches. > > I believe you... > >> I quickly realized that it could >> take a really long time to get it all straightened out, and I >> don't have the >> right expertise to do that anyway. So, to simplify things for >> myself, I >> focused on getting it right when looking in SUPPLIBS, and will >> leave the >> dynamic checking in the capable hands of Pat and Arlindo and >> anyone else who >> contributed to those *.m4 macros. I am eager to put out 2.0.a3, so >> I going >> to release what I've done so far, and that will allow more time >> for you guys >> to make tweaks and adjustments at a more relaxed pace. > > I'd need some guidance from you here. The build scripts in tag > grads-2_0_a2_oga-1 was my best attempt to build GrADS 2 with the > supplibs and the so-called "dynamic supplibs"; so far as I can tell > these were working, at least on darwin ppc/intel, Linux i686, x86_64, > and freebsd (based on passing the test suite). I did this by adapting > the stuff Pat had done for v1.9.0-rc1, and he later on revised what I > did. In converting the v1.9 build I tried to cleanup as much legacy > stuff as I could, but perhaps I left some debris here or there. > > Would I start tweaking it I would probably end up a place not too far > from the build scripts in 2.0.a2-oga.1 (there are minor C code changes > from COLA's v2.0.a2 but these are not related to the build.) I'll need > to understand which of features of the 2.0.a2-oga.1 build you object > so that I do not repeat the same mistake. Perhaps a face-to-face merge > exercise would be he most efficient way of getting this done. > >> It should build with >> Arlindo's gigantic supplibs tarball unpacked and compiled, but you'll >> probably need to set an environment variable SUPPLIBS to point to >> it, since >> configure.ac will only look in the top directory and one level >> above for a >> directory named "supplibs". > > The instructions on the wiki tell you to symlink the untarred supplibs > to the plain "supplibs" name, just as you require. > > BTW, are you making use of pkgconfig where appropriate? The > supplibs-2.0.x are built with their own version of pkg-config and many > of the packages are instrumented to use it, e.g., > > gadap.pc > libcurl.pc > libdap.pc > libdapclient.pc > libdapserver.pc > libpng.pc > libsx.pc > libxml-2.0.pc > > By using pkgconfig you get all the necessary flags for the build, and > the *.m4 macros take advantage of it. > >> At this point, the biggest noticeable change is >> that 2.0.a3 will require subdirectories under supplibs/include/ >> like this: >> dap/ >> gd/ >> grib2/ >> hdf/ >> libpng12/ >> netcdf/ >> readline/ >> udunits/ >> zlib/ > > Is this list supposed to be comprehensive? Currently, the > supplibs-2.0.1 have the following structure under include/ > > X11/ <====== (neXawt) > curl/ <===== (needed for build portability) > gadap/ <======= > gd/ > grib2c/ <===== (name change) > hdf/ > jasper/ [grib2c] > jpeg/ [hdf] > libdap/ <===== (name change) > libnc-dap/ <====== > libpng/ <==== (name change) > libsx/ <===== [athena] > libxml2/ <==== (needed for build portability [dap]) > ncurses/ <====== (needed for portability [readline]) > netcdf/ > readline/ > szlib/ <======= (needed for *reading* sziped files [hdf]) > udunits/ > zlib/ > > The "<====" above indicate discrepancies. We have built the > supplibs-2.0.1 on a number of platforms. If you could preserve the > names above it would not require us to go back have to rebuild all of > these again... Not a big deal, but kind of time consuming. > >> The configure.ac algorithm is nominally like this: >> $use_feature=no >> if $with_feature != no >> if (supplibs has required libraries and include files to >> support feature) >> ; then >> $use_feature=yes >> fi >> if $use_feature=no (i.e., not found in supplibs) and >> $ga_dyn_supplibs=yes, then >> use dynamic macros to find libraries >> fi >> fi >> Forcing the use of dynamic libraries is achieved by not having a >> supplibs >> directory. >> Forcing the use of ONLY supplibs is achieved by using the >> configure switch >> "--disable-dyn-supplibs". >> The dynamic macros I copied almost verbatim from the opengrads m4 >> directory. >> I may have changed a name or two for clarity. This will be code >> that I am >> going to generally ignore and leave for you guys to support, since >> I will >> always be building from supplibs. But I would like for it to work, >> so please >> send me patches and changes and I will check them in. >> The --with-* arguments are trickier, since there are some that >> should be >> just yes/no and others that provide directory locations. The >> --with-package=yes/no switches that I used are: >> --with-readline command line editing >> --with-printim image output >> --with-grib2 GRIB2 data format >> --with-sdf self-describing formats (HDF and NetCDF) >> --with-dap extra gradsdap executable, OPeNDAP-enabled >> --with-gui Athena X11 widget-based GUI >> The remainders are in the dynamic *.m4 macros. I used --with-sdf >> to avoid >> conflicts with --with-hdf and --with-netcdf arguments in the dynamic >> macros. >> I generally avoid the -l<libname> syntax when using supplibs. The >> only >> exceptions are the -lncurses/-ltermcap thing with readline and >> linking with >> libdap and libnc-dap always requires a few extra libs. > > pkgconfig usually takes care of these details. > >> I put libcurl.a and >> libxml2.a in supplibs/lib, but there are still others, and these >> are not the >> same for every OS. The dynamic macros use the output from "ncdap- >> config >> --libs", but on my mac this left out some of the required ones so >> I have >> hard-coded a kludge: >> if test "$is_darwin" = "yes" ; then >> dap_extra_libs="-lssl -lcrypto -lpthread -liconv -lm" >> else >> dap_extra_libs="-lidn -lssl -lcrypto -ldl -lpthread -lm" >> fi >> dap_libs="$gadap_lib $dap_libs $dap_extra_libs" >> This syntax gives me what I need to build on our mac and linux >> boxes, but >> will probably be wrong for sunOS and others. Since we have checks for >> host-specific options, any platform-specific dap_extra_libs can be >> added as >> necessary. > > Consider using pkgconfig. None better than the library developers to > know what is required for a given version; pkgconfig provides the > mechanism for them to convey this information. > >> Finally, I had wanted to include library version numbers in the 'q >> config' >> output, but that turned out to be tricky if the library did not >> contain a >> routine for spitting out a version string. Netcdf has >> nc_inq_libvers(), but >> many of the others simply have #define statements in the header >> files, but >> this was highly version-dependent and will cause problems if using >> system >> libraries instead of supplibs. I left some of that code in gacfg.c >> but other >> bits are commented out. If you guys have any ideas for how to do >> this, maybe >> there's a way to do it during the configuration process and >> populate GrADS's >> own config.h with strings like #define GA_ZLIB_VERSION 1.2.3 ... then >> gacfg.c need only look in config.h to get that info. > > The OpenGrADS supplibs have a tag corresponding to each supplib > version, say 2.0.1 (the one I use to build grads2). In the very least, > gacfg.c could report the supplibs version used for the build. I may > need to add a way for this version number to be retrieved... > > For tracking the version of the individual packages, as long as the > packages are using autoconf (true for supplibs-2.0.x) you can get the > version number by parsing configure.ac/configure.in during the > supplibs build, e.g., > > % grep ^AC_INIT netcdf/configure.ac > AC_INIT([netCDF], [3.6.2], [su...@un...]) > > A simple script could added to the supplibs build to compile this > information in a simple text file, say "supplibs.h". Are you willing > to adopt (and help maintain) the supplibs-2.0.x? > >> Well, that's enough. If you've read this far, I thank you >> sincerely for your >> attention to these arcane details. > > This is the reality of autoconf. > > 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-08-09 01:45:48
|
On Fri, Aug 8, 2008 at 11:25 AM, Jennifer Adams <jm...@co...> wrote: > Dear All, > I have been poring over the configure scripts. The whole thing got > complicated quickly trying to prioritize supplibs v. system libraries and > factor in the --with and --enable switches. I believe you... > I quickly realized that it could > take a really long time to get it all straightened out, and I don't have the > right expertise to do that anyway. So, to simplify things for myself, I > focused on getting it right when looking in SUPPLIBS, and will leave the > dynamic checking in the capable hands of Pat and Arlindo and anyone else who > contributed to those *.m4 macros. I am eager to put out 2.0.a3, so I going > to release what I've done so far, and that will allow more time for you guys > to make tweaks and adjustments at a more relaxed pace. I'd need some guidance from you here. The build scripts in tag grads-2_0_a2_oga-1 was my best attempt to build GrADS 2 with the supplibs and the so-called "dynamic supplibs"; so far as I can tell these were working, at least on darwin ppc/intel, Linux i686, x86_64, and freebsd (based on passing the test suite). I did this by adapting the stuff Pat had done for v1.9.0-rc1, and he later on revised what I did. In converting the v1.9 build I tried to cleanup as much legacy stuff as I could, but perhaps I left some debris here or there. Would I start tweaking it I would probably end up a place not too far from the build scripts in 2.0.a2-oga.1 (there are minor C code changes from COLA's v2.0.a2 but these are not related to the build.) I'll need to understand which of features of the 2.0.a2-oga.1 build you object so that I do not repeat the same mistake. Perhaps a face-to-face merge exercise would be he most efficient way of getting this done. > It should build with > Arlindo's gigantic supplibs tarball unpacked and compiled, but you'll > probably need to set an environment variable SUPPLIBS to point to it, since > configure.ac will only look in the top directory and one level above for a > directory named "supplibs". The instructions on the wiki tell you to symlink the untarred supplibs to the plain "supplibs" name, just as you require. BTW, are you making use of pkgconfig where appropriate? The supplibs-2.0.x are built with their own version of pkg-config and many of the packages are instrumented to use it, e.g., gadap.pc libcurl.pc libdap.pc libdapclient.pc libdapserver.pc libpng.pc libsx.pc libxml-2.0.pc By using pkgconfig you get all the necessary flags for the build, and the *.m4 macros take advantage of it. > At this point, the biggest noticeable change is > that 2.0.a3 will require subdirectories under supplibs/include/ like this: > dap/ > gd/ > grib2/ > hdf/ > libpng12/ > netcdf/ > readline/ > udunits/ > zlib/ Is this list supposed to be comprehensive? Currently, the supplibs-2.0.1 have the following structure under include/ X11/ <====== (neXawt) curl/ <===== (needed for build portability) gadap/ <======= gd/ grib2c/ <===== (name change) hdf/ jasper/ [grib2c] jpeg/ [hdf] libdap/ <===== (name change) libnc-dap/ <====== libpng/ <==== (name change) libsx/ <===== [athena] libxml2/ <==== (needed for build portability [dap]) ncurses/ <====== (needed for portability [readline]) netcdf/ readline/ szlib/ <======= (needed for *reading* sziped files [hdf]) udunits/ zlib/ The "<====" above indicate discrepancies. We have built the supplibs-2.0.1 on a number of platforms. If you could preserve the names above it would not require us to go back have to rebuild all of these again... Not a big deal, but kind of time consuming. > The configure.ac algorithm is nominally like this: > $use_feature=no > if $with_feature != no > if (supplibs has required libraries and include files to support feature) > ; then > $use_feature=yes > fi > if $use_feature=no (i.e., not found in supplibs) and > $ga_dyn_supplibs=yes, then > use dynamic macros to find libraries > fi > fi > Forcing the use of dynamic libraries is achieved by not having a supplibs > directory. > Forcing the use of ONLY supplibs is achieved by using the configure switch > "--disable-dyn-supplibs". > The dynamic macros I copied almost verbatim from the opengrads m4 directory. > I may have changed a name or two for clarity. This will be code that I am > going to generally ignore and leave for you guys to support, since I will > always be building from supplibs. But I would like for it to work, so please > send me patches and changes and I will check them in. > The --with-* arguments are trickier, since there are some that should be > just yes/no and others that provide directory locations. The > --with-package=yes/no switches that I used are: > --with-readline command line editing > --with-printim image output > --with-grib2 GRIB2 data format > --with-sdf self-describing formats (HDF and NetCDF) > --with-dap extra gradsdap executable, OPeNDAP-enabled > --with-gui Athena X11 widget-based GUI > The remainders are in the dynamic *.m4 macros. I used --with-sdf to avoid > conflicts with --with-hdf and --with-netcdf arguments in the dynamic > macros. > I generally avoid the -l<libname> syntax when using supplibs. The only > exceptions are the -lncurses/-ltermcap thing with readline and linking with > libdap and libnc-dap always requires a few extra libs. pkgconfig usually takes care of these details. > I put libcurl.a and > libxml2.a in supplibs/lib, but there are still others, and these are not the > same for every OS. The dynamic macros use the output from "ncdap-config > --libs", but on my mac this left out some of the required ones so I have > hard-coded a kludge: > if test "$is_darwin" = "yes" ; then > dap_extra_libs="-lssl -lcrypto -lpthread -liconv -lm" > else > dap_extra_libs="-lidn -lssl -lcrypto -ldl -lpthread -lm" > fi > dap_libs="$gadap_lib $dap_libs $dap_extra_libs" > This syntax gives me what I need to build on our mac and linux boxes, but > will probably be wrong for sunOS and others. Since we have checks for > host-specific options, any platform-specific dap_extra_libs can be added as > necessary. Consider using pkgconfig. None better than the library developers to know what is required for a given version; pkgconfig provides the mechanism for them to convey this information. > Finally, I had wanted to include library version numbers in the 'q config' > output, but that turned out to be tricky if the library did not contain a > routine for spitting out a version string. Netcdf has nc_inq_libvers(), but > many of the others simply have #define statements in the header files, but > this was highly version-dependent and will cause problems if using system > libraries instead of supplibs. I left some of that code in gacfg.c but other > bits are commented out. If you guys have any ideas for how to do this, maybe > there's a way to do it during the configuration process and populate GrADS's > own config.h with strings like #define GA_ZLIB_VERSION 1.2.3 ... then > gacfg.c need only look in config.h to get that info. The OpenGrADS supplibs have a tag corresponding to each supplib version, say 2.0.1 (the one I use to build grads2). In the very least, gacfg.c could report the supplibs version used for the build. I may need to add a way for this version number to be retrieved... For tracking the version of the individual packages, as long as the packages are using autoconf (true for supplibs-2.0.x) you can get the version number by parsing configure.ac/configure.in during the supplibs build, e.g., % grep ^AC_INIT netcdf/configure.ac AC_INIT([netCDF], [3.6.2], [su...@un...]) A simple script could added to the supplibs build to compile this information in a simple text file, say "supplibs.h". Are you willing to adopt (and help maintain) the supplibs-2.0.x? > Well, that's enough. If you've read this far, I thank you sincerely for your > attention to these arcane details. This is the reality of autoconf. Arlindo -- Arlindo da Silva da...@al... |
|
From: Jennifer A. <jm...@co...> - 2008-08-08 16:11:40
|
Dear All,
I have been poring over the configure scripts. The whole thing got
complicated quickly trying to prioritize supplibs v. system libraries
and factor in the --with and --enable switches. I quickly realized
that it could take a really long time to get it all straightened out,
and I don't have the right expertise to do that anyway. So, to
simplify things for myself, I focused on getting it right when
looking in SUPPLIBS, and will leave the dynamic checking in the
capable hands of Pat and Arlindo and anyone else who contributed to
those *.m4 macros. I am eager to put out 2.0.a3, so I going to
release what I've done so far, and that will allow more time for you
guys to make tweaks and adjustments at a more relaxed pace. It should
build with Arlindo's gigantic supplibs tarball unpacked and compiled,
but you'll probably need to set an environment variable SUPPLIBS to
point to it, since configure.ac will only look in the top directory
and one level above for a directory named "supplibs". At this point,
the biggest noticeable change is that 2.0.a3 will require
subdirectories under supplibs/include/ like this:
dap/
gd/
grib2/
hdf/
libpng12/
netcdf/
readline/
udunits/
zlib/
The configure.ac algorithm is nominally like this:
$use_feature=no
if $with_feature != no
if (supplibs has required libraries and include files to support
feature) ; then
$use_feature=yes
fi
if $use_feature=no (i.e., not found in supplibs) and
$ga_dyn_supplibs=yes, then
use dynamic macros to find libraries
fi
fi
Forcing the use of dynamic libraries is achieved by not having a
supplibs directory.
Forcing the use of ONLY supplibs is achieved by using the configure
switch "--disable-dyn-supplibs".
The dynamic macros I copied almost verbatim from the opengrads m4
directory. I may have changed a name or two for clarity. This will be
code that I am going to generally ignore and leave for you guys to
support, since I will always be building from supplibs. But I would
like for it to work, so please send me patches and changes and I will
check them in.
The --with-* arguments are trickier, since there are some that should
be just yes/no and others that provide directory locations. The --
with-package=yes/no switches that I used are:
--with-readline command line editing
--with-printim image output
--with-grib2 GRIB2 data format
--with-sdf self-describing formats (HDF and NetCDF)
--with-dap extra gradsdap executable, OPeNDAP-enabled
--with-gui Athena X11 widget-based GUI
The remainders are in the dynamic *.m4 macros. I used --with-sdf to
avoid conflicts with --with-hdf and --with-netcdf arguments in the
dynamic macros.
I generally avoid the -l<libname> syntax when using supplibs. The
only exceptions are the -lncurses/-ltermcap thing with readline and
linking with libdap and libnc-dap always requires a few extra libs. I
put libcurl.a and libxml2.a in supplibs/lib, but there are still
others, and these are not the same for every OS. The dynamic macros
use the output from "ncdap-config --libs", but on my mac this left
out some of the required ones so I have hard-coded a kludge:
if test "$is_darwin" = "yes" ; then
dap_extra_libs="-lssl -lcrypto -lpthread -liconv -lm"
else
dap_extra_libs="-lidn -lssl -lcrypto -ldl -lpthread -lm"
fi
dap_libs="$gadap_lib $dap_libs $dap_extra_libs"
This syntax gives me what I need to build on our mac and linux boxes,
but will probably be wrong for sunOS and others. Since we have checks
for host-specific options, any platform-specific dap_extra_libs can
be added as necessary.
Finally, I had wanted to include library version numbers in the 'q
config' output, but that turned out to be tricky if the library did
not contain a routine for spitting out a version string. Netcdf has
nc_inq_libvers(), but many of the others simply have #define
statements in the header files, but this was highly version-dependent
and will cause problems if using system libraries instead of
supplibs. I left some of that code in gacfg.c but other bits are
commented out. If you guys have any ideas for how to do this, maybe
there's a way to do it during the configuration process and populate
GrADS's own config.h with strings like #define GA_ZLIB_VERSION
1.2.3 ... then gacfg.c need only look in config.h to get that info.
Well, that's enough. If you've read this far, I thank you sincerely
for your attention to these arcane details.
--Jennifer
--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...
|
|
From: Patrice D. <per...@fr...> - 2008-08-04 12:31:50
|
On Fri, Aug 01, 2008 at 12:59:47PM -0400, Jennifer Adams wrote: > A fully-features OPeNDAP-enabled GrADS needs two things: libnc-dap and > libgadap. The station data interface is not so widely used as gridded > data, but it is still extremely important. Indeed, but what a user want may not be a fully-featured GrADS, so the build should proceed with what the user has. In fedora, we add all the features we can add, so when I have time, I'll submit libgadap for inclusion in fedora if the license is free software. I currently don't have time, but certainly in a few weeks. -- Pat |
|
From: Patrice D. <per...@fr...> - 2008-08-04 12:28:44
|
On Fri, Aug 01, 2008 at 12:45:46PM -0400, Arlindo da Silva wrote: > On Fri, Aug 1, 2008 at 12:08 PM, Patrice Dumas <per...@fr...> wrote: > > Or even for v1.9; in going to the new libdap there have been API level > changes that make it impossible to build against an old libdods. Being > able to use an old libgadods with gcc-2.95 is just too much trouble > and in my judgement, not worth it. libgadap/libgadods is not grads. There is an interface between them. The gadap/gadods interface may be stable and hide the libdap changes. > Perhaps we could take a bold step: build just one grads which is > nc-dap enabled; and have "gradsnc" built as an option for those who > need it. One could certainly try it out and see if the users can live > with a single grads. My guess is that it would work just fine. So, > you just add a single switch That could be doable, since libnc-dap also brings in netcdf support. So to have gradsnc one would build with different options and it wouldn't be possible to have both in one build. Is it what you are proposing? -- Pat |
|
From: Jennifer A. <jm...@co...> - 2008-08-01 16:59:56
|
A fully-features OPeNDAP-enabled GrADS needs two things: libnc-dap and libgadap. The station data interface is not so widely used as gridded data, but it is still extremely important. By the way, please look at ftp://grads.iges.org/grads/Supplibs/2.0/ src/gadap-2.0.tar.gz and let me know if I got everything right. I have changed the copyright, build scripts, m4 macros, version number, etc. Jennifer On Aug 1, 2008, at 12:45 PM, Arlindo da Silva wrote: > On Fri, Aug 1, 2008 at 12:08 PM, Patrice Dumas <per...@fr...> > wrote: >> On Fri, Aug 01, 2008 at 11:44:15AM -0400, Jennifer Adams wrote: >>> Very persuasive. I guess it depends a lot on which libraries we're >>> talking about. It's not fair to lump HDF into the same category >>> as DODS, >>> which is far more aggravating to support. But if you have an old >>> box with >>> gcc 2.95, you just can't have an opendap-enabled build of GrADS 2.0. >> > > Or even for v1.9; in going to the new libdap there have been API level > changes that make it impossible to build against an old libdods. Being > able to use an old libgadods with gcc-2.95 is just too much trouble > and in my judgement, not worth it. > >> Indeed, but gcc 2.95 is very very old. With anything above you can >> certainly (maybe with some stl implementation). Besides, grads >> doesn't >> link against libdap, but against libncdap which has a far better >> binary >> stability. and we can imagine that the binary compatibility will >> never >> break, so this gives room for backward compatibility at the source >> level. >> > > Except for the size of the binary, gradsdap appears just as stable as > "grads" built with the vanilla netcdf. Do you have any evidence that > it adds any performance penalty besides the start up time? > > Perhaps we could take a bold step: build just one grads which is > nc-dap enabled; and have "gradsnc" built as an option for those who > need it. One could certainly try it out and see if the users can live > with a single grads. My guess is that it would work just fine. So, > you just add a single switch > > --with-nc-dap (default) > --without-nc-dap > > This would really simplify the build... > > > 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-08-01 16:45:36
|
On Fri, Aug 1, 2008 at 12:08 PM, Patrice Dumas <per...@fr...> wrote:
> On Fri, Aug 01, 2008 at 11:44:15AM -0400, Jennifer Adams wrote:
>> Very persuasive. I guess it depends a lot on which libraries we're
>> talking about. It's not fair to lump HDF into the same category as DODS,
>> which is far more aggravating to support. But if you have an old box with
>> gcc 2.95, you just can't have an opendap-enabled build of GrADS 2.0.
>
Or even for v1.9; in going to the new libdap there have been API level
changes that make it impossible to build against an old libdods. Being
able to use an old libgadods with gcc-2.95 is just too much trouble
and in my judgement, not worth it.
> Indeed, but gcc 2.95 is very very old. With anything above you can
> certainly (maybe with some stl implementation). Besides, grads doesn't
> link against libdap, but against libncdap which has a far better binary
> stability. and we can imagine that the binary compatibility will never
> break, so this gives room for backward compatibility at the source level.
>
Except for the size of the binary, gradsdap appears just as stable as
"grads" built with the vanilla netcdf. Do you have any evidence that
it adds any performance penalty besides the start up time?
Perhaps we could take a bold step: build just one grads which is
nc-dap enabled; and have "gradsnc" built as an option for those who
need it. One could certainly try it out and see if the users can live
with a single grads. My guess is that it would work just fine. So,
you just add a single switch
--with-nc-dap (default)
--without-nc-dap
This would really simplify the build...
Arlindo
--
Arlindo da Silva
da...@al...
|
|
From: Patrice D. <per...@fr...> - 2008-08-01 16:08:11
|
On Fri, Aug 01, 2008 at 11:44:15AM -0400, Jennifer Adams wrote: > Very persuasive. I guess it depends a lot on which libraries we're > talking about. It's not fair to lump HDF into the same category as DODS, > which is far more aggravating to support. But if you have an old box with > gcc 2.95, you just can't have an opendap-enabled build of GrADS 2.0. Indeed, but gcc 2.95 is very very old. With anything above you can certainly (maybe with some stl implementation). Besides, grads doesn't link against libdap, but against libncdap which has a far better binary stability. and we can imagine that the binary compatibility will never break, so this gives room for backward compatibility at the source level. -- Pat |
15 messages has been excluded from this view by a project administrator.
