• Don't use the IRIX tar to untar...Use a linux box to untar because IRIX tar cannot make all of the symlinks right

• • Java support which requires CORBA

• • All possible plug-ins (OpenAL and Audiere as a bare minimum)

• • For VRPN, use 06.06 or newer as it is the first version that compiles with Visual C++ 7.1

• Build X11 version
  • Create a disk image for distribution purposes

• All Boost files were installed, including the few .h files that they have in their source tree.

• • C++ CORBA support which requires omniORB 4.0.3 or newer (for full compiler support)

• • For VRPN, use 06.06 beta 4 or newer as it is the first version that compiles with Visual C++ 7.1

1. Tag the tree with a release tag (referred to below as <TAG_NAME>).

• The target install-deps installs all the detected dependencies. By default, it installs into the same tree where VR Juggler is installed by the release target, but this can be changed by setting the varaible deps_prefix when running make. For example:

   make release
   make deps_prefix=/home/users/me/vrjuggler-2.0-deps install-deps

• Build N32/mips3 (default) SPROC
• Build N32/mips3 (default) POSIX
• Build 64/mips4 (--with-abi=64_M4) SPROC
• Build 64/mips4 (--with-abi=64_M4) POSIX

• Build NSPR debug and release
  • The Python script buildwin32.py will ask for a path for the VR Juggler installation and for the dependency installation. These can be the same if desired.
  • Select everything under the Batch Build dialog and build.

• Send an announcement email to vrjuggler-info@lists.sourceforgeSPAMSAFE.net, vrjuggler-devel@lists.sourceforgeSPAMSAFE.net, and the VRAC mass-mail list.
• Use the announcement to the VR Juggler lists to post a news item on our SourceForge project page.

Things to check before releasing

• All boost files were installed, including the few .h files that they have in their source tree.

1. For modules being checked out from a branch rather than a frozen release tag, in juggler/Gatherrc add the current date to the module configuration (Date: mm/dd/yyyy hh:mm:ss TZ;).

1. For modules being checked out from a branch rather than a frozen release tag, add the current date to the module configuration (Date: mm/dd/yyyy hh:mm:ss TZ;).

• Change juggler/Gatherrc back to the way it was prior to the release. That is, remove any dates that were added earlier.

Making a VR Juggler Release

Pieces

"VR Juggler" is basically supposed to be everything, which means that a lot of code goes into a release distribution. The following lists everything that goes into a distribution of VR Juggler (for a 2.0 pre-release).

• VPR
• Tweek
  • Java support which requires CORBA and JDOM
  • C++ CORBA support which requires omniORB 4.0.1 or newer (for full compiler support)
• JCCL
  • Java support
• Sonix
  • All possible plug-ins (OpenAL and AudioWorks as a bare minimum)
• Gadgeteer
  • All drivers except TrackdAPI (we don't have a copy of it)
• VR Juggler and VRJConfig
• vjAvatar with Cal3D

Steps

Source Distribution

1. Check out a clean copy of the juggler module. Do not run cvs-gather.
2. Increment the version in juggler/modules/vrjuggler/VERSION
   • Do this so that the release is against a specific VR Juggler version.
3. Update juggler/modules/vrjuggler/RELEASE-NOTES.txt with any relevant information regarding API changes, major bug fixes, and cool new features.
4. Change any CVS branch tags in juggler/Gatherrc to match the current date.
   • This is done to make something like a frozen snapshot of the dependent code acquired by cvs-gather.
   • Make sure to commit this, of course.
5. Tag the tree.
6. Remove the source tree you were just working with and run the following:
   • Note that after running cvs-gather, you could get rid of the CVS directories in the code checked out by cvs-gather, but that isn't terribly important.

   cvs -d <...> export -kv -r <TAG_NAME> juggler
   cd juggler
   ./cvs-gather.pl

• Once the above is done, tar up the fully populated source tree. Compress it with bzip2 -9 to make it as small as possible.
  • This is the source distribution.
  • Note that vjAvatar isn't included in this. This is kind of bad, but the vjAvatar source does not have a place to live in this source tree. It could go into juggler/external if nothing else.

Binary Distributions

• After each binary distribution is compiled, vjAvatar needs to be compiled against it. The compiled version of vjAvatar and Cal3D needs to be inserted into the binary release tree. Fun, huh?
• Use maximum compression when creating the final archive to be uploaded to SourceForge.
• Use make release unless otherwise noted.

Before Beginning

• Install the freshly made source distribution in /home/vr/Juggler/2.0.
  • Make all builds against this distribution, though do them in /tmp or /var/tmp to make the process a little faster. configure will find the source code in /home/vr/Juggler/2.0, so don't worry about that.
• When running configure.pl, pass --prefx=/TEMP_DIRECTORY/vrjuggler-VERSION.PLATFORM so that the installation happens on the local disk.
  • Once the distribution has been completed, it can be moved into /home/vr/Juggler/2.0.

IRIX

• Build N32 SPROC
• Build N32 POSIX

Linux

• Build POSIX

Windows

• Build NSPR debugging
  • On Windows, we currently have bugs relating to the binary incompatibility of debugging versus optimized code. No one has had time to try to improve the build system to account for this. At this pre-release stage of VR Juggler 2.0, people would be better off using the debug builds, so that is what we distribute on Windows. Do not bother trying to build optimized binaries.
  • Compress the binary distribution tree using WinZip with maximum compression.

Mac OS X

• Build NSPR + X11 version

Documentation

Note that documentation releases must be built on a Linux machine in the VRAC lab. Only there are all the necessary tools available and in a functioning state. (On IRIX, Java crashes when trying to run the XSLT code.)

• Build a documentation release:

   make -f Makefile.docs
   make -f Makefile.docs release
   cd ~
   mv vrj-docs.dist <versioned documentation distribution name>

Uploading to SourceForge

• Read their documentation about making file releases.
• Read their documentation about posting a news item (in this case, a release announcement).
  • Usually, it is fine to base an announcement on the last one that was made for that release series.

Finishing Up

• Change juggler/Gatherrc back to the way it was prior to the release. That is, change dates back to branch names.

-- PatrickHartling - 01 Jul 2003