You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.cmake was included too early. By having it here, this line will be called inside find_package where there's no IDL files yet and rosidl_write_generator_arguments will fail. This only happens when we are using rosidl_adapter_protobuf in rosidl_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_c and rosidl_typesupport_protobuf_cpp, rosidl_adapter_proto is find_packaged, the adapter package was found and maybe that's where you want to generate the .proto and .pb.h/cpp files? I'll see how to suppress the error in rosidl_generator_cpp.
But maybe another way, instead of find_packageing rodidl_adapter_proto, could be that we execute the extension point it registers earlier? Any thoughts?
Relative path should be used here when registering extention
A follow up on item 1. If that include was removed, the following CMake code on this line can not find rosidl_adapter_proto_VISIBILITY_CONTROL_HEADER, and leaves an empty -include in 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 -include here. Here's my two thoughts:
Can we move the lines of adding global -include into the extension file instead of leaving them in the -extra.cmake file?
Or, instead of using -include, can we modify the generated .pb.hpp file to include the visibility using sed.
The text was updated successfully, but these errors were encountered:
Hi, thanks for your suggestions, i originally considered modifying generated protobuf .pb.hpp files, but i've decided against it, mainly because it seemed more cumbersome to implement, i agree that its good idea to move it to extension file.
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.cmake
was included too early. By having it here, this line will be called insidefind_package
where there's no IDL files yet androsidl_write_generator_arguments
will fail. This only happens when we are usingrosidl_adapter_protobuf
inrosidl_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.rosidl_typesupport_protobuf_c
androsidl_typesupport_protobuf_cpp
,rosidl_adapter_proto
isfind_packaged
, the adapter package wasfound
and maybe that's where you want to generate the.proto
and.pb.h/cpp
files? I'll see how to suppress the error inrosidl_generator_cpp
.find_package
ingrodidl_adapter_proto
, could be that we execute the extension point it registers earlier? Any thoughts?Relative path should be used here when registering extention
A follow up on item 1. If that
include
was removed, the following CMake code on this line can not findrosidl_adapter_proto_VISIBILITY_CONTROL_HEADER
, and leaves an empty-include
in 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
-include
here. Here's my two thoughts:-include
into the extension file instead of leaving them in the-extra.cmake
file?-include
, can we modify the generated.pb.hpp
file to include the visibility usingsed
.The text was updated successfully, but these errors were encountered: