Add middleware bazel targets by lcastela · Pull Request #558 · eclipse-openbsw/openbsw

lcastela · 2026-08-18T09:59:16Z

Summary

Add Bazel build support for the OpenBSW middleware stack, including middleware libraries, unit tests, simulation, and reference-app middleware configuration.

What Changed

Added explicit Bazel targets for middleware core, memory, queue, and interface libraries.
Added Bazel targets for middleware unit tests and their mock implementations.
Consolidated middleware unit tests on the shared executables/unitTest/etl_profile.
Extended the unit-test ETL profile with middleware test settings:
- ETL_USE_TYPE_TRAITS_BUILTINS
- ETL_CHECK_PUSH_POP
- ETL_LOG_ERRORS
- ETL_VERBOSE_ERRORS
- ETL_DEBUG
Relocated middleware test sources and mocks to match the project layout.
Updated Bazel support for middleware simulation.
Updated Bazel support for reference-app middleware configuration.
Replaced system include paths with strip_include_prefix for middleware-owned targets to preserve compiler warning analysis.

depends-on: #559

DominikAFischer · 2026-08-19T10:09:01Z

Hi @lcastela and thank you for the contribution. Please note that there's a systematic effort underway to migrate OpenBSW to Bazel. Please make sure to include @christophruethingbmw and myself for review so that we can make sure to keep parallel work in check :)

From a first glance this looks great!
One thing that I would suggest is to split the PR up into smaller logical chunks if possible. this would make the review a lot easier. Ideas for chunks:

Python toolchain and infrastructure
Codegen Bazel implementation
Middleware changes (and ReferenceApp integration?)

lcastela · 2026-08-19T10:31:14Z

Hi @DominikAFischer. I've noticed your pull requests with the bazel changes and was already planning to ask for your and @christophruethingbmw review once the changes are finalized. Still need to addressed some issues before that.

lcastela · 2026-08-19T16:41:01Z

@DominikAFischer , @christophruethingbmw , ready! you can now have a look.

DominikAFischer · 2026-08-20T08:16:08Z

I will have a look later today. @christophruethingbmw is on leave and will only be back 2nd of September it seems.

DominikAFischer

Looks good in general, but I've added some remarks for discussion

DominikAFischer · 2026-08-20T09:13:09Z

            else:
                style_arg = "--style=file"  # fallback to default search

        cmd = ["clang-format", "-i", style_arg] + [str(f) for f in cpp_files]


This will try to use the clang-format host instance. In the docker container currently clang-format-17 is available but no unversioned clang-format symlink is set up. An easy fix would be to setup a symlink in the dockerfile.
This probably means in its current state, formatting is skipped with a warning in all cases anyhow.

Fixed. jinja2cpp.py now takes an explicit --clang-format-binary flag instead of resolving clang-format from $PATH.

DominikAFischer · 2026-08-20T09:36:39Z

 bazel_dep(name = "bazel_skylib", version = "1.9.0")
+bazel_dep(name = "rules_python", version = "0.40.0")
+
+python = use_extension("@rules_python//python/extensions:python.bzl", "python")


This will pull a standalone python instance as an online build-time dependency.
I was given to understand that online dependencies should be avoided.

@christian-schilling would this be acceptable here? Essentially, we're already doing the same thing inside the dockerfile during image building.

If not, we could try to reuse the container python instance via local_runtime_repo, although I'm not sure if we would still need to download the pip packages via Bazel then or if we could reuse them too from the host.

The other solution would be to sidestep rules_python entirely and use the docker pyhon instance and packages via a plain ctx.actions.run. (nonhermetic, will break in strict sandbox / with remote execution)

See comment below.
We should first setup our CI to build in containers with --network=none as a baseline and then figure out how to setup our build within that contraint.

No longer applicable, changes from latest main didn't need this.

DominikAFischer · 2026-08-20T09:38:29Z

