Skip to content
This repository was archived by the owner on May 31, 2025. It is now read-only.

Enable Trusty support for lunar-devel#1236

Merged
dirk-thomas merged 4 commits intoros:lunar-develfrom
locusrobotics:enable-old-ubuntu
Nov 17, 2017
Merged

Enable Trusty support for lunar-devel#1236
dirk-thomas merged 4 commits intoros:lunar-develfrom
locusrobotics:enable-old-ubuntu

Conversation

@ayrton04
Copy link
Copy Markdown
Contributor

This PR enables us to build the latest version of ros_comm on Trusty. The LZ4 API changed at version 1.7.2 to use LZ4_compress_default instead of LZ4_compress_limitedOutput, and this PR defines a version-dependent macro that allows us to build with the older LZ4 API.

@dirk-thomas
Copy link
Copy Markdown
Member

This commit seems to have added the new function LZ4_compress_default. According to the commit the first tag it is part of is r130. That tag identifies itself as version 1.7.0 which is also the same for the earlier tag r129. I also don't see a tag for version 1.7.2 which you mentioned. What information did you base the choice on?

Beside that ROS Lunar is specifically not targeting Ubuntu Trusty. Many other packages will have similar problems. Therefore I am not convinced that it makes sense to add this patch to the code base.

@ayrton04
Copy link
Copy Markdown
Contributor Author

There wasn't a tag; the version number was incremented in a commit without getting tagged. My original commit (and the version we had been using internally) was set to use version 1.7.0 as the version in which the switch occurred, but in verifying that I had the version number right before PR-ing it, I managed to make it wrong.

Given that Lunar is not targeting Trusty and that this check would ensure the behavior doesn't change for anyone running on supported platforms, is there danger in merging (once I correct the version number, that is)? We have been using this version of ros_comm internally for a while with no problems, though we admittedly use updated versions of many package that were not originally intended for Trusty.

In any case, it's not a big deal if you'd prefer not to merge it. We're just trying to minimize our differences with upstream.

@dirk-thomas
Copy link
Copy Markdown
Member

is there danger in merging (once I correct the version number, that is)?

That is why I am a little hesitant. Basically every change has the potential for regressions. With the recent Kinetic backports we noticed that sadly multiple times that is probably why I am currently extra cautious.

I guess this can be merged since it shouldn't effect the targeted platforms. One thing to change beside the exact version is the name of the macro. COMPRESS_DEFAULT seems too generic imo. Can you please rename it to LZ4_COMPRESS_DEFAULT.

@mikepurvis
Copy link
Copy Markdown
Member

I'm supportive of merging. Obviously we can't support old platforms forever, but when it's such a small change, it's certainly nice to provide that migration path forward.

I know at Clearpath we were using the Kinetic+ versions of many core repos long before we actually switched our underlying OS to 16.04, and it sure was nice being able to stage the rollout like that.

@ayrton04
Copy link
Copy Markdown
Contributor Author

Sounds good. Will fix.

// Note that the later versions of LZ4 contain a different macro that does this version math, but the earlier
// versions lack it.
#define LZ4_VERSION (LZ4_VERSION_MAJOR * 100 * 100 + LZ4_VERSION_MINOR * 100 + LZ4_VERSION_RELEASE)
#if LZ4_VERSION >= 10700
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

That tag identifies itself as version 1.7.0 which is also the same for the earlier tag r129.

As mentioned before since an older release (r129) identifies itself with this version too I don't think it can be used for the check.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Oh, apologies, I misunderstood your issue. I will get the first post-1.7.0 tag, which I believe is 1.7.3.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

r131 identifies as 1.7.1. Would that be more precise?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yes, it would.

@dirk-thomas
Copy link
Copy Markdown
Member

Thank you for iterating on this.

@dirk-thomas dirk-thomas merged commit 35d1e0d into ros:lunar-devel Nov 17, 2017
@ayrton04 ayrton04 deleted the enable-old-ubuntu branch November 17, 2017 14:02
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants