1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
# Build Stripping Rules
This document outlines the rules for stripping non-essential code from the final binary under the `STRIP_ALL` macro to achieve the <=64k size target.
## General Principles
- **Code Reduction:** Any code that is not critical for the demo's core functionality or runtime presentation should be conditionalized under `STRIP_ALL`.
- **Debug Features:** All debugging outputs, logging, and optional features not relevant to the final presentation must be stripped.
- **Configuration:** Minimize code paths related to configuration and argument parsing that are not essential for the demo's execution.
- **Dependencies:** Be mindful of dependencies pulled in by stripped features; their removal might also be necessary.
## Specific Stripping Targets
### 1. Debug Outputs & Logging
- **`printf`, `std::cerr`, `std::cout`:** Wrap all non-essential output statements within `#if !defined(STRIP_ALL)`. This includes:
- Informational messages during initialization.
- Debug logs from various systems (rendering, audio, etc.).
- Error messages that are not critical for runtime stability (e.g., recoverable warnings).
- Assert messages that are covered by runtime checks or are only for development.
### 2. Command-Line Interface (CLI) Arguments
- **Optional Flags:** Disable or remove CLI arguments that are purely for debugging or development purposes. This includes, but is not limited to:
- `--seek` (if not part of a required feature).
- Resolution adjustment flags.
- Debug visualization toggles (e.g., `--debug`).
- Verbose logging flags.
### 3. Debug Fields in Structs
- **Non-Essential Members:** Remove members from structs that are used solely for debugging or development. Examples include:
- `label` or `name` fields in objects or data structures.
- Pointers or data structures intended only for inspection.
- Temporary variables or buffers used only during development.
### 4. Dynamic Audio Generation
- **`generate_tone` and `generate_melody` functions:** These functions are used for runtime audio synthesis. If the final demo relies solely on pre-packaged spectrogram assets and does not require dynamic generation, these functions and their associated global variables (`g_spec_buffer_a`, `g_spec_buffer_b`, `g_melody_data`) should be wrapped in `#if !defined(STRIP_ALL)`.
- **`register_spec_asset` function:** This function is used to load spectrograms from assets. While useful, if all necessary spectrograms are embedded directly or if asset loading is deemed non-critical for the stripped build, consider conditionalizing its calls or the function itself.
## Implementation Strategy
- **Iterative Removal:** Apply stripping rules iteratively. After each set of changes, rebuild and test to ensure no regressions.
- **Compiler Warnings:** Pay close attention to compiler warnings, as they can indicate unintended side effects of stripping.
- **Testing:** Ensure that core functionality remains intact after stripping. Existing tests should pass.
|
