Conversation
|
what would be the recommended build invocation now? the same as before but without the |
|
Yes, same as before. To use |
|
ok so without modification to the packaging job build invocations, do I understand correctly that this should allow the failing linux packaging job to run again without having the RAM increased? (I have launched http://ci.ros2.org/view/packaging/job/packaging_linux/501/ to check) |
|
AFAI understand it should actually be decreased compare to the previous
runs without the messages we enabled recently
…On Tue, Dec 6, 2016 at 2:46 PM, dhood ***@***.***> wrote:
ok so without modification to the packaging job build invocations, do I
understand correctly that this should allow the failing linux packaging
job <http://ci.ros2.org/view/packaging/job/packaging_linux/500/console>
to run again without having the RAM increased? (I have launched
http://ci.ros2.org/view/packaging/job/packaging_linux/501/ to check)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#44 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGVh8B70aDSfze5Hl_9LXiA5G8a8l_3Aks5rFeWpgaJpZM4LFsGx>
.
|
|
Yes, the packaging job passes with this patch. |
|
|
||
| std::shared_ptr<FactoryInterface> | ||
| get_factory(const std::string & ros1_type_name, const std::string & ros2_type_name) | ||
| get_factory_@(ros2_package_name)(const std::string & ros1_type_name, const std::string & ros2_type_name) |
There was a problem hiding this comment.
I get the feeling that this might also one day suffer from the non-1:1 mapping situation mentioned here (I am not 100% sure). either way I don't think it should block it.
There was a problem hiding this comment.
The non-1:1 problem doesn't apply here. This patch only groups all specialization by their ROS 2 package name. Every mapping always has exactly one ROS 2 package associated with it. If there are multiple mapping for the same type within the package that is being handled within the generated conditions which compare the passed string values.
Fixes #40. Connect to #40.
I propose to merge this PR first. I am happy to look into updating the existing PRs since this one moves quite some code around.