valter/dosbox-staging
1
0
Fork 0
Code Releases Activity

Refactor the build and list-packages scripts

Browse source 
Until now the build and package scripts have supported
several architectures, compilers, build types, package-managers,
and bit-depth targets.

The code might be maintainable if left as-such, however we have plans
to continue expanding the number of architectures (ARM, PPC, ... ),
operating systems (Android, BSDs, ...), and build variations
amung those.

The scripts (regardless of language) would only grow in complexity
as more variations are added. Thus, we needed a solution that can
scale without adding complexity.

To achieve this, the scripts were refactored as follows:
 - all "data" was moved out of code into configuration files
 - A back-end "Automator" engine was written to parse the
   data based on generic variables fed to it by a front-end
   script
 - build.sh and list-packages.sh were re-authored as thin front-end
   scripts that drive the automator
 - Their CLI's were retained so there has been very little change
   needed to the CI invocation lines.  The only changes have been to
   clarify the existing arguments improved based on feedback, ie:
   --build-type release, --build-type debug instead of fast, small
This commit is contained in:
krcroft 2019-11-23 19:54:19 -08:00 • committed by Patryk Obara
parent fd74aa0720
commit 0f11ab8ecb
39 changed files with 478 additions and 697 deletions
Download patch file Download diff file Expand all files Collapse all files

13
scripts/build.md
View file

@ -57,7 +57,7 @@ Use of both scripts is described below.
`./scripts/list-build-dependencies.sh -p msys2 | xargs pacman -S --noconfirm`
1. Launch the build script with default settings:
`./scripts/build.sh --bin-path /mingw64/bin`
`./scripts/build/run.sh --bin-path /mingw64/bin`
## MacOS Installation and Usage
@ -131,10 +131,15 @@ options to the **list-build-dependencies.sh** and **build.sh** scripts:
After building, your `dosbox` or `dosbox.exe` binary will reside inside `./dosbox-staging/src/`.
Build flags you might be interested in:
* `--release debug`, to build a binary containing debug symbols (instead of **fast** or **small**)
* `--lto`, perform optimizations across the entire object space instead of per-file (Only available on Mac and Linux)
The above flags are othogonal and thus can be mixed-and-matched as desired.
* `--release debug`, to build a binary containing debug symbols
* You can run the resulting binary in the GNU debugger: `gdb /path/to/dosbox`, followed by `start mygame.bat`
* `--release profile`, to generate performance statistics
* Instructions are provided after the build completes, which describe how to generate and process the profiling data
* `--release <sanitizer-type>`, to build a binary that performs dynamic code-analysis at runtime (Linux and macOS)
* see `./scripts/build.sh --help` for a list of sanitizer-types that are available
* Run your binary like normal and it will generate output describing problematic behavior
* Some sanitizers accept runtime options via an environment variables, such as `ASAN_OPTIONS`, described here: https://github.com/google/sanitizers/wiki/AddressSanitizerFlags
If you want to run multiple back-to-back builds from the same directory with different settings then
add the `--clean` flag to ensure previous objects and binaries are removed.