ament buildsystem

[Thibault Kruse]

Since the word is out in the different thread[1], we might as well collect what can be known about the ament buildsystem, until more information will be provided.

The sources appear to be collected here: https://github.com/ament

The sources at a glance do seem like they started as a manual fork(copy) of catkin packages, but apparently not a VCS fork which would allow backporting patches via a VCS (probably the expecetd diff is too big anyway). The package.xml parser seems to be independent of catkin's package.xml parser.


What has been revealed so far was:

On Saturday, July 4, 2015 at 12:26:44 AM UTC+2, Dirk Thomas wrote:

Beside that ROS 1 and ROS 2 packages use a different CMake infrastructure (catkin vs. ament) to be built (hopefully we can publish an article about ament in the near future).

Later is necessary since ROS 2 require feature in the build process which are not available in ROS 1.

PS: ament is not "yet another ROS build system".

You could call it catkin 1.0 or catkin 2.0 which address problems in the current catkin version which have been identified in the last two/three years of usage.

At a glance of the sources, it seems that new cmake macros are provided (ament_*) and it seems the parsing of the package manifest is done by a new package https://github.com/ament/ament_package.

Also I found this rst document which at the time of this writing has a last updated date of 5th of march, so any information therein might not be accurate anymore:
https://github.com/ros2/ros_core_documentation/blob/master/doc/source/index.rst

It states: "ament's primary responsibility is to make it easier to develop and maintain ROS 2 core |packages|. However, this responsibility extends to any user who is willing to make use of our build system conventions and tools."

So EOL-ing catkin for ament is not planned, it seems. This would indicate that developing ROS2 using catkin was deemed more difficult than creating and maintaining ament as additional packages.

I found no file that would describe the main differences between catkin and ament (other than the source-files, of course), but the rst file makes several statements that could be hints:
 * 'The ament_cmake_core |package| contains a lot of the CMake infrastructure which makes it possible to cleanly pass information between |packages| using conventional interfaces.'
 * '[...] This allows you to install once and then edit non-generated resources like Python code and configuration files without having to rerun the install step for them to take effect. This feature essentially replaces the "devel space" from catkin because it has most of the advantages with few of the complications or drawbacks.'
 * 'Another feature provided by ament_cmake_core is the |package| resource indexing which is a way for |packages| to indicate that they contain a resource of some type.'

So from that it seems that introducing ament will require packages to be migrated from rosbuild/catkin to ament, once ament is introduced. It also seems that catkin and ament are not planned to interoperate within the same workspace. Which seems to imply that OSRF will have to support and maintain rosbuild, catkin_make, cmi, and ament in the future (and catkin_tools possibly), and users may have to learn to handle each of those, if working with ROS from source.

Whether one would like to call this "yet another ROS build system" or not depends on personal semantics, IMO.

[1] https://groups.google.com/d/msg/ros-sig-ng-ros/f7OcEJBj9tU/noWQeOZCTagJ

[David Lu]

From http://www.thefreedictionary.com/ament

am·ent  (ăm′ənt, ā′mənt) n. See catkin.

ament (æˈmɛnt; ˈeɪmənt) n. (Psychiatry) a mentally deficient person

Can't make this stuff up. 

[Jonathan Bohren]

I've really been trying to avoid bringing this up since I first discovered "ament".

The only question I have is:

What is the relationship / roadmap between catkin_tools and ament_tools?

-j

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tully Foote]

Hi,

As we've recently reiterated on this mailing list we want this to be an open and collaborative process involving as many people as possible. [1] We want to encourage discussions and debates about the topics being discussed. Part of making sure that we can do this is to maintain a respectful atmosphere which is open to participation and not combative. In particular please avoid conjecture and presumption.

If you would like more information about something please ask respectfully. There are many parts of the system in flight and there are a few of us working full time to make this system as great as possible. As in any large project choices about what to prioritize at any given time need to be made. If you would like to contribute to the effort we can make more progress.

We are working on a design document to post for comment about ament, it's still in bullet point form and we have not had time to flesh it out for circulation and review as we have been working on many other topics. [2]  Our use of ament has not been secret. Anyone who has followed our announcements including tutorials and demos or read our documentation for ROS 2.0 for more than a year now, has seen or experienced ament. It's been developed in the open on github, and has been in the ros2/examples repo since the first commit more than a year ago. [3]

Dirk and/or William will respond directly to the technical questions. And hopefully we can pull together the design documentation soon. However, I really want to make sure that we can keep our discussions positive and professional. It's very important to maintain this demeanor to foster a healthy community.

Tully

[1] https://groups.google.com/forum/#!topic/ros-sig-ng-ros/eK2CC-6WEcM
[2] http://design.ros2.org/
[3] https://github.com/ros2/examples

[William Woodall]

On Sun, Jul 5, 2015 at 10:41 AM, Jonathan Bohren <jonatha...@gmail.com> wrote:

I've really been trying to avoid bringing this up since I first discovered "ament".

The only question I have is:

What is the relationship / roadmap between catkin_tools and ament_tools?

I intend to combine them, but rather than delay progress on other elements of ROS 2 we started out with a minimal set of tools for ament. This is why I've delayed making ament tools more like catkin tools (parallel builds, profiles, captured console output, logging, etc...). The big thing that I prototyped in ament, and that I need to move over to catkin tools, is the plugable build type which allows us, for example, to have plain python packages (package.xml and setup.py, no CMake) in our workspace like ament_copyright and several other pure python packages in our code base. I don't see a reason why catkin and ament can't just each have their own built type. There are some changes to how setup files are handled in ament (the package never creates files that might collide like <prefix>/.catkin or <prefix>/setup.*sh files, but instead the build tool optionally does this for you) which will need to be sorted out between catkin and ament, but I think it's possible and I intend to do it at some point (probably after ROSCon). Help is welcome on that part.

The other big challenge was that you were making big changes to the way catkin tools handles configurations and I needed to work out how to make the devel space an optional thing (not all build types will have it) in the catkin tools options and interface and I didn't want to deal with merging those two change sets. This comes up because the other major thing we wanted to try is catkin without a devel space. We wanted to have just "install with symlink" instead and so far it's working out great. This makes catkin's implementation about half as complicated (much of the code was about handling the devel space) and it should make all other packages simpler also. Any one who's had to deal with finding package resources in the devel space vs install space might understand what I'm talking about.

 

-j

On Sun, Jul 5, 2015, 05:44 Thibault Kruse <tibo...@googlemail.com> wrote:

Since the word is out in the different thread[1], we might as well collect what can be known about the ament buildsystem, until more information will be provided.

The sources appear to be collected here: https://github.com/ament

The sources at a glance do seem like they started as a manual fork(copy) of catkin packages, but apparently not a VCS fork which would allow backporting patches via a VCS (probably the expecetd diff is too big anyway). The package.xml parser seems to be independent of catkin's package.xml parser.

The decision to try a version without the devel space resulted in such a large diff that backporting with patch files didn't really make sense, so we opted to start fresh and restructure the code base to be more modular at the same time. We wanted to make it more modular based on our experience with problems because we have too much integrated into the base build system package, like GTest vs GMock as an example. Since GTest was built into catkin you couldn't remove it and replace it with GMock easily (they are mutually exclusive options from my understanding).

 

What has been revealed so far was:

On Saturday, July 4, 2015 at 12:26:44 AM UTC+2, Dirk Thomas wrote:

Beside that ROS 1 and ROS 2 packages use a different CMake infrastructure (catkin vs. ament) to be built (hopefully we can publish an article about ament in the near future).

Later is necessary since ROS 2 require feature in the build process which are not available in ROS 1.

PS: ament is not "yet another ROS build system".

You could call it catkin 1.0 or catkin 2.0 which address problems in the current catkin version which have been identified in the last two/three years of usage.

At a glance of the sources, it seems that new cmake macros are provided (ament_*) and it seems the parsing of the package manifest is done by a new package https://github.com/ament/ament_package.

I'm not sure why we didn't fork the catkin_pkg for amen_package, but my take on the whole setup is that we should have a python package for parsing package.xml files, maybe python-rep-0140, and then reuse that in ament_package and catkin_pkg. There does need to be one for each I think, since catkin_pkg contains the catkin specific template files and some catkin specific functions. We could spend more time integrating them into one package, but to me the separate packages seems more straight forward and less disruptive to ROS 1. I'm open to discussing the merits of one layout versus the other.

 

Also I found this rst document which at the time of this writing has a last updated date of 5th of march, so any information therein might not be accurate anymore:
https://github.com/ros2/ros_core_documentation/blob/master/doc/source/index.rst

It's mostly up-to-date, only a few things have changed. It's been on my todo list to update it.

 

It states: "ament's primary responsibility is to make it easier to develop and maintain ROS 2 core |packages|. However, this responsibility extends to any user who is willing to make use of our build system conventions and tools."

