Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix support for assimp 5.1.0 #817

Merged
merged 5 commits into from
Jan 24, 2022
Merged

Fix support for assimp 5.1.0 #817

merged 5 commits into from
Jan 24, 2022

Conversation

traversaro
Copy link
Contributor

@traversaro traversaro commented Jan 7, 2022

assimp 5.1.0 has a relativly working CMake support (after the upstream work in assimp/assimp#3455) and assimp::assimp imported target, so if assimp > 5.0.1 we can avoid to used the custom logic necessary for old assimp versions.

Fix ros2/ros2#1222 .

@traversaro
Copy link
Contributor Author

Note that Ubuntu Jammy uses assimp 5.1.4 (see https://launchpad.net/ubuntu/jammy/+source/assimp), so this PR could be useful for ros2/ros2#1221 .

Copy link
Contributor

@clalancette clalancette left a comment

Choose a reason for hiding this comment

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

Nice, thanks for this! Confirmed that I can build on macOS Monterey after this PR. I'm going to run CI on our normal stuff, plus Jammy just to ensure that this works there as well.

@clalancette
Copy link
Contributor

CI:

  • Linux Build Status
  • Linux-aarch64 Build Status
  • Windows Build Status
  • Linux Jammy Build Status

@traversaro
Copy link
Contributor Author

Sorry @clalancette, I had missed your reply.

The Jammy CI is failing with the error:

15:24:35 CMake Error at /usr/lib/x86_64-linux-gnu/cmake/draco/draco-config.cmake:41 (add_library):
15:24:35   add_library cannot create imported target "draco::draco" because another
15:24:35   target with the same name already exists.
15:24:35 Call Stack (most recent call first):
15:24:35   /usr/lib/x86_64-linux-gnu/cmake/assimp-5.1/assimpConfig.cmake:37 (find_package)
15:24:35   /home/jenkins-agent/workspace/ci_linux/ws/install/rviz_assimp_vendor/share/rviz_assimp_vendor/cmake/rviz_assimp_vendor-extras.cmake:15 (find_package)
15:24:35   /home/jenkins-agent/workspace/ci_linux/ws/install/rviz_assimp_vendor/share/rviz_assimp_vendor/cmake/rviz_assimp_vendorConfig.cmake:41 (include)
15:24:35   CMakeLists.txt:33 (find_package)

I had a similar error (i.e. related to draco) on a Debian Testing CI (that I set up exactly to early catch problem that will arise in future Ubuntu distro) in robotology/robotology-superbuild#974 . I think there are several problem related to the fact that the Debian packaging of assimp is tryng to patch assimp to make sure that the Debian's draco instead of the vendored one. However, the situation was in rapid evolution, so probably it could make sense to try to re-run Jammy CI.

@clalancette
Copy link
Contributor

so probably it could make sense to try to re-run Jammy CI.

I did that (without this patch) here: https://ci.ros2.org/job/ci_linux/15962/console . Looks like it is still broken, so we may have to dig into the Debian/Ubuntu Jammy situation a bit more.

@traversaro
Copy link
Contributor Author

I have another build on latest Jammy that works fine, so I guess it is some kind of error related to repeated CMake calls, i.e.:

find_package(assimp)
find_package(assimp)

I will quickly check on a Jammy instance.

@traversaro
Copy link
Contributor Author

Bingo:

cmake_minimum_required(VERSION 3.15)

project(assimptest)

find_package(assimp REQUIRED)
find_package(assimp REQUIRED)

fails with:

CMake Error at /usr/lib/x86_64-linux-gnu/cmake/draco/draco-config.cmake:41 (add_library):
  add_library cannot create imported target "draco::draco" because another
  target with the same name already exists.
Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/assimp-5.1/assimpConfig.cmake:37 (find_package)
  CMakeLists.txt:6 (find_package)

while:

cmake_minimum_required(VERSION 3.15)

project(assimptest)

find_package(assimp REQUIRED)
# find_package(assimp REQUIRED)

works fine.

@traversaro
Copy link
Contributor Author

traversaro commented Jan 19, 2022

An even simpler example to reproduce the problem is:

cmake_minimum_required(VERSION 3.16)
project(assimptest)
find_package(draco REQUIRED)
find_package(draco REQUIRED)

(i.e. the issue is in libdraco-dev, not in libassimp-dev)

@traversaro
Copy link
Contributor Author

traversaro commented Jan 19, 2022

I opened a upstream (Ubuntu) bug in https://bugs.launchpad.net/ubuntu/+source/draco/+bug/1958432 . As the problem originates in Debian, it would have been more appropriate to report in Debian, but to be completly honest I am not an expert use of reportbug and all the machinery required to report bugs in Debian. On the other hand, the upstream mantainer is @roehling, and he seems to be interested in ROS, so perhaps it could be interested in the problem and the suggested solution even if not reported via Debian's bug tracker.

@roehling
Copy link
Contributor

I just uploaded a fixed version of draco to Debian unstable, and it should find its way to Ubuntu within a couple of days, since Ubuntu 22.04 is still syncing with Debian.

@traversaro: I am not notified about new bugs which are filed in Launchpad, which is the main reason why it is better to report Debian related bugs in Debian. Mentioning me on Github does help, though. ;)

@traversaro
Copy link
Contributor Author

I just uploaded a fixed version of draco to Debian unstable, and it should find its way to Ubuntu within a couple of days, since Ubuntu 22.04 is still syncing with Debian.

Great, thanks!

@traversaro: I am not notified about new bugs which are filed in Launchpad, which is the main reason why it is better to report Debian related bugs in Debian. Mentioning me on Github does help, though. ;)

