Add support for message definitions in omg idl syntax by woutervdstoel · Pull Request #617 · mvukov/rules_ros2

woutervdstoel · 2026-03-25T08:30:08Z

This PR adds support for directly including .idl files as message definitions rather than having them be generated by rosidl. It also supports mixing and matching of idl and msg definitions.

In our repo I also verified this works with rosbag recording and replay.

mvukov

Last time I looked at this, there were constraints:

1 msg in .idl file -> ROS msg
2 msg in .idl file -> ROS srv
3 msg in .idl file -> ROS action
and that logic is/was pretty much hard-coded in the parser (IIRC).

There should be decent disclaimer about this. Instead of silently failing, what can be done to ensure proper error handline? -- not for this PR but I am curious.

Also, what's the motivation to use .idl directly?

mvukov · 2026-03-28T09:36:18Z

+                outputs.append(src_file)
+                idl_manifest_contents.append(paths.join("msg", src.basename))
+
+            elif src.extension == "idl":


Please document why is this necessary.

Updated the PR with simplified logic and some explanation about generated_idl_files.

mvukov · 2026-03-28T09:40:00Z

    return struct(
        package_name = target.label.name,
        srcs = target[Ros2InterfaceInfo].info.srcs,
+        generated_idl_files = target[IdlAdapterAspectInfo].generated_idl_files if IdlAdapterAspectInfo in target else None,


Why are changes needed in this file?

I explained in a comment in ament.bzl why we also need the generated_idl_files . I'm open to implementation suggestions that don't involve changing this struct because I agree this is a bit of a detour.

woutervdstoel · 2026-03-31T11:11:29Z

There should be decent disclaimer about this. Instead of silently failing, what can be done to ensure proper error handline? -- not for this PR but I am curious.

I don't think we can handle this at analysis time since it requires looking at the content of the files. We could of course generate tests to assert it. I think that since it's a feature for advanced users anyway, maybe it doesn't need the greatest error handling?

Also, what's the motivation to use .idl directly?

In our setup: we want to annotate certain message fields with some custom annotations that another tool looks as (which reuses the existing rosidl parser). The IDL format is much more flexible in this regard than the msg format.

I also happen to know that Apex.AI recommends their customers directly write IDL because of the extended feature set.

woutervdstoel · 2026-04-02T14:19:27Z

    implementation = _ros2_interface_collector_aspect_impl,
    attr_aspects = _ROS2_COLLECTOR_ATTR_ASPECTS,
    provides = [Ros2InterfaceCollectorAspectInfo],
+    required_aspect_providers = [IdlAdapterAspectInfo],


This is necessary for the logic above to correctly be able to access the IdlAdapterAspectInfo

mvukov · 2026-04-02T19:17:51Z

I don't think we can handle this at analysis time since it requires looking at the content of the files. We could of course generate tests to assert it. I think that since it's a feature for advanced users anyway, maybe it doesn't need the greatest error handling?

For starters, I think it would be enough to clearly document this e.g. in ros2_interface_library rule docs. In a follow-up a proper build time testing can be introduced.

mvukov · 2026-05-17T21:14:43Z

@woutervdstoel Any plans to wrap up this work?

woutervdstoel · 2026-05-18T12:28:29Z

@mvukov I just pushed the documentation change you requested - please let me know if there's anything else that still needs improvement

mvukov

Left a few smaller comments. Please address them and then we can merge this PR. I'll proceed with finishing up Jazzy (@lalten FYI) afterward.

mvukov

On second thought, I have more questions.

Please let me know if you have time to work on this in the coming days -- let's see whether makes sense to iron out this PR or I can proceed with #558 .

BTW, I pushed a small fix to your branch recently today.

mvukov · 2026-06-08T17:24:19Z

+
+        new_file = ctx.actions.declare_file("{}/{}/{}.idl".format(package_name, idl_submodule_name, stem))
+        idl_files.append(new_file)
+        ctx.actions.run_shell(


Would a symlink suffice here?

mvukov · 2026-06-08T17:35:00Z

 def _get_stem(path):
    return path.basename[:-len(path.extension) - 1]

+def _get_idl_submodule_name(path):


On second thought... submodule is misleading and not readable. I'd rename submodule -> type because this essentially determines a type (action, msg, srv).

mvukov · 2026-06-08T17:35:22Z

+    For .msg/.srv and other files, return the extension
+    """
+    if path.extension == "idl":
+        return path.dirname.split("/")[-1]


If anything other than action/msg/srv this should error.

mvukov · 2026-06-08T17:38:08Z

-    return idl_files, idl_tuples
+    return idl_files, generated_idl_files, idl_tuples

 IdlAdapterAspectInfo = provider("TBD", fields = [


TBH, I don't see a need to touch this. But I'd like to learn more.

mvukov · 2026-06-08T17:39:18Z

    output_dir = adapter_map.dirname

    idl_files = []
+    generated_idl_files = []


On second thought: why don't you dump everything in idl_files?

IIUC, generated_idl_files is needed such that we put idl files to the ament index. We can dump all idl_files to the index IMO.

mvukov · 2026-06-08T17:40:59Z

+        # Generated IDL files in the output tree such that the rosbag mcap writer can include them in the metadata.
+        # mcap supports both IDL and msg definitions, but not combinations. Therefore, if any handwritten IDL files are
+        # present, the rosbag writer also needs any generated IDL files it depends on.
+        if idl.generated_idl_files != None:


IIUC, here you dump generated IDL files but not user-provided IDL files, right? How then e.g. rosbag knows how to handle user-provided IDL files?

mvukov

Until we sort out some details I pointed out earlier, I'll just make this PR as a not yet ready to be merged.

woutervdstoel force-pushed the direct-idl-support branch from 6983f20 to 36bd9c2 Compare March 25, 2026 08:32

lalten mentioned this pull request Mar 25, 2026

Feature/jazzy #558

Open

mvukov reviewed Mar 28, 2026

View reviewed changes

woutervdstoel commented Mar 31, 2026

View reviewed changes

Comment thread ros2/plugin_aspects.bzl Outdated

woutervdstoel force-pushed the direct-idl-support branch from b609bea to 893c59d Compare March 31, 2026 11:07

mvukov reviewed Apr 2, 2026

View reviewed changes

Comment thread ros2/interfaces.bzl Outdated

Comment thread ros2/interfaces.bzl Outdated

Comment thread ros2/interfaces.bzl Outdated

Comment thread ros2/interfaces.bzl

woutervdstoel commented Apr 2, 2026

View reviewed changes

Comment thread ros2/plugin_aspects.bzl Outdated

woutervdstoel commented Apr 2, 2026

View reviewed changes

mvukov reviewed May 25, 2026

View reviewed changes

Comment thread ros2/interfaces.bzl Outdated

Comment thread ros2/test/interfaces/py_messages_tests.py Outdated

Comment thread ros2/test/interfaces/cpp_messages_tests.cc

Comment thread ros2/test/interfaces/py_messages_tests.py

Comment thread ros2/interfaces.bzl

lalten mentioned this pull request May 26, 2026

Document & Enforce file name conventions #636

Closed

Add support for message definitions in omg idl syntax

2997cde

woutervdstoel force-pushed the direct-idl-support branch from 82929f6 to 2997cde Compare June 3, 2026 08:47

Move tests

4737dbe

woutervdstoel force-pushed the direct-idl-support branch from 2c144ed to 4737dbe Compare June 3, 2026 08:49

woutervdstoel and others added 2 commits June 3, 2026 10:50

end sentence with period

abf7178

Fix tests

2b17fc2

mvukov reviewed Jun 8, 2026

View reviewed changes

mvukov requested changes Jun 8, 2026

View reviewed changes

Conversation

woutervdstoel commented Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mvukov left a comment

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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

woutervdstoel commented Mar 31, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mvukov commented Apr 2, 2026

Uh oh!

mvukov commented May 17, 2026

Uh oh!

woutervdstoel commented May 18, 2026

Uh oh!

mvukov left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mvukov left a comment

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!

mvukov Jun 8, 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!

mvukov left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

woutervdstoel commented Mar 25, 2026 •

edited

Loading

mvukov Jun 8, 2026 •

edited

Loading