Revise DR-005-infra design document

[nradakovic]

Updated the design document to reflect the proposed directory structure and rationale for the S-CORE Bazel C++ Toolchain Configuration Repository.

[github-actions]

⚠️ Docs-as-Code version mismatch detected
Please check the CI build logs for details and align the documentation version with the Bazel dependency.

[AlexanderLanin]

Suggested change

	====================================================================================
	=================================================================================================

[evinoth1206]

Given that Linux has multiple distributions and S-core currently uses three different ones (Ubuntu for dev containers, EB-Linux and Red Hat Linux for reference integration), should we consider creating separate platform and tool chain definitions for each (e.g., linux-ubuntu, linux-eb, linux-redhat) or as the toolchain contains only rules/config it should be compatible for different Linux flavours?

[nradakovic]

These are distributions and as such should not depend on platform constraints (OS and CPU). We can add flags to platform if we want to have some separation between them, but I would like first to know what is delta between these 3 in terms of configuration.

[LittleHuba]

@nradakovic am I right that this would go into the direction of implementing all the toolchains on our own? What about available opensource toolchains for GCC and LLVM?
Or would it be viable to use these available toolchains as part of this setup?

I would like an evaluation of the different options. This helps in the future if we ever want to reevaluate or understand why we decided this way.

[nradakovic]

GCC doesn't exist in OS world (at least I'm not aware) and LLVM seems to be a bit heavy on resource usage (not optimized for CI). That's why BMW has it's own implementation of LLVM.

[LittleHuba]

It would still be great to have this as part of the document.

GCC doesn't exist in OS world (at least I'm not aware)

GCC does exist here: https://github.com/f0rmiga/gcc-toolchain
It works as advertised, but I can't judge the quality of the implementation.

LLVM seems to be a bit heavy on resource usage (not optimized for CI)

My proposal is to then upstream the necessary changes. I'm sure that other people also use the toolchain in a CI environment. So there should be interest in having this in the OS world.

[nradakovic]

Well, it's not my call when LLVM will be outsourced from SWH end, I cannot enforce this. For now we use the one that is available. Once it's available we can add it into repo without too much effort.
The other GCC solution doesn't really fit our needs. The interface is quite close, we cannot inject additional features (my implementation will support that) and there is no way of redefining existing features. Also I cannot point to different package. This config only support certain versions of GCC.