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.

Sign up for GitHub

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

Layered diagrams #121

Closed
wants to merge 2 commits into from
+44 −0
Closed

Layered diagrams #121

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f8e6aa2
table-based diagram of software layers
tkruse Mar 18, 2017
3fcb53a
Add pseud-code
tkruse Mar 18, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 44 additions & 0 deletions articles/101_build_tool.md
View file
Original file line number Diff line number Diff line change
@@ -42,6 +42,50 @@ As a consequence of being developed separately certain features are only availab
The reason to work on a single universal build tool comes down to reducing the effort necessary for development and maintenance.
Additionally this makes new features developed for one ROS version / build system available to the other supported ROS versions / build systems.

### Current Workspace and tool combinations

| Concept Layer | ROS2 | ROS1 (catkin) | ROS1 (rosbuild) |
|--------------|------------------------------------|--------------------------------|-------------------------|
| Workspace | ROS2 ament workspace | ROS1 catkin workspace | ROS1 rosbuild workspace |
| Build tool | ament_tools | catkin_tools, catkin_make, cmi | rosbuild |
| Build system | ament_cmake, cmake, python | catkin, cmake | rosbuild |
| Package | ROS2 package, cmake/python project | ROS1 package, cmake project | ros1 rosbuild package |
Copy link
Member

Choose a reason for hiding this comment

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

The visual presentation is certainly helpful. But I think the information is presented too early in the document. Especially since at that point the terms of build tools and build systems haven't been clearly defined. And because the table mixes the terminology and doesn't distinguish between those which imo confused the reader.

Copy link
Author

Choose a reason for hiding this comment

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

Feel free to move to another section or suggest one


(Note catkin_make cannot build pure cmake projects)

### Phase 1 goal: unify build systems (not rosbuild)
Copy link
Member

Choose a reason for hiding this comment

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

If someone would like to implement an extension to the unified build tool to support rosbuild that would be absolutely feasible. There this shouldn't be excluded like this.

Copy link
Author

Choose a reason for hiding this comment

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

would "rosbuild not shown" be ok for you?


| Concept Layer | ROS2 | ROS1 (catkin) |
|-------------------|-------------------------------------|--------------------------------|
| Workspace | ROS2 ament workspace | ROS1 catkin workspace |
| Build tool | *{universal build tool}* | *{universal build tool}* |
| Workspace adapter | *ament workspace adapter* | *catkin workspace adapter* |
| Build system | ament_cmake, cmake, python | catkin, cmake |
| Package | ROS2 package, cmake/python project | ROS1 package, cmake project |

This phase seems realistic to achieve in predictable time because both catkin_tools and ament_tools already have a large overlap.

A coarse pseudo-code looks like this

1. Detect workspace folder to use (e.g. current folder, or parent folder with marker file, ...)
2. Load workspace adapter for this workspaces buildsystem
3. Ask plugin/wrapper for package declarations (name, folder and dependencies of each package)
4. Create DAG of packages for building the workspace
5. Invoke buildsystem plugin command for each package in build order

### Phase 2 goal: unify workspaces
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this article to outline such a phase. The current draft briefly mentions the intrinsic complexity of mixing workspaces like that which are beyond the build tools control: see https://github.com/ros2/design/pull/115/files#diff-361c5cb5b98ec5e7f690f2dbce2cd7fdR186 Also even if all build tools and build systems do the technical part of mixing them well there are other aspects like name spacing of ROS 1 and ROS 2 packages, their rosdep keys, etc. Therefore I think this is exceeding the scope of this article.

Copy link
Author

Choose a reason for hiding this comment

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

In the comments of the main PR @wjwwood seems to argue for such a goal #115 (comment), that's why I added it.


| Concept Layer | All ROS / non-ROS |
|-----------------------|-------------------------------------------|
| Build tool | *{universal build tool}* |
| Workspace | *{universal workspace}* |
| Build system adapter | for catkin, ament, cmake, python, ... |
| Build system | catkin, ament_cmake, cmake, python ... |
| Package | ROS1/ROS2 packages, cmake/python projects |

Note this kind of homogenous workspace would likely require a changes to catkin and the cmake makros, also requiring users to migrate.


### Out of Scope

The build tool does not cover the steps necessary to fetch the sources of the to-be-built packages.