Skip to content
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

add load_library: Return actual library object, rather than file path as find_library #8

Open
EricCousineau-TRI opened this issue Apr 2, 2019 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@EricCousineau-TRI
Copy link

find_library shouldn't really return a path, but instead a loaded library.

This would permit things like ros2/rcutils#143 to not have to worry about paths, and could possibly reduce any possibility of ODR by returning currently loaded libraries rather than loading a new one.

@dirk-thomas
Copy link
Member

find_library shouldn't really return a path, but instead a loaded library.

The current behavior of only finding the library makes sense for the existing function. That being said introducing another function like load_library would be an option.

@EricCousineau-TRI
Copy link
Author

Aye, I didn't mean necessarily that find_library would keep it's name, so yeah, load_library would be good.

But I also wanted to imply that, at some point, it would be nice to fully encapsulate the path of a library and the only suggested workflow for handling libraries in ROS2 would be solely through load_library; then that could admit using already-loaded libraries. Then find_library would become deprecated (or at least discouraged...).

@dirk-thomas dirk-thomas changed the title find_library: Return actual library object, rather than file path add load_library: Return actual library object, rather than file path as find_library Sep 26, 2019
@hidmic hidmic self-assigned this Dec 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants