In response to the the blocking issue #890, I've introduced a simple mechanism for filtering ros2 interfaces out of the message generation process. The mechanism reads and external blocklist.json file containing filters that are used by rosidl_gen/package.js to determine which ROS2 interface files to excluded during the message-generation process. The user is informed of the ROS interfaces that are omitted with a console.log message.
An ideal solution to #890 is to generate javascript message files from idl files. This will take some time during which we are blocked. This mechanism provides a quick work-around. And we can always disable this feature by removing the rosidl_gen/blocklist.json file in the future.
Also I switched the windows workflows to use node 18.12.0 in place of 18.13.0. There is a repeatable issue with node-gyp configuration on node 18.13. It seems to be related to the node cache. Switching to 18.12 avoids using a cached version of node 18 and the issue no longer occurs.
In response to the the blocking issue #890, I've introduced a simple mechanism for filtering ros2 interfaces out of the message generation process. The mechanism reads and external blocklist.json file containing filters that are used by
rosidl_gen/package.jsto determine which ROS2 interface files to excluded during the message-generation process. The user is informed of the ROS interfaces that are omitted with aconsole.logmessage.An ideal solution to #890 is to generate javascript message files from idl files. This will take some time during which we are blocked. This mechanism provides a quick work-around. And we can always disable this feature by removing the
rosidl_gen/blocklist.jsonfile in the future.Also I switched the windows workflows to use node 18.12.0 in place of 18.13.0. There is a repeatable issue with node-gyp configuration on node 18.13. It seems to be related to the node cache. Switching to 18.12 avoids using a cached version of node 18 and the issue no longer occurs.
Fix #890