~yves-pelletier/libecbufr/documentation

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
Description:

LibECBUFR: Environment Canada BUFR Library

It is designed as a simple to use, Templates oriented, general purposes
library for reading and writing BUFR messages.  Using one single interface
for both reading and writing.


History:

libECBUFR originated from an older BUFR encoding library which was created
in 1994 within a project named GEWEX aka MOLTS (Model Output Local Time
Series) in which a BUFR encoder was needed to convert model forecast time
series into BUFR files for exchange purposes.  At that time, the library
was only capable of encoding BUFR.  At the beginning of summer 2007,
it became apparent that a number of needs across Environment Canada
could only be met with a unified approach to BUFR programming.
Soon afterwards, the need for a library capable of reading and writing BUFR
files based on templates was identified. A national requirement analysis
and a survey of available free and commercial software was conducted.
The conclusion was that while there are excellent BUFR software packages
available, the needs expressed in the Canadian context would be best met
with in-house software.

At the end of summer 2007, a prototype of the library was created
using the old BUFR encoding library. Also, new decoding functions along
with template support functions were added to the library.  At the end
of october (after 2 months), a working new BUFR library was born, which
allows applications to easily read and writes BUFR files using templates.

See the Examples directory for how to encode and decode BUFR using
this library.

For compiling, see INSTALL


Note to Developpers who Wish to Contribute
==========================================

Software Used
-------------

 - The autotools (autoconf, automake, configure) are used to generate 
   the Makefiles.
   http://www.gnu.org/software/autoconf/manual/
   http://www.gnu.org/software/automake/manual/

 - Libtool is used with the autotools to generate the libraries 
   automatically for any platform.
   http://www.gnu.org/software/libtool/manual/

 - Doxygen is used to automatically generate documentation from source code 
   comments.
   http://www.doxygen.org/

Standards
---------

This project follows certain standards.  Here is a list of standards that
should be followed when contributing to the libECBUFR project:

 - The NEWS file should contain a dated annoucement for every public release.
 - When a bug or an issue is found, always report it
 - Any public release of libECBUFR should have a different version.
 - The major version number (first number) should be changed when libECBUFR 
   acquires such a major change that it loses some backward compatibility. 
 - The minor version number (second number) should be changed when 
   the library acquires a new fonctionality, but maintains backward 
   compatibility. Something new from the user's point of view, like a new
   argument added to a function is enough to change the minor version number.
 - The micro version number (third number) should be changed when bugs are 
   fixed. Essentially, when the micro version number changes, one should 
   assume that the library does exactly the same thing but has clearer 
   documentation, fewer bugs, something might be implemented differently, 
   but it should be transparent for the user, etc...

 - When one is about to commit a change, one should make sure 
   the change is recorded in the Changelog file, and the entry in bug tracking 
   is updated before proceeding.

 - Don't forget to update your working directory before commiting any changes,
   if possible.

 - When you work in a branch for a modification that isn't trivial, 
   you should merge the bugfixes from the trunk regularily if relevant,
   so that you don't get yourself in a position where you need to merge 
   a huge amount of differences later on. The inverse is also true, 
   so don't forget to merge back in the trunk the bugs you fix in your branch.

- Contributions from parties outside Environment Canada may be considered for
  merge into trunk after evaluation.  If the contributed code source is distinct
  from the bulk of already-existing libECBUFR code, contributors may choose to
  retain their copyright, as long as they contribute the code under the LGPL,
  Version 3. If the code is mixed with existing Environment Canada code, we would
  kindly ask that you consider assigning the copyright to Environment Canada.