opengrads-devel

[Opengrads-devel] Wgrib2 and autotools

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

Wes,
   I am waiting for Pat to double check my instrumentation of wgrib2 with
the GNU autotools. I want to make sure it has all the necessary elements for
Pat to include it as a Fedora package. In the meantime, here are a few
guidelines for developing wgrib2 under autotools:

0) Here are the links for autoconf/automake in case you want to learn more
about these:

http://www.gnu.org/software/autoconf/manual/autoconf.html

http://www.gnu.org/software/automake/manual/automake.html


1) If you do not add any new file, just update the existing C sources, and
eventually update the package version. This is done in the top file "
configure.ac". Just edit the line near the top:

    AC_INIT(wgrib2, [0.1.7])

  replacing the 0.1.7 with whatever new version you would like. Once you do
that, type

  % autoreconf

  to regenerate configure/Makefile.in/Config.h.in. Then check back in the
modfied sources. The version appearing in the sources and tarballs will be
derived from this, no need to update the version elsewhere.

2) If you add a new Function, regular C source, or any *.dat or *.table file
run this script

  % cd src/
  % ./am_sources.sh

  which will recreate "am_sources.mk". (Automake restricts the use of *.c in
Makefile.am) Then do a "autoreconf" from the top dir as in 1).

3) If you need to customize the build, you usually edit file "Makefile.am"
and sometimes "configure.ac". Never edit configure, configure.h,
configure.h.in, Makefile, Makefile.in: these are automatically created from
"configure.ac", "Makefile.am". The actual "Makefile" is not meant to be
readable by humans.

4) I added the standard AUTHORS, ChangeLog, COPYING, INSTALL, NEWS, etc
files at the top per the GNU coding standards. You can read more about these
here:

  http://www.gnu.org/prep/standards/standards.html#NEWS-File

  and have used content from original sources/website to populate these.
Please check if this is adequate.



BTW, what is the current wgrib2 version: "0.1.7" or "1.7.0" ?

 Are the sources in the repo ready for a round of builds? Here are the
platforms I have in mind: Windows, Darwin Intel, Darwin PPC, i686, x86_64,
Altix ia64, IRIX64, FreeBSD. I can post the binaries on sf.net or else make
them available for you to post them on your site. Let me know what you would
like to do.

Hoop: would you be able to produce a solaris build? It should build out of
the box if you have the supplibs.

      Arlindo

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

Re: [Opengrads-devel] Wgrib2 and autotools

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

Wes et al,
  I just added a very rudimentary test suite, using PyUnit to organize the
tests. This is similar to what I did for GrADS; I have some notes here:

  http://opengrads.org/wiki/index.php?title=PyTests:_GrADS_Test_Suite

 The wgrib2 implementation is simpler than the one in grads as we only have
one executable (wgrib2) and only one type of input file (grib 2).

 After you build wgrib2, just type

% make check

and it will run all tests.

We need more test cases!!! In principle, each command line option should
have its own unit test.  Right now I have a single test data file (under
data/model_25.grb2) something the Mike Fiorino prepared for me for testing
grads v2. This single file could be used for most if not all test cases.

To add a new test, just add a new python function that starts with "test_"
in file pytests/TestModelFile.py - no other change is required. For example,
to test the -min/-max options I added the function:

    def test_opt_minmax(self):
        result = self.g2('-d 1 -min -max ')
        self.assertEqual(result[0],'1:0:min=10664.5:max=12531.1\n')
        result = self.g2('-d 33 -min -max ')
        self.assertEqual(result[0],'33:322100:min=95073.8:max=104675\n')
        result = self.g2('-d 67 -min -max')
        self.assertEqual(result[0],'67:676013:min=94670.3:max=104569\n')

The statement

        result = self.g2('-d 1 -min -max ')

runs

 ../src/wgrib2 -d 1 -min -max data/model_25.grb2

and captures the result in 'result'. The statement:

        self.assertEqual(result[0],'1:0:min=10664.5:max=12531.1\n')

compares the result with an expected (hard coded) outcome. This receipt can
be used for all the options producing simple ASCII output. For binary files,
one could produce the binary file and check the md5sum against a hardcoded
value, this way keeping the distribution tarball small enough. I can help
with the python wiring of the test cases, but it would be better for people
familiar with wgrib2 (i.e., developers) to come up with the actual tests.

  Take my word for it: a test suite is worth its weight in gold, specially
when porting to a new platform.

  To get the latest wgrib2 sources:

% gacvs co -P Wgrib2

and you should get the new pytests/ directory, including the test data.

   Arlindo

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