Home
Name Modified Size Downloads / Week Status
Totals: 11 Items   16.4 kB 1
1.0.9 2012-06-04 1 weekly downloads
1.0.8 2012-06-01 1 weekly downloads
1.0.7 2012-02-18 1 weekly downloads
1.0.6 2012-02-03 4 weekly downloads
1.0.5 2012-01-27 4 weekly downloads
1.0.4 2012-01-25 2 weekly downloads
1.0.3 2012-01-20 1 weekly downloads
1.0.2 2012-01-13 3 weekly downloads
1.0.1 2012-01-11 2 weekly downloads
1.0.0 2012-01-11 3 weekly downloads
README 2012-06-01 16.4 kB 11 weekly downloads
=============================================================================== 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
Source: README, updated 2012-06-01