-
Notifications
You must be signed in to change notification settings - Fork 49
Conversation
#endif | ||
#define MY_LIB_PUBLIC_TYPE | ||
#endif | ||
#endif // MY_LIB__VISIBILITY_CONTROL_HPP_ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may be missing something, but it seems that with this visibility control header, the code cannot be compiled/used as a static library?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lilustga can you comment on @traversaro's question? It would be good to capture this in the doc as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Related comment in an older PR: ros2/rclcpp#638 (comment) and ros/console_bridge#40 (comment) .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@traversaro, I generated a header using generate_export_header and saw how it uses LIB_NAME_STATIC_DEFINE
to not set the TOOLS_EXPORT
macro to either dllimport or dllexport. We could add the same logic to this boilerplate header, would that be sufficient to allow for building the same lib as both static and shared?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you have a non-generate export header, if you add a LIB_NAME_STATIC_DEFINE
to disable dllimport
and dllexport
decoration, you also need to specify that that the macro needs to be definde when the library is a static library, i.e. :
get_target_property(lib_name_TYPE lib_name TYPE)
if(lib_name_TYPE STREQUAL "STATIC_LIBRARY")
target_compile_definitions(lib_name PUBLIC LIB_NAME_STATIC_DEFINE)
endif()
Note that however this solution only works correctly in downstream projects that link the static version of the library if the downstream projects link the library using CMake and linking with the exported target. If they do not use CMake or they do not link with the exported target, they need to define LIB_NAME_STATIC_DEFINE
manually depending of whether they are linking the static version of lib_name or the shared one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the insight, I'll test this in a future workstream and incorporate it into the documentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could it make sense to link this new documentation in https://github.com/ms-iot/ROSOnWindows/blob/872aae72c3d806fab46f300dc9484e55cdbf744e/docs/Porting/Cookbook.md#error-lnk2019-unresolved-external-symbol ?
@lilustga Let's remove the section from the cookbook that @traversaro mentions above since we're elevating this to a top level link. |
New Page under the Porting Folder which describes how to add explicit symbol visibility to a ROS package.