Skip to content

Conversation

@Karsten1987
Copy link
Contributor

@Karsten1987 Karsten1987 commented Apr 11, 2017

I remove the rmw_string_array_t in lieu of the implementation in c_utilities.
Connected PRs:

c_utilities: ros2/rcutils#14
rmw_fastrtps: ros2/rmw_fastrtps#102
rmw_connext: ros2/rmw_connext#224
rmw_impl: ros2/rmw_implementation#20
rcl: ros2/rcl#118
rclcpp: ros2/rclcpp#320
rclpy: ros2/rclpy#75

@Karsten1987 Karsten1987 force-pushed the utilities_string_array branch from f1a79b3 to ba4b4fc Compare April 11, 2017 23:41
const rmw_node_t * node,
rmw_string_array_t * node_names);

RMW_PUBLIC
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are you removing this function instead of just changing the type?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the destroy function is part of the c_utilities package, here:

https://github.com/ros2/c_utilities/blob/master/include/c_utilities/types/string_array.h#L77

@mikaelarguedas mikaelarguedas changed the title use c_utilities package use string_array_t from c_utilities package Apr 12, 2017
"c_utilities")
configure_rmw_library(${PROJECT_NAME} LANGUAGE "C")

ament_export_dependencies(c_utilities)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line could be merged with the next.

@IanTheEngineer
Copy link

Outsider's view here, so feel free to take it with a grain of salt, as I likely don't see the larger picture.

It seems that this PR adds an additional dependency to every rcl* library in order to prevent code duplication. Is that the tradeoff being made? It would seem beneficial to enable the rcl* libraries to have as few external dependencies as possible.

@dirk-thomas
Copy link
Member

Is that the tradeoff being made?

Yes, pretty much.

@IanTheEngineer
Copy link

Gotcha - I missed the corresponding issue #94

@Karsten1987
Copy link
Contributor Author

I had the first initial thought, given that I touched basically the complete stack of packages, however given that it's "simply" only utility functions, which itselves don't have any dependencies and stay a clean c-package, I think it's a reasonable trade-off.

@Karsten1987
Copy link
Contributor Author

Karsten1987 commented Apr 13, 2017

Linux: Build Status
Windows: Build Status
OSX: Build Status

@Karsten1987 Karsten1987 added in review Waiting for review (Kanban column) and removed in progress Actively being worked on (Kanban column) labels Apr 13, 2017
@Karsten1987
Copy link
Contributor Author

I think that's up for review!

This is makes a nicer diff in the future if the list is appended.
@Karsten1987
Copy link
Contributor Author

Karsten1987 commented Apr 14, 2017

linux: Build Status
osx: Build Status unrelated, FAST-RTPS
windows: Build Status

@Karsten1987
Copy link
Contributor Author

CI's passing. I am going to merge this (and related PR) soonish if nobody has anything comments anymore.

@Karsten1987
Copy link
Contributor Author

given the changes in c_utilities, here is a new batch:

Linux: Build Status
OSX: Fails with network issues when downloading poco
windows: Build Status

@Karsten1987 Karsten1987 merged commit e240713 into master Apr 14, 2017
@Karsten1987 Karsten1987 deleted the utilities_string_array branch April 14, 2017 23:19
@Karsten1987 Karsten1987 removed the in review Waiting for review (Kanban column) label Apr 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants