ShuriZma
/
visualboyadvance-m
mirror of https://github.com/visualboyadvance-m/visualboyadvance-m.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update README.md and Developer Manual 

Update README.md and remove outdated information.

Update the Developer Manual and describe the current release process.

Signed-off-by: Rafael Kitover <rkitover@gmail.com>
This commit is contained in:
Rafael Kitover 2024-09-08 05:41:06 +00:00
parent 5d7023a5d6
commit e4a9340409
No known key found for this signature in database
GPG Key ID: 08AB596679D86240
2 changed files with 177 additions and 285 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

291
DEVELOPER-MANUAL.md
View File

@ -9,17 +9,15 @@
- [Commit Message](#commit-message)
- [Collaboration on a Branch](#collaboration-on-a-branch)
- [Commits from Maintainers](#commits-from-maintainers)
- [Strings, Character Sets and Translations](#strings-character-sets-and-translations)
- [Pulling Updated Translations](#pulling-updated-translations)
- [Translations Message Catalog](#translations-message-catalog)
- [Interaction with non-wxWidgets Code](#interaction-with-non-wxwidgets-code)
- [Windows Native Development Environment Setup](#windows-native-development-environment-setup)
- [Miscellaneous](#miscellaneous)
- [Debug Messages](#debug-messages)
- [Release Process](#release-process)
- [Environment](#environment)
- [Certificates](#certificates)
- [Release Commit and Tag](#release-commit-and-tag)
- [64-bit Windows Binary](#64-bit-windows-binary)
- [32-bit Windows Binary](#32-bit-windows-binary)
- [64-bit Mac Binary](#64-bit-mac-binary)
- [ARM64 Windows Binary](#arm64-windows-binary)
- [macOS Binary](#macos-binary)
- [Final steps](#final-steps)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
@ -53,11 +51,12 @@ Follow the following steps to process newly submitted issues:
- An issue is resolved by closing it in github. A commit that fixes the issue
should have the following line near the end of the body of the commit message:
```
- Fix #999.
Fix #999.
```
This will automatically close the issue and assign the closing commit in the
github metadata when it is merged to master. The issue can be reopened if
needed.
- A commit that is work towards resolving an issue, should have the issue number
preceded by a pound sign either at the end of a commit message title, if it is
of primary relevance to the issue, or the body otherwise.
@ -70,7 +69,7 @@ Follow these guidelines always:
https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
the description of your work should be in the **commit message NOT the pull
, the description of your work should be in the **commit message NOT the pull
request description**.
The title line must be no more than 50 characters and the description must be
@ -95,16 +94,21 @@ other projects, fewer is better.
The commit title line should be prefixed with an area, unless it involves the
wxWidgets GUI app, in which case it should **NOT** have a prefix.
If the commit is a user-facing functionality change or enhancement, the title
line of the commit must be a non-technical description of this change. For
example "Mute on speedup" because this will go into the changelog.
The text after the area prefix should not be capitalized.
Please use one of these area prefixes otherwise:
Please use one of these area prefixes for non-main-GUI-app commits:
- doc: documentation, README.md etc.
- build: cmake, installdeps, preprocessor compatibility defines, etc.
- gb-core: the GameBoy emulator core
- gba-core: the GameBoy Advance emulator core
- build: cmake, installdeps, preprocessor compatibility defines, compatibility
headers, etc.
- gb: the GameBoy emulator core
- gba: the GameBoy Advance emulator core
- libretro: the libretro core glue and build
- sdl-app: anything for the SDL app
- sdl: anything for the SDL port
- translations: anything related to translations
. Add other areas here if needed.
@ -138,137 +142,67 @@ things in mind:
better to edit the history than to add more commits. Never add commits fixing
previous commits, only improving or adding to them.
- To update when someone else (very rudely you might say) did a `push -f`, `pull
--rebase` will **USUALLY** work. Verify the log, and if necessary do this
instead:
- To update when someone else updated the branch with a `push -f`
```bash
git status # should be clean, with your work having been already pushed
git fetch --all --prune
git reset --hard origin/<branch-name>
```
.
While actively working on a branch, keep it rebased on top of master.
- While actively working on a branch, keep it rebased on top of master.
#### Commits from Maintainers
Maintainers have the power to commit directly to master. This power must be
used responsibly, something I fail to do myself often, and will try to improve
upon.
Maintainers and project members have the power to commit directly to master.
This power must be used responsibly.
Make your most earnest attempt to follow these general guidelines to keep our
Make your best attempt to follow these general guidelines to keep our
history clean:
- Things that are a straight fix or improvement that does not require discussion
- Things that are a minor fix or improvement that does not require discussion
can be committed directly, keeping the following guidelines in mind.
- Bigger new features, code refactors and changes in architecture should go
through the PR process.
- Push code changes to a branch first, so they can run through the CI.
Differences in what different compilers allow is a problem that comes up
**VERY** frequently. As well as incompatibilities between different
configurations for both the C++ code and any supporting code.
- Push code changes to a branch first, so they can run through the CI. When you
open the commit in GitHub there is a little icon in the upper left corner that
shows the CI status for this commit. Differences in what different compilers
allow is a problem that comes up **VERY** frequently. As well as
incompatibilities between different configurations for both the C++ code and
any supporting code.
### Miscellaneous
### Strings, Character Sets and Translations
#### Debug Messages
#### Pulling Updated Translations
We have an override for `wxLogDebug()` to make it work even in non-debug builds
of wx and on windows, even in mintty.
Once in a while it is necessary to pull new and updated translations from
transifex.
For this you need the transifex client, available for Windows as well from
chocolatey as `transifex-client`.
To pull translations run:
```bash
tx pull -af
```
then check `git status` and if any message catalogs were updated, commit the
result as:
```bash
git commit -a --signoff -S -m'Transifex pull.'
git push
```
#### Translations Message Catalog
Strings that need to be translated by our wonderful translators on transifex
(thank you guys very much) need to be enclosed in `_("...")`, for example:
It works like `printf()`, e.g.:
```cpp
wxLogError(_("error: something very wrong"));
int foo = 42;
wxLogDebug(wxT("the value of foo = %d"), foo);
```
The next time you run cmake after adding a string to be translated, the `.pot`
message catalog source will be regenerated, and you will see a loud message
telling you to push to transifex.
Strings in the XRC XML GUI definition files are automatically added to the
message catalog as well.
If you are working on a branch or a PR, don't push to transifex until it has
been merged to master.
Once it is, push it with:
```bash
tx push -s
```
#### Interaction with non-wxWidgets Code
Use our `UTF8(...)` function to force any `wxString` to UTF-8 for use by other
libraries, screen output or OS APIs. For example:
From the core etc. the usual:
```cpp
fprintf(STDERR, "Error: %s\n", UTF8(err_msg));
fprintf(stderr, "...", ...);
```
, will work fine.
There is one exception to this, when using `wxString::Printf()` and such, you
can't pass another `wxString` to the `%s` format directly, use something like
this:
```cpp
wxString err;
err.Printf("Cannot read file: %s", fname.wc_str());
```
this uses the `wchar_t` UTF-16 representation on Windows and does nothing
elsewhere.
For calling Windows APIs with strings, use the wide char `W` variants and the
`wc_str()` method as well.
### Windows Native Development Environment Setup
This guide has been moved to:
https://github.com/rkitover/windows-dev-guide
You need a debug build for this to work or to even have a console on Windows.
Pass `-DCMAKE_BUILD_TYPE=Debug` to cmake.
### Release Process
#### Environment
#### Certificates
The variable `VBAM_NO_PAUSE`, if set, will cause cmake to not pause before gpg
signing operations, you want to set this if you've disabled your gpg passphrase
to not require interaction during release builds.
gpg set up with your key is helpful for the release process on all environments
where a binary is built, but you can also make the detached signature files
yourself at the end of the process.
For codesigning windows binaries, put your certificate into
`~/.codesign/windows_comodo.pkcs12`.
On Mac the 'Developer ID Application' certificate stored in your login keychain
is used, `keychain unlock` will prompt you for your login keychain password, to
avoid that set the `LOGIN_KEYCHAIN_PASSWORD` environment variable to your
password.
Make sure you have set up a Windows code signing certificate with the right
password and a Mac 'Developer ID Application' certificate.
#### Release Commit and Tag
@ -280,8 +214,7 @@ tag:
mkdir build && cd build
cmake .. -DTAG_RELEASE=TRUE
```
then push the release:
, follow the instructions to edit the `CHANGELOG.md` and then push the release:
```bash
git push
@ -296,84 +229,103 @@ cmake .. -DTAG_RELEASE=UNDO
#### 64-bit Windows Binary
For this you will preferably need the powershell environment setup described
earlier, however you can use a regular Visual Studio 64 bit native developer
command prompt as well.
For this you will preferably need the PowerShell environment setup described
[here](https://github.com/rkitover/windows-dev-guide), or by starting the `x64
Native Tools Command Prompt` from your Start Menu.
```powershell
mkdir build
cd build
cmake .. -DVCPKG_TARGET_TRIPLET=x64-windows-static -DCMAKE_BUILD_TYPE=Release -DUPSTREAM_RELEASE=TRUE -G Ninja
mkdir build-msvc64
cd build-msvc64
cmake .. -DCMAKE_BUILD_TYPE=Release -DUPSTREAM_RELEASE=TRUE -G Ninja
ninja
```
Collect the following files for the release:
- `visualboyadvance-m-Win-64bit.zip`
- `visualboyadvance-m-Win-64bit.zip.asc`
- `visualboyadvance-m-Win-x86_64.zip`
- `translations.zip`
- `translations.zip.asc`
Repeat the process for the debug build, with `-DCMAKE_BUILD_TYPE=Debug` and
collect this file:
- `visualboyadvance-m-Win-x86_64-debug.zip`
.
#### 32-bit Windows Binary
For this the optimal environment is a linux distribution with the mingw
toolchain, I use fedora.
The 32-bit build is a legacy build for Windows XP compatibility. You will need
the MinGW toolchain to build it. The easiest method is to use the MINGW32 MSYS2
environment.
You can set up a shell on a fedora distribution with docker as described here:
https://gist.github.com/rkitover/6379764c619c10e829e4b2fa0ae243fd
If using fedora, the cross script will install all necessary dependencies, if
not install the base toolchain (mingw gcc, binutils, winpthreads) using the
preferred method for your distribution, you can also use mxe for this.
https://mxe.cc/
First install dependencies with:
```bash
sh tools/win/linux-cross-builder -32
./installdeps
```
You can also use msys2 on Windows, this is not recommended:
. Then build the 32-bit binary as follows:
```bash
sh tools/win/msys2-builder -32
mkdir build-mingw32
cd build-mingw32
cmake .. -DCMAKE_BUILD_TYPE=Release -DUPSTREAM_RELEASE=TRUE -G Ninja
ninja
```
. Collect this file for the release:
To set up msys2, see this guide:
- `visualboyadvance-m-Win-x86_32.zip`
https://gist.github.com/rkitover/d008324309044fc0cc742bdb16064454
. Then repeat the process for the debug build with `-DCMAKE_BUILD_TYPE=Debug`,
and collect this file:
Collect the following files from `~/vbam-build-mingw32/project` if using linux,
or `~/vbam-build-msys2-x86_64/project` if using msys2:
- `visualboyadvance-m-Win-x86_32-debug.zip`
.
- `visualboyadvance-m-Win-32bit.zip`
- `visualboyadvance-m-Win-32bit.zip.asc`
#### ARM64 Windows Binary
#### 64-bit Mac Binary
You will need the MSVC ARM64 cross toolchain to build this binary, if you used
the install script from [here](https://github.com/rkitover/windows-dev-guide)
you will have it installed, otherwise run Visual Studio Installer and install
the component.
To enter the ARM64 cross environment, edit the PowerShell profile described
[here](https://github.com/rkitover/windows-dev-guide) or use the `vcvarsall.bat`
script with the `amd64_arm64` argument as described
[here](https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170).
From there the process is the same as for the 64-bit build, collect the
following files for the release:
- `visualboyadvance-m-Win-arm64.zip`
- 'visualboyadvance-m-Win-arm64-debug.zip'
.
#### macOS Binary
Install the latest Xcode for your OS.
You will need bash and (optionally) gpg from homebrew (which you will also need
to install):
```bash
brew install bash gnupg
```
You will need bash from Homebrew/nix/MacPorts/whatever to run the build script.
You will need a codesigning certificate from Apple, which you will be able to
generate once you join their developer program. This is the certificate of the
type 'Developer ID Application' stored in your login keychain. `keychain
unlock` will prompt you for your login keychain password, to avoid that set the
`LOGIN_KEYCHAIN_PASSWORD` environment variable to your password.
generate once you join their developer program from XCode. This is the
certificate of the type 'Developer ID Application' stored in your login
keychain.
If you are not using a GUI session, you will need to use a method to unlock your
login keychain before building. Adding the certificate and key to the System
keychain is also a method that some people use.
Then run:
```bash
/usr/local/bin/bash tools/osx/builder -64
tools/osx/builder
```
, this will take a while because it builds all of the dependencies.
Collect the following files from `~/vbam-build-mac-64bit/project`:
- `visualboyadvance-m-Mac-64bit.zip`
- `visualboyadvance-m-Mac-64bit.zip.asc`
- `visualboyadvance-m-Mac-x86_64.zip`
- `visualboyadvance-m-Mac-x86_64-debug.zip`
.
#### Final steps
@ -381,27 +333,26 @@ Go to the github releases tab, and make a release for the tag you pushed
earlier.
Put any notes to users and distro maintainers into the description as well as
the entries from `CHANGELOG.md` generated earlier from git by the release
commit script.
the generated entries from `CHANGELOG.md` you edited earlier.
Upload all files collected during the earlier builds, the complete list is:
- `translations.zip`
- `translations.zip.asc`
- `visualboyadvance-m-Mac-64bit.zip`
- `visualboyadvance-m-Mac-64bit.zip.asc`
- `visualboyadvance-m-Win-32bit.zip`
- `visualboyadvance-m-Win-32bit.zip.asc`
- `visualboyadvance-m-Win-64bit.zip`
- `visualboyadvance-m-Win-64bit.zip.asc`
- `visualboyadvance-m-Win-x86_64.zip`
- `visualboyadvance-m-Win-x86_64-debug.zip`
- `visualboyadvance-m-Win-x86_32.zip`
- `visualboyadvance-m-Win-x86_32-debug.zip`
- `visualboyadvance-m-Win-arm64.zip`
- 'visualboyadvance-m-Win-arm64-debug.zip'
- `visualboyadvance-m-Mac-x86_64.zip`
- `visualboyadvance-m-Mac-x86_64-debug.zip`
Update the winsparkle appcast.xml by running this cmake command:
Update the winsparkle `appcast.xml` by running this cmake command:
```bash
cmake .. -DUPDATE_APPCAST=TRUE
```
follow the instructions to push the change to the web data repo.
, follow the instructions to push the change to the web data repo.
Announce the release on reddit r/emulation and the forum.

171
README.md
View File

@ -19,8 +19,6 @@
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
[![Join the chat at https://gitter.im/visualboyadvance-m/Lobby](https://badges.gitter.im/visualboyadvance-m/Lobby.svg)](https://gitter.im/visualboyadvance-m/Lobby)
Our bridged Discord server is [Here](https://discord.gg/EpfxEuGMKH).
We are also on *`#vba-m`* on [Libera IRC](https://libera.chat/) which has a [Web
@ -59,35 +57,39 @@ Factory Reset`.
## System Requirements
Windows 7, 8.1 or 10/11, Linux distro's or macOS.
Windows XP, Vista, 7, 8.1 or 10/11, Linux distros or macOS.
2Ghz x86 (or x86-64) Intel Core 2 or AMD Athlon processor with SSE, Snapdragon 835
or newer CPU compatible with Arm for Windows.
2Ghz x86(or x86-64) Intel Core 2 or AMD Athlon processor with SSE, Snapdragon 835
or newer cpu compatible with Arm for Windows.
- Just a guideline, lower clock speeds and Celeron processors may be able to run at full
speed on lower settings, and Linux based ARM Operating systems have wider cpu support.
speed on lower settings, and Linux based ARM Operating systems have wider CPU support.
DirectX June 2010 Redist [Full](https://www.microsoft.com/en-au/download/details.aspx?id=8109) / [Websetup](https://www.microsoft.com/en-au/download/details.aspx?id=35) for Xaudio (Remember to uncheck Bing on the websetup)
DirectX June 2010 Redist
[Full](https://www.microsoft.com/en-au/download/details.aspx?id=8109) /
[Websetup](https://www.microsoft.com/en-au/download/details.aspx?id=35) for
Xaudio (Remember to uncheck Bing on the websetup.)
## Building
The basic formula to build vba-m is:
```shell
```bash
cd ~ && mkdir src && cd src
git clone https://github.com/visualboyadvance-m/visualboyadvance-m.git
cd visualboyadvance-m
./installdeps
# ./installdeps will give you build instructions, which will be similar to:
./installdeps # On Linux or macOS
mkdir build && cd build
cmake .. -G Ninja
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release -G Ninja
ninja
```
`./installdeps` is supported on MSys2, Linux (Debian/Ubuntu, Fedora, Arch,
Solus, OpenSUSE, Gentoo and RHEL/CentOS) and Mac OS X (homebrew, macports or
fink.)
`./installdeps` is supported on MSYS2, Linux (Debian/Ubuntu, Fedora, Arch,
Solus, OpenSUSE, Gentoo and RHEL/CentOS) and Mac OS X (homebrew, MacPorts or
Fink.)
## Building a Libretro core
@ -98,7 +100,7 @@ cd src/libretro
make -j`nproc`
```
Copy vbam_libretro.so to your RetroArch cores directory.
Copy `vbam_libretro.so` to your RetroArch cores directory.
## Visual Studio Support
@ -118,14 +120,16 @@ environment loaded.
Using your own user-wide installation of vcpkg is supported, just make sure the
environment variable `VCPKG_ROOT` is set.
To build in the visual studio command prompt, use something like this:
To build in the Visual Studio `x64 Native Tools Command Prompt`, use something
like this:
```
mkdir build
cd build
cmake .. -DVCPKG_TARGET_TRIPLET=x64-windows-static -DCMAKE_BUILD_TYPE=Debug -G Ninja
cmake .. -DCMAKE_BUILD_TYPE=Release -G Ninja
ninja
```
.
## Visual Studio Code Support
@ -163,7 +167,7 @@ And the following development libraries:
- [gettext](https://www.gnu.org/software/gettext/) and gettext-tools
- [SDL2](https://www.libsdl.org/) (required)
- [SFML](https://www.sfml-dev.org/) (optional, for link)
- [OpenAL](https://www.openal.org/) or [openal-soft](https://kcat.strangesoft.net/openal.html) (required, a sound interface)
- [openal-soft](https://kcat.strangesoft.net/openal.html) (required, a sound interface)
- [wxWidgets](https://wxwidgets.org/) (required for GUI, 2.8 and non-stl builds are no longer supported)
On Linux and similar, you also need the version of GTK your wxWidgets is linked
@ -183,61 +187,46 @@ This is supported on Fedora, Arch, Solus and MSYS2.
may be `win32` which is an alias for `mingw-w64-i686` to target 32 bit Windows,
or `mingw-w64-x86_64` for 64 bit Windows targets.
The target is implicit on MSys2 depending on which MINGW shell you started (the
The target is implicit on MSYS2 depending on which MINGW shell you started (the
value of `$MSYSTEM`.)
On Debian/Ubuntu this uses the MXE apt repository and works quite well.
On Fedora it can build using the Fedora MinGW packages, albeit with wx 2.8, no
OpenGL support, and no Link support for lack of SFML.
On Arch it currently doesn't work at all because the AUR stuff is completely
broken, I will at some point redo the arch stuff to use MXE as well.
## CMake Options
The CMake code tries to guess reasonable defaults for options, but you can
override them, for example:
```shell
cmake .. -DENABLE_LINK=NO -G Ninja
cmake .. -DCMAKE_BUILD_TYPE=Release -DENABLE_LINK=NO -G Ninja
```
Of particular interest is making **Release** or **Debug** builds, the default
mode is **Release**, to make a **Debug** build use something like:
```shell
cmake .. -DCMAKE_BUILD_TYPE=Debug -G Ninja
```
Here is the complete list:
. Here is the complete list:
| **CMake Option** | **What it Does** | **Defaults** |
|-----------------------|----------------------------------------------------------------------|-----------------------|
| ENABLE_SDL | Build the SDL port | OFF |
| ENABLE_WX | Build the wxWidgets port | ON |
| ENABLE_DEBUGGER | Enable the debugger | ON |
| ENABLE_ASM_CORE | Enable x86 ASM CPU cores (**BUGGY AND DANGEROUS**) | OFF |
| ENABLE_ASM | Enable the following two ASM options | ON for 32 bit builds |
| ENABLE_ASM_SCALERS | Enable x86 ASM graphic filters | ON for 32 bit builds |
| ENABLE_MMX | Enable MMX | ON for 32 bit builds |
| ENABLE_LINK | Enable GBA linking functionality (requires SFML) | AUTO |
| ENABLE_LIRC | Enable LIRC support | OFF |
| ENABLE_FFMPEG | Enable ffmpeg A/V recording | AUTO |
| ENABLE_ONLINEUPDATES | Enable online update checks | ON |
| ENABLE_LTO | Compile with Link Time Optimization (gcc and clang only) | ON for release build |
| ENABLE_GBA_LOGGING | Enable extended GBA logging | ON |
| ENABLE_DIRECT3D | Direct3D rendering for wxWidgets (Windows, **NOT IMPLEMENTED!!!**) | ON |
| ENABLE_XAUDIO2 | Enable xaudio2 sound output for wxWidgets (Windows only) | ON |
| ENABLE_ASAN | Enable libasan sanitizers (by default address, only in debug mode) | OFF |
| UPSTREAM_RELEASE | Do some release tasks, like codesigning, making zip and gpg sigs. | OFF |
| BUILD_TESTING | Build the tests and enable ctest support. | ON |
| VBAM_STATIC | Try link all libs statically (the following are set to ON if ON) | OFF |
| SDL2_STATIC | Try to link static SDL2 libraries | OFF |
| SFML_STATIC_LIBRARIES | Try to link static SFML libraries | OFF |
| FFMPEG_STATIC | Try to link static ffmpeg libraries | OFF |
| OPENAL_STATIC | Try to link static OpenAL libraries | OFF |
| TRANSLATIONS_ONLY | Build only the translations.zip and nothing else | OFF |
| `ENABLE_SDL` | Build the SDL port | OFF |
| `ENABLE_WX` | Build the wxWidgets port | ON |
| `ENABLE_DEBUGGER` | Enable the debugger | ON |
| `ENABLE_ASM_CORE` | Enable x86 ASM CPU cores (**BUGGY AND DANGEROUS**) | OFF |
| `ENABLE_ASM` | Enable the following two ASM options | ON for 32 bit builds |
| `ENABLE_ASM_SCALERS` | Enable x86 ASM graphic filters | ON for 32 bit builds |
| `ENABLE_MMX` | Enable MMX | ON for 32 bit builds |
| `ENABLE_LINK` | Enable GBA linking functionality (requires SFML) | AUTO |
| `ENABLE_LIRC` | Enable LIRC support | OFF |
| `ENABLE_FFMPEG` | Enable ffmpeg A/V recording | AUTO |
| `ENABLE_ONLINEUPDATES` | Enable online update checks | ON |
| `ENABLE_LTO` | Compile with Link Time Optimization (gcc and clang only) | ON for release build |
| `ENABLE_GBA_LOGGING` | Enable extended GBA logging | ON |
| `ENABLE_XAUDIO2` | Enable xaudio2 sound output for wxWidgets (Windows only) | ON |
| `ENABLE_ASAN` | Enable libasan sanitizers (by default address, only in debug mode) | OFF |
| `UPSTREAM_RELEASE` | Do some release tasks, like codesigning, making zip and gpg sigs. | OFF |
| `BUILD_TESTING` | Build the tests and enable ctest support. | ON |
| `VBAM_STATIC` | Try link all libs statically (the following are set to ON if ON) | OFF |
| `SDL2_STATIC` | Try to link static SDL2 libraries | OFF |
| `SFML_STATIC_LIBRARIES` | Try to link static SFML libraries | OFF |
| `FFMPEG_STATIC` | Try to link static ffmpeg libraries | OFF |
| `OPENAL_STATIC` | Try to link static OpenAL libraries | OFF |
| `TRANSLATIONS_ONLY` | Build only the translations.zip and nothing else | OFF |
Note for distro packagers, we use the CMake module
[GNUInstallDirs](https://cmake.org/cmake/help/v2.8.12/cmake.html#module:GNUInstallDirs)
@ -247,52 +236,6 @@ On Unix to use a different version of wxWidgets, set
`wxWidgets_CONFIG_EXECUTABLE` to the path to the `wx-config` script you want to
use.
## MSys2 Notes
To run the resulting binary, you can simply type:
```shell
./visualboyadvance-m
```
in the shell where you built it.
If you built with `-DCMAKE_BUILD_TYPE=Debug`, you will get a console app and
will see debug messages, even in mintty.
If you want to start the binary from e.g. a shortcut or Explorer, you will need
to put `c:\msys64\mingw32\bin` for 32 bit builds and `c:\msys64\mingw64\bin`
for 64 bit builds in your PATH (to edit system PATH, go to Control Panel ->
System -> Advanced system settings -> Environment Variables.)
If you want to package the binary, you will need to include the MinGW DLLs it
depends on, they can install to the same directory as the binary.
Our own builds are static.
## Debug Messages
We have an override for `wxLogDebug()` to make it work even in non-debug builds
of wx and on windows, even in mintty.
It works like `printf()`, e.g.:
```cpp
int foo = 42;
wxLogDebug(wxT("the value of foo = %d"), foo);
```
From the core etc. the usual:
```cpp
fprintf(stderr, "...", ...);
```
will work fine.
You need a debug build for this to work or to even have a console on Windows.
Pass `-DCMAKE_BUILD_TYPE=Debug` to cmake.
## Reporting Crash Bugs
If the emulator crashes and you wish to report the bug, a backtrace made with
@ -311,27 +254,25 @@ do something such as:
```shell
ulimit -c unlimited
```
in your shell to enable coredump files.
, in your shell to enable core files.
[This
post](https://ask.fedoraproject.org/en/question/98776/where-is-core-dump-located/?answer=98779#post-id-98779)
explains how to retrieve core dump on Fedora Linux (and possibly other
distributions.)
explains how to retrieve core dump on some distributions, when they are managed
by systemd.
Once you have the core dump file, open it with `gdb`, for example:
Once you have the core file, open it with `gdb`, for example:
```shell
gdb -c core ./visualboyadvance-m
```
In the `gdb` shell, to print the backtrace, type:
. In the `gdb` shell, to start the process and print the backtrace, type:
```
run
bt
```
This may be a bit of a hassle, but it helps us out immensely.
. This may be a bit of a hassle, but it helps us out immensely.
## Contributing