Building a Bochs release

Preparing source files and CVS

Update version number and strings in configure.in.

VERSION="2.4"
VER_STRING="2.4"
REL_STRING="Build from CVS snapshot on June 7, 2009"
In the README file you have to update version number and date. Add some information about new features if necessary.
Bochs x86 Pentium+ Emulator
Updated: Sat May 3 07:34:00 CEST 2009
Version: 2.4
Check date, update/sumup info in CHANGES. Run autoconf to regenerate configure and check them in. Create a CVS tag to mark which revision of each file was used in the release. For prereleases I make a normal CVS tag like this:
  cvs tag REL_2_4_pre1
But for a real release, I make a CVS branch tag AND a normal tag.
  cvs tag REL_2_4_BASE
  cvs tag -b REL_2_4
The base tag marks where the branch split off of the main trunk. This is very useful in maintaining the branch since you can do diffs against it.
   cvs diff -r REL_2_4_BASE -r HEAD
   cvs diff -r REL_2_4_BASE -r REL_2_4
   cvs upd -j REL_2_4_BASE -j HEAD file
   etc.
The release and all bugfix releases after it are on the REL_2_4 branch. When the release is actually finalized, you can do this:
  cvs tag REL_2_4_FINAL
Now you can start building packages based on the created release tag.

Building the release on win32

These instructions require cygwin and MSVC++.

In Cygwin:

  sh .conf.win32-vcpp         # runs configure
  make win32_snap             # unzip workspace, make a win32 source ZIP
Copy the source ZIP to a windows machine, if necessary.

Open up Visual C++ and load the workspace file Bochs.dsw. Check the Build:Set Active Project Configuration is set the way you want it. For releases I use "Win32 Release".

To create "bochsdbg.exe" with Bochs debugger support, manually change two lines in config.h to turn on the debugger.

#define BX_DEBUGGER 1
#define BX_DISASM 1
VC++ will rebuild Bochs with debugger and overwrite bochs.exe. To avoid trashing the non-debug version, move it out of the way while the debugger version is being built. Then rename the debugger version to bochsdbg.exe.
cd obj-release
mv bochs.exe bochs-normal.exe
(build again with BX_DEBUGGER=1 this time)
mv bochs.exe bochsdbg.exe
mv bochs-normal.exe bochs.exe

To get the docbook installed, you need to do something like this:

Then you can do
cd doc/docbook; touch */*.html
Do make install_win32 into /tmp or someplace:
make install_win32 prefix=/tmp/bochs-2.4
This copies all the files into /tmp/bochs-2.4 and then creates a binary ZIP at /tmp/bochs-2.4.zip. Rename that bochs-2.4.win32-bin.zip.

Now make the NSIS installer package (the current script is known to work with NSIS 2.44)

cd build/win32/nsis
Unzip the binary ZIP file into bochs-$VERSION (must match Makefile) and then run make.
unzip ~/bochs-2.4.zip
make
That gives an installer called Bochs-2.4.exe. Test and upload it.

Building the release on Linux

Do a clean checkout using anonymous cvs, so that the source tarball will be all set up for anonymous cvs. First I'll create a clean directory called "clean-anon".

cvs -d:pserver:anonymous@bochs.cvs.sourceforge.net:/cvsroot/bochs login
cvs -z3 -d:pserver:anonymous@bochs.cvs.sourceforge.net:/cvsroot/bochs \
  checkout -d clean-anon bochs
Start with clean-anon which tracks the CVS head. Change its sticky tag so that it sticks to the release tag.
cp -a clean-anon bochs-2.4
cd bochs-2.4
cvs upd -P -r REL_2_4_FINAL
cd ..
tar czvf bochs-2.4.tar.gz --exclude CVS --exclude .cvsignore bochs-2.4
The source TAR file bochs-2.4.tar.gz is ready to upload.

The RPM will be building using the configuration in .conf.linux with a few parameters from build/redhat/make-rpm. Make any last minute changes to .conf.linux. Any changes will go into the source RPM. The DLX Linux demo package will be downloaded to the Bochs root directory if it is not already present there.

./build/redhat/make-rpm | tee ../build.txt
This produces two rpm files in the current directory. Test and upload.

Creating a file release and uploading files on SF

When you are ready with creating release packages you have to upload them using the SF file manager feature. Create a subdirectory with the version number in the bochs directory. Point the download destination to the new directory and start uploading packages. The top of the CHANGES file should be used as the release notes. After setting up the file properties the new release is ready for download.