Contributing to Development - Shin-Aska/DosboxStagingReplacerForGOGGalaxy GitHub Wiki

Contributing to Development

Welcome to the development and contribution guide for Dosbox Staging Replacer for GOG Galaxy.

Whether you're fixing a bug, implementing a new feature, or improving documentation, this page will help you get started with contributing.

Getting Started

  1. Fork the repository and clone your fork:

    git clone https://github.com/YOUR_USERNAME/DosboxStagingReplacerForGOGGalaxy.git
cd DosboxStagingReplacerForGOGGalaxy

  2. Install dependencies:

    • C++20-compatible compiler (Tested to work as low as GCC-11)
    • CMake version 3.30 or up

  3. Create a build folder (in this example, we will create a folder for debug)

    mkdir -p cmake-build-debug

  4. Change to the build folder

    cd cmake-build-debug

  5. Run CMake to generate the build files

    cmake ..

  6. Build the project

    cmake --build . --config Debug

  7. Run test

    ctest

  8. Run the application

    DosboxStagingReplacer.exe --help

IDE Integration

  • CLion: CLion automatically detects and configures the project using the provided CMakeLists.txt. No additional setup is required.
  • Visual Studio Code (VSCode): Install the C++ extension (by Microsoft), which includes built-in support for CMake. Once installed, open the repository folder and VSCode will detect the CMakeLists.txt file at the root. You can configure build settings and targets via the Command Palette (Ctrl+Shift+P) using commands like CMake: Configure and CMake: Build.
  • Other IDEs: If your IDE supports CMake natively, it should recognize the root CMakeLists.txt file and configure the project automatically. If not, check whether a CMake plugin is available for your IDE. Alternatively, you can use CMake's -G option to generate project files (e.g., for Code::Blocks or Eclipse), though note that this method is deprecated by CMake since version 3.27

Note: It is recommended to name build directories with a cmake-build- prefix (e.g., cmake-build-debug, cmake-build-release). The repository's .gitignore is configured to exclude such folders automatically.

Contribution Guidelines

Areas You Can Help With

  • Feature Additions
    • Support alternate DOSBox versions (--dosbox-version-manual)
  • Code Improvements
    • Refactor loops to use const refs
    • Enforce consistent naming (operationsCount, SqlLiteService)
    • Improve exception handling on filesystem or DB edge cases
  • File & Config Tools
    • Expand ScriptEditService to handle edge cases in .conf parsing
  • Documentation
    • Expand code documentation (Doxygen-friendly)
    • Help maintain class diagrams or flow charts
  • Security
    • Due to the nature of bundling third-party libraries via amalgamation, manually update these libraries to their latest versions
  • Test case
    • Help in creating new and maintaining existing test cases

Development Notes

  • Most result models like PlayTaskInformation implement a fillFromStatement() method for populating from SQLite.
  • Service classes (e.g., GogGalaxyService, FileBackupService) are designed to be testable and loosely coupled.
  • Currently the diagram is manually created. Will explore automated solutions in the future.

Submitting a Pull Request

  1. Create a feature branch:

    git checkout -b feature/your-change

  2. Commit changes using conventional commit format:

    git commit -m "feat(service): add custom launch parameter support"

  3. Push and open a pull request to main.

Unit Testing

To add a new test:

  1. Create a new *.cpp file in the tests/ directory containing your test code.
  2. Re-run cmake .. in your build directory to configure the new test.
  3. Re-run cmake --build in your build directory to recompile all test cases (including your newly created one)
  4. Execute ctest to verify

To update an existing test:

  1. Modify the existing test .cpp file under the tests/ directory.
  2. Rebuild the tests by running cmake ..
  3. Recompile all tests again using cmake --build
  4. Execute ctest to verify

Tips

  • Stick to camelCase for variables and PascalCase for class names.
  • Keep classes that require factories in interfaces/, utility classes in helpers/ and logic in services/.

Questions?

Open a discussion or ping directly via a PR comment.