-
Notifications
You must be signed in to change notification settings - Fork 22
Description
Hi @brakmic-aleksandar. In our local integration of rosidl_typesupport_protobuf we found something that can be (possibly) improved but I want to discuss it with you.
-
In this line,
rosidl_adapt_proto_interfaces.cmakewas included too early. By having it here, this line will be called insidefind_packagewhere there's no IDL files yet androsidl_write_generator_argumentswill fail. This only happens when we are usingrosidl_adapter_protobufinrosidl_generator_cpp. Though I don't understand why it works for msg packages, logically a extension file should only be called when the cmake reaches the extension point.- Update: Regarding this problem, I kinda understand why it's included here. In the extension point of
rosidl_typesupport_protobuf_candrosidl_typesupport_protobuf_cpp,rosidl_adapter_protoisfind_packaged, the adapter package wasfoundand maybe that's where you want to generate the.protoand.pb.h/cppfiles? I'll see how to suppress the error inrosidl_generator_cpp. - But maybe another way, instead of
find_packageingrodidl_adapter_proto, could be that we execute the extension point it registers earlier? Any thoughts?
- Update: Regarding this problem, I kinda understand why it's included here. In the extension point of
-
Relative path should be used here when registering extention
-
A follow up on item 1. If that
includewas removed, the following CMake code on this line can not findrosidl_adapter_proto_VISIBILITY_CONTROL_HEADER, and leaves an empty-includein the gcc call.
I understand that there's no easy way to inject the visibility header in the protobuf header so you have to use-includehere. Here's my two thoughts:- Can we move the lines of adding global
-includeinto the extension file instead of leaving them in the-extra.cmakefile? - Or, instead of using
-include, can we modify the generated.pb.hppfile to include the visibility usingsed.
- Can we move the lines of adding global