So EOL-ing catkin for ament is not planned, it seems. This would indicate that developing ROS2 using catkin was deemed more difficult than creating and maintaining ament as additional packages.

This is the same thing with a little more context:

Iterating on catkin from ROS 1 we have created a set of |packages| under the moniker ament. Some of the reasons for changing the name to ament are that we wanted it to not collide with catkin (in case we want mix them at some point) and to prevent confusion with existing catkin documentation. ament's primary responsibility is to make it easier to develop and maintain ROS 2 core |packages|. However, this responsibility extends to any user who is willing to make use of our build system conventions and tools. Additionally it should make |packages| conventional, such that developers should be able to pick up any ament based |package| and make some assumptions about how it works, how to introspect it, and how to build or use it.

We had ideas for how to make the build system better. They were based entirely on catkin and the direction it has been evolving for years. We could not introduce these ideas into ros/catkin without disrupting ROS 1 considerably. So we decided to fork for ROS 2. Now whether that is called catkin 1.0 or catkin 2.0 or ament, in my opinion is poses essentially the same burden on us, but by choosing a new name, makes it easier to determine whether someone is talking about ROS 1's version of catkin or ROS 2's. As I explained above the VCS fork didn't make much sense either because we wanted to make large changes and split the content up over more than one package and repository.

 

I found no file that would describe the main differences between catkin and ament (other than the source-files, of course), but the rst file makes several statements that could be hints:
 * 'The ament_cmake_core |package| contains a lot of the CMake infrastructure which makes it possible to cleanly pass information between |packages| using conventional interfaces.'
 * '[...] This allows you to install once and then edit non-generated resources like Python code and configuration files without having to rerun the install step for them to take effect. This feature essentially replaces the "devel space" from catkin because it has most of the advantages with few of the complications or drawbacks.'
 * 'Another feature provided by ament_cmake_core is the |package| resource indexing which is a way for |packages| to indicate that they contain a resource of some type.'

So from that it seems that introducing ament will require packages to be migrated from rosbuild/catkin to ament, once ament is introduced. It also seems that catkin and ament are not planned to interoperate within the same workspace.

The sentence I included in my snippet above explicitly states "(in case we want mix [catkin and ament] at some point)", so I wouldn't rule out interoperability between them, even in the same workspace. There is work to be done there which we haven't had time for, but it should be possible. The plugable built types are in the direction of a set of conventions and tools that make integrating a different build system (autotools, gradle, scons, etc...) fairly straight forward, which I think is exciting.

 

Which seems to imply that OSRF will have to support and maintain rosbuild, catkin_make, cmi, and ament in the future (and catkin_tools possibly), and users may have to learn to handle each of those, if working with ROS from source.

We've heard overwhelmingly from the community surveys that they want less disruption. So we slowed down releases and decided to push major changes to the core, which need to be made, off to a separate endeavor. The latter decision has the draw back of needing to support users of the current system and users of the new system. However, the advantage is that we can prevent what happened when we rolled catkin out which was we encouraged a large part of the community to change to it and which required others to understand it, at least enough to use it. So far ROS 2 and all of its differences are opt-in for the community, and that's what we intended.

So yes, users will have to learn about ament as soon as they want to use ROS 2 or they want to use something someone else has done in ROS 2, but the question is if that is better or worse than incrementally rolling out the differences into catkin to support our work in ROS 2. That would force them to learn about those changes just to go to the next ROS distribution. I'd say that it is not. If you're argument is that we shouldn't have taken the opportunity to change catkin at all for ROS 2, then I'd have to just disagree with you on that point. I think the changes are useful and worth the effort. However, I would point out what was said before, nothing in ROS 2 is set in stone, so if we can come to a consensus that changes to the build system are not needed or that we could just change catkin in place then we'll explore that, but so far we've just been using our best judgement.

Hopefully we can get a design document up in the near future and we can all discuss the technical pros and cons of our changes.

 

Whether one would like to call this "yet another ROS build system" or not depends on personal semantics, IMO.

[1] https://groups.google.com/d/msg/ros-sig-ng-ros/f7OcEJBj9tU/noWQeOZCTagJ

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

William Woodall

ROS Development Team

wil...@osrfoundation.org

http://wjwwood.io/

[William Woodall]

On Sun, Jul 5, 2015 at 10:22 AM, David Lu <davi...@gmail.com> wrote:

From http://www.thefreedictionary.com/ament

am·ent  (ăm′ənt, ā′mənt) n. See catkin.

ament (æˈmɛnt; ˈeɪmənt) n. (Psychiatry) a mentally deficient person

Can't make this stuff up. 

It's just a name, and what's that really worth?

git
ɡit/
noun

BRITISHinformal

an unpleasant or contemptible person.

I thought ament had a certain je ne sais quoi. :)

 

--

You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thibault Kruse]

Given that Jack O'Quinn was suprised this week to hear about ament, and Jon Bohren in this thread did not know about how this relates to catkin_tools, I wonder whether OSRF made sufficient effort to include the community from the start. But if Tully as plattform manager (I think?) says that there is nothing here to raise an eyebrow over because ament was openly used for ROS2 for a year, then I guess that should be good enough.

On Monday, July 6, 2015 at 1:37:50 AM UTC+2, William Woodall wrote:On Sun, Jul 5, 2015, 05:44 Thibault Kruse <tibo...@googlemail.com> wrote:

We had ideas for how to make the build system better. They were based entirely on catkin and the direction it has been evolving for years. We could not introduce these ideas into ros/catkin without disrupting ROS 1 considerably. So we decided to fork for ROS 2.

It seems a hell of a price to pay, to me. Maybe it was still the best alternative, I cannot estimate that.

Hopefully we can get a design document up in the near future and we can all discuss the technical pros and cons of our changes.

I have some curiosity about the details, but I believe that now is too late to influence the decisions made. So I wont discuss the details.
A year ago, that would have seemed nice. Today, I cannot even be moved to request a REP for this. I have no wish for OSRF resources to waste time on creating a document that wont change anything. So this thread is just to collect some facts and check how people feel about this.


While I am unconvinced about the wisdom of the decisions, I'd say overall this is probably less painful than the introduction of catkin has been.

[Luetkebohle Ingo (CR/AEA2)]

Hi Guys,

 

ahem. I don’t think that the question of who told whom and whether that was “early enough” is really helpful here.

 

I can understand that the authors of ament are a bit taken aback that there seems to be criticism of their effort about a year after they, in their view, made it public. I can also understand that other people are surprised about ament. I myself am *very* surprised.

 

So, communication was clearly not optimal, but isn’t the really important question the one on *why* ament was undertaken? Once we know that, we can discuss whether replacing the build system (again) is the way to go, or not.

 

Mit freundlichen Grüßen / Best regards

Ingo Luetkebohle
Application Software (CR/AEA2)

Tel. +49(711)811-12248
Fax +49(711)811-0
Ingo.Lue...@de.bosch.com

--

[Jonathan Bohren]

I think I first noticed ament last fall when snooping around the ROS2 pages. At the time Will was still putting considerable work into catkin_tools and ament appeared to be very similar in design. I have continued to trust that Will would not be putting so much work into catkin_tools if osrf intended to abandon it, and that ament was just a minimal set of tools for the ROS2 prototype team. I hoped that once they were ready to receive feedback that could actually influence it, they would request it.

