Bugs

I collected several bugs I now combine in this ticket.
Here a short overview of the bugs I encountered:

• (1) Missing dependency in rules_ocs
• (2) Incorrect DaVinci Developer resolution in rules_ocs
• (3) Incorrect rule output location in rules_ocs
• (4) Modification of sources during rule execution in rules_ocs
• (5) Incorrect gradle usage under windows in rules_dvteam
• (6) Missing visibility declaration of generated modules in rules_cfg5

We worked around the issues creating some patches. Those do not solve the issues in general but show patches that work for us.
rules_dvteam.patch
rules_ocs.patch
rules_cfg5.patch

Maybe they help to understand the issues or for others to use them to temporarily fix their issues.

I'll describe each bug in more detail in the following:

(1) Missing dependency in rules_ocs

rules_vtt is set as dependency in rules_ocs, but rules_vtt is not provided in vector bazel registry.

Bazel generates the following error:

ERROR: Error computing the main repository mapping: in module dependency chain <root> -> rules_dvteam@0.0.1 -> rules_vtt@0.0.1: module rules_vtt@0.0.1 not found in registries: ...

(2) Incorrect DaVinci Developer resolution in rules_ocs

Both davinci_developer_label and davinci_developer_path are not provided by rules_davinci_developer toolchain but rules_ocs expects them.

ERROR: XXX: in ocs_def rule XXX: 
Traceback (most recent call last):
        File "XXX/external/rules_ocs+/private/rules.bzl", line 151, column 53, in _ocs_impl
                additional_cmds += _format_createproject(ctx)
        File "XXX/external/rules_ocs+/private/rules.bzl", line 74, column 40, in _format_createproject
                developer_path = _resolve_developer(ctx)
        File "XXX/external/rules_ocs+/private/rules.bzl", line 49, column 38, in _resolve_developer
                if not info_davinci_developer.davinci_developer_label and not info_davinci_developer.davinci_developer_path:
Error: 'ToolchainInfo' value has no field or method 'davinci_developer_label'
Available attributes: davinci_developer_cmd_label, davincidev_path, dvimex_label, dvimex_path, dvswcgen_label, dvswcgen_path

Refer to attachment rules_ocs.patch.

(3) Incorrect rule output location in rules_ocs

OCS CreateProject builds the project directory as project_dir = "{}/{}".format(ctx.bin_dir.path, ctx.label.name).
This places the generated project on the root of the bin directory and we get dependency issues once we build upon that.

Please put the output in the package path (if it exists).

Refer to attachment rules_ocs.patch.

(4) Modification of sources during rule execution in rules_ocs

When executing the CreateProject plugin with the ocs rule the CreateProject.json is being modified in place in the source tree of the project.
Bazel recognized this and applies its guardrail stopping it from uploading this action to the remote cache it outputs:

WARNING: //...: Skipping uploading outputs because of concurrent modifications with --guard_against_concurrent_changes enabled: .../CreateProject.json was modified during execution

As this action is the first in the project generation sequence this hits especially hard.

Currently we need to deactivate this guardrail --noguard_against_concurrent_changes which, of course, is a bit risky.
I'd rather prefer the rule to copy the source as is into the bin directory and modifying it there ans using this as the input for the ocs execution.

(5) Incorrect gradle usage under windows in rules_dvteam

Rule dvteam extracts the gradle path from the gradle toolchain.
Command template _DVTEAM_TEMPLATE_WINDOWS interprets the retrieved gradle path as a relative path: start-process "./{gradle_path}"

This leads to the following bazel output:

ERROR: .../BUILD:28:31: Executing DVTeam @ .../build.gradle failed: (Exit 1): powershell.exe failed: error executing dvteamWindows command (from dvteam_def rule target //...) powershell.exe -NoProfile ... (remaining 1 argument skipped)
start-process : Dieser Befehl kann aufgrund des folgenden Fehlers nicht ausgef�hrt werden: Das System kann die 
angegebene Datei nicht finden.
In Zeile:7 Zeichen:171
+ ... lue $false; start-process "./C:/Gradle/gradle-8.14.5/bin/gradle.bat"  ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand
 
start-process : Dieser Befehl kann aufgrund des folgenden Fehlers nicht ausgef�hrt werden: Das System kann die 
angegebene Datei nicht finden.
In Zeile:7 Zeichen:791
+ ... utput.log"; start-process "./C:/Gradle/gradle-8.14.5/bin/gradle.bat"  ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

Our gradle toolchain points to a globally installed gradle on windows (absolute path) and therefore this relative path breaks.
The linux command template _DVTEAM_TEMPLATE_LINUX does not intrinsically assume a relative path - this seems correct.

Suggested change: Replace all occurences of ./{gradle_path} with {gradle_path}.

Refer to attachment rules_dvteam.patch.

(6) Missing visibility declaration of generated modules in rules_cfg5

We implement a symbolic macro as a wrapper around the cfg5 tooling rules and need to depend on the generated modules for compilation.
As the visibility of all generated target inside a symbolic macro are set automatically to private we have no chance depending on the generation result in our compile target.

ERROR: .../BUILD:226:13: in cc_library rule //...:Os: Visibility error:
target '//...:microsar_Os' is not visible from
target '//...:Os'
Recommendation: modify the visibility declaration if you think the dependency is legitimate. For more info see https://bazel.build/concepts/visibility

Please make the instantiations of extract_component_cc_info inherit the visibility passed into legacy macro cfg5_generate_rt.

Refer to attachment rules_cfg5.patch.

Description of the bug:

see above

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Each bug has its own reproduction - the following list shall be interpreted as Bug 1 is reproduced with list element 1 ect.

(1) Depend on rules_ocs in MODULE.bazel without having a local rules_vtt available.

(2) Instantiate and build ocs target.

(3) Build ocs target with CreateProject plugin active

(4) Build ocs target with CreateProject plugin active - observe modification of CreateProject.json in source tree.
Alternatively execute ocs with CreateProject plugin active an bazel option --guard_against_concurrent_changes set to at least lite to see Bazel not uploading to cache server.

(5) Build dvteam target on windows with global gradle toolchain and absolute gradle binary path.

(6) Encapsulate target cfg5_generate_rt in a symbolic macro and depend on the component based output for e.g. compilation

What are the involved Vector tools and their versions?

Which operating system are you running Bazel on?

Windows 10

What is the output of bazel mod graph --verbose --depth 1?

<root> (@_)
├───bazel_skylib@1.8.2 
├───platforms@1.0.0 
├───rules_bsw@0.0.1 
├───rules_cc@0.2.17 
├───rules_cfg5@0.0.5 
├───rules_common@0.2.0 
├───rules_davinci_developer@0.0.1 
├───rules_dotnet@0.22.1 
├───rules_dvteam@0.0.1 
├───rules_gradle@0.0.1 
└───rules_ocs@0.0.1 

What is the output of bazel info release?

release 9.2.0

Have you found anything relevant by searching the web?

-

Any other information, logs, or outputs that you want to share?

-