+# *******************************************************************************
+
+pip = use_extension("@rules_python//python/extensions:pip.bzl", "pip")
+pip.parse(


Downloads wheels at fetch time as an online dependency.
@christian-schilling is this acceptable?

https://thehackernews.com/2026/08/rust-supply-chain-attack-puts-build.html

What else needs to happen to get the point across that absolutely no network access during a build is acceptable?

No longer applicable, changes from latest main didn't need this.

DominikAFischer · 2026-08-20T09:59:31Z

Not actually introduced by this PR but still relevant:
Should these python lockfiles not also be pinned with hashes? (via pip-compile --generate-hashes)
@christian-schilling FYI

Yes they should.

No longer applicable, changes from latest main didn't need this.

DominikAFischer · 2026-08-20T14:14:18Z

This list needs to be hand maintained and could drift silently from the deployment.yaml.
We can prevent the drift by using his sort of staleness check:

Add a write_file rule that can be used to generate a generated_outputs_expected.txt from generated_outputs.bzl

Add a --list-output-files mode on jinja2cpp.py that can be used to create a generated_outputs_actual.txt

Add a diff_test target that will compare the files and prevent merging inconsistent state (bazel test //... is run in CI)

already addressed in the latest main, just add to adapt the pr

DominikAFischer · 2026-08-20T14:16:59Z

This list needs to be hand maintained and could drift silently from the deployment.yaml.
We can prevent the drift by using his sort of staleness check:

Add a write_file rule that can be used to generate a generated_outputs_expected.txt from generated_outputs.bzl

Add a --list-output-files mode on jinja2cpp.py that can be used to create a generated_outputs_actual.txt

Add a diff_test target that will compare the files and prevent merging inconsistent state (bazel test //... is run in CI)

already addressed in the latest main, just add to adapt the pr

DominikAFischer · 2026-08-20T14:30:19Z

Every migrated libs/bsw module up until has only a single BUILD file in the module root and no subpackages / nested BUILD files (assumption: module = "atomic" package unit).
I'm sure there's valid exceptions from this convention, but I would argue that there should not be any subpackages defined in any of the standard module folders:

I would argue, that there should not be any subpackages / BUILD files created inside any of the "standard" module subfolders:

include

doc

test

src

mock

That said, I understand that middleware is a bigger sized module and BUILD file bloat can be a problem.
Since the tools subfolder is logically separate from the module, I think it makes sense to keep it as a separated package.

DominikAFischer · 2026-08-20T14:40:34Z

This BUILD file should be moved to the tools root package (one level up) instead in my opinion.

kept it aligned with latest main

lcastela · 2026-09-02T14:26:24Z

I didn't forget about this, but I had to switch to more prio topics. will follow-up with this soon

lcastela · 2026-09-14T12:51:43Z

@christophruethingbmw , @DominikAFischer , can you have another look?

Define configurable middleware interfaces, unit-test implementations, and simulation targets. Align middleware CMake sources and platform integrations with the Bazel package layout.

Add Bazel targets and generated middleware configuration for the reference application. Align the CMake package with the relocated platform integration sources and expose the application logging headers.

The simulation and referenceApp middlewareConfiguration BUILD.bazel files still targeted the old codegen.bzl rule that main dropped in favor of the middleware_codegen macro, and carried a generated_headers / generated_sources output_group indirection that macro never produces. Wire both packages to depend directly on the cc_library the macro already returns. Strip the stale generated_files/ path prefix from simulation/generated_outputs.bzl, a leftover from the old rule's generated_files_prefix parameter; jinja2cpp.py writes outputs relative to --output without that prefix, so the genrule silently failed to produce the declared outputs. Fix middlewareConfiguration/BUILD.bazel: logger_impl depended on a nonexistent :headers target instead of :demo_logger, which is what LoggerImpl.cpp actually includes (app/DemoLogger.h). Restore the middleware_config target name and public visibility so the existing alias in application/BUILD.bazel keeps resolving. Remove ETL_USE_TYPE_TRAITS_BUILTINS from the simulation etl_profile.h. It routes ETL's is_destructible to the raw __is_destructible GCC builtin, which this toolchain does not support and fails to compile with -fpermissive errors.

Replace the per-executable_config select with plain no-op stub implementations (concurrency/logger/os/time) that live in interfaces/src/noop and depend on nothing but the interface headers themselves and etl. Real consumers already override these through middleware_config: referenceApp supplies its own platform_integration impls, and the test targets supply the gmock-based mocks explicitly. The default now only matters for a bare, unwrapped dependency, and a no-op is the correct, layering-safe answer for that case (no dependency on libs/bsw/middleware/test, no dependency on executables/referenceApp).

middleware_codegen() doesn't accept a target_compatible_with argument (it's a plain macro with a fixed cc_library/rule signature, unlike a native rule which forwards common attributes automatically). Drop it from the middleware_configuration_generated call in executables/referenceApp/middlewareConfiguration/BUILD.bazel; the downstream middleware_impl cc_library already carries target_compatible_with = reference_app_posix_only(), matching how main's original middleware_configuration library did it before the Bazel migration split it into per-platform cc_library targets. Also drop two now-unused build_variant compatibility.bzl loads (unit_test_only, reference_app_posix_only) flagged by bazel run //:format_check.

lcastela force-pushed the communication/AddMiddlewareBazelTargets branch 2 times, most recently from b3e9cea to 046372c Compare August 18, 2026 15:43

lcastela mentioned this pull request Aug 19, 2026

ReferenceApp middleware deps abstraction #559

Merged

lcastela force-pushed the communication/AddMiddlewareBazelTargets branch from 8a6b84a to 3a336e1 Compare August 19, 2026 16:40

rolandreichweinbmw previously approved these changes Aug 20, 2026

View reviewed changes

DominikAFischer suggested changes Aug 20, 2026

View reviewed changes

lcastela dismissed rolandreichweinbmw’s stale review via b285486 September 11, 2026 14:59

lcastela force-pushed the communication/AddMiddlewareBazelTargets branch from 3a336e1 to b285486 Compare September 11, 2026 14:59

lcastela requested a review from DominikAFischer September 11, 2026 15:11

lcastela force-pushed the communication/AddMiddlewareBazelTargets branch from b285486 to cfee200 Compare September 14, 2026 11:03

lcastela force-pushed the communication/AddMiddlewareBazelTargets branch 2 times, most recently from f101aaf to 9591755 Compare September 18, 2026 13:09

lcastela added 6 commits September 22, 2026 14:12

Add Bazel targets for middleware components

582f666

Define configurable middleware interfaces, unit-test implementations, and simulation targets. Align middleware CMake sources and platform integrations with the Bazel package layout.

Add reference app middleware integration

ded254d

Add Bazel targets and generated middleware configuration for the reference application. Align the CMake package with the relocated platform integration sources and expose the application logging headers.

Fix middleware doc examples CMakeLists.txt paths after main rebase

0ce1e46

lcastela force-pushed the communication/AddMiddlewareBazelTargets branch from 0048715 to 5d2d401 Compare September 22, 2026 13:30

Conversation

lcastela commented Aug 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

What Changed

Uh oh!

DominikAFischer commented Aug 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lcastela commented Aug 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lcastela commented Aug 19, 2026

Uh oh!

DominikAFischer commented Aug 20, 2026

Uh oh!

DominikAFischer left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lcastela Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

lcastela commented Sep 2, 2026

Uh oh!

lcastela commented Sep 14, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

lcastela commented Aug 18, 2026 •

edited

Loading

DominikAFischer commented Aug 19, 2026 •

edited

Loading

lcastela commented Aug 19, 2026 •

edited

Loading

lcastela Sep 11, 2026 •

edited

Loading