Thibault, I definitely empathize with your exasperation. When I first noticed that the ROS2 examples used a new buildsystem, I almost (╯°□°）╯︵ ┻━┻ but it all appeared that it was a prototype tool very similar to catkin_tools and at the very least they were trying to fix the abominable parts of catkin, so it can't be all bad.

I think my pending contributions to catkin_tools make it easier to add additional build types since it separates job execution from the handling of catkin and vanilla CMake packages. Ideally the only thing that the core of the top-level build tool cares about is the package.xml fille. Then everything else should be pluggable.

Now that people are talking about it, I propose that under the assumption that we can separate the tools used to handle information from package.xml files and building workspaces from the tools that handle actually building resources from individual packages (CMake and Python builds):

(1) We make "ament" a buildable type in catkin_tools for the time being
(2) We merge any missing features from ament_tools into catkin_tools
(3) We merge any missing features from the rest of the ament repos which have direct analogs to catkin
(4) We start discussing the merits of ament CMake versus just adding features to catkin CMake

-j

[Thibault Kruse]

On Monday, July 6, 2015 at 1:52:20 PM UTC+2, Jonathan Bohren wrote:

I think I first noticed ament last fall when snooping around the ROS2 pages. At the time Will was still putting considerable work into catkin_tools and ament appeared to be very similar in design. I have continued to trust that Will would not be putting so much work into catkin_tools if osrf intended to abandon it, and that ament was just a minimal set of tools for the ROS2 prototype team.

So does the ament command work like catkin_make or like the catkin command from catkin_tools? In other words, are package builds isolated (and parallel) or mashed together via cmake?

Now that people are talking about it, I propose [...]

I believe that roughly a year ago, there was a conference call around the buildsystems, as referred to here:
https://groups.google.com/d/msg/ros-sig-buildsystem/K7_QBJzFlVA/RVnMZfSYfWQJ

To me it would seem that this would be the best form of communication at this point.

[Jonathan Bohren]

On Mon, Jul 6, 2015 at 1:09 PM Thibault Kruse <tibo...@googlemail.com> wrote:

On Monday, July 6, 2015 at 1:52:20 PM UTC+2, Jonathan Bohren wrote:

I think I first noticed ament last fall when snooping around the ROS2 pages. At the time Will was still putting considerable work into catkin_tools and ament appeared to be very similar in design. I have continued to trust that Will would not be putting so much work into catkin_tools if osrf intended to abandon it, and that ament was just a minimal set of tools for the ROS2 prototype team.

So does the ament command work like catkin_make or like the catkin command from catkin_tools? In other words, are package builds isolated (and parallel) or mashed together via cmake?

Ament not only appears to isolate builds, but it also appears to drop the develspace pattern completely. I haven't used it in practice, and I don't know all the design decisions that went into it so I'll defer Will to explain in more detail. 

Now that people are talking about it, I propose [...]

I believe that roughly a year ago, there was a conference call around the buildsystems, as referred to here:
https://groups.google.com/d/msg/ros-sig-buildsystem/K7_QBJzFlVA/RVnMZfSYfWQJ

To me it would seem that this would be the best form of communication at this point.

Yeah, I think that that G+ hangout was great for the build tools. I think we should have one of those again, and I think it would be really good to have more such meetings for other aspects of ROS design. I think having a G+ on air hangout with everyone in the hangout also logged into IRC or something would be really great for the community.

-j

[Shaun Edwards]

Yeah, I think that that G+ hangout was great for the build tools. I think we should have one of those again, and I think it would be really good to have more such meetings for other aspects of ROS design. I think having a G+ on air hangout with everyone in the hangout also logged into IRC or something would be really great for the community.

We hold online community meetings for ROS-Industrial every so often.  Some are more technical than others, but the value of them can't be understated.  I would definitely recommend them in a broader ROS context. 

[Dirk Thomas]

I have just published an article on the ROS 2 design page about ament: http://design.ros2.org/articles/ament.html

While it mentions the design goals of ament its focus is currently on the second part which describes the differences between ament and catkin.

It should answer the questions raised in this thread as well as clarify uncertainties / guesses mentioned.

If there are questions pending after reading the article please ask them here.

If you have any suggestions on improving the article itself please either create a PR directly or post the them here as well.

Cheers,

- Dirk

+1 for having a conference call / hangout on a regular basis, please propose a date and time as well as an agenda.

[Jonathan Bohren]

Thanks for writing this up, Dirk. From a quick glance, I think many of us are going to have a lot to say about some of these points. Should we comment on that document on this list, in the buildsystem list, or on GitHub?

-j

[Dirk Thomas]

I think the mailing list is a good location for the discussion. But feel free to use either or.

Cheers,

- Dirk

[Dirk Thomas]

On Mon, Jul 6, 2015 at 5:12 PM, Bill Morris <bi...@neautomation.com> wrote:

    How does /ament/ relate to /catkin/?

|catkin| has been used for ROS 1 since ROS Groovy. |catkin| is based
around CMake and even packages only containing Python code are being
processed via CMake. It was developed as a replacement of |rosbuild|
which was used from the beginning of ROS. Therefore various features of
catkin have been designed to be similar to rosbuild.
----

The issue is that the word 'ament' does not appear in your answer.
Also, it reads like the same argument for 'catkin > rosbuild'.

The section has many subsections and they enumerate the differences between catkin and ament:

* no devel space 

* not using CMAKE_PREFIX_PATH directly

* restructuring to support the catkin_simple use case

* not building within a single CMake context

* support for gtest, gmock has been "externalized"

 

I think it needs more TL;DR to explain:
Will ament replace catkin?
Is ament run by catkin?
Is catkin run by ament?
Is ament the 'alpha' version of catkin?
Will the improvements in ament be backported to catkin?

The answer to all questions is: no.

The rational for that is not ament specific but mentioned in the general ROS 2 article: http://design.ros2.org/articles/why_ros2.html#why-not-just-enhance-ros-1

We are neither building ROS 1 on-top of ROS 2 nor the other way around.

And we do not intend to port any changes to ROS 1 since the major reason why ROS 2 is a separate "project" is to avoid changes / regressions in ROS 1.

If certain feature are considered useful for ROS 1 and don't impose a risk of being disruptive they could be consider for porting, but we don't expect to spend time on anything like that in the near future.

- Dirk

PS: I think these questions and answers should be posted back to the mailing list (which I did in this post)

[Bill Morris]

First, thanks for your efforts! I really am excited that ROS2 will be
such a huge leap forward. TCPROS/XML-RPC messaging will be updated to
support DDS, the haze of Python 2 will be updated to a haze of Python 3,
and catkin seems like it will have the same scale of change moving to ament.

Unsorted thoughts below.

My concerns include the burden on developers to support two build
systems or two code bases. The other big issue is the number of
documentation changes. A possible minor issue is giving up all of the
search engine and external references to catkin, making it harder to
find information. Will there be a seperate wiki for ROS2? Will we use
this opportunity to switch wiki backends?
Do we really want to double the documentation burden on developers?

As for the article, I think there needs to be a section titled 'Why
should you be excited/planning to use ament?'
The article should do more to sell me as a developer on why ament is
going to be awesome. Are builds going to be faster? I think my C++ to
Python code base is about 1:10 in terms of LoC, making
maintenance/development of python packages/libraries faster/easier would
help sell me on why we really need yet another build system. I'm not
sure many developers are going to initially be excited about changing
build systems again. So, perhaps a more explicit enumeration of the
benefits would be helpful.

At some place, either the article or the eventual documentation I'd like
to see an example as to the most common case of what is required to
support both build systems in a single version controlled C++ repo.

Could it be possible to convert config files from Catkin to Ament or
vise-versa programatically?
If we can convert from Ament to Catkin programmatically, maybe it would
make sense to have catkin run a pre-processor
if it detects a ament-ified package <build>ament</build> in package.xml
to generate catkin config files. While it might not work for every
package, it could reduce the work/complexity required to maintain ROS1
support.

If the command line interfaces of Ament match that of Catkin, it may
help reduce the number of documentation changes.

[Bill Morris]

On 07/06/2015 08:59 PM, Dirk Thomas wrote:
> On Mon, Jul 6, 2015 at 5:12 PM, Bill Morris <bi...@neautomation.com> wrote:
>
>> How does /ament/ relate to /catkin/?

> The section has many subsections and they enumerate the differences between
> catkin and ament:

I think my problem might be web browser rendering of the CSS. The
heading and subheadings only differ slightly in size.
Perhaps subheadings could be indented or more visually differentiated.

> * no devel space
> * not using CMAKE_PREFIX_PATH directly
> * restructuring to support the catkin_simple use case
> * not building within a single CMake context
> * support for gtest, gmock has been "externalized"

I'm not sure most developers would see these as being directly
beneficial. (catkin_simple and external test support are the easiest to
understand). e.g. "no devel space" sounds like a bad thing, "Allows
editing of non-generated resources like Python code without
reinstallation" sounds like a feature I want.

>> I think it needs more TL;DR to explain:
>> Will ament replace catkin?
>> Is ament run by catkin?
>> Is catkin run by ament?
>> Is ament the 'alpha' version of catkin?
>> Will the improvements in ament be backported to catkin?
> The answer to all questions is: no.

I don't understand how this is right. Can you explain how ament will not
replace catkin?
Does this mean we can use catkin in ROS2? or are you just trying to say
that catkin will still be supported but the catkin equivalent for ROS2
is ament?

> The rational for that is not ament specific but mentioned in the general
> ROS 2 article:
> http://design.ros2.org/articles/why_ros2.html#why-not-just-enhance-ros-1
>
> We are neither building ROS 1 on-top of ROS 2 nor the other way around.
> And we do not intend to port any changes to ROS 1 since the major reason
> why ROS 2 is a separate "project" is to avoid changes / regressions in ROS
> 1.
> If certain feature are considered useful for ROS 1 and don't impose a risk
> of being disruptive they could be consider for porting, but we don't expect
> to spend time on anything like that in the near future.

Does this mean you expect to see most developers to also maintain two
separate code bases?

[Dirk Thomas]

On Mon, Jul 6, 2015 at 6:21 PM, Bill Morris <bi...@neautomation.com> wrote:

My concerns include the burden on developers to support two build
systems or two code bases.

The build system is not the only thing which changes.

And since ament as well as catkin are based on CMake they are pretty similar (compared to rosbuild vs. catkin back in the days).

Also the API of the ROS client library will be different.

ROS 2 also uses C++11 and therefore std::shared_ptr instead of boost::shared_pointer.

So it will likely not be feasible to build a package for ROS 1 and ROS 2 from the same code base. 

As suggested before this will be collected an a migration document in the future.

The other big issue is the number of
documentation changes. A possible minor issue is giving up all of the
search engine and external references to catkin, making it harder to
find information. Will there be a seperate wiki for ROS2? Will we use
this opportunity to switch wiki backends?
Do we really want to double the documentation burden on developers?

The design repository contains a draft article about documentation: https://github.com/ros2/design/blob/gh-pages/articles/80_ros_documentation_system.md

While no concrete progress has made on setting up any infrastructure I am pretty sure that ROS 2 documentation will not be mixed with the ROS 1 wiki.

If it is a separate wiki (definitely not based on MoinMoin) or GitHub pages, or ReadTheDocs or a mixture of different things has still to be determined.

As for the article, I think there needs to be a section titled 'Why
should you be excited/planning to use ament?'
The article should do more to sell me as a developer on why ament is
going to be awesome.

Since ament will enable something like catkin_simple in a really usable way I would expect that the CMake code of a lot of packages becomes much simpler.

But I don't expect anybody to get excited about the new build system - ament is more an evolution then a revolution.

 

Are builds going to be faster?

In general most packages are based on CMake and there is no performance difference.

For Python package the CMake overhead will go away.

 

I think my C++ to
Python code base is about 1:10 in terms of LoC, making
maintenance/development of python packages/libraries faster/easier would
help sell me on why we really need yet another build system.

If your package contains only Python code than with ament you will only need a setup.py file and no CMakeLists.txt file anymore.

 

I'm not
sure many developers are going to initially be excited about changing
build systems again. So, perhaps a more explicit enumeration of the

benefits would be helpful.

As mentioned before the article is currently mostly focused on the differences between ament and catkin.

It can be extended in the future to enumerate the advantages but many are already mentioned in the current version of the article.

Only a few thing come to my mind which are not explicitly mentioned yet:

* various linting packages with easy integration

* more modular CMake API allow easier integration of new features (like gtest, gmock)

But most of the advantages are already mentioned in the article.

At some place, either the article or the eventual documentation I'd like
to see an example as to the most common case of what is required to
support both build systems in a single version controlled C++ repo.

As mentioned in the article it is not intended to mix both build system.

A folder cannot contain a catkin as well as an ament package - it is either or.

Due to the changes in the API in general it is not expected that the same code base will work for both ROS versions.

Therefore I don't see why that should be a goal on the build system level.

Could it be possible to convert config files from Catkin to Ament or
vise-versa programatically?
If we can convert from Ament to Catkin programmatically, maybe it would
make sense to have catkin run a pre-processor
if it detects a ament-ified package <build>ament</build> in package.xml
to generate catkin config files. While it might not work for every
package, it could reduce the work/complexity required to maintain ROS1
support.

If somebody would like to look into that we can always help and answer questions but we will likely not work on this topic.

Cheers,

- Dirk

[Dirk Thomas]

On Mon, Jul 6, 2015 at 6:48 PM, Bill Morris <bi...@neautomation.com> wrote:

On 07/06/2015 08:59 PM, Dirk Thomas wrote:
> On Mon, Jul 6, 2015 at 5:12 PM, Bill Morris <bi...@neautomation.com> wrote:
>
>>     How does /ament/ relate to /catkin/?
> The section has many subsections and they enumerate the differences between
> catkin and ament:
I think my problem might be web browser rendering of the CSS. The
heading and subheadings only differ slightly in size.
Perhaps subheadings could be indented or more visually differentiated.

This is how the current style sheet looks like: https://github.com/ros2/design/blob/gh-pages/css/ros2-design.css

Please feel free to make a PR to improve the style.

 

> * no devel space
> * not using CMAKE_PREFIX_PATH directly
> * restructuring to support the catkin_simple use case
> * not building within a single CMake context
> * support for gtest, gmock has been "externalized"
I'm not sure most developers would see these as being directly
beneficial. (catkin_simple and external test support are the easiest to
understand). e.g. "no devel space" sounds like a bad thing, "Allows
editing of non-generated resources like Python code without
reinstallation" sounds like a feature I want.

Please read the ament article in full.

ament explicitly offers the same advantage without the disadvantages.

It is described in the section "symlinked install".

>> I think it needs more TL;DR to explain:
>> Will ament replace catkin?
>> Is ament run by catkin?
>> Is catkin run by ament?
>> Is ament the 'alpha' version of catkin?
>> Will the improvements in ament be backported to catkin?
> The answer to all questions is: no.

I don't understand how this is right. Can you explain how ament will not
replace catkin?

Does this mean we can use catkin in ROS2? or are you just trying to say
that catkin will still be supported but the catkin equivalent for ROS2
is ament?

Yes, the catkin equivalent for ROS 2 is ament.

catkin will continue to be used for ROS 1.

ament will be used only for ROS 2.

ROS 1 and ROS 2 will likely coexist beside each other for quite some time.

Neither do be plan to deploy ament in ROS 1 nor allow using catkin for ROS 2. 

> The rational for that is not ament specific but mentioned in the general
> ROS 2 article:
> http://design.ros2.org/articles/why_ros2.html#why-not-just-enhance-ros-1
>
> We are neither building ROS 1 on-top of ROS 2 nor the other way around.
> And we do not intend to port any changes to ROS 1 since the major reason
> why ROS 2 is a separate "project" is to avoid changes / regressions in ROS
> 1.
> If certain feature are considered useful for ROS 1 and don't impose a risk
> of being disruptive they could be consider for porting, but we don't expect
> to spend time on anything like that in the near future.

Does this mean you expect to see most developers to also maintain two
separate code bases?

We expect that packages are being migrated from ROS 1 to ROS 2:

* when all their dependencies are available in ROS 2

* and the maintainers sees an advantage in using ROS 2 over ROS 1

For a certain amount of time it is likely that packages will be available and maintained in both versions.

While this involves for sure a certain overhead the disadvantages mentioned in the why-ros2 article are also pretty compelling why we are not planning to roll all these changes into ROS 1.

- Dirk

[Thibault Kruse]

On Tuesday, July 7, 2015 at 3:21:04 AM UTC+2, Bill Morris wrote:

My concerns include the burden on developers to support two build
systems or two code bases.

This is also my main concern. ROS should only needs one codebase for package.xml specifications and only one multi-package build scheduler that builds a DAG of packages and decides on the order of building them, offering convenience commands to clean and build only a subset of packages and such.

Ideally the package.xml format will not be different between catkin and ament.
Ideally also the CMakeLists.txt of ros1 packages will not have to change other than the find_package(catkin ...) line to build with ament (not to migrate to ros2).
This would make it easier to sustain an experimental ament branch for packages, and to eventually migrate to ament. Migration to ROS2 client api can be a separate step.

Making the CMakeLists.txt simpler (like catkin_simple) is also nice, but IMO a *simple migration* from catkin to ament
would right now be more valuable than a cleanup/simplification of the cmake API. Maintainers have
spent a lot of time on writing cmake API code for their ros1 packages, and they should be more happy
if they do not have to touch the cmake code again in a major way for now while switching to ament.

A lovely switch scenario would be:
 * Prepare a sourcespace for ROS1 with many public catkin packages
 * find replace in all CMakeLists.txt replace "find_package(catkin" with "find_package(catkin2" (with some more regex magic)
 * run ament (or catkin_tools with ament switch)
 * done (ros1 works)

I currently do not see the technical obstacles for making this work, maybe there are some.
Since apparently ament started off as some kind of fork of catkin+catkin_tools able to build ros1, it must have been easily possible in the beginning.

If that worked, ament would not be perceived as a third buildtool, but as a drop-in replacement for catkin.
It would still be bothersome to migrate ros1 catkin packages to ament (coordination, changing the build farm, documentation, regressions), but EOLing catkin in favour of ament should free resources in the long run. Since migrating to ROS2 requires migrating to ament, making the migration from catkin to ament easily possible as a first step without migrating to ROS2 would also be beneficial to community happiness.
With that strategy, the name "catkin2" might also be more viable.

On Monday, July 6, 2015 at 11:38:08 PM UTC+2, Dirk Thomas wrote:

> +1 for having a conference call / hangout on a regular basis, please
> propose a date and time as well as an agenda. 

 
I suggested this call, but since I seem to antagonize people at OSRF, I wont
participate, so I trust someone else will setup a doodle and Google doc or something. Not sure
why OSRF does not organize this. Not sure whom Dirk addressed there anyway.

[Cedric Pradalier]

Hi all, 

If we want to amend the build system, could we keep in mind that some of us are using ROS for teaching? Teaching robotics in all its breadth is already a challenge, and I loved rosbuild for staying out of the way when teaching. Catkin was definitely a step backward in this respect (I'm aware there are plenty of good reason for catkin). Now I have to pre-write all the packages to make sure we're not stuck in cmake issues when we're trying to teach obstacle avoidance.

Please include this constraint in any design session.

Regards

--

You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Cedric Pradalier

[Bill Morris]

On 07/07/2015 02:17 AM, Dirk Thomas wrote:
> On Mon, Jul 6, 2015 at 6:21 PM, Bill Morris <bi...@neautomation.com> wrote:
>> My concerns include the burden on developers to support two build
>> systems or two code bases.

> So it will likely not be feasible to build a package for ROS 1 and ROS 2
> from the same code base.

I'm willing to accept that this ament thing could be worth doing and I'm
willing to accept that the increased package maintenance, development
and documentation costs for all package maintainers to maintain two
separate code bases are probably unavoidable. I will admit that ROS2
with ament may be only slightly more work than ROS2 without ament, if it
were possible.

If ament is not capable of meeting all of our foreseeable needs, then I
believe there will be a harsh reaction**if ament also ends up being
replaced in another few years.

Perhaps it would be productive to consider what use cases we would like
to see a build system handle. Even if all of these are not possible,
perhaps the design could enable them to be built in the future. Below
are some things which may or may not be good ideas or within scope. OSRF
doesn't need to write code to meet all of our use cases, but it would be
nice if the architecture can support some of these tasks.

# Use Case: Android builds
Building Android packages (with gradle?)
Calling 'adb' to install Android packages on phone
Calling 'adb' to install Android packages on emulator

# Use Case: VM / Container / virtualenv support
How can ament make the development cycle for virtual ROS installs /
testing easier
Remote install? Better integration with bloom?

# Use Case: Embedded system builds / installs
'ament build' on a rosserial package to build arduino code
using 'ament install' to write firmware to the hardware without the
stupid Arduino GUI

# Use Case: interactive testing
What might be needed to support Hardware-in-the-loop testing?
Can we test GUIs? physical buttons?
Burn in testing for hardware platforms?

# Use Case: multi-language codebases
Linting package configuration vs linting code
Testing multiple languages in the same build
Installing a utility shell script along with c++ code

# Use Case: hardware introspection based builds
plugging in a robot arm/sensor and query the hardware to determine the
compiler optimizations for an embedded build.
Using build time hardware introspection to build URDFs based on hardware

# Use Case: udev
How can ament improve setting up permissions for usb based devices
correctly?
Can we have a macro to generate and install udev rules for common uses

# Use Case: calibration
Does it make sense to consider calibration part of the build process?
For a hardware-in-the-loop build does it make sense to provide a way to
perform tasks such a zeroing gyros or endstops?

# Use Case: documentation testing
If a developer writes documentation in jekyll
'ament test_docs' could automatically launch jekyll serve --watch
--baseurl='' && firefox --new-tab http://localhost:4000/

# Use Case: testing robotwebtools based interfaces
Provide a way from ament to use something like http://qunitjs.com/ or
http://docs.seleniumhq.org/

# Use Case: benchmarking, profiling and feedback
Is this part of the build process?
Does it make sense to provide a way for users to send feedback on how
long it took tests to run or errors encountered?

[Dirk Thomas]

On Tue, Jul 7, 2015 at 2:00 PM, Bill Morris <bi...@neautomation.com> wrote:

If ament is not capable of meeting all of our foreseeable needs, then I
believe there will be a harsh reaction**if ament also ends up being
replaced in another few years.

ament is not really the third iteration of build systems in ROS.

It is an improved version of catkin - it could be called catkin2 (see http://design.ros2.org/articles/ament.html#why-use-a-new-name-instead-of-continuing-to-call-it-catkin why we decide to choose a significantly different name).

The improvements are based on the feedback from the community over the last two years.

Updating from catkin to ament will be much easier then the migration from rosbuild to catkin (please see two example CMake files: https://gist.github.com/dirk-thomas/596a53bbb922c4d6988a https://gist.github.com/dirk-thomas/83ae6bfbfc94e06cd519).

That being said it is always difficult to foresee what will be demanded features in the future.

One significant advantage of ament is that it has been refactored internally significantly to be very modular.

Many individual features which are available in the monolithic catkin package have been modularized in ament and are provided by a separate package.

Please see the list of packages in the ament_cmake repo for that: https://github.com/ament/ament_cmake

Therefore I would argue that ament is better suited for future demands.

(But as with any software the design will probably not be able to handle everything out-of-the-box.)

Perhaps it would be productive to consider what use cases we would like
to see a build system handle. Even if all of these are not possible,
perhaps the design could enable them to be built in the future. Below
are some things which may or may not be good ideas or within scope. OSRF
doesn't need to write code to meet all of our use cases, but it would be
nice if the architecture can support some of these tasks.

Absolutely!

I will comment on the some use cases inline but it might be sometime difficult to give a realistic answer based on the provided information about the use cases.

For some of the use cases I don't have enough knowledge to answer that.

I would encourage users with that use case to look into catkin / ament and try to use it for that purpose.

Based on their feedback we would be happy to work with them to make the tools more flexible to address their use case.

But as you mentioned before we at OSRF might not have the bandwidth and / or expertise to work on that and rely on the community to contribute to it.

# Use Case: VM / Container / virtualenv support
How can ament make the development cycle for virtual ROS installs /
testing easier
Remote install? Better integration with bloom?

Could a remote install be separated in a local install plus transferring the files to the remote machine?

Would do you mean with "Better integration with bloom"?

# Use Case: Embedded system builds / installs
'ament build' on a rosserial package to build arduino code
using 'ament install' to write firmware to the hardware without the
stupid Arduino GUI

CMake (and therefore catkin as well as ament) allows to run arbitrary logic during the install step.

I think that would be sufficient if you want to write the firmware in that step.

 

# Use Case: interactive testing
What might be needed to support Hardware-in-the-loop testing?
Can we test GUIs? physical buttons?
Burn in testing for hardware platforms?

In ament each testing framework is integrated via a separate package.

Therefore it should be straight forward to implement e.g. GUI tests using what ever framework you find suitable for your application.

While catkin only provides nosetests and gtest integration it is still possible to use external test frameworks.

It would just be a bit more effort to register them as test within catkin.

 

# Use Case: multi-language codebases
Linting package configuration vs linting code
Testing multiple languages in the same build
Installing a utility shell script along with c++ code

The current linters cover: CMake style, Python style and docblocks, C / C++ style, C / C++ static code analysis, check for copyright / license for these three languages

Integrating more linters (e.g. one which checks the package.xml and / or CMakeLists.txt) is easily possible.

Existing linters like roslint can be integrated with minutes via a separate package.

You can already install arbitrary resources with a package (in catkin as well as in ament).

I am not sure what you mean with "Testing multiple languages in the same build".

May be you can provide a more detailed use case for that?

# Use Case: hardware introspection based builds
plugging in a robot arm/sensor and query the hardware to determine the
compiler optimizations for an embedded build.
Using build time hardware introspection to build URDFs based on hardware

This obviously requires the hardware to be available when the build is performed.

But I don't see any obstacles beside someone needs to implement that logic?

# Use Case: udev
How can ament improve setting up permissions for usb based devices
correctly?
Can we have a macro to generate and install udev rules for common uses

I don't think such a feature should be "provided" by ament itself.

I would recommend to implement a catkin / ament package which provides the functionality you describe and then other packages can rely on that and use it without having to worry about the details.

 

# Use Case: calibration
Does it make sense to consider calibration part of the build process?
For a hardware-in-the-loop build does it make sense to provide a way to
perform tasks such a zeroing gyros or endstops?

I think the answer is similar to the previous use case: such functionality should be provided by a separate package.

# Use Case: documentation testing
If a developer writes documentation in jekyll
'ament test_docs' could automatically launch jekyll serve --watch
--baseurl='' && firefox --new-tab http://localhost:4000/

Currently we haven't made any decision or prototypes how to handle documentation (some early draft can be found here: https://github.com/ros2/design/blob/gh-pages/articles/80_ros_documentation_system.md).

But I would certainly envision a command like "ament build_docs" to work across multiple different documentation tools.

It should probably not invoke firefox for you but let the user know where the documentation has been generated ;-)

# Use Case: testing robotwebtools based interfaces
Provide a way from ament to use something like http://qunitjs.com/ or
http://docs.seleniumhq.org/

As  mentioned about support for other testing frameworks (like selenium) can be provided by a separate package.

In fact in ament gtest and gmock support are implemented that way since they can't we used at the same time easily.

# Use Case: benchmarking, profiling and feedback
Is this part of the build process?
Does it make sense to provide a way for users to send feedback on how
long it took tests to run or errors encountered?

While tests commonly only have a boolean return value catkin as well as ament use JUnit compatible result files to capture more details about the tests.

While some test frameworks support generating those directly catkin / ament can generate them for you based on a simple boolean return value.

Those result files include information about which tests have been run, which ones failed and contain the output of each of the tests.

You can even get a summary across all tested packages in your workspace (catkin_test_results | ament test_results).

- Dirk

[Bill Morris]

On 07/08/2015 02:04 PM, Dirk Thomas wrote:
> On Tue, Jul 7, 2015 at 2:00 PM, Bill Morris <bi...@neautomation.com> wrote:
>> If ament is not capable of meeting all of our foreseeable needs, then I
>> believe there will be a harsh reaction**if ament also ends up being
>> replaced in another few years.
> ament is not really the third iteration of build systems in ROS.
> It is an improved version of catkin - it could be called catkin2 (see
> http://design.ros2.org/articles/ament.html#why-use-a-new-name-instead-of-continuing-to-call-it-catkin
> why we decide to choose a significantly different name).
> The improvements are based on the feedback from the community over the last
> two years.
> Updating from catkin to ament will be much easier then the migration from
> rosbuild to catkin (please see two example CMake files:
> https://gist.github.com/dirk-thomas/596a53bbb922c4d6988a
> https://gist.github.com/dirk-thomas/83ae6bfbfc94e06cd519).
>
> That being said it is always difficult to foresee what will be demanded
> features in the future.

Avoiding the perception of a new build system every two years may be
enough of a reason not to rename it.

>> Perhaps it would be productive to consider what use cases we would like
>> to see a build system handle. Even if all of these are not possible,
>> perhaps the design could enable them to be built in the future. Below
>> are some things which may or may not be good ideas or within scope. OSRF
>> doesn't need to write code to meet all of our use cases, but it would be
>> nice if the architecture can support some of these tasks.
> Absolutely!
> I will comment on the some use cases inline but it might be sometime
> difficult to give a realistic answer based on the provided information
> about the use cases.

Thanks for the comments, I think they provide a better understanding of
ament.

>
> For some of the use cases I don't have enough knowledge to answer that.
> I would encourage users with that use case to look into catkin / ament and
> try to use it for that purpose.
> Based on their feedback we would be happy to work with them to make the
> tools more flexible to address their use case.
> But as you mentioned before we at OSRF might not have the bandwidth and /
> or expertise to work on that and rely on the community to contribute to it.
>
>
> # Use Case: VM / Container / virtualenv support
>> How can ament make the development cycle for virtual ROS installs /
>> testing easier
>> Remote install? Better integration with bloom?
>>
> Could a remote install be separated in a local install plus transferring
> the files to the remote machine?

Doing development for offline ROS cloud processing involves spinning up
a virtual system with specific package versions. Building in the VM is
slow and installing all of these packages locally isn't really an
option, so right now the development feedback loop looks like:
hack -> build with catkin -> transfer files to VM -> test -> find bug ->
hack
I think what I am asking for is if it is possible to to set the install
prefix to sftp://ros@vm/usr/local or something similar
This is somewhat similar to remote testing/debugging needed for embedded
systems.

> Would do you mean with "Better integration with bloom"?

Maybe there is already a way to do this but perhaps, ament could call
bloom to generate the debian packages locally as something like a 'ament
build_dist' target

> # Use Case: interactive testing
>> What might be needed to support Hardware-in-the-loop testing?
>> Can we test GUIs? physical buttons?
>> Burn in testing for hardware platforms?
>>
> In ament each testing framework is integrated via a separate package.
> Therefore it should be straight forward to implement e.g. GUI tests using
> what ever framework you find suitable for your application.
>
> While catkin only provides nosetests and gtest integration it is still
> possible to use external test frameworks.
> It would just be a bit more effort to register them as test within catkin.

Does it make sense to have a flag to separate blocking and non-blocking
tests
ament test --non-interactive package_name
This would allow tests that expect user input to be skipped for
continuous integration testing.

>> # Use Case: documentation testing
>> If a developer writes documentation in jekyll
>> 'ament test_docs' could automatically launch jekyll serve --watch
>> --baseurl='' && firefox --new-tab http://localhost:4000/
> Currently we haven't made any decision or prototypes how to handle
> documentation (some early draft can be found here:
> https://github.com/ros2/design/blob/gh-pages/articles/80_ros_documentation_system.md
> ).
> But I would certainly envision a command like "ament build_docs" to work
> across multiple different documentation tools.
> It should probably not invoke firefox for you but let the user know where
> the documentation has been generated ;-)

I think what I'm trying to suggest here is that 'ament build_docs' and
'ament test_docs' are two separate things.
Also firefox -> xdg-open, maybe.

>> # Use Case: testing robotwebtools based interfaces
>> Provide a way from ament to use something like http://qunitjs.com/ or
>> http://docs.seleniumhq.org/
> As mentioned about support for other testing frameworks (like selenium)
> can be provided by a separate package.
> In fact in ament gtest and gmock support are implemented that way since
> they can't we used at the same time easily.

So the testing plugin system should allow us to automatically launch
roscore, webserver, websockets and selenium?

Thanks!
Bill

[G.A. vd. Hoorn - 3ME]

On 8-7-2015 21:55, Bill Morris wrote:
> On 07/08/2015 02:04 PM, Dirk Thomas wrote:
>> On Tue, Jul 7, 2015 at 2:00 PM, Bill Morris <bi...@neautomation.com> wrote:

[..]

>> # Use Case: VM / Container / virtualenv support
>>> How can ament make the development cycle for virtual ROS installs /
>>> testing easier
>>> Remote install? Better integration with bloom?
>>>
>> Could a remote install be separated in a local install plus transferring
>> the files to the remote machine?
> Doing development for offline ROS cloud processing involves spinning up
> a virtual system with specific package versions. Building in the VM is
> slow and installing all of these packages locally isn't really an
> option, so right now the development feedback loop looks like:
> hack -> build with catkin -> transfer files to VM -> test -> find bug ->
> hack
> I think what I am asking for is if it is possible to to set the install
> prefix to sftp://ros@vm/usr/local or something similar
> This is somewhat similar to remote testing/debugging needed for embedded
> systems.

[..]

Personally I'd say that is not the responsibility of a meta-build tool.

Remote deployment could easily be accomplished by mounting the remote
file system under a local mount point (using sshfs fi). Installing to
that would then not be any different from installing into any other
location on the filesystem.

I really like to integrate things myself, but in this case I believe
KISS is more appropriate.


Gijs

[Dirk Thomas]

On Wed, Jul 8, 2015 at 12:55 PM, Bill Morris <bi...@neautomation.com> wrote:

On 07/08/2015 02:04 PM, Dirk Thomas wrote:
> On Tue, Jul 7, 2015 at 2:00 PM, Bill Morris <bi...@neautomation.com> wrote:
>
Avoiding the perception of a new build system every two years may be
enough of a reason not to rename it.

Please see the article (http://design.ros2.org/articles/ament.html#why-use-a-new-name-instead-of-continuing-to-call-it-catkin) for the rational why we think it is technically necessary to have a different name (on the CMake level) to implement features like the ROS 1 / ROS 2 bridge.

If anybody can come up with an approach which allows it to be named the same we would be happy to hear about it.

 

> Would do you mean with "Better integration with bloom"?
Maybe there is already a way to do this but perhaps, ament could call
bloom to generate the debian packages locally as something like a 'ament
build_dist' target

This has been asked before: please see http://answers.ros.org/question/173804/generate-deb-from-ros-package/

For sure it can be automated for a set of packages using ament_tools.

ament_tools allows you to extend it with any command, in your example "build_dist".

> # Use Case: interactive testing
>> What might be needed to support Hardware-in-the-loop testing?
>> Can we test GUIs? physical buttons?
>> Burn in testing for hardware platforms?
>>
> In ament each testing framework is integrated via a separate package.
> Therefore it should be straight forward to implement e.g. GUI tests using
> what ever framework you find suitable for your application.
>
> While catkin only provides nosetests and gtest integration it is still
> possible to use external test frameworks.
> It would just be a bit more effort to register them as test within catkin.
Does it make sense to have a flag to separate blocking and non-blocking
tests
ament test --non-interactive package_name
This would allow tests that expect user input to be skipped for
continuous integration testing.

I don't understand why a unit test would be interactive in the first place?

CTest provides various ways to specify which tests to run.

But I don't think that CTest allows you at all to interact with the tests.

 

>> # Use Case: documentation testing
>> If a developer writes documentation in jekyll
>> 'ament test_docs' could automatically launch jekyll serve --watch
>> --baseurl='' && firefox --new-tab http://localhost:4000/
> Currently we haven't made any decision or prototypes how to handle
> documentation (some early draft can be found here:
> https://github.com/ros2/design/blob/gh-pages/articles/80_ros_documentation_system.md
> ).
> But I would certainly envision a command like "ament build_docs" to work
> across multiple different documentation tools.
> It should probably not invoke firefox for you but let the user know where
> the documentation has been generated ;-)
I think what I'm trying to suggest here is that 'ament build_docs' and
'ament test_docs' are two separate things.
Also firefox -> xdg-open, maybe.

May be I still don't understand your goal.

What does "test_docs" actually test for?

>> # Use Case: testing robotwebtools based interfaces
>> Provide a way from ament to use something like http://qunitjs.com/ or
>> http://docs.seleniumhq.org/
> As  mentioned about support for other testing frameworks (like selenium)
> can be provided by a separate package.
> In fact in ament gtest and gmock support are implemented that way since
> they can't we used at the same time easily.
So the testing plugin system should allow us to automatically launch
roscore, webserver, websockets and selenium?

Add test can provide whatever process / resources it needs.

E.g. we do the same with rostest where one single test launches a roscore as well as multiple nodes.

- Dirk

[Jonathan Bohren]

On Wed, Jul 8, 2015 at 4:12 PM Dirk Thomas <dth...@osrfoundation.org> wrote:

On Wed, Jul 8, 2015 at 12:55 PM, Bill Morris <bi...@neautomation.com> wrote:

On 07/08/2015 02:04 PM, Dirk Thomas wrote:
> On Tue, Jul 7, 2015 at 2:00 PM, Bill Morris <bi...@neautomation.com> wrote:
>

Avoiding the perception of a new build system every two years may be
enough of a reason not to rename it.

Please see the article (http://design.ros2.org/articles/ament.html#why-use-a-new-name-instead-of-continuing-to-call-it-catkin) for the rational why we think it is technically necessary to have a different name (on the CMake level) to implement features like the ROS 1 / ROS 2 bridge.

If anybody can come up with an approach which allows it to be named the same we would be happy to hear about it.

Dirk, can you elaborate on how a ROS1 / ROS2 bridge requires using both Catkin and Ament in the same CMake project?

-j 

[Dirk Thomas]

A ROS bridge needs to `find_package()` all packages which contain messages in ROS 1 as well as in ROS 2.

Since some packages might call find_package(catkin) when being find_packaged that needs to resolve to the "right" catkin package.

- Dirk

--

[Bill Morris]

Most of this is trying to brainstorm ways to cut time off the
development cycle.
One idea might be something like a local post-install hook to do tasks
such as this for forked packages.

[William Woodall]

On Wed, Jul 8, 2015 at 12:55 PM, Bill Morris <bi...@neautomation.com> wrote:

On 07/08/2015 02:04 PM, Dirk Thomas wrote:
> On Tue, Jul 7, 2015 at 2:00 PM, Bill Morris <bi...@neautomation.com> wrote:
>> If ament is not capable of meeting all of our foreseeable needs, then I
>> believe there will be a harsh reaction**if ament also ends up being
>> replaced in another few years.
> ament is not really the third iteration of build systems in ROS.
> It is an improved version of catkin - it could be called catkin2 (see
> http://design.ros2.org/articles/ament.html#why-use-a-new-name-instead-of-continuing-to-call-it-catkin
> why we decide to choose a significantly different name).
> The improvements are based on the feedback from the community over the last
> two years.
> Updating from catkin to ament will be much easier then the migration from
> rosbuild to catkin (please see two example CMake files:
> https://gist.github.com/dirk-thomas/596a53bbb922c4d6988a
> https://gist.github.com/dirk-thomas/83ae6bfbfc94e06cd519).
>
> That being said it is always difficult to foresee what will be demanded
> features in the future.
Avoiding the perception of a new build system every two years may be
enough of a reason not to rename it.

That's worth discussing the trade-offs of, because the other side of that coin is allowing users to more easily identify when a tutorial is for catkin or ament, because otherwise they are subtly different. I'm reminded of learning OpenCV around the time they introduced the C++ style API and it was common for me to misstep by grabbing parts of a tutorial that used the cv_ C style API and mixing it with snippets from the cv:: C++ style API, which enviably resulted in errors and confusion on my part. The easier it is to tell the difference the better in my opinion. If we called it catkin 1.0 or catkin2 or something like that then we have to be careful not to drop the modifier to avoid confusion. If we're that careful to always use catkin2 or similar, then using a different name, like ament, is just pr and expectation management. We've not done a good enough job at those two things, but we're trying to do better. My rational for the name change was that we can take the benefit of this name change at little cost, but my initial reaction to your valid concern is that we should address perception with communication, not spending time renaming the system and loosing the benefit of clear separation.

For this type of thing I use sshfs or nfs, and it works great. I develop on a mac, so to test on Linux I fire up a VM, mount my source space which is on my mac as an nfs folder in Linux and build it there. I can build the same source space on my mac locally. This lets me edit and commit to one place and test in two. I'm certain a similar thing could be accomplished with a docker container or a remote VM. I'd rather not complicate the tool with special logic for something that's easily addressed with devops tools. If there is something that ament could do better to allow you to do this though, that's worth talking about.

 

> Would do you mean with "Better integration with bloom"?
Maybe there is already a way to do this but perhaps, ament could call
bloom to generate the debian packages locally as something like a 'ament
build_dist' target

> # Use Case: interactive testing
>> What might be needed to support Hardware-in-the-loop testing?
>> Can we test GUIs? physical buttons?
>> Burn in testing for hardware platforms?
>>
> In ament each testing framework is integrated via a separate package.
> Therefore it should be straight forward to implement e.g. GUI tests using
> what ever framework you find suitable for your application.
>
> While catkin only provides nosetests and gtest integration it is still
> possible to use external test frameworks.
> It would just be a bit more effort to register them as test within catkin.
Does it make sense to have a flag to separate blocking and non-blocking
tests
ament test --non-interactive package_name
This would allow tests that expect user input to be skipped for
continuous integration testing.

This is more of a domain specific utility as well, though it could easily be worked in if a common enough convention is in place. But just as an example, I override the question asking routine for testing in bloom:

https://github.com/ros-infrastructure/bloom/blob/master/test/utils/common.py#L72-L99

This might not be fool proof, but it has worked for bloom for now. Again, I'm not sure it is something that is generically handled by any other system and it's not clear to me how we'd address it in a generic way.

One thought might be that we could introduce a tag system into the tests, allowing you to select from the tests based on that meta information, so you could do something like `ament test --tags="-interactive,+network"` or something like that. Just a rough idea, but I've often desired more from CTest's ability to narrow test selection. Implementation of the tags idea would be problematic as is, since we delegate everything test related to CTest at the moment, unlike catkin which has its own run_tests target in addition to CTest support.

 

>> # Use Case: documentation testing
>> If a developer writes documentation in jekyll
>> 'ament test_docs' could automatically launch jekyll serve --watch
>> --baseurl='' && firefox --new-tab http://localhost:4000/
> Currently we haven't made any decision or prototypes how to handle
> documentation (some early draft can be found here:
> https://github.com/ros2/design/blob/gh-pages/articles/80_ros_documentation_system.md
> ).
> But I would certainly envision a command like "ament build_docs" to work
> across multiple different documentation tools.
> It should probably not invoke firefox for you but let the user know where
> the documentation has been generated ;-)
I think what I'm trying to suggest here is that 'ament build_docs' and
'ament test_docs' are two separate things.
Also firefox -> xdg-open, maybe.

>> # Use Case: testing robotwebtools based interfaces
>> Provide a way from ament to use something like http://qunitjs.com/ or
>> http://docs.seleniumhq.org/
> As  mentioned about support for other testing frameworks (like selenium)
> can be provided by a separate package.
> In fact in ament gtest and gmock support are implemented that way since
> they can't we used at the same time easily.
So the testing plugin system should allow us to automatically launch
roscore, webserver, websockets and selenium?

You can make a Python nosetest and implement it to do pretty much anything you want under the hood, including launching other processes and blocking on results of other test systems. The main work would be bridging x-unit like test results out of the single nosetest and into the test results without modification. But that's just a work around, so if you find a common need to support this kind of testing, then you could implement a custom test, which is really just an exercise in CMake and then provide that functionality through an additional api, like `org_add_webtest`. If it works well we could promote it to an ament package and maybe even install it by default. But I think it's much more concurrent (you don't have to wait on us to review it and iterate with you) and lower risk to start with an external package to support something like this and move on from there.

 

Thanks!
Bill

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

[Bill Morris]

On 07/08/2015 04:12 PM, Dirk Thomas wrote:
> On Wed, Jul 8, 2015 at 12:55 PM, Bill Morris <bi...@neautomation.com> wrote:
>
>> On 07/08/2015 02:04 PM, Dirk Thomas wrote:
>>> On Tue, Jul 7, 2015 at 2:00 PM, Bill Morris <bi...@neautomation.com>
>> wrote:
>>
>> # Use Case: interactive testing
>>>> What might be needed to support Hardware-in-the-loop testing?
>>>> Can we test GUIs? physical buttons?
>>>> Burn in testing for hardware platforms?
>>>>
>>> In ament each testing framework is integrated via a separate package.
>>> Therefore it should be straight forward to implement e.g. GUI tests using
>>> what ever framework you find suitable for your application.
>>>
>>> While catkin only provides nosetests and gtest integration it is still
>>> possible to use external test frameworks.
>>> It would just be a bit more effort to register them as test within
>> catkin.
>> Does it make sense to have a flag to separate blocking and non-blocking
>> tests
>> ament test --non-interactive package_name
>> This would allow tests that expect user input to be skipped for
>> continuous integration testing.
>>
> I don't understand why a unit test would be interactive in the first place?

Hardware-in-the-loop testing may require a human to push a button or a
servo to rotate an IMU
A burn-in test may require the hardware to run multiple times to ensure
that is works before
shipping the robot to a customer. So it may be days before it returns,
does this break anything unexpected?

> CTest provides various ways to specify which tests to run.
> But I don't think that CTest allows you at all to interact with the tests.
>
>
>>> # Use Case: documentation testing
>>>> If a developer writes documentation in jekyll
>>>> 'ament test_docs' could automatically launch jekyll serve --watch
>>>> --baseurl='' && firefox --new-tab http://localhost:4000/
>>> Currently we haven't made any decision or prototypes how to handle
>>> documentation (some early draft can be found here:
>>>
>> https://github.com/ros2/design/blob/gh-pages/articles/80_ros_documentation_system.md
>>> ).
>>> But I would certainly envision a command like "ament build_docs" to work
>>> across multiple different documentation tools.
>>> It should probably not invoke firefox for you but let the user know where
>>> the documentation has been generated ;-)
>> I think what I'm trying to suggest here is that 'ament build_docs' and
>> 'ament test_docs' are two separate things.
>> Also firefox -> xdg-open, maybe.
>>
> May be I still don't understand your goal.
> What does "test_docs" actually test for?

It provides a consistent interface that allows a developer to test that
their documentation changes look correct without having to remember the
incantations necessary to start the jekyll server, figure out where the
docs were written to or whatever.

[Bill Morris]

# Use Case: Remote testing / Multi-master

It there anything that would be useful to do testing in the context of multi-master / rocon

[Jack O'Quin]

On Mon, Jul 6, 2015 at 3:27 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

Given that Jack O'Quinn was suprised this week to hear about ament, and Jon Bohren in this thread did not know about how this relates to catkin_tools, I wonder whether OSRF made sufficient effort to include the community from the start.

My lack of insight into the ROS 2 design is due to the small amount of time I've spent looking at it (until recently). It does not reflect on OSRF work or documentation.  

--

 joq

[Bill Morris]

On 07/08/2015 02:04 PM, Dirk Thomas wrote:

> On Tue, Jul 7, 2015 at 2:00 PM, Bill Morris <bi...@neautomation.com> wrote:
>> # Use Case: Embedded system builds / installs
>> 'ament build' on a rosserial package to build arduino code
>> using 'ament install' to write firmware to the hardware without the
>> stupid Arduino GUI
> CMake (and therefore catkin as well as ament) allows to run arbitrary logic
> during the install step.
> I think that would be sufficient if you want to write the firmware in that
> step.

Ok, supposing I write some CMake macros to handle arduino builds and
firmware installs for rosserial based packages.
How can these macros get shared with other developers?
Will development of ament extensions also be federated or do we have to
submit patches to ament?

[Dirk Thomas]

A CMake macro / function is not different to any other code.

You create a package and put you CMake stuff in there (usually in the cmake subfolder).

And then you export it using the CFG_EXTRAS option in catkin_package().

A simple example would be catkin_simple:

* https://github.com/catkin/catkin_simple/blob/0e62848b12da76c8cc58a1add42b4f894d1ac21e/CMakeLists.txt#L8

* https://github.com/catkin/catkin_simple/blob/0e62848b12da76c8cc58a1add42b4f894d1ac21e/cmake/catkin_simple-extras.cmake.em

(If your package provides multiple macros / functions you might want to define them in separate files though.)

- Dirk

[Thibault Kruse]

I have another ROS1-packages-in-ament question.

Would it be possible to be extend the catkin cmake API in such a way that a catkin package in a catwkin workspace remains undisturbed, but in an amend workspace has the symlinked install capability.

As an example (not necessarily the best solution), based on my limited understanding that one of the problems is the placement of the relevant macro inside the CMakelists.txt:

```

catkin_package(
  CATKIN_DEPENDS message_runtime std_msgs
  CONFIG_EXTRAS "foo-extras.cmake"
  DEPENDS Boost
)

add_executable(...)

catkin2_symlink_install()

```

where the macro catkin2_symlink_install() is a no-op in catkin, but does similar things to amend_package() within an ament workspace.

This would not win any code beauty contest, but would allow code in ROS1 to remain as is (undisturbed) and conveniently working with ROS1 packages in ament workspaces.

[Dirk Thomas]

On Mon, Jul 13, 2015 at 1:45 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

I have another ROS1-packages-in-ament question.

Would it be possible to be extend the catkin cmake API in such a way that a catkin package in a catwkin workspace remains undisturbed, but in an amend workspace has the symlinked install capability.

I am not sure if supporting the symlinked install option is crucial in this case.

First of all it would be necessary to actually be able to build a catkin based package with the ament tools.

Depending on how that is achieved the symlinked install could happen very early in the existing catkin functions (e.g. in `catkin_package_xml`).

Basically it is only overwriting the default `install()` function.

As an example (not necessarily the best solution), based on my limited understanding that one of the problems is the placement of the relevant macro inside the CMakelists.txt:

```

catkin_package(
  CATKIN_DEPENDS message_runtime std_msgs
  CONFIG_EXTRAS "foo-extras.cmake"
  DEPENDS Boost
)

add_executable(...)

catkin2_symlink_install()

A function like `catkin2_finalize` would be necessary to actually invoke `ament_package` after all targets and is not related to the symlinked install.

But in general building a catkin-based package with the ament tool will require some more consideration and is not "solved" by supporting symlinked installs (which is imo the easiest feature to achieve).

- Dirk

[William Woodall]

In the same vein of thought (getting catkin to work within an ament workspace), I think something like Jonathan's "symlinked devel space", which he's proposing for catkin build, would be appropriate. Basically we would install catkin packages to a folder in that package's build space and then symbolically link the files from there to the target install destination. I think this would be good for two reasons:

- We could symlink from the devel space and source space to emulate the symlinked install.

- We could selectively symlink files, avoiding the setup files and other files which may collide or otherwise are inappropriate for installation into an ament install space.

The down side is that it probably won't be very fast.

There are still some issues surrounding the use of setup files between the two systems that would need to be figured out, but I'm confident that those could be resolved.

Additionally we have modifications to our package.xml parser in ament_package which, among other things, defaults the build type to ament_cmake if nothing else is specified rather than to catkin. We'd have to merge these two and probably explicitly put ament_cmake as the build type in all of the ROS2 package.xml files or something like that.

Like I said before, I think there is a path forward but there are still things that need to resolved to make it work. The question is when will anyone have time to sink into the issue. We did most of the build system work almost a year ago, but right now we're focused on middleware stuff and we'll likely not spend time on it until after ROSCon and maybe even some time after that.

On Mon, Jul 13, 2015 at 1:45 AM, Thibault Kruse <tibo...@googlemail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thibault Kruse]

On Monday, July 13, 2015 at 11:14:36 PM UTC+2, William Woodall wrote:

Like I said before, I think there is a path forward but there are still things that need to resolved to make it work. The question is when will anyone have time to sink into the issue. We did most of the build system work almost a year ago, but right now we're focused on middleware stuff and we'll likely not spend time on it until after ROSCon and maybe even some time after that.

Currently there is no strong need to make anything work (though I would still strongly suggest somehow porting ROS1 message generators into the ROS2 world and thus avoiding the duplication of message definitions across packages for bridging).

The current matter is for OSRF to communicate the chosen path for the future. That means if OSRF has a changed perspective on some ament-related issues after the current discussion, you could write new decisions down somewhere (in the ament / ros2 docs). Or document where OSRF is yet very unsure about decisions and will very likely revisit when the time comes.

I guess for now the relevant places would be:
https://github.com/ros2/ros_core_documentation/blob/master/doc/source/index.rst
and
http://design.ros2.org/articles/ament.html