Open Watcom Reflections 2012-08-07
From Open Watcom
Software Build, Test, and Release Plan
As we transition from generation 1.9x to 2.0x, we will need to enhance our build, test, and release procedures to ensure product reliability and availability for all our platforms. Our existing procedures for generation 1.9x are fairly complete. We build all configurations using a central database, driven by intelligent build tools. Each module is generated free of errors and warnings then tested at the regression and application level prior to release. Releases are made available via the Perforce depot or through compressed tar files. As we head into generation 2.0x, we will need to reduce build times, increase our test coverage, and make alternative release methods available to different user groups.
Parallel Build System
Firstly, build times can be enormous for large projects. With projects easily containing tens of thousands of files, build times are often measured in terms of days instead of hours. Luckily, Open Watcom is a still a moderately sized project. Depending on the machine, the project will build in two hours or less. However, this will most likely change with generation 2.0x. Our future build system will need to make much better use of existing hardware. With typical make routines processing operations serially, very little use is made of available cpu time. This is why we are investigating a parallel, multiprocessor build system to be run on a networked machine cluster. By exploiting POSIX and networking capabilities, the build system will use parallelism to run as much work on the machines as possible. I have a 4 machine FreeBSD cluster with 10 available cpu cores in place for this development. For our existing generation 1.9x builds, we will continue using a 32-bit Windows server for this purpose.
Secondly, with the increasing list of features and operating modes, we will need to further expand and automate our test coverage. This will begin with selected operating systems tested on dedicated hardware, followed up with other operating systems tested using cpu emulation.
Our hardware installed systems are:
v1.9x and v2.0x
- MS-DOS 6.22/Windows 3.1, Windows ME, FreeDOS 1.1, RDOS
- Windows XP/32, 7/32, 7/64
- eComStation 2.10
- Linux Debian 6.0 i386/Amd64
Added for v2.0
- FreeBSD 9.0 i386/Amd64
- NetBSD 5.1 i386/Amd64
- Solaris 11 x86
- OS X 10.6 Snow Leopard
We will use cpu emulation to test:
v1.9x and 2.0x
- PC-DOS, DR-DOS, OpenDOS
- React OS
- Linux Ubuntu, Redhat
- Novell Netware 6.5
- Open Indiana
- Novell Open Enterprise Server
Each major Open Watcom module contains automatic regression tests that are run at build time. We will try to expand these tests and add additional checking capabilities within the build tool for processing these regressions. The remaining tests are performed by Open Watcom team members at the application level. I will try organizing and documenting a standard set of application tests that we will run regularly on the build. These would be common tools that a user would build using the compiler.
Thirdly, as the Open Watcom community grows and branches out into new applications, we will want to support alternative delivery methods for the releases. Perforce will always be the core project database. However, we will support and endorse a GIT and an SVN database for each release and nightly build. The GIT database, maintained by Jiri Malak, a long time Open Watcom developer, will be a fork of the design. This fork will be an independent project under Jiri's direction. The SVN database, maintained by Christof Meerwald, another long time Open Watcom developer, will track changes made in Perforce. A daily Perforce snapshot will be made available as a compressed tar file. The web addresses for each are:
With these alternatives, we should be able maintain the availability of the project for all users.
I hope to expand on these topics as we progress throughout the year. For now, it has been a pleasure chatting with you. I hope to talk with you again soon.
Maintainer, Open Watcom Project