search

AutonomyLab / libcreate

C++ library for interfacing with the iRobot Create 1 and 2.
BSD 3-Clause "New" or "Revised" License
47 stars 76 forks source link

libcreate failing to build on resource constraints platforms #34

Closed mikaelarguedas closed 6 years ago

mikaelarguedas commented 6 years ago

Hi @jacobperron and libcreate maintainers.

libcreate has been released in Lunar and has been failing to build on arm since then: http://build.ros.org/view/Lbin_dsv8_dSv8/job/Lbin_dsv8_dSv8__libcreate__debian_stretch_arm64__binary

It looks like this package is exhausting the memory of the host by cloning googletest. Can you clarify why you need to clone gtest in the build process?

If this is not a requirement, we strongly recommend unsing the system version of gtest (by adding a dependency on gtest in your package.xml) and avoid performing downloads during the CMake phase.

Cheers!

jacobperron commented 6 years ago

Fix upstream Jenkins build for Debian Strecth arm64

jacobperron commented 6 years ago

@mikaelarguedas Thanks. I wasn't sure why it was failing.

My thought was that cloning gtest was more portable and doesn't require the user to have it pre-installed in the context of non-ROS systems. I integrated gtest this way following their README on integrating into an existing CMake project.

To resolve this issue, I can instead make testing optional by only building tests if gtest is installed. At the same time I can add gtest to the package.xml.

I'm not sure the best way for installing gtest in a non-ROS system. I found an old post that suggests the following:

# Install gtest headers
sudo apt-get install libgtest-dev

# Build
cd /usr/src/gtest
sudo cmake CMakeLists.txt
sudo make

# Copy compiled libraries to /usr/lib
sudo cp *.a /usr/lib

This seems to work for me. I can incorporate those instructions into the CI and README and make the necessary changes to CMakeLists.txt unless someone has a better idea.

jacobperron commented 6 years ago

Looks like the issue is resolved with 1.6.1

mikaelarguedas commented 6 years ago

thanks @jacobperron ! all green on the farm now!

I think it's generally recommended that each project builds it's own verison of the gtest library and doesnt install it to not impact other packages. Though gtest can be built using the source and headers provided by the system package which allows to not need to download and duplicate the sources in every package.