SCORE Maintenance

This describes how to become a SCORE maintainer. One good reason is to make a new build for inclusion in a DDS. Another is to join a club that is nearly as exclusive as the Moonwalkers'.

Environment

For Windows, a desk maintainer environment obtained by installing the score-trac-maintainer-tools package from category Deos-bundles is the recommended environment. See install for more.

README PC installation provides a detailed description of the necessary Cygwin installation (if you are not installing a DESK or need information about sizes and environment variables).

Linux 2.6.18 and newer should provide the necessary tools natively.

SCORE building requires a Bash shell (the top level build script checks that the expected tools are present).

A SCORE Native compiler must be installed manually for a non-desk maintainer environment. For Windows, e.g. build 287 from DDS-20150910 may be used (build 281 from DDS-20120822 is the classic tool compiler which has seen service for over a decade). For Linux (e.g. linux03 or linux04), the preferred compiler is build 256 that can be found in ~jon/SCORE_DIR.

Installing SCORE build 288 in an old baseline such as Greys may require a patch (if /SCORE/common/bin/dacs_private/set_errorlevel.exe does not exist). Locate a set_errorlevel.exe in any SCORE installation then patch as follows from a DESK bash prompt:

 $ mkdir -p /SCORE/common/bin/dacs_private
 $ cp -p <path-to-set_errorlevel.exe> /SCORE/common/bin/dacs_private/

Checkout

Check out svnco using any svn client and run it from the directory where you want your SCORE_dev checkout to appear. Extra parameters can provide e.g. SVN credentials (if checking out as user scoretest); see script for examples. The script is also useful for checking out SCORE_test (see Testing) and TRAC_dev.

The primary reason for this script is to get commit time stamps on files (such as headers) that appear directly in the final build. Another reason is that some internal dependencies exist (at least in the dera component) that cause the build to fail if certain files have check out time stamps; don't worry - these files are highly unlikely to require updating in the course of maintenance.

Building

It is the intention that any correct environment is equally well suited to make official builds. At the time of writing, however, SCORE 1750a is known to fail building under Cygwin 2022 and newer (PCR 5119).

Ensure the version number information has been updated appropriately. See build.txt for a description. Run build with option -K to increase the build number; commit all files that are changed by this before proceeding.

Follow SCORE HowTo. Work from a fresh check out (for consistent time stamps and avoid problems with less than perfect clean up procedures). It takes several hours to run the fullshow script (typically 6 hours on a laptop).

Check that the build is successful. The output on the screen should end with "Build completed". Most build problems lead to a build.dif file.

So far nothing has changed outside your sandbox. Once you are satisfied with your build, it should be posted to the ftp server. The identification of the zip files to post is output by fullshow. You should follow the steps outlined in the "Post Development Distribution" section in Software Release Howto.

A Bash console must be used to build SCORE. After setting up the environment as described above, you enter the build directory (e.g. SCORE_dev/branches/mainline/build) and issue:

        ./fullshow

The fullshow script defaults to building all targets but can be called with the names of specific targets.

Tag SCORE_dev after posting a new release. Use svnsave to ensure proper handling of subcomponents.

Warning Before Building

These instructions will build from the head version of everything. Before undertaking this effort, you should synchronize with the developers. The head version should be regarded as work in progress unless development has been temporarily frozen for release. Doing a build at a random time could therefore fail.

Testing

It is customary to test your build before releasing it. The test system is described in the SCORE test reports stored under SCORE Maintenance and Support in the Project Folders database in Lotus Notes and maintained under reports.

A check out of SCORE_test is needed for testing. The svnco.sh script can also be used to check out SCORE_test. See README for a test description.

TRAC must be installed for the targets to be tested. The Cygwin installer can do this for targets that are not already installed as part of the maintainer desk.

Note that score_use.sh and trac_use.sh must be edited manually to set SCOREHOME and TRACHOME to the appropriate paths before the tests are started. This is required for certain test suites (including acats) that use Bourne shell.

Making Updates

See README and what it points to. Ask existing SCORE maintainers for help.

New Cygwins have often required generalizations to common_setup.sh and the component build scripts (e.g. build).