-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Windows] dllexport support for ament_cmake #201
Comments
Those two referenced PRs are now in. I'm generally in favor of this, I think it makes more sense than our current approach of placing |
This has been discussed before: #164 In summary, I prefer the boilerplate header we use (e.g. https://github.com/ros2/rclcpp/blob/231b991098d685ff019c44edb80a8ff170d65e4a/rclcpp/include/rclcpp/visibility_control.hpp#L25-L54) to the boilerplate generated code that cmake has to generate every time you build. Neither change, but the static one is nicer in my opinion because you don't waste time generating it each time and because it lets static code analysis (or like autocomplete for text editors) work without having to first build the package and have the build/install space for that package on the path for your tool. Also, if you were to port a package to a different build system (e.g. bazel or something) then you don't have to also port the behavior of |
It's fine, but as I said above I prefer just committing a single header per library.
I don't see what this has to do with |
Just to clarify, the existing boilerplate header and the functionality provided by the A non-generated header roughly equivalent to #if defined _WIN32 || defined __CYGWIN__
#ifdef __GNUC__
#define RCLCPP_EXPORT __attribute__ ((dllexport))
#define RCLCPP_IMPORT __attribute__ ((dllimport))
#else
#define RCLCPP_EXPORT __declspec(dllexport)
#define RCLCPP_IMPORT __declspec(dllimport)
#endif
#ifndef RCLCPP_STATIC_LIBRARY
#ifdef RCLCPP_BUILDING_LIBRARY_SHARED
#define RCLCPP_PUBLIC RCLCPP_EXPORT
#else
#define RCLCPP_PUBLIC RCLCPP_IMPORT
#endif
#else
#define RCLCPP_PUBLIC
#endif
#define RCLCPP_PUBLIC_TYPE RCLCPP_PUBLIC
#define RCLCPP_LOCAL
#else
#define RCLCPP_EXPORT __attribute__ ((visibility("default")))
#define RCLCPP_IMPORT
#if __GNUC__ >= 4
#define RCLCPP_PUBLIC __attribute__ ((visibility("default")))
#define RCLCPP_LOCAL __attribute__ ((visibility("hidden")))
#else
#define RCLCPP_PUBLIC
#define RCLCPP_LOCAL
#endif
#define RCLCPP_PUBLIC_TYPE
#endif And the following CMake code will be necessary for the library, to correctly pass the compilation flags: set_target_properties(${PROJECT_NAME} PROPERTIES DEFINE_SYMBOL RCLCPP_BUILDING_LIBRARY_SHARED)
if(BUILD_SHARED_LIBS)
target_compile_definitions(${PROJECT_NAME}
PUBLIC RCLCPP_STATIC_LIBRARY)
endif() As the definition of the |
Another example of well defined visibility macro header is the one reported in https://gcc.gnu.org/wiki/Visibility, but in the "Step-by-step guide" section instead of the "How to use the new C++ visibility support" section that is the one that is manually copied in almost all ROS2 packages and described in https://index.ros.org/doc/ros2/Tutorials/Ament-CMake-Documentation/#building-libraries-on-windows . |
We could update our visibility headers to support the static library case. However, we need to probably touch each one anyways to properly support that, and so it's not much of a burden. At the very least we'd have to manage the use of the compiler definitions that indicate static library on windows, and also though we've built some/most of the stack static for Android in the past, I'm not sure what the current state of it is. It's not an officially supported use case or at least not one that we test regularly. |
On Windows, Microsoft C/C++ compiler comes with a concept of
dllexport
anddllimport
. In order to make a DLL library header able to be consumed by the downstream project, the function, class, or data declaration needs to be decorated with the correct attributes.CMake
providesCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS
and attempts to fix the problem less intrusive to the existing code base. However, it still comes with limitation, for example, it doesn't supportstatic
member, and it will bloat the size of the generated imported library because it exhaustively exposes whatever it can do.In ROS1, I explored a way to enable
dllexport
anddllimport
for a catkin-based project. Here is the pull request forrviz
to show the example. This change makes use ofgenerate_export_header
and with some careful steps to stage and install it to a place to be consumed within and across catkin packages.I would like to use this ticket to discuss:
generate_export_header
approach?ament_cmake
requirements or should it be just step-by-step guidance in theament_cmake User Documentation
.The text was updated successfully, but these errors were encountered: