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

Filter class should be compiled separately from pcl_ros_filters library #16

Closed
hershwg opened this issue May 28, 2013 · 2 comments · Fixed by #239
Closed

Filter class should be compiled separately from pcl_ros_filters library #16

hershwg opened this issue May 28, 2013 · 2 comments · Fixed by #239
Assignees
Labels
enhancement New features and improvements. help-wanted Contribution welcome!

Comments

@hershwg
Copy link
Member

hershwg commented May 28, 2013

Documentation about the pcl_ros::Filter class http://ros.org/doc/groovy/api/pcl_ros/html/classpcl__ros_1_1Filter.html makes it appear that it is a class which can be used by implementers of new pcl filter nodelets.

However as pointed out in #9 the CMakeLists.txt file includes the line "class_loader_hide_library_symbols(pcl_ros_filters)", and pcl_ros_filters is the only library containing the compiled contents of pcl_ros::Filter. Therefore pcl_ros::Filter is not actually usable by outside programmers. If it is really intended to be only an internal helper class for the pcl_ros_filters library, then it should be documented as such.

However it appears to be a more generally useful helper class, making it easy to write PCL filter nodelets without a bunch of boilerplate. To make this possible, a new library should be defined, say pcl_ros_filter or pcl_ros_filter_base which contains only pcl_ros::Filter. That library would naturally not have class_loader_hide_library_symbols() because it would not be defining a plugin. Then implementors of new filters would link against that library, as would the existing pcl_ros_filters library.

In the meantime the solution to my problem is to copy pcl_ros/filters/filter.cpp into my own code and do a bunch of renaming.

@tfoote
Copy link
Contributor

tfoote commented May 29, 2013

Yes, the cleaner solution would be to make it a separate object such that it is reuseable.

@paulbovbel paulbovbel self-assigned this Apr 11, 2014
@LucidOne
Copy link
Contributor

pull requests are welcome

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New features and improvements. help-wanted Contribution welcome!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants