Proposal: build clean with recent compilers for system-agnostic S-CORE

[AlexanderLanin]

Context

The current setup primarily relies on qcc for QNX 8.0 = gcc 12.
However, SCORE is expected to be integrated into multiple target environments.
Relying on a single compiler/version locks SCORE to one ecosystem and makes broader adoption difficult.

Problems

• Limited scope: qcc/gcc 12 is tied to QNX 8.0. For future targets beyond QNX, this setup does not scale.
• Missed diagnostics: Newer and other compilers provide stronger checks “for free,” reducing the need for additional static-analysis tools.

Proposal

Adopt a “build clean with recent compilers” philosophy to make SCORE as system-agnostic as safety allows:

• Define a minimum set of supported compilers (covering gcc and clang, old and modern).
• Require all SCORE modules to build cleanly with this set.
• Ensure compiler support covers both safety-relevant targets and integration into arbitrary environments.

Benefits

• System-agnostic: SCORE can integrate into a wide range of environments, not just QNX.
• Future-proof: Easier adaptation to new platforms.
• Higher quality: Modern compilers catch issues that older ones miss.
• Clear baseline: Every module is validated against the same modern standards.

Next Steps

• A go-ahead from tech leads to move forward.
• Infrastructure community defines the exact compiler set and versions.
• Update CI pipelines to enforce clean builds across the selected compilers.

---

❓ Requested decision: Should SCORE adopt a modern system-agnostic compiler baseline (build clean with recent compilers, not just qcc/gcc 12) to support integration into arbitrary environments as far as safety allows?

[FScholPer]

Added to the workshop agenda tomorrow but please also add some proposals what should be used

[AlexanderLanin]

We did not discuss anything concrete. Basic idea is:

• oldest gcc that is required for whatever OS / distribution
• oldest clang that is required for whatever OS / distribution
• newest gcc (provides most advanced warnings + stepping stone for future updates)
• newest clang (provides most advanced warnings + stepping stone for future updates)
• (versions in between are typically not required, as incompatibilities are very rare)

[opajonk]

How about this:

For all builds:

• Recent Clang and Clang-Tidy: LLVM releases major version every 6 moths, with bugfix releases every 2 weeks. This is one (if not the) best compilers to find issues in your code. The Arm Compiler for Embedded FuSa is based on LLVM. Must use both (clang != clang-tidy).
• Recent GCC (they seem to have a "support period" of about 12 months for a major release). Default compiler for many OSs. Base of the QNX compiler. Must use.
  • Specifically: GCC 12.2 as well, since the QNX 8 compiler is based on this it makes sense to use this as well. Maybe as part of all builds, maybe only in some kind of higher-level integration build is sufficient... cannot say.

Updates:

• Minor version updates should be done when they are released. This should not break anything (must be validated before roll-out, obviously). Major version updates could "break stuff", so that needs an agreement. However, with a good test suite (which we need anyway), changing the compiler version is a set of "Dependabot-style version updates" and can be validated perfectly.

Misc:

• Important side discussions, but can be done with C++ experts:
  • Which settings to use for each compiler in detail?
  • How to perform MISRA-C++? Could be tricky in open source.
  • How to perform code coverage measurements? (especially MC/DC is probably a good idea, but tricky business)
  • Which sanitizers to use with Clang / GCC. Some are really necessary, some are mutually exclusive, ...

[opajonk]

And actually: Rust compilers are not yet part of this discussion. I have no good clue about this, to be honest. Maybe someone "rusty" can jump in?

[FScholPer]

Can we continue that discussion in an issue as then we can move the whole stuff to the TL LOP?

[AlexanderLanin]

Sure, converted: #1730