{"id":44956412,"url":"https://github.com/eclipse-score/bazel_platforms","last_synced_at":"2026-04-02T18:33:02.954Z","repository":{"id":306055864,"uuid":"1024259987","full_name":"eclipse-score/bazel_platforms","owner":"eclipse-score","description":"Bazel platform definitions used by S-CORE modules","archived":false,"fork":false,"pushed_at":"2026-03-26T10:49:58.000Z","size":46,"stargazers_count":1,"open_issues_count":0,"forks_count":9,"subscribers_count":1,"default_branch":"main","last_synced_at":"2026-03-27T03:56:27.463Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"https://eclipse-score.github.io/bazel_platforms","language":"Starlark","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/eclipse-score.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":"NOTICE","maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2025-07-22T12:26:47.000Z","updated_at":"2026-03-26T10:49:21.000Z","dependencies_parsed_at":"2025-12-30T16:05:51.604Z","dependency_job_id":null,"html_url":"https://github.com/eclipse-score/bazel_platforms","commit_stats":null,"previous_names":["eclipse-score/bazel_platforms"],"tags_count":8,"template":false,"template_full_name":null,"purl":"pkg:github/eclipse-score/bazel_platforms","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eclipse-score%2Fbazel_platforms","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eclipse-score%2Fbazel_platforms/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eclipse-score%2Fbazel_platforms/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eclipse-score%2Fbazel_platforms/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/eclipse-score","download_url":"https://codeload.github.com/eclipse-score/bazel_platforms/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/eclipse-score%2Fbazel_platforms/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31312920,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-02T12:59:32.332Z","status":"ssl_error","status_checked_at":"2026-04-02T12:54:48.875Z","response_time":89,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-02-18T12:03:41.395Z","updated_at":"2026-04-02T18:33:02.946Z","avatar_url":"https://github.com/eclipse-score.png","language":"Starlark","funding_links":[],"categories":[],"sub_categories":[],"readme":"# S-CORE Bazel Platforms\n\nThis repository serves as the central source for S-CORE Bazel platforms and constraints, designed to:\n\n- Provide global constraints that complement the standard set offered by Bazel, enabling more precise environment description and selection.\n- Define consistent platform configurations to make toolchain selection seamless and uniform across all S-CORE modules.\n\nBy using this repository, S-CORE teams can ensure compatibility, reproducibility, and clarity when specifying build environments and extending Bazel’s default capabilities.\n\n## Table of content\n\n- [How to Use It](#how-to-use-it)\n- [Existing Constraints](#existing-constraints)\n  - [CPU Architecture](#cpu-architecture)\n  - [Operating System](#operating-system)\n  - [Versions](#versions)\n  - [Runtime Ecosystem](#runtime-ecosystem)\n- [Change Process](#change-process)\n  - [Adding a New constraint_setting](#adding-a-new-constraint_setting)\n  - [Adding a New constraint_value](#adding-a-new-constraint_value)\n  - [Adding a New platform](#adding-a-new-platform)\n\n## How to use it\n\nTo use predefined platforms and constraints, add `score_bazel_platforms` as a dependency in your `MODULE.bazel` file:\n\n```python\nbazel_dep(name = \"score_bazel_platforms\", version = \"\u003clatest-version\u003e\")\n```\n\nYou can then load and reference the provided constraints or platforms in your BUILD or .bzl files.\nFor example, to select a platform in your .bazelrc:\n\n```python\n# in .bazelrc selecting the platform\nbuild:\u003cconfig\u003e --platforms=@score_bazel_platforms//:x86_64-linux\n```\n\nor setting select statment based on Operating System:\n\n```python\nmy_rule(\n    name = \"example\",\n    data = select({\n        \"@platforms//os:linux\": \":linux_runtime_config\",\n        \"@platforms//os:qnx\": \":qnx_runtime_config\",\n    })\n)\n```\n\n\u003e NOTE: Predefined `constraint_setting` and `constraint_value` like CPU and/or OS targets can be used directly by referencing the `@platforms` module.\n\n## Existing constraints\n\nPlatforms are typically defined by combination of operating system (OS) and CPU architecture. Our goal is to reuse Bazel's canonical definitions whenever possible, leveraging it's core platform model to ensure consistency.\n\nDefined `constraint_settings`:\n\n- CPU Architecture\n- Operating System\n- Version (OS, GCC, glibc, ...)\n- Runtime ecosystem\n\n### CPU Architecture\n\nThis setting is entirely reused from Bazel upstream definitions, however, it's important to note that the specificity of constraint_values for CPU architecture can vary. In this platform module, we only refer to the ISA (Instruction Set Architecture) - such as x86_64 or arm64 - rather than microarchitecture used in some Bazel projects.\n\n### Operating System\n\nThis setting is also entirely reused from Bazel upstream definitions.\n\n### Platform Variant (Kind and Version)\n\nThe platform_variant constraint represents the `\u003cvariant_kind\u003e_\u003cvariant_version\u003e` segment of the platform identifier:\n```bash\ncpu-os-\u003cvariant_kind\u003e_\u003cvariant_version\u003e-runtime_es\n```\n\nThis constraint models a versioned environment component that influences build behavior, ABI compatibility, or runtime expectations.\u003c/br\u003e\nOnly one platform variant is active per platform instance.\u003c/br\u003e\nThe variant kind determines which component family is being constrained, and the variant version specifies the exact version.\u003c/br\u003e\n\nWe currently support the following variant kinds:\n\n- GCC version\n- GLIBC version\n- OS version\n- SDK version\n- SDP version\n\n#### `os_version` constraint\n\nThe `os_version` constraint identifies the version of the operating system userland and ABI targeted by a platform.\u003c/br\u003e\nIt captures version-specific compatibility requirements beyond the OS family itself, such as:\n\n- kernel or userland ABI expectations\n- system library versions\n- OS-level feature availability\n- distribution-specific behavior\n\nThis constraint allows targets to distinguish between different versions of the same operating system (for example different QNX or Linux releases) while keeping the OS family modeled separately via the os constraint.\u003c/br\u003e\nThe os_version constraint is used to:\n\n- ensure ABI compatibility\n- select version-specific dependencies\n- avoid overloading OS or toolchain definitions\n- isolate distribution-specific patches or behaviors\n\n#### `gcc_version` constraint\n\nThe `gcc_version` constraint identifies the compiler version used to build a target.\u003c/br\u003e\nIt captures compiler-specific compatibility concerns such as:\n\n- supported language standards\n- code generation behavior\n- ABI or runtime library differences\n- compiler-specific workarounds or flags\n\nThis constraint allows platforms and toolchains to express compiler version requirements independently of the operating system, CPU architecture, or SDK version.\u003c/br\u003e\nThe gcc_version constraint is used to:\n\n- select appropriate toolchains\n- gate compiler-dependent features\n- maintain compatibility across compiler upgrades\n- prevent accidental mixing of incompatible compiler runtimes\n\n#### `glibc_version` constraint\n\nThe `glibc_version` constraint identifies the GNU C Library version targeted by the platform.\u003c/br\u003e\nSince glibc defines critical parts of the userspace ABI, this constraint directly impacts binary compatibility.\u003c/br\u003e\nIt captures compatibility requirements such as:\n\n- symbol versioning\n- dynamic loader behavior\n- system call wrappers\n- threading and memory model behavior\n\nThis constraint is especially important when:\n- building binaries intended to run on older distributions\n- maintaining forward/backward ABI compatibility\n- cross-compiling against a specific sysroot\n\nThe glibc_version constraint is used to:\n\n- guarantee runtime compatibility\n- prevent linking against incompatible libc versions\n- enforce consistent sysroot usage\n\n#### `sdk_version` constraint\n\nThe `sdk_version` constraint identifies the version of the Software Development Kit used to build the target.\u003c/br\u003e\nAn SDK may bundle:\n\n- compilers and linkers\n- sysroots\n- headers and libraries\n- platform configuration files\n- auxiliary build tools\n\nThe SDK version often defines a coherent and validated build environment.\u003c/br\u003e\nThe sdk_version constraint is used to:\n\n- ensure build reproducibility\n- select consistent toolchain bundles\n- align development and CI environments\n- control transitions between SDK releases\n\n#### `sdp_version` constraint\n\nThe `sdp_version` constraint identifies the version of the Software Distribution Platform (SDP) targeted by the build.\u003c/br\u003e\nAn SDP typically represents a higher-level integration layer that may include:\n\n- prebuilt components\n- distribution packaging rules\n- runtime layout definitions\n- platform integration policies\n\nUnlike SDK, which is primarily a build-time concern, SDP may affect both build-time integration and runtime deployment structure.\u003c/br\u003e\nThe sdp_version constraint is used to:\n\n- ensure compatibility with distribution packaging rules\n- align with deployment/runtime expectations\n- control integration against specific platform releases\n\n### Runtime Ecosystem\n\nThe runtime_ecosystem constraint identifies the system-level runtime environment a binary or target is built to run in.\u003c/br\u003e\nIt captures non-OS, non-CPU assumptions about the execution environment, such as:\n- available system services and middleware\n- process lifecycle and supervision\n- IPC and communication models\n- deployment and startup conventions\n\nThis constraint distinguishes mutually exclusive runtime ecosystems (for example AutoSD, Android Automotive, or pure POSIX) that may run on the same operating system and CPU architecture but expose different runtime contracts.\u003c/br\u003e\nThe runtime_ecosystem constraint is used for:\n- platform compatibility checks\n- conditional dependencies via select()\n- expressing runtime-specific behavior without overloading OS or CPU constraints\n\nCurrently, our platform support following `runtime_es`:\n- `autosd`: is an automotive runtime platform and software ecosystem that defines a standardized execution environment for in-vehicle applications. From a build and platform perspective, AutoSD represents a distinct runtime ecosystem that is orthogonal to OS and CPU architecture and must be modeled explicitly to ensure correct compatibility and dependency selection.\n- `posix` : denotes a generic execution environment where applications rely only on standardized POSIX APIs and behavior, without assumptions about higher-level middleware, platform-specific services, or vendor-defined runtime frameworks.\n- `ebclfsa`: EB corbos Linux for Safety Applications is a hypervisor-based safety extension to Linux. It can be used for automotive safety-relevant workloads (up to ASIL B / SIL 2 level under ISO 26262 and IEC 61508 standards).\n\n## Change process\n\n### Adding a New constraint_setting\n\n1. Create a new constraint_setting target in an appropriate package or directory.\n2. Document its purpose clearly in the `BUILD` file.\n3. Open a pull request with:\n   - The new `constraint_setting`\n   - A brief explanation of why it's needed and how it should be used\n\n### Adding a New constraint_value\n\n1. Define a new constraint_value under the relevant constraint_setting.\n2. Ensure it’s logically named and documented.\n3. Submit a pull request with the change and a short description.\n\nOnce reviewed and approved, the new constraint will be available for use across all dependent modules.\n\n### Adding a New platform\n\nThis repository defines canonical Bazel platforms that combine existing constraint values into a single, reusable target. Platforms must follow a strict naming convention to ensure consistency, discoverability, and predictable toolchain selection across all S-CORE modules.\n\n#### Platform Naming Convention\n\nEach platform must be named according to the following format:\n```bash\n{target_cpu}-{target_os}-{gcc_version|sdp_version|or other version}-{runtime_es}\n```\nWhere:\n| Component           | Description                                  | Source                        |\n|---------------------|----------------------------------------------|-------------------------------|\n| `target_cpu`        | CPU instruction set architecture             | `@platforms//cpu`             |\n| `target_os`         | Operating system family                      | `@platforms//os`              |\n| `platform_variant`  | GCC version or SDK/SDP version or OS version | `gcc_version` or `os_version` |\n| `runtime_es`        | Runtime ecosystem                            | `runtime_es`                  |\n\nNote that 3rd and 4th segment are optional to set (however we advise people to use it).\n\nExamples:\n| Platform name                  | Meaning           |\n|--------------------------------|-----------------------------------------------------------------------------------|\n| x86_64-linux-gcc_12.2.0-posix  | x86_64 Linux built with GCC 12.2.0, POSIX runtime - generic execution environment |\n| aarch64-linux-autosd10         | Arm 64 Linux built, AutoSD 10 runtime - Automotive Stream Distribution            |\n| x86_64-linux-sdk_0.1.0-ebclfsa | x86_64 Linux built, EBcLfSA runtime - EB corbos Linux for Safety Applications     |\n\n\n#### Naming Rules (Mandatory)\n\n1. **OS and CPU are mandatory, platform_variant and runtime_es are optional **.\u003c/br\u003e\nNo component may be omitted or merged with another.\n\n2. **Lowercase only**.\u003c/br\u003e\nPlatform names must be lowercase and kebab-cased.\n\n3. **Exactly one version dimension**.\u003c/br\u003e\nUse:\n    - gcc_version for generic Linux / POSIX builds\n    - os_version or SDK/SDP version for vendor OS platforms (e.g. QNX)\n\n4. **Runtime ecosystem is always explicit**.\u003c/br\u003e\nEven for “generic” environments, posix must be stated explicitly.\n\n5. **No ambiguity**.\u003c/br\u003e\nThe platform name alone must uniquely describe the execution and toolchain environment without additional context.\n\n#### Design Rationale\n\nThis strict platform naming scheme ensures:\n- Deterministic toolchain selection\n- Clear ABI and runtime expectations\n- Predictable select() behavior\n- Long-term maintainability as platforms scale\n\nAny deviation from this convention must be explicitly justified and approved during review.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Feclipse-score%2Fbazel_platforms","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Feclipse-score%2Fbazel_platforms","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Feclipse-score%2Fbazel_platforms/lists"}