scalps releases are built and tested on openSUSE Leap 16.0 on x86-64. This is the only configuration the maintainers commit to supporting. Other compatible operating systems and toolchains may configure, build, and run scalps, but the project does not promise to test them or fix problems limited to them.
| Component | Release-tested version |
|---|---|
| Operating system | openSUSE Leap 16.0 |
| C and C++ compiler | GCC 15.x from Leap 16 |
| C++ language level | C++17 |
| LLVM and Clang | 19.1.x from Leap 16 |
| JsonCpp | 1.9.6 from Leap 16 |
| SQLite | 3.35 or newer from Leap 16, built with FTS5 |
| CMake | 3.20 or newer |
The versions in the table describe the release-tested configuration, not an allowlist. The normal CMake configuration does not reject an operating system, compiler, LLVM and Clang release, or JsonCpp release merely because it differs from that configuration. It checks the actual build requirements: C++17; a Clang CMake package that provides matching clang-cpp and LLVM targets; a usable JsonCpp pkg-config or CMake target; SQLite 3.35 or newer with FTS5; Clang's builtin headers; and linker support for position-independent executables. A missing requirement remains a configuration error.
Clang's CMake package selects the LLVM package built for that Clang release. CMake obtains the builtin-header directory from the corresponding Clang driver instead of assuming a distribution-specific library path. Installations without that driver may set SCALPS_CLANG_RESOURCE_DIRECTORY explicitly.
Reports and portability changes from other configurations are welcome when they preserve the release-tested build, but acceptance does not add that configuration to the project's maintenance commitment.
Environments that inject toolchain arguments through compiler wrappers (including Nix) use compiler configuration discovery on index and status. Configure .scalps/query-driver with auto or absolute patterns, or rely on the Nix store default when every compilation driver already resolves under /nix/store/. scalps then runs only allowlisted, GCC-compatible drivers to recover the effective target and ordered system includes. The facility is deliberately limited: it does not emulate arbitrary wrapper behavior, and without authorization a previously queried index reports unknown freshness rather than re-running drivers. Index from the build environment when package includes are environment-injected. See Compiler configuration discovery and the security policy.
A change to the release-tested environment or a required dependency requires all of the following in one change:
- Review the CMake package discovery and diagnostics.
- Update the openSUSE RPM build requirements and verify its generated runtime dependencies.
- Configure and build with strict warnings in the new environment.
- Run the complete test suite, including the installed-executable indexing test.
- Build the RPM and run its
%checksection in a clean Leap 16 build environment. - Update this policy and installation documentation.
When testing a different LLVM, Clang, or JsonCpp release, configure and compile scalps and run the complete test suite rather than relying on the version number alone. If an LLVM or Clang change alters extracted records, the extractor version must also be increased and existing indexes must be rebuilt. SQLite storage changes similarly require the schema version and compatibility checks to be reviewed.
The strict local check is:
cmake --preset warnings
cmake --build --preset warnings
ctest --preset warningsThe openSUSE RPM provides the reproducible system-package check. Its optimized production build invokes the same complete CTest suite before producing a package. Strict warnings remain a separate Debug check because GCC 15's optimized builds emit a -Wnonnull diagnostic from the Clang 19 headers; treating that external-header diagnostic as a release-build error would prevent packaging otherwise valid code.