Yes, I suspected that. On the other hand, I am a bit afraid afraid of doing something wrong when submitting Debian bugs as I need to manually compose mails, without the possibility of validating (as far as I know) the message before I send it.

@clalancette
Copy link
Contributor

clalancette commented Jan 20, 2022

So it looks like the new libdraco-dev has propagated through Debian into Jammy (I see 1.5.0+dfsg-5 available in Jammy now). Thanks @roehling !

Unfortunately, I think the changes in this PR aren't sufficient. With the newest libdraco-dev installed, I can now successfully build rviz_rendering and rviz_assimp_vendor, but trying to link downstream packages (like rviz_rendering_tests) fails:

CMake Error at ros2_ws/install/ament_cmake_gmock/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:69 (add_executable):
  Target "mesh_loader_test_target" links to target "assimp::assimp" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ros2_ws/install/ament_cmake_gmock/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:52 (_ament_add_gmock)
  CMakeLists.txt:57 (ament_add_gmock)

@traversaro Would you mind taking a look?

@traversaro
Copy link
Contributor Author

@traversaro Would you mind taking a look?

I added 2e47d07 that should fix the issue.

@clalancette
Copy link
Contributor

Thanks for giving it a try again. Unfortunately, I still have exactly the same issue on Jammy, even with the updated code. Any other thoughts on what it might be?

@traversaro
Copy link
Contributor Author

Thanks for giving it a try again. Unfortunately, I still have exactly the same issue on Jammy, even with the updated code. Any other thoughts on what it might be?

Interesting. Do you have a log to check? Otherwise I will try to setup an instance on which to debug the problem, but it may take longer on my side.

@clalancette
Copy link
Contributor

clalancette commented Jan 21, 2022

Ah, I may have found it. I think rviz_rendering is missing an export of rviz_assimp_vendor. Will do a bit more testing locally and push a patch shortly if it works.

@clalancette
Copy link
Contributor

clalancette commented Jan 21, 2022

All right, at least locally what I just pushed seems to fix the problem for me. I'll run another round of CI to check on it:

  • Linux Build Status
  • Linux-aarch64 Build Status
  • Windows Build Status
  • Linux Jammy Build Status

@Ace314159
Copy link
Contributor

Ah, I may have found it. I think rviz_rendering is missing an export of rviz_assimp_vendor. Will do a bit more testing locally and push a patch shortly if it works.

I'm not sure if the issue was fixed by this, but I had to export rviz_assimp_vendor in rviz_common. I didn't need to export it in rviz_rendering, but that could just be due to environment differences.

@clalancette
Copy link
Contributor

I'm not sure if the issue was fixed by this, but I had to export rviz_assimp_vendor in rviz_common. I didn't need to export it in rviz_rendering, but that could just be due to environment differences.

Hm, interesting. It actually looks like rviz_common doesn't directly depend on assimp at all, so it actually should not have a dependency there at all. It should just inherit it from rviz_rendering. I'll try that out locally here and see what happens.

Separately, the Linux Jammy job is still failing with the draco::draco problem. Presumably the underlying Jammy Dockerfile is out-of-date, since with local packages here it works fine. I'm still somewhat reluctant to merge without this, but if it continues for a lot longer we can consider it.

@traversaro
Copy link
Contributor Author

I'm still somewhat reluctant to merge without this, but if it continues for a lot longer we can consider it.

No problem for me to just wait for the Dockerfile update to merge this.

It doesn't directly depend on it, so it should not include it.

Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
@clalancette
Copy link
Contributor

Hm, interesting. It actually looks like rviz_common doesn't directly depend on assimp at all, so it actually should not have a dependency there at all. It should just inherit it from rviz_rendering. I'll try that out locally here and see what happens.

Yeah, that worked fine for me locally, so 0d26798 removes it.

@clalancette
Copy link
Contributor

I re-ran the job on Jammy, and it looks like the Docker images were updated over the weekend. So the build passed (there are a bunch of warnings on Jammy, but those are completely unrelated to this PR). So I'm going to go ahead and merge this; thanks for the fix @traversaro !

@clalancette clalancette merged commit 3e12c99 into ros2:ros2 Jan 24, 2022
@traversaro
Copy link
Contributor Author

Thanks for merging @clalancette !

@Ace314159
Copy link
Contributor

@clalancette Can this be backported to the galactic and foxy branches? Is there an automated tool to do this? If not, I can make the PR.

@ros-discourse
Copy link

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-2-tsc-meeting-january-20th-2022/23986/1

@clalancette
Copy link
Contributor

@clalancette Can this be backported to the galactic and foxy branches?

I'm somewhat hesitant to do it, just because this changes enough of how things are done that it could cause problems in Foxy and Galactic.

Are you more interested in the support for assimp 5.1.0, or in the part of this PR where we did the export of rviz_assimp_vendor properly?

@Ace314159
Copy link
Contributor

@clalancette I'm interested in the support for assimp 5.1.0, which I don't think will cause any issues in Foxy and Galactic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

library_abs set to Not FOUND on Mac Big Sur intel
5 participants