Hyrax - Build the Shrew Project: Difference between revisions

From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽
(Created page with "= What to Checkout = = Configuring Prior to the Build = = Different Ways to Build = = Testing and Running the Server =")
 
Line 1: Line 1:
= What to Checkout =
= What to Checkout =
There are two main 'shrew' projects active at any given time: The project actually named ''shrew'' which is located on the trunk of our subversion repository and a second version of tis project located on a branch that corresponds to the current release of the Hyrax server. The trunk copy of shrew if for active development while the branch is used for fixes made to a specific release. By convention, the release branches are all named 'hyrax_''version''_release', where ''version'' is a two digit number like '1.8'.
The 'trunk shrew' should be used if you're developing new features for libdap or the BES or if you're developing new features that will depend on changes to them. The release branch should be used for fixes to a release (and there is some complicated processes that must be followed to ensure those fixes are merged back to the trunk so they can be included in future version) or if you're developing new features for a handler and that development will benefit from a stable set of libdap and BES versions. The latter means that servers can use you handler/module changes without updating the entire server (but you must be very careful regarding libdap and BES ABI compatibility).
To check out:
;The trunk ''shrew'' project: ''svn co $svn/trunk/shrew''
;The release branch of shrew: ''svn co $svn/branch/shrew/hyrax_1.8_release'' (note that you can browse around on scm.opendap.org/trac/branch/shrew to see which versions are there).
Note that ''shrew'' uses svn externals, so the 'shrew' checkout really means you are checking out a directory with some build files and then performing a number of other checkouts. The result is a collection of projects all rooted in one place. The 'mater project' contains the build files that tie the entire ting together. You could do all of this by hand; the shrew project checkout is much easier.
To check the externals being used, get the property in the shrew directory you checked out:
<tt>svn propget svn:externals</tt>
which for the trunk shrew returns:
<pre>
aries@chinchilla$ svn propget svn:externals
^/trunk/libdap src/libdap
^/trunk/bes src/bes
^/trunk/dap-server src/modules/dap-server
^/trunk/freeform_handler src/modules/freeform_handler
^/trunk/fileout_netcdf src/modules/fileout_netcdf
^/trunk/netcdf_handler src/modules/netcdf_handler
^/trunk/hdf4_handler src/modules/hdf4_handler
^/trunk/hdf5_handler src/modules/hdf5_handler
^/trunk/ncml_module src/modules/ncml_module
^/trunk/wcs_gateway_module src/modules/wcs_gateway_module
^/trunk/wcs_module src/modules/wcs_module
^/trunk/olfs src/olfs
</pre>


= Configuring Prior to the Build =
= Configuring Prior to the Build =

Revision as of 01:16, 8 May 2012

What to Checkout

There are two main 'shrew' projects active at any given time: The project actually named shrew which is located on the trunk of our subversion repository and a second version of tis project located on a branch that corresponds to the current release of the Hyrax server. The trunk copy of shrew if for active development while the branch is used for fixes made to a specific release. By convention, the release branches are all named 'hyrax_version_release', where version is a two digit number like '1.8'.

The 'trunk shrew' should be used if you're developing new features for libdap or the BES or if you're developing new features that will depend on changes to them. The release branch should be used for fixes to a release (and there is some complicated processes that must be followed to ensure those fixes are merged back to the trunk so they can be included in future version) or if you're developing new features for a handler and that development will benefit from a stable set of libdap and BES versions. The latter means that servers can use you handler/module changes without updating the entire server (but you must be very careful regarding libdap and BES ABI compatibility).

To check out:

The trunk shrew project
svn co $svn/trunk/shrew
The release branch of shrew
svn co $svn/branch/shrew/hyrax_1.8_release (note that you can browse around on scm.opendap.org/trac/branch/shrew to see which versions are there).

Note that shrew uses svn externals, so the 'shrew' checkout really means you are checking out a directory with some build files and then performing a number of other checkouts. The result is a collection of projects all rooted in one place. The 'mater project' contains the build files that tie the entire ting together. You could do all of this by hand; the shrew project checkout is much easier.

To check the externals being used, get the property in the shrew directory you checked out:

svn propget svn:externals

which for the trunk shrew returns:

aries@chinchilla$ svn propget svn:externals
^/trunk/libdap src/libdap
^/trunk/bes src/bes
^/trunk/dap-server src/modules/dap-server
^/trunk/freeform_handler src/modules/freeform_handler
^/trunk/fileout_netcdf src/modules/fileout_netcdf
^/trunk/netcdf_handler src/modules/netcdf_handler
^/trunk/hdf4_handler src/modules/hdf4_handler
^/trunk/hdf5_handler src/modules/hdf5_handler
^/trunk/ncml_module src/modules/ncml_module
^/trunk/wcs_gateway_module src/modules/wcs_gateway_module
^/trunk/wcs_module src/modules/wcs_module
^/trunk/olfs src/olfs

Configuring Prior to the Build

Different Ways to Build

Testing and Running the Server