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.
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."ament_cmake_core
|package| contains a lot of the CMake infrastructure which makes it possible to cleanly pass information between |packages| using conventional interfaces.'catkin
because it has most of the advantages with few of the complications or drawbacks.'ament_cmake_core
is the |package| resource indexing which is a way for |packages| to indicate that they contain a resource of some type.'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.
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
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.
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.
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.
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:
* 'Theament_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" fromcatkin
because it has most of the advantages with few of the complications or drawbacks.'
* 'Another feature provided byament_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
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.
From http://www.thefreedictionary.com/amentam·ent (ăm′ənt, ā′mənt) n. See catkin.ament (æˈmɛnt; ˈeɪmənt) n. (Psychiatry) a mentally deficient personCan't make this stuff up.
git
ɡit/
nounBRITISHinformalan unpleasant or contemptible person.
--
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.
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.
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.
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
--
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
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.
Now that people are talking about it, I propose [...]
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.
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.
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
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'.
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?
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.
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?
My concerns include the burden on developers to support two build
systems or two code bases.
> +1 for having a conference call / hangout on a regular basis, please
> propose a date and time as well as an agenda.
--
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.
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: 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?
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.
> 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?
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.
--
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.
> 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
--
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.
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.
```catkin_package(CATKIN_DEPENDS message_runtime std_msgsCONFIG_EXTRAS "foo-extras.cmake"DEPENDS Boost)add_executable(...)
catkin2_symlink_install()
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_msgsCONFIG_EXTRAS "foo-extras.cmake"DEPENDS Boost)add_executable(...)
catkin2_symlink_install()
--
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.
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.