===============================================================================
About
===============================================================================
Package: TournamentBuddy
A home Poker tournament organizer / blind timer.
URL: http://tournamentbuddy.sourceforge.net/
Platforms: POSIX:
Linux, FreeBSD
Should also work fine on other POSIX platforms, depending on
the availability of the third-party libs for that platform.
Tested on Linux (several /32/64) and FreeBSD (FreeBSD/32).
Windows
I would say at least Windows2000 or later versions.
Tested on Windows XP/32, Vista/32, Windows7/64.
Mac OS X
Not quite yet; got no idea how/where to install the files
and if there are other minor issues. Maybe some day..
Requires: wxWidgets (libwxgtk) application framework
OpenAL Soft (libopenal) audio i/o library
POSIX: GTK+ (libgtk2) required by libwxgtk
Windows: DirectX (DirectSound) required by OpenAL Soft
See also: Building TournamentBuddy from sourcecode (below).
Author: Oliver Lange<tournamentbuddy@bloody.in-berlin.de>
License: GPLv3+ (GNU General Public License, version 3 or later).
===============================================================================
Third-Party Licenses
===============================================================================
All third-party libs are free software as well. Detailed license information
is included here:
Sourcecode distribution:
See also: distfiles/doc/tournamentbuddy/licenses.txt
Win32 binary distribution:
See also: shared/doc/tournamentbuddy/licenses.txt
===============================================================================
Win32 binary distribution
===============================================================================
Installing TournamentBuddy
==========================
Unzip the archive to any location. No installer needed.
Updating TournamentBuddy
========================
Delete (or rename) an existing TournamentBuddy installation folder, then
unpack the new release archive. TournamentBuddy never creates or modifies
any files within the TournamentBuddy installation folder, so you can always
safely delete it. All runtime files are stored in your home path. See below.
TournamentBuddy never makes any changes to the system and/or the Windows
registry.
===============================================================================
Tournament Configuration
===============================================================================
All runtime files (configuration files) are saved in your home directory,
which is:
POSIX:
~/.tournamentbuddy/
Windows:
C:\Documents and Settings\<username>\Application Data\TournamentBuddy\
(The drive letter and directory names depend on the Windows installation
path and language.)
Max OS X:
~/Library/Application Support/TournamentBuddy/
(At least that's what i think it would be..)
About the autosave_config.txt
=============================
Once a tournament was started, TournamentBuddy will automatically save the
current configuration and runtime status of the tournament once per minute,
as a safety/rescue measure for the case of crashes, power shortages etc.,
into a file named "autosave_config.txt". Once your computer is up and running
again after a crash, just load the autosave_config.txt and you're back in
the tournament as it was before.
===============================================================================
Building TournamentBuddy from sourcecode
===============================================================================
This project supports gcc/g++ as well as clang/clang++ (tested with clang 2.9
and 3.0; does NOT work with clang 2.7 as wxWidgets causes trouble there).
Other compilers might or might not work. Anyhow, support for MSC is meanwhile
abandoned on my part, even if most sourcecodes still make a distinction when
MSC is detected.
You also need a Make, of course.
On Win32, MSYS/MinGW was used to build the project.
This program also works on 64-bit systems, although i've never tried to build
binaries for Win64. This might or might not work out-of-the-box.
Other Requirements:
A Bourne-compatible shell (basically any Unix shell). On Windows, MSYS will
do just fine.
On POSIX, pkg-config is required to configure libopenal.
If you want to build distribution archives, you also need the usual binaries
installed, such as tar, gzip, xz, zip etc.
Win32: if you have upx installed, the build scripts will utilize it to
compress the Win32 executable(s).
If you plan on running a maintainer-clean, you'll need autoconf, automake and
their respective dependencies installed in order to re-create the configure
script and the final Makefiles.
Building dependencies:
libwxgtk - (wxWidgets for GTK), at least version 2.9.3. See below.
libopenal - at least version 1.2.0.
POSIX:
libgtk - version 2.x (with wxWidgets-3.x it is expected that GTK3 will
be supported aswell).
Debian/Ubuntu: users of Debian-based distributions also need the developer
packages of the required libraries (i.e., libwxgtk[x.y]-dev, libgtk[x.y]-dev
and libopenal-dev) in addition to their binary counterparts.
After successfully building TournamentBuddy, these developer packages are
no longer required by the application.
POSIX:
Most distributions still package wxWidgets 2.8.x which contains a rather
immature string class which cannot be used with this application.
The next stable version (3.0) is expected to be released in summer 2012,
but the current version (2.9.3) does just fine on all systems i've tested.
So you'll need to either install wxWidgets manually instead of using the
distro package(s) or compile a separate static version.
Fortunately, this is a pretty easy task:
Grab a 2.9.3 (or later) release from www.wxwidgets.org and unpack it.
The small shell script below shows what i did to build wxWidgets as static
lib (so we won't have any conflicts with existing wxWidgets installations):
cd wxWidgets-2.9.3
mkdir -p _release_static
cd _release_static
../configure --disable-shared --disable-debug \
&& make -j4 \
&& rm -rf *.o .pch/*
cd ..
cd ..
The commands above include a little cleanup, deleting all objects and all
pre-compiled headers, cutting most of the fat that isn't required afterwards.
The script above assumes that libpng and zlib are installed. If not (highly
unlikely), add the following two parameters to the configure command:
--with-zlib=builtin --with-libpng=builtin
OpenIndiana (illumos/OpenSolaris) notes:
{
In the package manager, add sfe (http://pkg.openindiana.org/sfe) on top of
the repository list to get access to a pre-built gcc 4.6, clang (llvm) 3.0,
openal, some of the gcc dependencies and more.
Don't forget to install the following packages aswell (which are currently
not installed with OpenIndiana by default):
system/header
system/header/math/header-math
developer/library/lint
developer/gnome/gettext
(The latter includes pkg-config.)
Add "--with-gtk=2 --enable-permissive" to the ./configure options, else
wxWidgets won't select GTK by default and instead fallback to Motif if
installed (eek!). I also needed the --enable-permissive option to get rid
of errors regarding const cast macros.
On my vbox, the machine got pretty busy on the harddisk so i only used
"make -j1" instead. Maybe i just didn't give it enough memory (only 768MB).
}
We don't need to run make install. We can keep everything where it is and
link the application directly against the static libs in the build directory.
Finally, add the path to wx-config (in wxWidgets-2.9.3/_release_static)
to your $PATH env variable or create a symbolic link to the file in one
of the existing directories in your $PATH variable.
Make sure that the path is added *before* any of the /usr binary paths
in case you got an older wxWidgets version already installed.
Example: (using $PATH instead of a symlink)
export PATH="/path/to/wxWidgets-2.9.3/_release_static:$PATH"
To test this, enter "wx-config --version" in the console and see if the
output contains "2.9.3". If so, wxWidgets should be ready for use.
Windows:
Download the 2.9.3 (or later) wxWidgets release from www.wxwidgets.org and
compile it. Here's what i did to build wxWidgets nodebug static libs:
cd wxWidgets-2.9.3
mkdir -p _release_static
cd _release_static
../configure --disable-shared --disable-debug --with-zlib=builtin --with-libpng=builtin \
&& make -j4 \
&& rm -rf *.o .pch/*
cd ..
cd ..
The commands above include a little cleanup, deleting all objects and all
pre-compiled headers, cutting most of the fat that isn't required afterwards.
Then you need to add the path to wx-config to your MSYS $PATH env variable,
like:
export PATH="/path/to/wxWidgets-2.9.3/_release_static:$PATH"
Make sure that the path is added *before* any of the MSYS/MinGW paths
in case you got an older wxWidgets version already installed.
To test this, enter "wx-config --version" in the MSYS shell and see if the
output contains "2.9.3". If so, wxWidgets should be ready for use.
OpenAL Soft on Windows:
This one is easy, as the author provides a lib file for use with GCC (MinGW)
in a Win32 binary .zip archive. Download that archive from
http://kcat.strangesoft.net/openal.html and unpack it.
The easiest way to get this library ready is to copy the libOpenAL32.dll.a
file (from lib/Win32) to MinGW/lib, the include files to MinGW/include, and,
at your option, the Win32/soft_oal.dll to Mingw/bin as "OpenAL32.dll".
Yes, the DLL needs to be renamed, but you could also take the OpenAL32.dll
from the TournamentBuddy distribution which is already stripped & compressed.
Building TournamentBuddy
========================
After unpacking the source distribution, cd to the TournamentBuddy folder
you just unpacked and enter the usual build commands:
./configure
make
[make check]
On POSIX, you can directly run the install command once the build succeeded:
[sudo] make install
or:
[sudo] make install-strip
The latter command installs stripped (smaller) binaries.
For further options, run './configure --help'.
Win32:
To create a binary release .zip file for Win32, use the following command:
make bindist-win32
Unpack the archive to any location. No installer needed.
Win64:
Should be working if you find a good 64-bit MinGW. Maybe you want to try
http://mingw-w64.sourceforge.net which is probably a fine choice.
Using clang/clang++
===================
POSIX:
If gcc/g++ is the default compiler on your system, you can use clang/clang++
by setting $CC and $CXX accordingly, e.g. by running ./configure like:
CC=clang CXX=clang++ ./configure
Windows:
I had some problems with clang (2.9) regarding linking with the static
wxWidgets library (built with MinGW), but i guess i just didn't understand
how to properly setup & use clang on Windows.
Also, clang does not provide the -static-libstdc++ option and usleep() is
missing in unistd.h. I'll wait for a more mature release, maybe one which
is easier to setup. For now, you're on your own with clang on Windows,
good luck.
Additional configure options
============================
--enable-debug
This option is used to create debug builds.
--enable-pch=no
Disables the creation of a pre-compiled header (only used with g++/clang++).
This project is just barely big enough to justify using a pre-compiled header
by default. With g++ running multiple jobs the difference is marginal, but
with "make -j1" or if clang++ is used (with any number of jobs) there is a
noticeable difference, so this option is enabled by default.
--enable-monolithic (Debian6: see notes below)
This option creates a monolithic build with all C++ sources compiled as one
big compilation unit, allowing the compiler to apply even more optimizations
which result in a smaller binary size. Use this option if you just want to
build a release binary. If you want to build the application more than once,
i.e., if you intend to play around, modify the sourcecodes and re-build the
application a couple of times, using a monolithic build would take more time
as every change to any of the C++ sourcecodes would always compile all C++
sources again instead of only those which have been changed.
If this option is used, you may also want to use "--disable-pch" as there
will be only one C++ compilation unit which means that a pre-compiled header
would not gain anything. On the contrary, compiling would effectively take
longer if a pre-compiled header is created separately.
The Win32 binary release was built using this option.
Win32: if an external builddir is used, the builddir must be located
somewhere relative to the srcdir, i.e., it won't work if configure was
invoked like "/c/projects/tournamentbuddy/configure". Use a relative path
instead (on the same Windows 'drive'), such as "../configure".
Debian6: with g++ (Debian-4.4.5-8), using this option caused a segfault as
soon as i clicked on the Tournament/Settings button, at least this is what
happened on my box. This did not happen on Xubuntu, siduction, Arch Linux,
Mageia1, FreeBSD or OpenIndiana; only on the current Debian6 as of 2012-01.
If this happens on your system aswell, this option cannot be used.
clang: this compiler currently doesn't support the gcc/g++ -fwhole-program
option, so it won't benefit much from a monolithic build (only about 3-4 KB
smaller binary size). On some installations, clang++ issued a warning about
that option being defined but not used, on other systems it quietly accepted
the option. For upward compatibility with future clang releases which might
eventually support this option, i've enabled the option even if clang++ is
used instead of g++. The unused-option warning can be safely ignored.
See also: Using clang/clang++.
--enable-upx-lzma (Win32)
Enables lzma compression with UPX (used to compress Win32 binaries), if UPX
is present somewhere in $PATH.
Note that lzma decompression is slower than the regular decompressor, but as
long as the application binary is not too big, the startup time difference
becomes marginal and therefor makes it worth using lzma to make the
executable even smaller. With the current version of TournamentBuddy,
this option is enabled by default.
UPX is available at http://upx.sourceforge.net.
--enable-upx-ultra (Win32)
Enables ultra-brute compression with UPX (used to compress Win32 binaries),
if UPX is present somewhere in $PATH. The Win32 binary release is created
using this option.
This option overrides --enable-upx-lzma.
Warning: this takes a VERY long time (several minutes). If you're using a
RXVT terminal for MSYS, you might wonder if the build script is hanging, but
it's only UPX taking that long. With other consoles (e.g. Console2) you can
watch the progress bar to verify that UPX is still squeezing bytes.
The difference between using lzma and ultra-brute (which includes tests with
lzma) is marginal and virtually not worth it, but hey, release is release..
Additional make targets
=======================
bindist-win32
Only available on Win32, creates the Win32 binary distribution archive (zip).
Autotools
=========
If you want to run 'make maintainer-clean', you'll need autotools installed to
re-build the project later on.
If you're new to autotools, there's no fuzz about in which order the autotools
commands shall be run, just enter 'autoreconf -[f]i' and you'll be fine, like:
[make maintainer-clean]
autoreconf -i
./configure
make
[make check]
[sudo] make install-strip
make maintainer-clean
On Win32 (MSYS), to build the binary distfile, use the same commands except:
instead of
[sudo] make install-strip
use
make bindist-win32
