- Clone the repository:
git clone https://github.com/cm-jones/libdsc.git
cd libdsc- Open in VSCode with Dev Containers extension to get a complete development environment with all tools pre-installed.
./scripts/build.sh./scripts/build.sh
cd build
ctest --output-on-failure./scripts/lint.sh./scripts/format.shThe recommended way to create releases is through GitHub:
- Tag your version:
git tag v0.1.0
git push origin v0.1.0- GitHub Actions will automatically:
- Build source tarball
- Create Debian packages
- Create RPM packages
- Create Arch packages
- Upload all artifacts to the GitHub release
This ensures consistent, reproducible builds in a clean environment.
For development and testing, you can build packages locally in the dev container:
./scripts/build-debian.shOutputs:
- libdsc0_*.deb (runtime)
- libdsc-dev_*.deb (development)
./scripts/build-rpm.shOutputs:
- libdsc-*.rpm (runtime)
- libdsc-devel-*.rpm (development)
Requirements:
- RPM-based system (Fedora/RHEL) or container
- rpm-build and rpmdevtools packages
./scripts/build-arch.shOutputs:
- libdsc-*.pkg.tar.zst (combined runtime/dev)
Requirements:
- Arch Linux system or container
- base-devel package group
Note: Local package builds are useful for testing but should not be distributed. Official packages should come from GitHub releases.
-
Debian (.deb)
- libdsc0: Runtime library
- libdsc-dev: Development files (headers, cmake)
-
RPM (.rpm)
- libdsc: Runtime library
- libdsc-devel: Development files (headers, cmake)
-
Arch (.pkg.tar.zst)
- Single package with both runtime and development files
- Release tags: v0.1.0
- Debian format: 0.1.0
- RPM format: 0.1.0
- Arch format: 0.1.0
- Create a feature branch:
git checkout -b feature/my-feature- Make your changes
- Run tests and linting
- Submit a pull request
- Follow existing code formatting
- Use clang-format (configured in .clang-format)
- Run format.sh before committing